dual mode

[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