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

[John C Klensin]

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