[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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

Home | Date list | Subject list