Re: dnssec: resolver - application communication

[David Fort <david.fort@irisa.fr>]

Miek Gieben wrote:

>[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?
>  
>
We play a lot with DNSSEC here and it appears that it is quite easy to 
have non working
configurations. So here, SERVFAILs aren't so unusual.

>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.
>
>  
>
For me it should be option 1. When using configuration 1, applications 
can still behave as if
they were in configurations 2.

-- 
Fort David, Projet IDsA
IRISA-INRIA, Campus de Beaulieu, 35042 Rennes cedex, France
Tél: +33 (0) 2 99 84 71 33