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

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Mark Andrews writes:
> 
> In message <[e-mail]>, Joe Abley writ
> es
> :
> >
> > On 20 Aug 2014, at 17:48, Mark Andrews <[e-mail]> 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: [phone]                 INTERNET: [e-mail]