Re: [dnsext] New Version Notification for draft-barton-clone-dns-labels-fun-profit-00

[Nicholas Weaver <[e-mail]>]

On Mar 7, 2011, at 5:56 AM, Doug Barton wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> As promised I've managed to squeak this draft in under the wire. As I
> say in the Foreword I expect that it will need some polishing, and if
> the group chooses to adopt the document I look forward to getting lots
> of help with that. :)

Interesting, but a couple of comments:

For the non-CLONE aware case (no EDNS0 option in query), I think instead of returning "as if" its an alias, INSTEAD it should be a CNAME or DNAME with TTL=0 with the part the authority is responsible for canonicalized.  (TTL=0 prevents the problems inherent for both CNAME and DNAME combined).  

That way, (using ASCII as an example)

cLIent.othErS.myTlD DNAME cLIent.othErS.mytld TTL=0
otERs.mYtLD CNAME otERs.mytld TTL=0

Why?  Because this way the systems underneath the authority in the hierarchy don't have any worry about the canonicalization: its precanonicalized for their viewpoint, which means if the main authority and clients have DIFFERENT notions of canonicalization, each level in the hierarchy does not have to concern itself about other levels in the hierarchy, just their own.

(Note, I don't know what final TTL the client will see, this is something that needs to be checked)




The more important configuration is probably the model of 

CARNS STUB  <----> Non-CARNS Resolver <---> CARNS Auth.

As it is far more likely that clients will upgrade (EG, as part of the browser or OS) rather than resolver authorities in many cases.  

I do not know if unknown EDNS0 options are likely to be passed from the stub to the authority through the intermediary resolver, which may instead require doing a parallel query for a CLONE RR (akin to how A and AAAA records are looked up in parallel by many hosts, rather than having a 'Support IPv6' EDNS0 option.)




The CLONE RR really needs to be a "canonicalization program", describing a set of character/word transformations that should be applied, NOT just a simple pointer.[1]  This enables CLONEs to be DNSSEC signed offline.  Otherwise, if you want DNSSEC EVEN FOR CLONE-aware clients, you need to...


Discuss online signing.  There is nothing which prevents the slaves from dynamically signing and caching the results, or dynamically querying a MASTER and caching the results (so no key distribution to the slave authorities).  The load is more than reasonable WITH caching (~100+ signatures/cluster node/second should be reasonable to accomplish, and such nodes should cost on the order of $.20/hr total cost amortized out over 3 years). 

More important, the caching can make it NOT 'single point of failure' in practice (and thus DOS resistant in practice as well), because although the canonicalization space is near exponential, the canonicalization in PRACTICE is probably much smaller [2], and that smaller space in practice could even be prefetched so online signatures are only needed in the exceptional cases of not-seen-before biZZArO canonicalizations being required..





[1]  I believe that if CLONE is just a simple pointer, it is unnecessary, because 0 TTL CNAMES and DNAMES can accomplish the same thing.  The value in a CLONE-type new RR and associated EDNS0 signaling lies in allowing it to work with the offline DNSSEC signature model.


[2]  How to determine the canonicalization space:  For a given language and canonicalization, take a large corpus of text (probably an email corpus would be the best, as this represents 'what people type in a computer'), and pass it through the canonicalization.  This gives you an estimate on how canonicalization needs to happen in practice, how well signature caching works, etc.  

EG, (although not needed for ASCII), its clear that for ASCII only a few canonicalizations are all that happen in practice, even if the input space possible is huge.  People type www.google.com, WWW.google.COM, www.Google.COM, etc, NOT wWw.goOGLe.COm.