To:
Matt Larson <mlarson@verisign.com>
Cc:
Michael Richardson <mcr@sandelman.ottawa.on.ca>, dnssec@cafax.se
From:
Miek Gieben <miekg@atoom.net>
Date:
Wed, 12 May 2004 12:03:40 +0200
Content-Disposition:
inline
In-Reply-To:
<20040511154445.GR31336@chinook.corppc.vrsn.com>
Mail-Followup-To:
Matt Larson <mlarson@verisign.com>,Michael Richardson <mcr@sandelman.ottawa.on.ca>, dnssec@cafax.se
Sender:
owner-dnssec@cafax.se
User-Agent:
Vim/Mutt/Linux
Subject:
Re: dnssec: resolver - application communication
[On 11 May, @17:44, Matt wrote in "Re: dnssec: resolver - applica ..."] > have been in the "AD bit, SERVFAIL sucks" camp for some time and a > voice crying for something else. I think some additional RCODEs (or I tend to agree that having only SERVFAIL to signal "something" is not enough. But I also want to ask the following: aren't we optimizing the least used code-path? How often does one get SERVFAIL of a respected site (known to have it's DNS in order)? I don't get it that often. Why can a secure aware application/resolver that receives a SERVFAIL not _always_ follow up with a requery + CD=1? And what do we expect the lecacy application/resolver to do when it get a NOTVAL error code? So two options can be pursued: 1) Either we add a NOTVAL error code to signal that "yes, we've got the data, and no it didn't verify". So that the thing at the other end might requery with CD=1 if it requires so. 2) Or we say SERVFAIL is enough, and if you get SERVFAIL the thing at the other end might requery with CD=1 if it requires so. regards, Miek