Petr,
Petr Špaček:
Dne 1.6.2018 v 12:51 Shane Kerr napsal(a):
Wessels, Duane:
On May 25, 2018, at 11:33 AM, 神明達哉 <jin...@wide.ad.jp> wrote:
At Wed, 23 May 2018 15:32:11 +0000,
"Weinberg, Matt" <mweinberg=40verisign....@dmarc.ietf.org> wrote:
We’ve posted a new version of draft-wessels-dns-zone-digest. Of note,
this -01 version includes the following changes:
[...]
We plan to ask for time on the dnsop agenda in Montreal. Your
feedback
is welcome and appreciated.
I've read the draft. I have a few high level comments and specific
feedback on the draft content:
- It was not really clear exactly what kind of problem this digest
tries to solve, especially given that the primarily intended usage
is for the root zone, which is DNSSEC-signed with NSEC.
Thanks you for the feedback. We will write a clearer problem statement
in the introduction for the next version.
As I mentioned, I have seen zones broken during transfer in production,
and having a standard way to check for this seems reasonable.
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.
Another scenario is when you are not using TSIG at all. For my own zones
I don't bother because I don't have any confidential data in them and I
prefer the operational simplicity of not having to set up keys
everywhere. But this may also be the case for things like the root zone
where the zone publishers explicitly want people to be able to transfer
the zones without authentication.
I wonder if this proposal is worth the complexity ... If we wanted plain
checksum we could use TSIG with built-in key (all zeroes or so) and to
get checksum for the network part with negligible implementation
complexity. (TSIG trick is Mukund's idea, not mine
I kind of like this approach. It doesn't provide any help for
stand-alone zone files, but in general there is no interoperability
requirement there and a simple sha256sum file is probably good enough.
Instead of zone digest maybe it makes sense to document Mukund's
approach in an informational (?) RFC? It still doesn't solve problems
where something on the receiving side doesn't work due to an
implementation bug, but I'm basically okay with the recommendation being
"don't run software that doesn't work". 😉
Cheers,
--
Shane
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
