> Mark Andrews <mailto:ma...@isc.org> > Thursday, November 27, 2014 7:22 PM >> if your master server sends you a final (matching) SOA not having >> stuffed its end of the tcp session with all the right records in >> between, or if your TCP is allowing end-to-end badness without its CRC32 >> detecting same at the tcp segment level, then you have bigger worries. > > Given named does sanity checks when apply ixfr deltas and they > actually have been known to trigger, knowing that you have a complete > zone after applying a ixfr would be a good thing. > ... > ... Whether is is TSIG or these records you are using a > cryptographic hash + a key to ensure that all the glue is correct > and you are trusting the generator of that hash and signer to be > doing the correct thing. And the key is tied back to a trust anchor > directly or indirectly.
is there some reason why an updated sig(0) is not a solution to this? > >>> As to whether you iterate or not also depends on the trust anchors >>> installed, whether the keys are RFC 5011 managed or similar. Having >>> a managed trust anchor for every zone isn't a be deal. >> adding RFC 5011 support to a non-mixed-mode (authority only) server >> would be a very big deal. so, that's an area of strong disagreement if >> we discuss it further. > > and the whole trigger for this discussion was a mixed mode server with > a local copy of the root zone. is there a specification for how mixed-mode servers will validate data they don't fetch? as in, you really are making a recommendation for zone-level validation that would then permit zone-local data to be used in forming responses to recursive queries in a mixed-mode server? i'd like to hear the details of that, because while DNSSEC talks about how to validate data you receive in queries, it does not talk about how to validate data you've received in zone transfers. i argue that it's not a trivial exercise, even if an updated sig(0) could be used to validate zone transfers. (i remember more than olafur claims to, concerning why we don't have zone-level signatures today. it's related to why glue is not signed and does not need to be signed, and it comes from security theory not dns theory.) > > As for adding RFC 5011 support for the zones it serves, a authorative > server has all the data it needs to do that as part of its normal > roll of being a authoritative server. It's only a matter or reading > what it is serving to others. i don't think this is true. rfc 5011 assumes that you're starting with a known-good TA and that you'll use this to validate subsequent changes to that TA. those starting conditions are not in effect on any authoritative-only server i have administered. -- Paul Vixie
_______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
