Re: [DNSOP] Adoption of new EDNS opcode "rrserial"

[Petr Špaček <[e-mail]>]

On 27. 01. 20 16:08, Hugo Salgado wrote:
> Dear DNSOPers, as an operator I tend to have this need to couple
> an answer for a query to an auth server, with the actual "SOA zone
> version" used. So I think it'll be valuable to have an EDNS option
> for it.
> 
> Here I'm proposing it with this new draft. The 'camel index' for
> its implementation/hack/proof-of-concept is about 37 lines in
> NSD 4.1 (more details in Appendix A).
> 
> I've asked some operators and they see value on it. Is there any
> support for adoption in DNSOP?
> 
> -----
> Name:           draft-salgado-rrserial
> Revision:       01

...

>     This "RRSERIAL" data allows to debug problems and diagnosis by
>     helping to recognize the origin of an answer, associating this answer
>     with a respective zone version.

I think it needs more thought. Here's why:

Extending TTLs
==============
First, people in this thread have floated ideas about using SOA serial 
for extending TTLs.

I think it's a bad idea because:
a) It would be pretty complex to implement right.
b) There are no guarantees that the SOA serial did not overflow in the 
meanwhile. As an extreme example, auth server can legally increment SOA 
value by 2^29 for each update, thus rolling SOA serial over very frequently.


Debugging
=========
Secondly, let's consider just the "debugging" use-case, which removes 
the requirement to make the proposed mechanism 100 % reliable:

In practice, this RRSERIAL option is a specialized way to conflate two 
queries into one:
- First query specified by the standard (qclass, qtype, qname)
- Second query with hardcoded qtype=SOA, qclass derived from the primary 
qclass in question section, and SOA name derived from qname in the 
question section.

To me, this sounds like a crude hack, and I think the proper solution 
should be a real multi-query option, which incidentally provides a 
superset of RRSERIAL capabilities.

A multi-query option would also work multi-master architectures that 
cannot rely on SOA serial but on some other (presumably queriable) 
information.


Epilogue
========
Generally, I think SOA serial design was fine in 1985 but is ill-fitted 
for 2021. (I have to admit I'm biased because I'm implemented 
multi-master auth in topologies with tens of DNS servers, all accepting 
dynamic updates at the same time.)

For this reason, I think the DNS protocol should be gradually getting 
rid of the dependency on SOA serial, not increasing it.

-- 
Petr Špaček