Subject: [DNSOP] The DNSOP WG has placed draft-salgado-dnsop-rrserial in state "Call For Adoption By WG Issued"

From: IETF Secretariat <[email-masked]>
Date: Fri, 28 May 2021 07:26:36 -0700

The DNSOP WG has placed draft-salgado-dnsop-rrserial in state
Call For Adoption By WG Issued (entered by Tim Wicinski)

The document is available at
https://datatracker.ietf.org/doc/draft-salgado-dnsop-rrserial/

---

From: "John Levine" <[email-masked]>
Date: 28 May 2021 18:30:02 -0000

>https://datatracker.ietf.org/doc/draft-salgado-dnsop-rrserial/

I have the same reservation as last time, while many authorititative
servers have meaningful zone serial numbers, a lot don't, and there's
no way to tell no answer because not authoritative from no answer because
there's no meaningful serial.

Bonus question: why is the reply a new EDNS option rather than just adding
the SOA record to the additional section?  If you do that you can add RRSIG
to show you're telling the truth.

-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Peter Thomassen <[email-masked]>
Date: Fri, 28 May 2021 21:27:10 +0200

Hi,

I like the idea of having a way to add provenance information to responses. However, as with all new proposals, I think what's needed is a careful analysis of alternative ways to achieve the same goal, then an assessment of what's the best approach (which may very well turn out to be RRSERIAL).

Some thoughts on this (some may be new, others not):

1.) multi-qtype
---------------
With the proposed extension, we get a response for one and a half queries (whatever was asked, plus a piece from the SOA record).

The same thing could be achieved with some generic multi-qtype query method. Ray wrote a draft for this a while ago: https://datatracker.ietf.org/doc/draft-bellis-dnsext-multi-qtypes/

This would facilitate
- the debugging use case,
- other use cases (as explained in Ray's draft),
- enable DNSSEC validation (if requested; note that this is regardless of whether DNSSEC is useful for the debugging use case).

If we now introduce RRSERIAL and then end up introducing multi-qtype one day, we'd have two methods for this. This would not be a desirable state (unless there is some extra advantage through RRSERIAL).

On a related note, multi-qtype would also allow you to use the same method for other kinds of debugging in the future. For example, you may want to look at the response together with a ZONEMD record, or whatever else may help you debug.

2.) NSID option
---------------
The draft says, RRSERIAL helps "recognize the origin of an answer" (supposedly when secondaries are out of sync).

There already is a way to do that, using the NSID option (RFC 5001). It works as a part of another query, so no separate query is necessary (dig +nsid ...).

The question here would be why another method for discovering the origin should be introduced.

3.) Versioning
--------------
The draft says that RRSERIAL is useful for "associating this answer with a respective zone version".

We (deSEC) ran into problems several times because we relied on the serial as a version indicator.

One of the issue was the following: when customers created a zone, made a change or two, then deleted the zone, and created it again. As we don't keep deleted states, the serial for the recreated zone started counting from its default value, and then often ended up lower or equal to the serial of the old zone last seen on secondaries. If this sequence happens quickly enough that the secondary didn't see the deletion, weird things happen.

So, using the serial as a version indicator may be misleading. That's not to say that it is not useful; my point is rather to ask whether it is wise to introduce more of it. I would expect that once it is there, automation tools will start using it, and edge cases will be forgotten.

Thinking about multi-qtype again: Ray's draft has it such that multiple qtypes can be queried for the same owner name only. That means that SOA could only be queried in an apex query. The RRSERIAL method does not have this issue, which is certainly favorable.

Cheers,
Peter

On 5/28/21 4:26 PM, IETF Secretariat wrote:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
> 

-- 
Like our community service? 💛
Please consider donating at

https://desec.io/

deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 28 May 2021 20:34:09 +0000

> to show you're telling the truth.

Because SOA does not now normally appear in the Additional section, and because the Additional section does not normally have RRSIGs. Proposing a new EDNS0 option causes much less epistemological grief than extending the semantics of the Additional section.

Having said that, I believe that a possible draft-ietf-dnsop-additional-section-as-kitchen-sink is actually a good idea. If the WG like it, "SOA of this response" and "signed SOA of this response" would certainly fit there. 

--Paul Hoffman

---

From: Peter Thomassen <[email-masked]>
Date: Fri, 28 May 2021 23:02:52 +0200

I just discovered the related thread that started in January (when I was not yet on the list) and discusses most of this. Apologies for the noise.

https://desec.io/

deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany

---

From: "libor.peltan" <[email-masked]>
Date: Sat, 29 May 2021 09:19:43 +0200

Hi,

just an idea: I don't know how important the amplification factor is. If 
it is, the proposed EDNS option would have the advantage of practically 
no answer:query amplification, unlike multi-query or additional SOA.

Libor

Dne 28. 05. 21 v 21:27 Peter Thomassen napsal(a):
> Hi,
>
> I like the idea of having a way to add provenance information to 
> responses. However, as with all new proposals, I think what's needed 
> is a careful analysis of alternative ways to achieve the same goal, 
> then an assessment of what's the best approach (which may very well 
> turn out to be RRSERIAL).
>
>

---

From: Paul Wouters <[email-masked]>
Date: Sat, 29 May 2021 10:49:58 -0400

On May 29, 2021, at 03:20, libor.peltan <[email-masked]> wrote:
> 
> Hi,
> 
> just an idea: I don't know how important the amplification factor is.

Does that even matter these days ?

dig txt cnn.com

---

From: Mark Andrews <[email-masked]>
Date: Mon, 31 May 2021 07:14:42 +1000

If the SOA was to be added it should be to the authority section per STD13. 

RRSIG regularly get added to the additional section. Only referrals don’t have RRSIGs added. 

-- 
Mark Andrews

> On 29 May 2021, at 06:34, Paul Hoffman <[email-masked]> wrote:
> 
> --Paul Hoffman_______________________________________________
> DNSOP mailing list
> [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Mon, 31 May 2021 07:18:16 +1000

It shouldn’t matter because everyone should be doing DNS COOKIES.

-- 
Mark Andrews

> On 30 May 2021, at 00:50, Paul Wouters <[email-masked]> wrote:
>