Subject: [DNSOP] I-D Action: draft-ietf-dnsop-rrserial-01.txt

From: [email-masked]
Date: Wed, 06 Apr 2022 07:08:21 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

        Title           : The "RRSERIAL" EDNS option for the SOA serial of a RR's zone
        Authors         : Hugo Salgado
                          Mauricio Vergara Ereche
	Filename        : draft-ietf-dnsop-rrserial-01.txt
	Pages           : 6
	Date            : 2022-04-06

Abstract:
   The "RRSERIAL" EDNS option allows a DNS querier to request a DNS
   authoritative server to add an EDNS option in the answer of such
   query with the SOA serial number field of the origin zone which
   contains the answered Resource Record.

   This "RRSERIAL" data allows to debug and diagnose problems by helping
   to recognize the data source of an answer in an atomic single query,
   by associating the response with a respective zone version.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rrserial/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-dnsop-rrserial-01.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rrserial-01

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts

---

From: Hugo Salgado <[email-masked]>
Date: Wed, 6 Apr 2022 10:26:14 -0400

Dear DNSOP.
The authors have just reactivated the draft after its expiration, with
no changes. After some time waiting for other more urgent documents, we
believe that we can now reactivate it in the WG and ask for your
opinions. The last comments and suggestion were acknowledged, and we
think we could be close to Last Call.

