Subject: Re: [DNSOP] I-D Action: draft-wessels-dns-zone-digest-06.txt

From: Olli Vanhoja <[email-masked]>
Date: Fri, 17 May 2019 22:14:28 +0300

I believe this has been in a bit stall for some time. I'm finally
trying push for some real production implementations.

I have one note that I wrote when I was initially reading the draft:

- Canonical RR Form comes from RFC 4034 s. 6.2 and it doesn't require
require normalization of SPF and CAA records. RFC 6844 specifically
allows any string formatting allowed by
https://tools.ietf.org/html/rfc1035#section-5.1

Not sure if there is any real issue with this one but in theory I
guess there could be functionally equivalent records with a digest
mismatch. Maybe it's even desirable that those are not normalized,
just a note.

---

From: Joe Abley <[email-masked]>
Date: Mon, 20 May 2019 07:34:25 -0400

Hi Duane,

(Olli's message just bumped this thread up in my inbox, so it's an enormously late reply but not for me, if you see what I mean)

On 25 Mar 2019, at 17:15, Wessels, Duane <dwessels=[email-masked]> wrote:

> I'm not aware of anything that could be enabled by non-apex ZONEMD records. My preference would be to forbid non-apex ZONEMD records.
> 
> I guess my concern was just that it means implementors need to check for this and treat the RR type somewhat specially, as they do for SOA and maybe a couple other RR types.

I don't actually see any benefit to forbidding anything, and I don't know what "forbid" would mean in this instance.

I think there's a ready analogy of the former in PTR records. I can put a PTR record in a zone whose apex owner name doesn't end in "in-addr.arpa" or "ip6.arpa". It's not forbidden. It's occasionally useful, since I can put CNAMEs in the reverse tree in zones managed by other people and not have to bother them when I want to update the mapping. CNAMEs are not a good example in the case of ZONEMD, but perhaps there are other future operational tricks that might come to light that are not obvious today. In any case, putting a ZONEMD RRSet somewhere other than an apex doesn't do any harm.

As to the meaning of "forbid", if there's an implication that such a prohibition should be enforced somewhere (in zone parsers, in nameservers, in stub resolvers, somewhere) then I am against it. :camel_wagging_finger_and_shaking_head_sadly:

Maybe there's actually an operational use-case here, actually, in the case where you're removing a zone cut. Perhaps you want to preserve a low-TTL ZONEMD RRSet at the place where the zone cut was in the superset zone to accommodate zone distribution graphs that are slow (e.g. across badly-connected networks). This is a bit of a stretch and I haven't thought it through very well, but I think it's a bigger stretch to assert that there is definitively no use for this, especially if leaving the door open is free and bolting it shut is expensive.

Joe

---

From: "Wessels, Duane" <[email-masked]>
Date: Mon, 20 May 2019 22:24:47 +0000

> On May 20, 2019, at 4:34 AM, Joe Abley <[email-masked]> wrote:
> 
> Hi Duane,
> 

Thanks for the feedback, Joe.  

To me SOA is a better example than PTR.  I know some software will complain or refuse to load a zone that has a non-apex SOA, but I also expect there is software out that there accepts/allows it.  DNS seems to have a small number of other apex-only records, but I doubt they are strictly forbidden.

Personally I think a strict, rather than liberal, approach would be better, but I'm not opposed to allowing non-apex records.

Here's what the current (not-yet-published) draft now says:

2.1.  ZONEMD Location

   This specification utilizes ZONEMD RRs located at the zone apex.
   Non-apex ZONEMD RRs are not forbidden, but have no meaning in this
   specification.

DW

---

From: "Wessels, Duane" <[email-masked]>
Date: Mon, 20 May 2019 22:26:28 +0000

> On May 17, 2019, at 12:14 PM, Olli Vanhoja <[email-masked]> wrote:
> 

Hi Olli,

Can you expand on this?  I'm not sure that I follow.  

ZONEMD doesn't operate on presentation format of RRs.  It only operates on canonical wire format.  Are you saying that some RRs can have different valid wire formats?  That would surprise me since DNSSEC signatures are also based on that format.

DW

---

From: "Wessels, Duane" <[email-masked]>
Date: Mon, 20 May 2019 22:35:54 +0000

> On Mar 25, 2019, at 6:53 AM, Matthew Pounsett <[email-masked]> wrote:
> 
> 
> 
> On Wed, 13 Feb 2019 at 22:56, Wessels, Duane <dwessels=[email-masked]> wrote:
> The only change to this document since -05 is to note that ZONEMD has been allocated RR type code 63 by IANA following an expert review back in December.
> 
> I haven't reviewed this for a couple of revisions, so some notes here that don't apply to the new codepoint. :) . I've tried doing some searches of the discussion history to make sure I'm not raising points already addressed, but my apologies if I've missed something.
> 
> Section 2 discussion:  I was initially ambivalent about whether multiple ZONEMD records should be allowed with different digest types.  Having gone back and re-read some of the discussion, I'm persuaded that it would be beneficial to allow multiple digest types to be used on the same zone instance.  I think we'd want to have a bunch of discussion about the details in order to keep code complexity under control, though.

Thanks Matt, this seems to be the consensus, so we'll be adding some text about how to interpret multiple ZONEMDs.

> 
> Section 3.2. discussion:  Unless there's a potential benefit to non-apex ZONEMD records that I'm not seeing, I think it makes sense to forbid them.  Was there a particular thing that could be enabled by that, which prompted the suggestion?

I'm not aware of any use for non-apex ZONEMDs.  I think it comes down to the choice to either be liberal or strict in what you accept.

> 
> In 3.4.1 would it make sense to include a sentence explaining the catch-22 that would result if the RRSIG covering the ZONEMD record were included in the digest?

Added, thanks.

> 
> In section 4, I suggest replacing all of the instances of "provably [un]signed" with "provably [in]secure".

Good catch, thanks.

> Section 5 discussion: I can't remember if I commented on this bit before or not, but just in case.. I support keeping the reserved field.  It seems to me that if we have to get a new type for an incremental-friendly version of ZONEMD that we're going to have implementation fragmentation and a migration issue.  Especially if we don't allow multiple ZONEMD records, I can imagine it being difficult to have both in the zone at once, and that it could be hard to specify what should happen if an operator wants to migrate from ZONEMD v1 to ZONEMD v2 without knowing which one the consumers of their zone support

Appreciate the feedback.

DW

---

From: Mark Andrews <[email-masked]>
Date: Tue, 21 May 2019 09:08:37 +1000

I think the worry is that some name servers may normalise the text format when loading from disk. The slave would then have a different wire format. 

Such servers are broken. Wire to text to wire should produce the same rdata bit pattern with the exception of the types which are known to be compressible. 

-- 
Mark Andrews

> On 21 May 2019, at 08:26, Wessels, Duane <dwessels=[email-masked]> wrote:
> 
>

---

From: Joe Abley <[email-masked]>
Date: Mon, 20 May 2019 19:53:17 -0400

>   Non-apex ZONEMD RRs are not forbidden, but have no meaning in this

I think that's perfect.

Joe