On Aug 20, 2014, at 9:21 PM, Andrew Sullivan <a...@anvilwalrusden.com> wrote: > 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.
I will confess to being deeply puzzled by this conversation, which probably means that I've missed something. What Mark appears to be saying above is that if a recursive server has been given bogus answers to feed to the stub, and the stub tries to validate them, the validation will fail. This is mom and apple pie. The cure for this is not for the stub to do its own recursion, if by that you mean it should bypass the caching resolver. The cure is not to send it stuff that won't validate. The only way to do this is to make delegations for these zones that are insecure, as is proposed in the document. I do not understand how this can be controversial, and Joe's explanation didn't help me. Of course we should assume that stubs validate, even if that is not the current state of the art. What am I missing? _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
