Re: [idn] Re: 7 bits forever!

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

Erik Nordmark wrote:

> Instead of a brand new proposal I'd be more interested in finding out
> how you can address the DNSSEC issues I pointed out in
> draft-hall-dm-idns-00.txt

The DNSSEC problem is hard, for multiple reasons. Some zones can sign
dynamically, some can't. The state of the delegation parent also affects
the negotiation. The solution to this problem will be multi-faceted. The
OPT-IN work can probably help solve part of it. Small changes to DNSSEC
may be required to solve other parts of it. One of the changes I am
planning to make (and would encourage substitutes to use) is EDNS RCODE
responses in OPT RRs, such that each transaction in the query operation
has a distinct code for fallback purposes, and this will help with part of
the problem too.

Essentially, one RCODE value could be used whenever fallback processing
has occurred (the cache/server/whoever tells the client: "I am falling
back to legacy mode"), and this will reset the query timer on the client.
This means that queries can fallback as neeeded multiple times, without
triggering the client's query timer. This would also mean that DNSSEC can
be preserved if the final data has been signed in UTF-8 form, even if the
immediate parent is only ACE.

Another RCODE value could be used for "cannot fallback" and couldd occur
for any (valid) reason. Implementations would have to be prohibited from
refusing to fallback because ~"I don't want to", but they could refuse to
do it if they are under heavy load, if a configuration error prevents it,
or if DNSSEC prevents it, such as a delegation NS RR only being available
in ACE, and it is signed. In such an event, the resolver would report
"cannot fallback" and the original client would have to reissue the query
in ACE in order for the query to succeed.

Anyway, there are several angles to pursue here. I'm not really sure that
any of this can be done until DNSSEC stabilizes some. Frankly, I'd rather
somebody else try to solve this problem.

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