Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

[Mark Andrews <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 
> 
>> On Jun 22, 2018, at 6:58 AM, Petr Špaček <[e-mail]> 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
>> [e-mail]
>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]              INTERNET: [e-mail]