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

["Wessels, Duane" <[e-mail]>]

> On Apr 4, 2018, at 4:01 AM, Shane Kerr <[e-mail]> wrote:
> 
> One issue is that the algorithm proposed requires that the recipient who
> is generating a digest has to store basically the entire zone before
> beginning the digest calculation, since it has no way to know if the
> zone will be delivered in any kind of canonical order.

Yes.  Certainly for large zones this could be an issue.  We will have to
find the right balance between complexity and efficiency here.

I think it makes the most sense to perform a verification when the zone is
loaded or received by a name server, but it could also be done in an external
process, such as named-checkzone or ldns-verify-zone.


> 
> As for specific questions in the draft:
> 
> * I think that it should be allowed for unsigned zones. If nothing else,
>  it provides the equivalent of checksum to help prevent truncations or
>  not properly updated records (missing deletions or additions).
> 
> * I don't see much benefit in multiple ZONEMD. We generally expect
>  masters & slaves to co-operate, so they should be able to find
>  software that has an algorithm that both sides support.

Yes, but master/slave transfers can already be protected with TSIG.  Perhaps
the more interesting use case is out-of-band zone distribution.

> 
> * I think the serial in ZONEMD is helpful. Doesn't it also help prevent
>  replay attacks?

You might have to convince me that it does...

> 
> * I would rather not special-case ZONEMD regarding responding. Even
>  though it is bigger than most RDATA, large responses seem like a
>  general problem. OTOH, I won't object too loudly if someone feels very
>  strongly that this should be an option.
> 
> A final possible concern is that generating a digest on a large zone
> might be computationally quite expensive. Indeed it could be used as an
> attack vector on a hosting provider by using small IXFR to cause large
> zone digests to be repeatedly calculated. Is it worth exploring the
> possibility of including multiple ZONEMD in a zone at different names,
> which digest the part of the zone up to that point? So something like:


Yes, as currently specified it probably only works well with relatively static zones.
Again, we'll have to decide where we want to be in the complexity vs efficiency tradeoff.

DW