Re: dnssec: resolver - application communication

[Mike StJohns <Mike.StJohns@nominum.com>]

At 09:23 AM 5/10/2004, Miek Gieben wrote:

>This essentially leads to the case whereby every application will do it's own
>validation. When you are validating DNSSEC data, it is very handy to directly
>talk to the authoritative server. Thus this, in turn, will lead to increased
>pounding on the authoritative servers on the Internet. Most notably the secure
>entry points, which will be root in some future. In short: this will most
>probably break the DNS.

This is an unwarranted assumption.   A DNSSEC aware stub resolver should 
still be talking to its local caching/recursive server.  Its just the 
information it gets from that server needs to differ from what it gets 
currently if the server implemented DNSSEC (e.g. not SERVFAIL, NXDOMAIN, 
etc).   For a SASR (security aware stub resolver) to be able to verify a 
piece of information, it needs the RRSet for that information, the 
applicable RRSIG, and a chain of DNSKEY and DS records back to some trust 
anchor.  The recursive resolver needs to be able to provide those along 
with the other parts of the response.  Note that because of a possible 
difference in trust anchors between the SASR and recursive resolver 
(recursive has .MIL, stub has "." for example), the recursive resolver 
needs to provide ALL the keys that may make up a chain as far back as it 
can go, or expect the SASR will ask for them explicitly later.

>The other solution is to do what we do now: SERVFAIL when data is bogus, but
>then the app. doesn't know the security status. Our new thinking at labs 
>is now that
>this is not that bad. DNSSEC is created to _detect_ attacks, when giving back
>SERVFAIL we indicate an attack - I don't care what kind of attack. I only need
>to know there is one going on right now. Then I can fire up my dig++ and look
>what is really happening.
>
>So basically it comes down to answering the question:
>
>       * Must applications know the security status of DNS answers? *
>
>(last week we thought: yes, now we (labs) think no)

Why do you think this way?  (Not arguing one way or the other, but prefer 
to have supported arguments when trying to understand a point.)  You seem 
to be saying that the only utility of DNSSEC is to detect attacks, but 
"never explain by conspiracy that which can be explained by 
incompetence"  suggests that DNSSEC failures are going to be related more 
to errors in the data set than actual attacks.

Mike