> 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 <mailto:DNSOP@ietf.org> > https://www.ietf.org/mailman/listinfo/dnsop > <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
