Subject: [dnsext] DNSCurve name server selection

From: Matthew Dempsky <[email-masked]>
Date: Fri, 23 Apr 2010 11:13:23 -0700

For the DNSCurve I-D, I limited wording about how a cache should
behave to that it MAY use DNSCurve when querying a server with a
DNSCurve public key, but no advise is offered on when it should or how
it should behave when some-but-not-all of a zone's name servers
support DNSCurve.  In particular, I can see a number of possible cache
behaviors such as:

 A. Existing query strategy, except caches send queries using DNSCurve
to authoritative servers that have public keys.

 B. Same as A, but the cache sorts its list of name servers to put all
DNSCurve-enabled authoritative servers before non-DNSCurve-enabled
servers.

 C. Caches only contact DNSCurve-enabled authoritative servers and
only use DNSCurve queries.

 D. Numerous variants on the above (e.g., one or two iterations of
only contacting DNSCurve servers before falling back to sending plain
DNS queries to all servers).

I'd like to see C be a valid strategy, as it's the only one that can
guarantee no MITM exposure, but I can see practical reasons why caches
might prefer to use other strategies.

Any thoughts?

---

From: Edward Lewis <[email-masked]>
Date: Mon, 26 Apr 2010 15:55:15 -0400

At 11:13 -0700 4/23/10, Matthew Dempsky wrote:
>  A.
>  B. Same as A, but the cache sorts its list of name servers ...
>  C. Caches only contact DNSCurve-enabled servers...
>  D.
>Any thoughts?

First I'll say that it is fine to put recommendations in the draft, 
but until now, no one has put firm requirements on a resolver's 
actions.  "Local policy" should always be allowed.

Second, I'd recommend specifying simple strategies, but not to simple 
as to be random.  I.e., D is over complicated and A is a waste of 
time to explain.

Perhaps you can describe B & C and mention that a "general purpose 
implementation" might want to allow a user to choose.

The reason for C is that the operator is really interested in 
applying this security.  The reason for B is resiliency, sometimes, 
it's better to get anything as opposed to holding out for the 
provably safe answer.

We've learned some lessons in deriving DNSSEC, A6 and bit labels. 
It's gotta be plum simple to work.  Fancy policies means fancy 
specification languages are needed - and we aren't good parser 
writers.  If you require a DNS element to think much, it can be tied 
up in knots easily.  Ask anyone that really understands bit labels to 
explain it up on a chalkboard and you are guaranteed to see someone 
to get the example wrong.  If you can't do it by hand, a DNS server 
won't be able to handle it.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Wouldn't it be nice if all of the definitions of equivalence were the same?