Re: [dnsext] draft-mohan-dns-query-xml-00.txt

[Mohan Parthasarathy <[e-mail]>]

<snip>
>
>> > asks for www.example.com/DO=1/CD=1.  The validating recurive server
>> > get a answer from P (without DNSSEC records) and passes it on.
>> > Validation fails.  The stub resolver asks for www.example.com/DO=1/CD=
>> =1
>> > again and it gets the same answer (from thout DNSSEC records) the
>> > CD=1 cache and again fails.  Rince, lather, repeat.
>> >
>> > Now if the stub asks for www.example.com/DO=1/CD=0 the validating
>> > resolver will reject any answers from P and only pass on answers
>> > from D (with DNSSEC record) which should then validate.
>>
>> So, this is a validating resolver, sets CD=0 (ignoring what is said in
>> RFC 4035), gets the "proper" responses, ignores the AD bit,
>> validates the responses. Is this discussed in any document ?
>
> No, its not ignoring what is said in RFC 4035, CD=1 is a SHOULD
> (4.9.2).  In this case I'm recommending that defaulting to CD=0 as
> the default is what should be done and falling back to CD=1 in
> SERVFAIL is what should be done.  AD should be ignored by a validating
> stub resolver.  It's for stubs that trust the resolver, not stubs
> that validate.
>
> As for whether this is documented anywhere, apart from the archive
> of this list and dns/dnssec lists I doubt it.  I've definitely
> mentioned this before.  Mike St John's discussion of CD/DO setting
> is similar in nature if I'm remembering it correctly.
>
> Remember when RFC 4035 was written there was very little experience
> with validating stub resolvers.  There still isn't much but defaulting
> to CD=1 is clearly wrong.  Making stub validating resolvers work
> well may still require more work or what we have may be "good
> enough".
>
Why can't the recursive server fetch the "proper" response when it
sees DOK=1/CD=1 ? It knows that a validating resolver is asking for
DNSSEC records to validate itself. If it does not get from the first
server, it can ask the next server and get it. Why should the behavior
be different for CD=0/1 ? As long as DOK=1, it should do it.

>> > Now if the recursive server doesn't validate or it validates as
>> > insecure you are left with first senario hoping that you are getting
>> > answers from the DNSSEC aware authoritative server.
>> >
>> > What would help would be a EDNS option to send to the recursive
>> > server the closest trust anchor(s) and current time so that it can
>> > validate responses in a consistant manner to the stub resolver.
>>
>> This seems complex to me. Perhaps, the operational document should say
>> that a dnssec signed zone should be served only by dnssec aware
>> authoritative servers. If there is still an operational error, the
>> validating resolver should just give up. For example, if i set
>> DO=1/CD=1 and there are no RRSIGS, then abort and declare insecure.
>
> Except you can't do that most of the time because there could be a
> zone cut that makes that name insecure.
>
You should get a NSEC/NSEC3 in that case, right ?

-mohan

> Mark
>
>> -mohan
>>
>> > Mark
>> >
>> >> If there was spoofing or other problems, it can find out itself.
>> >> It is much easier to set CD=1 always.
>> >>
>> >> -mohan
>> > --
>> > Mark Andrews, ISC
>> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> > PHONE: [phone]   =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@is=
>> c.org
>> >
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: [phone]                 INTERNET: [e-mail]
>