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

Jaap Akkerhuis jaap at NLnetLabs.nl
Fri Feb 27 19:54:39 CET 2009


Andrew, 

some comments in line.
     
    > 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.  

Note that a person will be querying for een RRSG unless you are debugging
a problem. People will likely want to query for the hypothethical RNAME
metadata. And then we are quickly back where we started.

And of course, 
    
    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.

there is always that.

	jaap


More information about the Idna-update mailing list