On 18. 07. 24 17:28, Shane Kerr wrote:
Petr,
On 18/07/2024 17.09, Petr Špaček wrote:
I'm one of the guys who implemented a server which ignored SOA serial
semantics on purpose - because its distributed multi-master backend
offered only eventual consistency.
Of course it had to expose _some_ value for SOA serial, but the fake
serial did not have the properties promised in RFC 1034, and there is
no way to make it so.
I believe some PowerDNS installations suffer from the same problem.
With this experience in mind I support Philip's proposal to add
instruction for authors of such servers. It does not hurt anyone and
it's a good reminder for authors of weird software.
If there's trouble with defining "meaningful" then we can try this
alternative wording:
----
If a DNS zone's SOA Serial number does not conform to RFC 1034
semantics then the SOA-SERIAL ZONEVERSION option SHOULD NOT be
returned in a reply.
----
The draft has this lovely TYPE field, which defines a single option:
The first and only ZONEVERSION option TYPE defined in this document is a
zone's serial number as found in the Start of Authority (SOA) RR.
There are also private use ZONEVERSION TYPE reserved, so I think your
suggestion is correct for ZONEVERSION TYPE SOA-SERIAL. Anyone who wants
to return a value that is meaningful in some other way can use one of
the private use values.
Indeed that's exactly what I meant!
To provide a practical example, BIND with a LDAP-backed (e.g.
"bind-dyndb-ldap") could return syncCookie [1] which identifies content
of the backing LDAP database, but SHOULD NOT return SOA serial because
that value is likely inconsistent across "replicas" as they call
individual servers.
[1] https://datatracker.ietf.org/doc/html/rfc4533#section-2.1.2
--
Petr Špaček
Internet Systems Consortium
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
