Re: [DNSOP] IETF 102 Hackathon: prototype implementation of draft-wessels-dns-zone-digest-02
On 07/22/2018 12:12 AM, Peter van Dijk 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. That seems to argue more against such a caching policy of the resolver. They would have problems e.g. with NSEC3PARAM already. --Vladimir ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] IETF 102 Hackathon: prototype implementation of draft-wessels-dns-zone-digest-02
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/ signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] IETF 102 Hackathon: prototype implementation of draft-wessels-dns-zone-digest-02
All, On 2018-07-18 14:36, Wessels, Duane wrote: 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. Duane sent me a mail off-list and after minor tweaks on both sides it seems like the two implementations now interoperate. * 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 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? I think just adding like this is enough: "calculated by concatenating the canonical on-the-wire form, without name compression, of all RRs" * 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. 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] IETF 102 Hackathon: prototype implementation of draft-wessels-dns-zone-digest-02
On 15.7.2018 20:37, Shane Kerr 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: > > 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. 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. > 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 OT: Please create issues in dnspython Github pages, we might look into it ... > 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). -- Petr Špaček @ CZ.NIC ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
