Re: [DNSOP] Call for Adoption: draft-fanf-dnsop-rfc2317bis

[Andreas Gustafsson <[e-mail]>]

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, [e-mail]