So what if it is not feasible for COM and similarly sized zones? At the moment we have one zone where we need a zone signature so that the zone contents can be loaded into every recursive server.
The question we should be asking is "Is SIG(AXFR) a good fit for the root zone?” not whether is is a good mechanism for all zones because quite frankly there are very few zones that you would want loaded into all recursive servers. “.”, “arpa”, “in-addr.arpa” and “ip6.arpa” would be about it. Does anyone else have any others? Any zone would necessarily be small. Mark > On 9 Jul 2018, at 10:28 am, Olafur Gudmundsson <o...@ogud.com> wrote: > > > >> On Jun 22, 2018, at 6:58 AM, Petr Špaček <petr.spa...@nic.cz> wrote: >> >> On 21.6.2018 22:31, Hugo Salgado-Hernández wrote: >>> On 22:09 21/06, Shane Kerr wrote: >>>>> Dne 1.6.2018 v 12:51 Shane Kerr napsal(a): >>>>> >>>>> Hmm, can you share some details about your experience? >>>>> Did you find out when the data corruption took place? >>>>> a) network transfer >>>>> b) implementation bugs (e.g. incorrectly received IXFR) >>>>> c) on disk >>>>> d) some other option? >>>> >>>> I don't know. I have seen incorrectly transferred zone files both in >>>> BIND >>>> and NSD slaves. IIRC our solution was to include sentinel records in >>>> the >>>> zone files to spot problems, take the node out of service, and force a >>>> re-transfer. This of course won't work if you are slaving zones that >>>> you do >>>> not control, and it doesn't prevent a small window of time when the >>>> servers >>>> are operating with broken zones. TSIG was being used. >>> >>> We have also seen broken transfers between secondaries. Our solution >>> is to dump the zone after transfer, calculate a hash and compare. We >>> would benefit from having a ZONEMD record inside the zone. >> >> If the zone got broken during TSIG-secured transfer then it was not most >> probably not caused by network problem because TSIG would have caught that. >> >> Honestly I do not think it is worth the effort because all the >> complexity does not help to prevent implementation bugs, I would say it >> even increases probability of a bug! >> >> What is left is bug on auth and/or slave sides and in that case there is >> no guarantee that >> a) master did not compute ZONEMD from already broken data >> b) slave verification of ZONEMD actually works >> >> >> If we wanted to catch problems with implementation we need something >> which is outside of the DNS stack we are attempting to check, be is >> simple checksum or some fancier crypto. >> >> I can easily imagine OPENPGPKEY RR located at _zonefile.apex.example >> node and an utility which would extract OPENPGPKEY RR from the zone file >> and verify that the zone file signature (either detached or in .gpg >> file) can be verified using that key (+ add DNSSEC into the mix if you >> wish). >> >> -- >> Petr Špaček @ CZ.NIC >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > > > > +1 > I spent lots of time earlier this century along with Johan Ihren trying to > figure out how to > secure the transfer of a particular zone (the root) to any resolver. > The only sane way is to not transfer the zone over AXFR as any intermediary > can mess with the zone contents mostly in the case of “glue” records, > thus transferring the zone over HTTPS or RSYNC with a PGP signature over the > zone file is the only viable solution going forward. > > > Historical background: SIG(AXFR) was rejected because it required putting the > zone into canonical order and calculating the signature, > in the case of dynamic update this is a real expensive operation, thus we got > rid of it. > > Olafur > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- 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
