Tony Finch wrote: > Hmm, I am reluctant to introduce new layering. Is there a precedent for > the distinction you are making?
Any web standard could be said to specify "requirements on HTTP clients", yet most of them don't use that term or update the HTTP specification. Any mail standard could be said to "specify requirements on SMTP clients", yet most of them don't use that term or update the SMTP specification. The requirements in Section 9 should apply to entities like DHCP servers and IP management systems, whose functionality includes the management of reverse mappings, and that may contain, call upon, or (if we must use that term) "be" an UPDATE client to perform the changes. But an entity that only serves as an UPDATE client, like the "nsupdate" program in the BIND distribution, should not be subject to the requirements because it does not deal specifically with reverse mappings, but with arbitrary DNS names and records. Calling them "requirements on UPDATE clients" when they only apply to entities that are more than just UPDATE clients seems wrong to me. > > I would even say that the requirement to follow CNAME and DNAME > > redirections should apply equally when the updates are not performed > > using the RFC2136 UPDATE protocol at all, but using some other > > mechanism. > > What deployed examples do you have in mind? The RA-API REST interface used by dyn.com would be one if they only supported PTR records. I also recall implementing a different proprietary update protocol to work around some limitations of RFC2136 as part of the NameSurfer IP management system back in the 90s. In principle, the draft's requirement to follow CNAMEs and DNAMEs could even be applied to tools that update zones through mechanized editing of master files. > Who here knows how Active Directory interacts with DNS aliases? Not me... -- Andreas Gustafsson, g...@araneus.fi _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
