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

[Tony Finch <[e-mail]>]

Andreas Gustafsson <[e-mail]> wrote:
> 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.

I meant precedents specific to DNS UPDATE.

> 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.

Right, Mark Andrews made the same point in response to Petr Spacek's
earlier draft. I tried to write the requirements so that they take
this into account but I know the text can be improved.

Can you point to specific wording that needs changing?

I want to avoid having to write a taxonomy of different kinds of UPDATE
clients; I think it is more straightforward to talk about the kind of
modification some software is trying to make to the DNS and therefore how
it should construct an UPDATE message.

There's also the question in the appendix about DNS UPDATE and aliases in
the forward DNS. It's similar to the reverse DNS problem, except that
you're more likely to get varying answers to the question of whether to
update records at the given owner name or at its canonical name. I found
it too difficult to describe it clearly the first time round so I punted
and kept to Petr's tighter scope.

> > > 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.

More details might be helpful :-)

> 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.

Right.

In a lot of cases the APIs require you to specify the zone you are
modifying (this is true for UPDATE and the Gandi API, for instance) which,
as you say, implies that a client must have already canonicalized the name
before calling the API, if that is what it needed to do.

I will try to cover this kind of situation. Thanks for the discussion, it
has helped to get things clearer in my head. We shall see if I manage to
get them clearer in words :-)

Tony.
-- 
f.anthony.n.finch  <[e-mail]>  http://dotat.at/
Malin, Hebrides, Bailey: East or southeast 4 or 5, occasionally 6 at first.
Rough or very rough in Bailey, otherwise moderate or rough. Rain or showers.
Good, occasionally poor.