In message <20140402025854.gb90...@mx1.yitter.info>, Andrew Sullivan writes: > On Wed, Apr 02, 2014 at 09:39:43AM +1100, Mark Andrews wrote: > > > Always set CD=1 is also bad advice. Stub resolvers need to send > > both CD=1 and CD=0 queries and should default to CD=0. CD=1 should > > be left to the case where they get a SERVFAIL result to the CD=0 > > to handle the case where the recursive server's clock is broken or > > it has a bad trust anchor. > > It strikes me that this argument has been hashed pretty well to death > before, but just to refresh everyone's memory, there are several > different strategies one can use here: > > 1. CD=1 all the time, and if you get into trouble consider the > failure a feature. Mark's argument (which has some merit) is that > this is too strong, because if the stub gets the bogus answer, it > can't "fall through" and pick up another one that might be good. > > 2. CD=1 mostly, and if you get a failure try falling back to CD=0. > Maybe with CD=0, the recursive server will find you something that > validates in order to get you on your way. > > 3. The opposite of (2), defauling to CD=0 (what Mark advocates). > > 4. Give up on stubs and be a full service resolver all the time. > > For 1-3, people may have a peek at RFC 6840, especially section 5.9 > and Appendix B.
And I pointed out before RFC 6840 was published that the appendix was incomplete in its analysis. You didn't want to reopen the analysis, as it was a long discussion to get what was there, and the wg, I suspect, was too fried to care one way or the other. As a result we have to deal with the fallout now. > None of this, AFAICT, helps us at all with the 1024/2048 choice. Actually it does as it shows that recursive servers need to validate. If you are looking at workload you have to factor that into the analysis. 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
