In message <54885a5d-2afa-4d37-9b83-2229082d7...@virtualized.org>, David Conrad writes: > > Hi, > > On Aug 20, 2014, at 6:21 PM, Andrew Sullivan <a...@anvilwalrusden.com> > 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: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
