> On Jul 18, 2024, at 11:03 AM, Petr Špaček <pspa...@isc.org> wrote: > > Caution: This email originated from outside the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > 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. >
Thanks everyone for the input on this thread started by Philip. We’ve added this new text to the document to be published in the next revision: 4. The SOA-SERIAL ZONEVERSION Type ... As mentioned previously, some DNS zones may use alternative distribution and synchronization mechanisms not based on the SOA Serial number and the Serial field may not be relevant with respect to the versioning of zone content. In those cases a name server SHOULD NOT include a ZONEVERSION option with type SOA-SERIAL in a reply. DW
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
