Duane,
apologies for not responding earlier. I've re-read diff between -09 and
-11 and the changes look good to me.
Thank you for patience!
Petr Špaček
On 23. 07. 24 2:59, Wessels, Duane wrote:
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
--
Petr Špaček
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
