On Tue, 6 May 2025 22:02:22 +0000 "Wessels, Duane" <dwessels=40verisign....@dmarc.ietf.org> wrote:
> Hi Stefan! Hello Duane, Thank you for reading the draft, my comments are inline. > I read through your draft and have the following comments and > suggestions: > > I understand the idea is to define a new ZONEVERSION type. Whereas > the SOA-SERIAL type copies the SOA SERIAL number into the zone > version option, this one would would copy a value from a TXT RR with > a well-known name. Yes, that is the idea. > You might want to state in the draft that setting the value for this > TXT RR is out of scope of the specification. If I understand > correctly, the name server software just treats it as an opaque value > and doesn’t ever update or change the value. That is done externally > from the name server. That might reduce some of Ondřej's concerns? Thank you for that suggestion, I will include something in that regard in the next version. > In a few places the draft says something like "constructed from a > label in the zone” or "MUST be a copy of the _version label in the > zone”. I think here you mean the value must come from the RDATA of > the record, not its label (name). Yes, that is correct. I will change that. > I think it would be good to be more consistent in naming and > describing the new option. For example, if it is going to be called > “backend serial” then the new label should be _backend_serial instead > of _version. And the draft title should be “DNS Backend Serial Zone > Version Option” instead of “zone version extended”. Thank you. I will make changes to make it more consistant. > Maybe give some thought to whether or not the new version value > should be like a serial number or could be more general. Maybe there > are some use cases where the backend data source is not identified by > a serial number, but by some other type of identifier using letters > or other characters. If the value is restricted to be like an SOA > serial number then you have to say what the name server does if the > RDATA value isn’t numeric or is lager than 32 bits, etc. > > You might even want to generalize it further so that it’s just an > opaque version identifier with no particular meaning (i.e. not even > “backend something”). Someone implementing this would probably > prefer to just once implement a copy-zoneversion-from-txt-rr feature > that works for as many use cases as possible. I like the idea that is not limited to a SOA like number. The current example is just a basic example. Adding an other example with a different layout can help show other possibilities than the SOA like number. If it is a free form TXT field that is just copied, I think it still should be limited to minimize the possible misuse for reflection attacks. > > On May 2, 2025, at 5:26 AM, Stefan Ubbink > > <Stefan.Ubbink=40sidn...@dmarc.ietf.org> wrote: > > > > Hello, > > > > Last year [1] I had an idea to extend ZONEVERSION (RFC9660) with a > > version of the database. > > This is my first submission of the Internet Draft. > > > > Please let me know what you think. > > > > [1] > > https://secure-web.cisco.com/1fJ2sgqgPFtkg2CQRB_4smfL2zu1EORwtObnrqUIUNqZqu5CB1kF7OVP1EPSZEUj5-sgqZ0_-vTOy7JYqRvJFJlQuRCvhLFxsulLpN4p9j2uh3NVMOh31HCdjakRgXFwhttWcCI0vrXG9_rnEX6iUShfD7G4qMonzjTM1O6ae7vIu1dCsmc15vsQxX8CWtaGGF8D3f64jl13Vdy7POBm-TSXNiHf7sxHVG4-25NNb6OXlEIFEXGO0c-yMyz7A-EQV4IsLbL0XnUqcUcigeG61B_RqT1K8hC_C_wVLLLdJv5E/https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fdnsop%2FeVJYb-PDKQUPE8Z6VNLTDG_1rbI%2F > > > > > > Begin forwarded message: > > > > Date: Fri, 2 May 2025 01:06:56 -0700 > > From: internet-dra...@ietf.org > > To: Stefan Ubbink <stefan.ubb...@sidn.nl> > > Subject: New Version Notification for > > draft-ubbink-zoneversion-extended-00.txt > > > > > > A new version of Internet-Draft > > draft-ubbink-zoneversion-extended-00.txt has been successfully > > submitted by Stefan Ubbink and posted to the IETF repository. > > > > Name: draft-ubbink-zoneversion-extended > > Revision: 00 > > Title: DNS Zone Version (ZONEVERSION) Extended > > Date: 2025-05-02 > > Group: Individual Submission > > Pages: 4 > > URL: > > https://secure-web.cisco.com/1CP1isBRhFwwJMBiIBOuDUQcIpPNkrhZ46VkYxxjtAHkpSMgxZEWMyW70N3Xo6OirCLxQbM5J06MhzxlMCp45fb2CTdtDEXJBSWctzWy-7srCIu8ewYQyoxdekVmeIlx3ReLuTZCJknmX_VNgBOYFC4f88f4Yn05z5jesEn-SNa_1Si_8cN2Uby6B2AFSE2Bx3Wmc-TR0SEIFZx8aPzsA_uO84cOx06GTxLvcp4oPmxxc4j3tsRCBgRDBgYyhXaivjZ3MNGfqofYxmmuhfU8wJ7ZX9zPJvjZvQFTY3qGYn5k/https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ubbink-zoneversion-extended-00.txt > > Status: > > https://secure-web.cisco.com/1iyVEsTylCCId39ASj5ARCESY07ha8xL5LwGPSrhreq-30lrB4MgAOOhAWa9A35rGtfnoJC6bu-FzJim5h-eil3OpYOL81kPtQqo61aJJys9yLSL8DoQVsXLYMcpRAXyoEBlrWjHyu-Psa0Q-MZFt6wdiLxmyBaQVQ5JWJ_HAvoWRA8WBgU9nw1zk1SebX9LwXOx-nUnP-QkNqPSeZTCl6_G6w9_iQFPgo4v4tbxrq5pyDgavKeKKQivC2Sr-bAJaCtzSaO4oMDQeK1uz6TJpCZ9R72bI6mM_HtCwhoeiGV8/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ubbink-zoneversion-extended%2F > > HTML: > > https://secure-web.cisco.com/1q47N5nHu63L-BMRhwsoKffka4DyfycSnKjc4QkuSYF8WkkwoFmRfTC_hUGt5ad4w7No3aHtk4BSGf1SUpT7fPNdEdCadw8szlbn7InBYtLtFS77kwy8p6GEFPEJ6TY1MlT9I4sTClceF7xYVPRy7vCbyTXFWsyKsJUd17Uo279QZaCM0kxyIXaEovnlGvZuIeJJrHRIpifxxy1P8_NQP8DzrDFOf74WTn4lzDw7j43UewDxxiL3LIc_LijwU1uyNUGhnF7245lR-KbQtsDy4cm6JDvJqkXSbQS0bE9FGICI/https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ubbink-zoneversion-extended-00.html > > HTMLized: > > https://secure-web.cisco.com/1ukt_9dvy6GNFhI1YMJIibZgNqS-dbdJiOJ0NZSaJB0yQ17nUctatclp7xJNaxAcW4HL8ndnuuRqGA1quNEYh-U_xuzQdcqECUBDaEymyhroYNiEvLwpGS2_mjcfEBais2jJGkl2mGMRHRPVPU2k8oUuEm6PBZRcSpJBr7JL8fbUzOfGQ-oJqF29jMWlQ8QoEEekY0vGJAgd9jKaQe5lTc0T6TSM1l_UVoNqmLfottIQngHau3P9QPUZuVYA22ajxdrMpy2OXn-W69CXu2-2om66lqtxMR9cZFNimxZHU_ws/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ubbink-zoneversion-extended > > > > > > Abstract: > > > > The DNS Zone Version (ZONEVERSION) extended is a way to get > > information about the version of a DNS in the backend. For > > example when a DNSSEC signer for a zone generates a new SOA serial, > > because it has created new RRSIG records, the original data has not > > changed, but this is not visible to anyone looking at the zone. > > This document will make it possible show the zone information which > > is the base of the presented data. > > > > > > > > The IETF Secretariat > > > > > > > > > > -- > > Stefan Ubbink > > DNS & Systems Engineer > > Present: Mon, Tue, Wed, Fri > > SIDN | Meander 501 | 6825 MD | ARNHEM | The Netherlands > > T +31 (0)26 352 55 00 > > https://secure-web.cisco.com/1ZNRDL8yn2bf6uGFIzwcsdzjaoLwXZSrrswwkuzIu7EJvDl3cjyXAhagiPmjufIdClclKoy3-bIxbqV_mUDkJsXm-AqPMqHfkEswUpY1zD2Xxd0sBfXe3BHs7SAZS0mvu62ZHjGD7rXU20vZrYogoF-t67Zy6rVV0hHkX1555GFdhZ7xX4g8jUiGNOaDQLbyGLo3mIg1hX3ZAcGQuo4zuN3Re_oWUN8sW8eh2DZYPDRuUpaBd4QJ_3rk_jtkJ7p6za03sf4rDJAoMkxJf0rDkWmlcuGhPMWl9yVihI_Dno04/https%3A%2F%2Fwww.sidn.nl > > 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. > > > > _______________________________________________ > > DNSOP mailing list -- dnsop@ietf.org > > To unsubscribe send an email to dnsop-le...@ietf.org > -- Stefan Ubbink DNS & Systems Engineer Present: Mon, Tue, Wed, Fri SIDN | Meander 501 | 6825 MD | ARNHEM | The Netherlands T +31 (0)26 352 55 00 https://www.sidn.nl
pgpTQYQ6k23u2.pgp
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
