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/
