Re: [DNSOP] draft-ietf-dnsop-rfc6598-rfc6303-01

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, David Conrad writes:
>
> Hi,
>
> On Aug 20, 2014, at 6:21 PM, Andrew Sullivan <[e-mail]>
> wrote:
>
> > On Thu, Aug 21, 2014 at 10:52:46AM +1000, Mark Andrews wrote:
> >> It was also a required step as you can't reliably
> >> validate in the client unless the recursive server has filtered out
> >> the spoofed answers.
> >
> > If I understand you correctly, this devolves to the claim that the
> > validating client has to do its own recursion, lest it trut something
> > without basis.  Is that what you're suggesting?  I'm not opposed, but
> > let us be clear.
>
> I'm getting confused.
>
> What's the difference between the "validating client" and a full
> validating resolver?  Just the lack of cache?
>
> Tanks,
> -drc

A validating application (client it too overloaded) will use a stub
resolver, which set DO=1 and CD=0 (yes, this is not what the RFC
6840 says) on the applications behalf, to get answers from a caching
recursive server, which it will then validate.  If the validation
fails it can try any other recursive servers.  If they fail it can
fallback to making iterative queries or just accept the failure.
The recovery will be more easily done if it is built into the
resolver library as it knows which recursive servers it has queried.
It should also retry the queries in case there were spoofed responses.

The basic difference is where it directs its queries to.  Whether
there is or isn't a cache is a implementation detail.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]