In message <20140820235118.e952b1d1b...@rock.dv.isc.org>, Mark Andrews writes: > > In message <e4ad7d21-995c-46b1-813e-70ca0919f...@hopcount.ca>, Joe Abley writ > es > : > > > > On 20 Aug 2014, at 17:48, Mark Andrews <ma...@isc.org> wrote: > > > > > You will give answers that validate as bogus in the stub resolver. > > > > This seems to be the crux of our differing world views. > > > > > A validating stub resolver > > > > Validating stub resolvers? > > > > In my own personal taxonomy a stub resolver doesn't validate. Validation > > signalling is available from a validating resolver (e.g. using the AD > > bit, of which I am not a fan), and that resolver (validating or not) is > > where I was suggesting the locally-relevant data would be served. > > > > (Note that I'm not saying that my own personal taxonomy is of any use to > > anybody apart from me; I'm just putting it out there by way of > > explanation of the current forehead wrinkles. I continue to think it > > would be good to have a common understanding of these overloaded terms.)
DNSSEC responses were, from day one, designed to be validated in the application/client/resolver library. For the discussion about 100.64/10 reverse in which of these places is immaterial Getting validation into recursive servers was a first step and it also protected non-DNSSEC aware clients from a class of attacks. It was also one of the easiest piece to update which was why it was promoted first. 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. The next step was/is getting validation performed in the clients. There are several validating stub resolver libraries from different vendors. ISC has shipped one as part of BIND for over a decade. Yes, you can link libdns into a application and have it validate answers you receive from a recursive server before handing them to the application. named is the main application that uses this library but it is not the only one. The newer releases have simpler calling points and setup. Validation is starting to move into the application with inititatives like DANE. AD is only useful as a signal that a answer is secure when you can trust the path between the recursive server and the application *and* you can trust the configuration of the recursive server to be setting AD appropriately. See all the caveats about trusting AD in the RFC's where it is mentioned. 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
