In message <20140821012100.gc2...@mx1.yitter.info>, 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 > a...@anvilwalrusden.com > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- 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