As this document indicates where I have tried to keep track of work
(https://github.com/huguei/rrserial) there's a new implementation in
NSD and a couple of clients (dig and perl Net::DNS).

Currently we're working in an infrastructure for a public testbed that
we'll make available for implementers.

Thanks,

Hugo

On 07:08 06/04, [email-masked] wrote:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Petr Špaček <[email-masked]>
Date: Thu, 7 Apr 2022 08:54:31 +0200

Hello,

I think this is useful in a very limited way. The reason of this 
limitation is already stated in section 1:

 > The RRSERIAL EDNS extension doesn't offer much relevance for zones 
served by an Authoritative server that don't use the SOA serial 
versioning as a meaning to its content. There are cases where 
nameservers use different backends for its data sources, like relational 
databases or by using a different off-DNS synchronicity. In such cases 
this extension has no benefit or utility to use in debugging or analysis 
of a response.

 From my perspective, these systems are not rare, quite the contrary:
- PowerDNS with a database backend
- Multi-master flavors of BIND
- Various "cloud" auths with dynamic backends
- Windows DNS with Active Directory (I think)

To handle the traditional SERIAL together with more "modern" backends I 
propose simple modification to extend this draft to handle both.

Say that wire format could look like:

<length field, 2 octets, unsigned int>
<backend specific data with length specific above>

This allows the auth server to either send (length=2,data=4) with SOA 
serial as usual, or return any other identification suitable for a given 
backend.

If we _really_ wanted we could add also type field to distinguish 
"traditional" SERIAL vs. backend-specific blob, but I think it is not 
really needed.

To me this is very simple addition which increases value of the proposed 
protocol.

Opinions?

Petr Špaček

---

From: Paul Vixie <[email-masked]>
Date: Thu, 7 Apr 2022 06:42:57 -0700

hugo, mauricio,

i hope you will change your nomenclature. a zone serial applies to an 
rrset not just to an rr. answers contain rrsets not merely rrs. other 
than this, your proposal looks solid to me.

paul

re:

-- 
P Vixie

---

From: Paul Vixie <[email-masked]>
Date: Thu, 7 Apr 2022 06:47:52 -0700

Petr Špaček wrote on 2022-04-06 23:54:
> ...

because IXFR and NOTIFY and UPDATE use serial numbers, the DNS protocol 
itself is aware of serial numbers. i hope that any recognition of 
non-traditional serial numbers will be an optional addition to the 
RRSERIAL response, and that if a zone has no actual serial number (so, 
it cannot participate in IXFR, NOTIFY, and UPDATE) the RRSERIAL value 
will just be a magic number like zero, or just missing altogether.

-- 
P Vixie

---

From: Petr Špaček <[email-masked]>
Date: Thu, 7 Apr 2022 17:30:11 +0200

> will just be a magic number like zero, or just missing altogether.

I fail to understand what you mean, can you elaborate?

I will try to rephrase myself for clarity:

"Let's make this draft _also_ usable for debugging e.g. PowerDNS and 
multi-master BIND."

I cannot see any technical reason not to support it. Moreover this draft 
does not touch notify or transfer protocol in any way - which is why 
your e-mail confuses me.

-- 
Petr Špaček

---

From: Dick Franks <[email-masked]>
Date: Thu, 7 Apr 2022 16:48:50 +0100

> will just be a magic number like zero, or just missing altogether.

Magic numbers are messy.
Zero-length option preferred, same as the outbound request.
Need explicit statement somewhere that zero-length response means that
IXFR, NOTIFY, and UPDATE are not supported.

Not keen on the implementation-specific blob idea, which is of little
use to the general user. Implementers and power users will already
have more appropriate debugging tools.

--Dick

---

From: Paul Vixie <[email-masked]>
Date: Thu, 7 Apr 2022 10:35:35 -0700

Petr Špaček wrote on 2022-04-07 08:30:
>> because IXFR and NOTIFY and UPDATE use serial numbers, the DNS 
>> protocol itself is aware of serial numbers. i hope that any 
>> recognition of non-traditional serial numbers will be an optional 
>> addition to the RRSERIAL response, and that if a zone has no actual 
>> serial number (so, it cannot participate in IXFR, NOTIFY, and UPDATE) 
>> the RRSERIAL value will just be a magic number like zero, or just 
>> missing altogether.
> 

if a debugging method is needed let's add one but let's decide in 
advance not to use that debugging method in production or to overload a 
production method with non-production data.

you probably want a text record at example.com.zone.server (chaos class) 
or similar. it's a good idea and will help, but should not be stuffed 
into any in-band response such as the rrserial option.

-- 
P Vixie

---

From: Hugo Salgado <[email-masked]>
Date: Thu, 7 Apr 2022 14:02:49 -0400

On 06:42 07/04, Paul Vixie wrote:
> hugo, mauricio,
> 
> i hope you will change your nomenclature. a zone serial applies to an rrset
> not just to an rr. answers contain rrsets not merely rrs. other than this,
> your proposal looks solid to me.
> 

Thank you very much Paul, agree with specifying that it is a set.

However it's not clear to me what you mean by *nomenclature*. Is it
about changing the name of RRSERIAL to RRSETSERIAL? (Or RRS-SERIAL?)
Or will it be enough to clarify it in the introduction and change the
references from "resource record" to "resource record set"?

Hugo

---

From: Paul Vixie <[email-masked]>
Date: Thu, 7 Apr 2022 11:10:15 -0700

> references from "resource record" to "resource record set"?
the semantics of an answer are pretty well understood -- the rrset which 
is in the zone containing the qname is easily found. therefore you could 
rename the option code to ZONESERIAL or even SERIAL and it would have an 
unambiguous meaning.

but it seems to me you'd be better off with a zero-length option called 
SERIAL which if set in the query causes the SOA of the answer's zone to 
be added to the authority section (similar to an RFC 2308 negative 
proof) and which option would only be echoed in the answer's OPT if the 
option was supported. you'd want to specify that the SOA in this case is 
not optional and that its truncation would cause the TC bit to be set.

-- 
P Vixie

---

From: Hugo Salgado <[email-masked]>
Date: Thu, 7 Apr 2022 14:31:43 -0400

> "Let's make this draft _also_ usable for debugging e.g. PowerDNS and

Hi Petr, thank you for your suggestions.

The way we see RRSERIAL extension is just as a copy of the SOA serial
value.

I think what you’re trying to describe on PowerDNS and multi-master
BIND, is that the value contained there doesn’t offer any meaning;
I assume it could be either 0 or 1 or any custom other value (and here,
we can all agree there is a value). In such cases I would still expect
an RRSERIAL answer with that specific value, irrespective if it has a
meaning, and also, those implementations can just avoid to answer
RRSERIAL queries (which BTW it is allowed). Did we understand that
correctly, right?

So, maybe there's another way of accomplish this need: we can drop
entirely this RRSERIAL option, and create a new "ZONEVERSION" EDNS
option, that has a new meaning of... well... zone versioning :) So,
this ZONEVERSION value would be the SOA serial number in classic zones
(like this RRSERIAL proposal) but it would also add a new opaque
meaning for the other server implementations. If this new value has
another structure, then maybe we need a new field inside ZONEVERSION
to differentiate it. If it's just a 32 bits unsigned number just like
RRSERIAL, then it's a number, just not the same as the SOA serial value.

