Internationalized Domain Name (idn)

Re: Re: 7 bits forever!

> That's what me and Edmon has been talking about all the time, we need ACE as
> transition and move to UTF8 as smooth as we can. So an internet draft for
> this transition is needed, we will be posting a draft about this soon.

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 and how you would be different than the techniques
in that draft.

   Erik

headers

Eric A. Hall | 3 Apr 20:25

Re: Re: 7 bits forever!

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

(Continue reading)

headers

Edmon Chung | 4 Apr 01:22

Re: Re: 7 bits forever!


----- Original Message -----
From: "Eric A. Hall" <ehall <at> 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

(Continue reading)

headers

Eric A. Hall | 4 Apr 02:37

Re: Re: 7 bits forever!

[ietf removed from cc list]

Edmon Chung wrote:

> 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!

There are multiple "clients" in the process. The application client
shouldn't have to mess with fallback unless there is a really good reason
for it (a cache being unable to convert an ACE-only DNSSEC answer being
one of them). In those cases, an EDNS RCODE is a workable way to tell the
application that the original query needs to be reissued in ACE form if it
wants an answer.

For other situations, such as circumnavigating old servers which only
support ACE-ified i18n domain names, letting a resolving/caching server do
the convolutions makes some sense, since those boxes can cache the
canonical UCS answer and referral data, which will help future queries.

I guess what I'm saying is that forcing the application client to pick up
resolver and caching duties doesn't make a lot of sense to me personally
since it will preclude the benefits of caching data.

--

-- 
Eric A. Hall                                        http://www.ehsco.com/

(Continue reading)

headers

Edmon Chung | 4 Apr 16:06

Re: Re: 7 bits forever!


----- Original Message -----
From: "Eric A. Hall" <ehall <at> ehsco.com>
> There are multiple "clients" in the process. The application client
> shouldn't have to mess with fallback unless there is a really good reason
> for it (a cache being unable to convert an ACE-only DNSSEC answer being
> one of them). In those cases, an EDNS RCODE is a workable way to tell the
> application that the original query needs to be reissued in ACE form if it
> wants an answer.

I meant the application client.  That is right.

> For other situations, such as circumnavigating old servers which only
> support ACE-ified i18n domain names, letting a resolving/caching server do
> the convolutions makes some sense, since those boxes can cache the
> canonical UCS answer and referral data, which will help future queries.

However, there is advantage for not having the nameservers do any ACEing.
It should make the phasing out of ACE faster.

> I guess what I'm saying is that forcing the application client to pick up
> resolver and caching duties doesn't make a lot of sense to me personally
> since it will preclude the benefits of caching data.

But we are anticipating that this be a "transitional" phase only.
Eventually, IDN/EDNS will be common place.

Edmon

(Continue reading)

headers

Eric A. Hall | 4 Apr 17:45

Re: Re: 7 bits forever!

Edmon Chung wrote:
> 
> ----- Original Message -----
> From: "Eric A. Hall" <ehall <at> ehsco.com>

> > For other situations, such as circumnavigating old servers which only
> > support ACE-ified i18n domain names, letting a resolving/caching
> > server do the convolutions makes some sense, since those boxes can
> > cache the canonical UCS answer and referral data, which will help
> > future queries.
> 
> However, there is advantage for not having the nameservers do any
> ACEing. It should make the phasing out of ACE faster.

What is your reasoning for this?

Also, would you have the client perform all recovery operations, such as
retransmitting the original UTF-8 query once a problematic delegation
server had been gotten around? These will still result in caches being
updated but it will essentially result in each application implementing
its own full-service resolver.

> But we are anticipating that this be a "transitional" phase only.
> Eventually, IDN/EDNS will be common place.

I agree that the end-result will be an EDNS-majority, but I think it will
take so long that it is better designed as a coexistence than transition.
In the end, we want it to be transitional, but for the next 10+ years it
will be coexistence, IMO.

(Continue reading)

headers

Edmon Chung | 4 Apr 19:03

Re: Re: 7 bits forever!

----- Original Message -----
From: "Eric A. Hall" <ehall <at> ehsco.com>
> Edmon Chung wrote:
> > However, there is advantage for not having the nameservers do any
> > ACEing. It should make the phasing out of ACE faster.
>
> What is your reasoning for this?
>
> Also, would you have the client perform all recovery operations, such as
> retransmitting the original UTF-8 query once a problematic delegation
> server had been gotten around? These will still result in caches being
> updated but it will essentially result in each application implementing
> its own full-service resolver.

The client app probably wont do any proactive recovery, but when the user
initiates another query, it would try th UTF8 again, and fallback only if
the request fails again.  In the meantime, the cache server will have ready
the ACE respond already.  The cache resolver still performs its usual job,
not the client app.  The client app is only responsible for the fallback
mechanism.

The reason really for this proposal is to make sure that DNSSEC works within
the architecture.  If the resolver does any conversion, DNSSEC would have to
be changed.  But if the client falls back, the origination of the request as
well as the authoritative response is not changed throughout the resolution
path.

Edmon

(Continue reading)

headers

Eric A. Hall | 4 Apr 19:29

Re: Re: 7 bits forever!


Edmon Chung wrote:

> The client app probably wont do any proactive recovery, but when the
> user initiates another query, it would try th UTF8 again, and fallback
> only if the request fails again.  In the meantime, the cache server
> will have ready the ACE respond already.  The cache resolver still
> performs its usual job, not the client app.  The client app is only
> responsible for the fallback mechanism.

All of that is true for both models. The difference is that if the cache
handles the non-fatal cases, then the application doesn't have to deal
with minor burps, and instead only has to deal with fatal failures.

> The reason really for this proposal is to make sure that DNSSEC works
> within the architecture.  If the resolver does any conversion, DNSSEC
> would have to be changed. But if the client falls back, the origination
> of the request as well as the authoritative response is not changed
> throughout the resolution path.

This is also true for both models.

--

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