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. None of this, AFAICT, helps us at all with the 1024/2048 choice. A -- Andrew Sullivan a...@anvilwalrusden.com _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
