[I changed the subject line] > > tell me again how this concersion would work with DNSSEC. > > As a placeholder, I have an RCODE for "conversion failed" which tells the > original application that the data was found but that it cannot be > converted. The application then has to reissue the query which the cache > can answer with whatever data it has received as part of the fallback > process. If the original query was provided in UTF-8 and the UTF-8 data is > provided with DNNSEC there is no need for this of course. > > I am hoping that the DNSSEC people can help make this more efficient, but > this addresses the prima concern.
Yes, the examples you provided make the RRset go end-to-end so the signatures would work. 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. 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. 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). It would make sense to consult with folks on namedroppers for this. Erik
