[idn] Re: dual mode

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

on 6/11/2002 1:39 PM Erik Nordmark said the following:

> Presumably the benefits of this scheme is that that caching resolver
> can cache both the FALLBACKFAIL RCODE for the <IDN> QNAME and the
> actual RRsets for the <ACE-IDN> QNAME, so that other queries
> immediately get the FALLBACKFAIL error and retry using the ACE form.

The primary benefit is that DNSSEC works at all. For subsequent queries,
the application has explicitly stated interest in UTF-8 data, so it needs
to be told that the data isn't available, and that the data that *is*
available can't be converted. The resolver probably won't enter into any
decisions that the application makes as to what to do next.

I'm sure the DNSSEC brains can find a dozen ways to streamline and
simplify this. This is only presented to make it work.

> I'm not an expert in DNS (I haven't even read RFC 2308) so I don't know
> what the issues is with negative caching in general, thus I can't tell
> if this scheme introduces new issues.

Not this scheme in particular, although there are negative caching issues
in general. A "negative cache" works by getting a negative response and
some supporting data from a server (such as an SOA for the zone). In the
case of a NOTIMPL response to an EDNS question, however, there is no
supporting information (the server couldn't read the question section, so
it can't provide an SOA). There are simple ways to deal with the problem,
such as using TTL information from the resulting STD13 query (the NS
and/or SOA RRs in the authority section). For the most part, the existing
negative caching knowledge work without any difficulies, and only a couple
of new landmines. Some of these have resulted from changes in the fallback
model itself (DM-IDNS-00 did not have servers performing fallback more
than once on the first query, but this is necessary change to support
DNSSEC, and has introduced other issues).

> Also, it isn't clear to me if the caching resolver needs to ensure that
> the negative cache for the <IDN> and the RRsets for the <ACE-IDN>
> expire in concert (or there are some other constraints on how they
> expire).

Domain names in general are supposed to be stored as UCS strings, not as
views of a string. This model allows the cache to construct a view based
on the incoming message format, without having to track 2x the data. In
that design, all expirations occur whenever the base entry expires. For
the most part, the well-known and understood negative caching rules can
apply without any additional effort, although there are some peculiar
issues (as with NOTIMPL described above).

The biggest difficulties are in managing the RR data.

> It would make sense to consult with folks on namedroppers for this.

Yeah, DM-IDNS-01 will be brought to them for discussion. I need to find
out what kind of architectural ramifications will be imposed by the IDNA
spec before I can finish writing this up, however. Contrary to certain
commentary, the current rules wrt nameprep being mandatory impose multiple
considerations on the design, as well as on the future use of RRs within
DNS in general.

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