Re: [idn] Re: 7 bits forever!

["Edmon Chung" <edmon@neteka.com>]

----- Original Message -----
From: "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.
>

These are good ideas and should work well. But for a quicker and dirtier
way, we could simply continue to let the client do all the heavy lifting, as
is mandated by IDNA anyway, by failing the request anytime it hits a node
that does not support UTF8 form and force the client to fallback to ACE
resolution.  This way, the servers dont even need to know how to do ACE
conversions at all!

Edmon