Subject: [DNSOP] IETF 102 Hackathon: prototype implementation of draft-wessels-dns-zone-digest-02

From: Shane Kerr <[email-masked]>
Date: Sun, 15 Jul 2018 14:37:49 -0400

Bonjour,

I decided to implement draft-wessels-dns-zone-digest-02 at the IETF 102 
Hackathon. As expected, it is fairly straightforward. You can see the 
code on GitHub:

https://github.com/shane-kerr/ZoneDigestHackathon

It seems to work, although since I have no other implementation to 
compare against I can't be sure that the digest values are in any way 
correct.

In proper hackathon style there are no tests. Bugs surely abound. If you 
use it in production please keep a fire extinguisher handy.

I found the draft to be clear and fairly complete, although I have a few 
suggestions:

* It might be worth mentioning that names are expected to be
   uncompressed. It's kind of obvious, but it might trick up some
   implementations.

* The TTL of the ZONEMD record has to come from somewhere. It can either
   come from configuration or pulled from somewhere else (I used the TTL
   of the SOA record). This should be documented.

* It might be worthwhile giving some recommendations or even
   requirements about what to do with failures. For example, something
   like "secondary servers who receive a zone that fails a digest
   validation SHOULD NOT serve the zone".

* Having some example zones and the expected digest values would be very
   useful for implementers.

As a final note, while it is awesome to have dnspython available to do 
such projects, dnspython is not a joy to work with. I had a brief 
discussion with some other hackathon attendees and it seems to be a 
shared experience. I was encouraged to look at the getdns Python API, 
which has apparently had quite some thought in making it Pythonic. I may 
look at that or making a pure Python version of it at some point in the 
future. If you have other suggestions for DNS in Python feel free to 
contact me off-list (since this isn't a software development list).

Cheers,

--
Shane

---

From: Petr Špaček <[email-masked]>
Date: Tue, 17 Jul 2018 13:34:40 +0200

> * Having some example zones and the expected digest values would be very

First of all thanks for your work! It is useful to test drafts this way,
it obviously uncovered some definiencies.

In any case, I believe that real problem is not the spec or
toy-implementation, the real complexity is still hidden and will unveil
itself once we attempt an efficient implementation inside a
high-performace DNS server.

> discussion with some other hackathon attendees and it seems to be a

OT: Please create issues in dnspython Github pages, we might look into
it ...

-- 
Petr Špaček  @  CZ.NIC

---

From: "Wessels, Duane" <[email-masked]>
Date: Wed, 18 Jul 2018 18:36:40 +0000

> On Jul 15, 2018, at 11:37 AM, Shane Kerr <[email-masked]> wrote:
> 
> Bonjour,
> 
> I decided to implement draft-wessels-dns-zone-digest-02 at the IETF 102 Hackathon. As expected, it is fairly straightforward. You can see the code on GitHub:
> 

Thanks Shane!

> It seems to work, although since I have no other implementation to compare against I can't be sure that the digest values are in any way correct.

My own implementation, alluded to in the draft, is here:

https://github.com/verisign/draft-dns-zone-digest/tree/master/impl

I have a few test cases in the Tests directory.

> 
> In proper hackathon style there are no tests. Bugs surely abound. If you use it in production please keep a fire extinguisher handy.
> 
> I found the draft to be clear and fairly complete, although I have a few suggestions:
> 

The draft says "It also adopts DNSSEC's canonical RR form (Section 6.2 of [RFC4034])" in one place and "calculated by concatenating the canonical on-the-wire form of all RRs" later.  I wouldn't object to being more explicit.  Do you want to propose some text or shall I take a stab?

>  of the SOA record). This should be documented.

I also used the SOA TTL in my implementation.  I can make that a recommendation in the draft.

>  validation SHOULD NOT serve the zone".

Happy to add something like that.

> * Having some example zones and the expected digest values would be very

Agreed.  I would like to have some examples as an appendix in the document.

DW

---

From: Shane Kerr <[email-masked]>
Date: Thu, 19 Jul 2018 10:26:13 -0400

All,

> I have a few test cases in the Tests directory.

Duane sent me a mail off-list and after minor tweaks on both sides it 
seems like the two implementations now interoperate.

> The draft says "It also adopts DNSSEC's canonical RR form (Section 6.2 of [RFC4034])" in one place and "calculated by concatenating the canonical on-the-wire form of all RRs" later.  I wouldn't obj…

I think just adding like this is enough:

"calculated by concatenating the canonical on-the-wire form, without 
name compression, of all RRs"

> I also used the SOA TTL in my implementation.  I can make that a recommendation in the draft.

Someone pointed out to me that since ZONEMD is meta-data we don't really 
expect it to be queried normally, and a TTL of 0 is a reasonable default.

My own feeling is that I would like ZONEMD to be a "normal" record 
outside of zone generation, so assume that it can and will be queried 
just like any other record. (This is also an open question in the 
current draft, IIRC.)

In the current draft we already have to look at the SOA to get the 
serial, so using the TTL is straightforward. If we remove serial from 
the ZONEMD then TTL from the SOA might be less obvious, but I think it 
will still be the best default.

Cheers,

--
Shane

---

From: "Peter van Dijk" <[email-masked]>
Date: Sun, 22 Jul 2018 00:12:12 +0200

Hello,

On 19 Jul 2018, at 16:26, Shane Kerr wrote:

> Someone pointed out to me that since ZONEMD is meta-data we don't really expect it to be queried normally, and a TTL of 0 is a reasonable default.

I recall a story about some resolver (Google Public DNS perhaps?) applying the lowest TTL per name, instead of per RRset. This, if true, would argue against 0.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

---

From: Vladimír Čunát <[email-masked]>
Date: Mon, 23 Jul 2018 13:24:29 +0200

> I recall a story about some resolver (Google Public DNS perhaps?) applying the lowest TTL per name, instead of per RRset. This, if true, would argue against 0.

That seems to argue more against such a caching policy of the resolver. 
They would have problems e.g. with NSEC3PARAM already.

--Vladimir