> On Jul 8, 2018, at 9:35 PM, Mark Andrews <ma...@isc.org> wrote: > > 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
So the followup question is Should we burden the Auth Server implementations with this calculation if the usage case if 4 zones ? or is this better handled by external tools ? DNS Camel says ? Olafur >> 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
