Hi Stefan, > On 7. 5. 2025, at 10:45, Stefan Ubbink > <Stefan.Ubbink=40sidn...@dmarc.ietf.org> wrote:
[...] >> The draft is definitely underspecified in this area. Especially, the >> IXFR and NSUPDATE cases feel very hairy to me as this is practically >> makes SOA+(_version TXT) to be practically bound together during the >> updates. > > Would getting the _version TXT from the zone data only when a query > with the ZONEVERSION option enabled make sense? No, not really. It would be easier just to always check this. >> Is this a practical problem that it adds yet another requirement for >> the authoritative nameserver implementations? > > I would like to have a uniform way to know what the source of the DNS > data is in a way that it is visible to the public. That's probably the one thing I don't really understand - why? What's the use case of having this information available via DNS? I can clearly see that for the plain ZONEVERSION because that works with the loose nature of the DNS. Because as far as I understand this, you can achieve the same thing by: 1. publishing the list of SERIAL - DBVERSION outside of the DNS, it could be even available using the REST API 2. using the SERIAL number to publish this information, as the SERIAL numbers are integers and what we put into them is just convenience, you can for example round the seconds to the nearest hundreds and then use the last two digits to for just resigning. But again that boils down to - who would be a consumer of this information? And what do you envision such consumer would get by getting this information? And one more question - do you envision that the SOA SERIAL and your "_version" could somehow get out of sync? E.g. is something like this possible? Server 1: - SERIAL 10 - DBVERSION 2 Server 2: - SERIAL 11 - DBVERSION 1 Ondřej -- Ondřej Surý (He/Him) ond...@sury.org _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
