summary: no worries, this isn't what i thought it was. details below. > Warren Kumari <mailto:war...@kumari.net> > Thursday, November 27, 2014 2:20 PM > > This allows a slave (or anyone else who wants to validate a zone, e.g > a master loading from disk) to know that they have a full and correct > zone. This covers things like accidental zone truncation (which has > bitten some folk),
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. > zone file corruption, etc. if someone hands me a zone somehow (e.g > AXFR) and asks me to serve it I'd like a way to make sure it hasn't > been accidentally (or intentionally) changed. for a dnssec signed zone the only way to do that is to zone-walk and validate. belt-and-suspenders isn't a good model for axfr/ixfr, because complexity, and because the zone signature would have to be incrementally maleable and so not one-way or crypto-authentic, because update. > I'm assuming I'd want my name server software to refuse to load the > zone and try retransfer, throw an error, or similar. > The signature could be (and the way I'd envisioned it) DNSSEC, so up > to a TA, or a manually configured key specific to the zone. if this is proposed and adopted, my discussion input will be along the lines of "no authority server can every be required to query for anything as part of its operations". just letting you know where "DNSSEC ... signature" leads to. importantly, you're envisioning this as a new way to fail, but not a new criteria for success. that is, this new signature mechanism is to you a reason to reject an AXFR or IXFR, which would then lead to zone timeout and SERVFAIL unless corrected. that's not a problem. i was worried that this would be used in some way to permit/deny zone data to be used by a mixed-mode server in response to RD=1 queries. that would be a larger kettle of different fish. furthermore: > Mark Andrews > Thursday, November 27, 2014 2:45 PM > > Just having a cryptographically strong zone self consistancy check > is a big win with IXFR. If that fails you AXFR the zone and try > again. if you're trying to make a case for public key TSIG, i'd agree with you, and say, SIG(0) [RFC 2931]. i'd support an rfc 2931-bis effort, as a reviewer and as a contributor. > For the root zone you don't need a iterative validator as you would > have the root as a trust anchor and in general a authoritative > server needs a interative resolver for NOTIFY. if you're arguing that NOTIFY should support DNSSEC by including RRSIG(SOA), i'd agree. but right now there is no TA on root zone slaves, they never query for anything, they never validate anything, they don't speak RFC 5011. and that's a deliberate design decision, not an accident or oversight. > 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. 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