> On 12 Jul 2018, at 18:55, Warren Kumari <war...@kumari.net> wrote: > > On Thu, Jun 21, 2018 at 4:31 PM Hugo Salgado-Hernández <hsalg...@nic.cl> > 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. > > i *seem* to remember something happening with .de a few years back -- > IIRC, slaves did a zone transfer, ran out of disk and truncated the > file, and so only had a partial zone file to serve - something like > 2/3ds of the .de zone "disappeared". A zone checksum would allow the > nameserver to know that they do not have a full zone file.
https://www.denic.de/en/whats-new/press-releases/article/partial-disturbance-of-the-dns-service-for-de-domains/ > > My memory is hazy, because I would have expected the AXFR to fail and > the nameserver to just continue using the old zone. Perhaps there was > some other transfer mechanism and it involves restaring the > nameserver? I'm sure someone must remember more detail on this event. > > W > >> >> Hugo >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
