To:
dnssec@cafax.se
From:
David Blacka <davidb@verisignlabs.com>
Date:
Mon, 10 May 2004 10:41:53 -0400
Content-Disposition:
inline
In-Reply-To:
<20040510132357.GA28493@atoom.net>
Sender:
owner-dnssec@cafax.se
User-Agent:
KMail/1.6.2
Subject:
Re: dnssec: resolver - application communication
On Monday 10 May 2004 9:23 am, 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. I'm not sure I agree here. Why would validating stub resolvers (a term I'm using for the "application") wish to talk directly to the authoritative servers? > 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. You may be right in thinking that (most) applications will not care about which particular validation failure occurred, but SERVFAIL does _not_ indicate an attack. It is so overloaded that it just indicates that some sort of vaguely defined problem has occurred (e.g., a lame delegation). > 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) A better question might be: * Must (Should?) applications be able to distinguish between DNSSEC related failure and other forms of failure? -- David Blacka <davidb@verisignlabs.com> Sr. Engineer VeriSign Applied Research