Hugo

---

From: Joe Abley <[email-masked]>
Date: Thu, 7 Apr 2022 21:44:18 +0300

On Apr 7, 2022, at 21:10, Paul Vixie <paul=[email-masked]> wrote:

> but it seems to me you'd be better off with a zero-length option called SERIAL which if set in the query causes the SOA of the answer's zone to be added to the authority section (similar to an RFC 2308 negative proof) and which option would only be echoed in the answer's OPT if the option was supported. you'd want to specify that the SOA in this case is not optional and that its truncation would cause the TC bit to be set.

That sounds like a lovely and clean way to do this. I like it. 

Joe

---

From: Dick Franks <[email-masked]>
Date: Thu, 7 Apr 2022 21:24:09 +0100

> That sounds like a lovely and clean way to do this. I like it.

This is an excellent idea, requiring trivial client-side support.

PV did not say so, but I would expect the SOA's RRSIG to be included
in the response.

--Dick

---

From: Petr Špaček <[email-masked]>
Date: Fri, 8 Apr 2022 14:39:14 +0200

> RRSERIAL queries (which BTW it is allowed). Did we understand that

Yes, that's exactly what I meant.

> RRSERIAL, then it's a number, just not the same as the SOA serial value.

Yes, that's basically what I meant.

Let's sketch a wire format for ZONEVERSION option:
- 1 byte - flags
- 2 bytes - length L
- L bytes

Flags:
- bit 0 - is the value in fact SOA serial?

What do you think?

-- 
Petr Špaček

P.S. I'm going to be AFK for a week or so. Silence from my side does not 
mean I intentionally ignore responses.

---

From: Hugo Salgado <[email-masked]>
Date: Mon, 11 Apr 2022 12:49:38 -0400

> PV did not say so, but I would expect the SOA's RRSIG to be included

The idea of having the complete SOA + RRSIG was proposed before[1]
and were discussed its disadvantages regarding size increase[2], query
amplification[3], authority/additional epistemological grief[4][5]
with changes in processing[6].

I personally believe that the path of including the full SOA is
dangerously close to multi-qtype[7][8], which has historically failed
for various reasons.

Finally, the full SOA prevents us from going down the path of using a
zone versioning other than SOA serial, which allows other
implementations to indicate useful data, as we discussed last week[9].

It is our understanding that the complete SOA path was rejected by the
group, and that the path through the EDNS extension that also allows
other types of versioning data would have greater consensus.

Thanks,

Hugo

[1]: https://mailarchive.ietf.org/arch/msg/dnsop/JMMKO7Q6WfFq25pqMQ5Yjsklywc
[2]: https://mailarchive.ietf.org/arch/msg/dnsop/Oy6DeGp9xiGenV8IsYy3faQbn1A
[3]: https://mailarchive.ietf.org/arch/msg/dnsop/kGTyENBGDnNwR1YOALurQFMNB8g
[4]: https://mailarchive.ietf.org/arch/msg/dnsop/D5ZYnZf-E_TOhZmTLjkaFWxO_P0
[5]: https://mailarchive.ietf.org/arch/msg/dnsop/1F24G6vtreg3q5c5PxEOndXCI68
[6]: https://mailarchive.ietf.org/arch/msg/dnsop/0kynqLc8Ksicv4JDX3opB3nYyfI
[7]: https://mailarchive.ietf.org/arch/msg/dnsop/07ISssrct9IXXyMpOgwGBXUczlw
[8]: https://mailarchive.ietf.org/arch/msg/dnsop/0kynqLc8Ksicv4JDX3opB3nYyfI
[9]: https://mailarchive.ietf.org/arch/msg/dnsop/VGTgsYAPXF_KsHCi2ruNa57QWYU