Re: [idn] UTF-8 / RACE

[Keith Moore <moore@cs.utk.edu>]

> > still, I don't see any harm in having a native UTF-8 DNS query
> > interface if we can achieve the following:
> > 
> > - delegation paths for UTF-8 are the same as for ACE
> >   (queries for equivalent names go to the same servers)
> > - results of a query are consistent between the two encoding schemes
> >   (a query of one type made to a server produces equivalent results
> >   - modulo encoding - as a query of the other type)
> > - success/failure semantics are the same for the two
> >   (if a query using one encoding succeeds or fails, the same
> >   should be true for the same query using the other encoding)
> > - delay characteristics are similar for the two
> 
> This is doable with the following scenario:
> 
>  - UTF8 is only sent in new EDNS message.
> 
>  - ACE is only sent in legacy message.
> 
>  - Server returns answer data based on query message format.

that's pretty much what I imagined.  however my understanding is that many 
existing DNS caches/proxies cannot forward EDNS queries, which implies
that the ACE queries will be more reliable than the EDNS ones.

if you adopt a strategy of "try EDNS, and if that fails, try ACE"
then the EDNS queries take longer on average than the ACE ones.

it's difficult to imagine why your host library wouldn't always convert
the query to ACE format, since that would be both faster and more reliable.

> There are a few other issues here:
> 
>  - There needs to be a wide() version of gethostbyname and the
>    like so that clients can make the right calls depending on
>    their application support.

we would need this in any case, regardless of the format used
for IDN queries on the wire.

>  - Caches will not always be completely synchronized, since an
>    ACE query may arrive two hours before a UTF8 query, and the
>    data may have changed in the meantime. I don't consider
>    this to be a propblem since cache integrity is not assured
>    currently. But it may be excessively confusing to have two
>    users issue the same query and get different answers.

another good point I hadn't thought of.

Keith