Final Sigma (was: RE: Esszett, Final Sigma, ZWJ and ZWNJ)

[Patrik Fältström]

27 feb 2009 kl. 19.17 skrev John C Klensin <klensin at jck.com>:

>
>
> --On Friday, February 27, 2009 12:55 -0500 Andrew Sullivan
> <ajs at shinkuro.com> wrote:
>
>> On Fri, Feb 27, 2009 at 10:08:43AM -0500, John C Klensin wrote:
>>
>>> --On Thursday, February 26, 2009 22:03 -0800 Erik van der Poel
>>> <erikv at google.com> wrote:
>>>
>>>> Just an afterthought, but if it really is impossible to add
>>>> a new field to DNS,
>>>
>>> I should let one of the DNS experts who follow the list
>>> respond to this, but...
>>>
>>> Nothing is impossible, but this comes close.
>>
>> Well, closeish.  I can think of a way, but it certainly falls
>> afoul of the charter requirement that we not change the way
>> DNS processing works.  So that people get an idea of the
>> flavour of difficulty, however, let me say a few words about
>> it.
>>
>>> It is far more complex than this because of rules about
>>> caching, additional information, and RR set integrity, but
>>> looking data up separately for two separate RRs (if that is
>>> what you mean by "field" causes the DNS overhead for IDNs to
>>> double (probably not acceptable) and introduces race
>>> conditions and vulnerabilities to attack (certainly not
>>> acceptable if we care anything about conditions).
>>
>> Instead of having two RRTYPEs that have to be fetched
>> separately, I can imagine using an EDNS0 option that signalled
>> "I am a resolver who knows how to use this data".  In that
>> case, additional RRs could be returned along with the "plain"
>> RR (A record, for instance).  The additional RR (call it META)
>> could contain the metadata about the RNAME.  This is very
>> similar to the way one gets RRSIG RRs back with answers when
>> DNSSEC is in use.
>>
>> Now, that all sounds nice and easy, until you remember that
>> DNSSEC has been a work in progress for over 10 years, and it's
>> still not widely deployed.  This would require upgrading every
>> target system's stub resolver, and quite likely many recursive
>> resolvers around the Internet.  User experience would be
>> terribly uneven while this all got deployed.  I doubt very
>> much that it would be a productive direction to try, although
>> I can certainly imagine how to do it.
>
> Yes.  And what you didn't call out, in addition to the DNSSEC
> example, is that this way of doing it requires EDNS0 and
> requires support for both it and the additional RRs and
> structures, clear out to the endpoints (and, because of caching,
> everywhere in between).   Given the desire to support IDNs even
> for those users who are still running Windows 95 and 98 and the
> "rapid deployment" constraints of the IDNA decision decisions,
> that is pretty much a showstopper.  My "nearly impossible"
> comment applied to that deployment issue, not merely to the
> question of implementation in the DNS and selected zones.
>
> Conversely, if one can contemplate that radical a chance to the
> DNS, then it is plausible to rethink the entire IDNA model and
> start thinking about a transition to a UTF-8-native model in
> which we get rid of Punycode and all of the considerations of
> mappings to simulate server-side matching behavior.

The question about utf-8 or punycode is orthogonal to the question of  
equivalence.

If we would not had decided to use punycode with a prefix, but utf-8,  
we would never have been able to change it...

There is another problem with having parallel rr's with meta  
information and that is that so many solutions in ietf reuse  
(overload) the txt rr.

    Patrik

>  That would
> also eliminate the prefix-changing debate in favor of "no
> prefix" and would eliminate most of the transition problem
> because resolvers would ask for A-labels for "old" names and
> make EDNS (and/or different CLASS) requests for the services
> they wanted with new ones.  Of course, that wouldn't work with
> older systems or un-upgraded applications either.
>
> Anyone who is willing to accept the 10 year (minimum) that
> transition would take before we had stable IDNs should certainly
> advocate just such a solution.
>
>    john
>
>
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>