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

[Andrew Sullivan]

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.

A

-- 
Andrew Sullivan
ajs at shinkuro.com
Shinkuro, Inc.