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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
