Re: dnssec: resolver - application communication

[Miek Gieben <miekg@atoom.net>]

[On 10 May, @17:51, Mike wrote in "Re: dnssec: resolver - applica ..."]
> >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 

I'll agree it's a bit blunt :-) Maybe it is a chicken and egg
problem... see below.

> 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.

I fully agree with what you say here, but right now such a cache does
not exist, hence a application needs to bypass the current available
cache and it goes out on the Net to talk to the authoritative servers.

(it is possible to _use_ a cache and try to built the chain of trust
yourself, but this is really an exercise in "programming around the
cache", and getting the cache to do the right thing)

> >      * 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.

well, for one, it was the "problem" of applications going directly to
the authoritative servers that lead to some rethinking. Secondly I
believe that DNSSEC is here to give us detecting of attacks. So
consider the following ssh example (as also used somewhere else in
this thread):

a user connects for the first time to a remote machine. Thanks to
DNSSEC an attack is detected and a SERVFAIL is generated. Thanks to
this the user will be unable to use ssh (for this host). Mission
accomplished...

[Note: I would not be satisfied with this, so I will check with dig++,
but I do not consider myself "an average user"]

But reading the rest of the thread, and trying to respond here, it
seems that:
o SERVFAIL is too overloaded,
o We need something like the CD-bit, that will return an entire chain
  of trust, which consists of the RR's you specified above: ALL keys,
  ALL DSs, ALL RRSIGs, and the RRset,
o A library/daemon that can handle this,
o Standarization of the errors in DNSSEC.
o ....

grtz,
--Miek

--
today's fortune:
People with narrow minds usually have broad tongues.