Re: [idn] Fast nameprep vs. slow nameprep

["Eric A. Hall" <ehall@ehsco.com>]

Patrik Fältström wrote:

> I created the confusion by seeing the need that the nameprep is NOT
> done in the resolver libraries or in the DNS server,

I agree that the resolver is a bad place to do this. It seems fairly
obvious from a cursory analysis that the best place to do this is in the
application layer in front of the resolver (before gethostbyname). Any app
which calls the API should have done the necessary work before the API is
called. This also applies to DNS-specific apps like nsupdate and dig and
the rest.

However, I think that the use of ACE -- more specifically, the use of a
mechanism which favors backwards compatibility -- pretty much dictates
that the resolver has to do the work. In addition, I think it is pretty
clear that servers will have to do the work against incoming queries as
well. I don't see any way around it.

Since there are no new RRs, classes or EDNS structures to make legacy
applications and resolvers barf on new-style labels, we can pretty much
expect that there will always be some legacy applications that will try to
feed unformatted, un-prepped raw IDNs through a legacy resolver, and that
some of those resolvers will simply treat the data as raw eight-bit data.
The fact is that somebody somewhere is going to click on an IDN URL and
expect that Netscape 3 is going to work with the Windows 3.0 resolver. It
is inescapable. The real problem is that it will also happen with users of
Netscape 6 and Windows 2000, MacOS X, and every other current day
operating system.

In those cases, the un-prepped data will still enter the DNS namespace,
having never been formatted. The DNS servers will have to examine and
reject unformatted data. New DNS resolvers will end up being the first
line of defense to this problem should it emerge.

The need for this will be measured by the amount of effort required to
communicate failure back to the client. If it is a simple match->fail
sequence that uses the same NXDOMAIN errors we already have (and if it
doesn't happen a lot) then it won't be much of a problem. Conversely, if
enough users yell about not being able to resolve IDNs (even though it is
because their patch-current apps/resolvers aren't doing the work) then
there might be sufficient non-technical motivation to introduce an
intermediary solution somewhere within the DNS infrastructure, either at
the server or with patched resolvers.

In short:
  legacy apps+legacy resolvers=server labor
  legacy apps+patched resolver=resolver labor
  new apps=app labor

I'd say spec for the last scenario but implementaions need to be prepared
for all three.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/