Re: dnssec: resolver - application communication

[Russ Mundy <mundy@tislabs.com>]

Hi,

It's my belief that we simply don't know enough yet about how signed zones
will be used to determine whether or not 'applications' (for some
definition of 'applications') will care about getting a response other than
SERVFAIL.  I do believe that there will be _some_ applications that want to
get more useful information than SERVFAIL especially since it is already so
overloaded that one could argue that it's not a useful response - all you
know is the _something_ didn't work right but you have no useful
information about _what_ didn't work right.

As a minimum, I believe that we will need some applications for use in
getting signed zones fielded that can provide additional information about
'what's not working' in a newly signed zone (or one that has been signed
and functioning for a while and for some reason stops working).  Some
people might call these 'tools' or 'diagnostics' for signed zone operation
and I would not disagree but I would assert that they are also applications
that need more useful responses than SERVFAIL - your example of using dig++
to find out more is a very good illustration of one such application - I
believe that we need several more applications of this type.

On a broader basis, as more zones begin to be operated as signed zones, it
is not possible for the designers, engineers and implementers (i.e., us) to
figure out in advance how people will _actually_ use this thing that we're
about to give them.  I strongly believe that we need to explore some of the
possibilities for where and how validation of responses from signed zones
can and/or should be done.  I also believe that it's much too early to
standardizing interfaces and such but we do need to keep track of what we
learn in the exploration.  (this will be especially true if we find that it
is, in fact, a bad idea for applications to do validation - if designers
believe that something's a bad idea and they don't tell (those pesky) users
the what & why that it is a bad idea, there's a much higher likelihood that
users will just do it and not understand that it's a bad idea.)

Russ

At 3:23 PM +0200 5/10/04, Miek Gieben wrote:
>Hello,
>
>[I'm using this list to start the discussion about it, rathen than
>starting a new list (i'm on too many ML already :) )]
>
>
>At the last RIPE meeting I've given a presentation on wether an application
>needs to know the security status of answers the resolver got from a secured
>DNS.  link: http://www.nlnetlabs.nl/prespub/RIPE-48/html-miek/index.html
>This is related to:
>http://www.nlnetlabs.nl/dnssec/draft-gieben-resolver.txt
>
>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.
>
>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)
>
>grtz,
>--Miek
>
>--
>today's fortune:
>I'll show you MY telex number if you show me YOURS ...