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

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Andrew Sullivan writes:
> 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.

Even, if you 100% trust the recursive server, DNSSEC will not
reliably work through a recursive server unless that server filters
spoofed answers as a stub resolver, by definition, doesn't directly
query the authoritative sources.  You get filtered answers by sending
CD=0 queries to a validating recursive server.

This is why "always send CD=1" is bad.  The validating application
/ stub resolver needs to get answers that have been filtered.  It
can then reject spoofed last mile responses to its queries to the
recursive server.  When the last mile is from 8.8.8.8 and similar
this is important.

Yes, this does mean that validation is done in two places on good
answers.

Even if you don't trust the recursive server you can still use it
as you will validate the answers you get.  Spoofed answers from
secure zones for which you have a trust chain for will not get
though.

If the recursive server does not validate, then as long as the
recursive server sets DO=1 on its queries and is not under attack,
the stub resolver will still get the data required to validate the
answers and it will almost always succeed.  This is equivalent to
always sending CD=1 requests to a validating recursive resolver as
it then works in pass through mode when it doesn't have the answer
already cached.
 
Now if you are getting bogus answers from all the recursive servers,
you can fallback to making direct iterative queries.  This may or
may not succeed depending upon what the actual issue for the failure
is.  If you are getting SERVFAIL you can try flipping CD state on
your queries before falling back to interative queries.

Mark

> A
> -- 
> Andrew Sullivan
> [e-mail]
> 
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]