On Dec 12, 2024, at 06:53, Tim Wicinski <tjw.i...@gmail.com> wrote: > > Current versions of the draft is available here: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-generalized-notify/
I have voiced reservations about this approach in the past, keep that in mind when reviewing what I have here. Between section 2 and 2.1 there is no text. I suggest that there be something introducing the DSYNC record, perhaps stating that it is a record to be held in the parent (delegating) zone to direct where NOTIFY messages are sent. My first concern is that if the entries under _deleg.$parent will “leak” the registrar (when applicable) of a name for names that are run by operators that are not also registrars for the name. I don’t know if this is a business concern. While the identity of a registrar for a name may be available via other means, the distinction between domains that are operated by a registrar and domains that only use the registrar for name management is not generally available. My second concern relates to failed requests for services - i.e., a NOTIFY is sent to update a domain’s records. After some time passes the respondent discovers the domain is locked, thus the request cannot be satisfied. How the requestor is able to associate the error with the request that is not being satisfied? If the operator of zones sends hundreds of NOTIFY messages to a registrar when rolling keys, how will the operator be able to determine the few zones that cannot have their DS resource records updated? During EPP development time, there was a concern over errors that emerged after the message exchange was finished. Queues had to be created by servers for clients and a mechanism to poll for queued messages. This experience is what makes mention the second concern. In a sense, defining generalized NOTIFY is a positive step and perhaps my concerns will require a layer over generalized NOTIFY. I see the DSYNC record in the _dsync subtree as necessary (NOTIFY’s original definition assumed the server named in the SOA resource record). I see that it is necessary to include in each NOTIFY a means to return status (perhaps also positive acknowledgments) once the request is completed. The biggest problem in troubleshooting DNS is that each message lacks context. When looking at a stream of messages, it is hard to diagnose what’s happening. Generalized NOTIFY is helping with coordination of systems, it needs to make sure there are hooks to associate message exchanges (query out, response back; responses for AXFR) over time. I see the need, in the future, to have a document that covers how a child zone gets a parent to update delegation information. Using generalized NOTIFY and using CDS records and relying on EDNS0 error reporting are parts of that. The end-to-end session layer has to be defined. Still, this quote from an operator rings in my head “complexity causes centralization”. As more is added to the protocol, fewer will be qualified to operate it at scale. While it is necessary to add things to the DNS as it is today to fix the problems with the protocol, at some point it will have to be simplified again - whether making it easier to run servers or just that there are fewer providing service. Summary - about the document: Section 2 needs some text to introduce the DSYNC record (before section 2.1). Possibly text to recommend that if EDNS0 error reporting is used, there is someway to tie an error report the request (prompting the generalized NOTIFY request).
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
