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

[Olafur Gudmundsson <[e-mail]>]

George, 

The reason I should have stated before is 
if the zone fails the check we should not tell the server to load it 

There are roughly 3 kinds of zones in based on update frequency 
— almost Never 
— On schedule 
— All the time 

Calculating the zone “digest” is only feasible in the third case when the zone is small 
i.e. imagine calculating the updated zone digest for .org (not to mention .com) every time there is an update to the zone. 
SO  if the problem statement that it only applies to the first two then you may have a case for a zone digest. 
For the record root zone falls into the second category and my private zone falls into the first one.

Olafur
PS: Also for the record I think AXFR is a horrible protocol hack. 
PPS: I almost agree with Prof Bernstein that rsync  is a better solution, from an interoperability perspective. 



> On Jul 8, 2018, at 9:02 PM, George Michaelson <[e-mail]> wrote:
> 
> So if I look at what you said, what I see is "inband, canonicalization
> is a cost we don't want to bear, to produce a signed product of whole
> of zone" and "if we accept knowledge of a PGP or other external key as
> the moment of trust, out of band, disordered but specifically testable
> as *this file* is signed by *known key* is workable.
> 
> wow. Firstly, I thought canonicalization was a given: we have
> definitions of canonical zone order for other reasons (NSEC*) don't
> we?
> 
> secondly, I absolutely (and no sarcasm implied or intended, I really
> mean it) applaud the pragmatism. If we can move to a world which
> accepts the root is a resource which can routinely be fetched out of
> band, validated out of band, and then locally bound to a DNS server,
> we've probably moved on.
> 
> in-band is great. but, sometimes, its really hard.
> 
> So how about use of a PGP key which is a payload in TXT signed over by
> the ZSK/KSK so the trust paths bind together?
> 
> fetch one DNS record +sigs, check against the TA (which has to be a
> given) and then..
> 
> -G
> 
> On Mon, Jul 9, 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
>>