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
