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

[Andreas Gustafsson <[e-mail]>]

Tony Finch wrote:
> I meant precedents specific to DNS UPDATE.

RFC 4703 specifies DNS UPDATE behavior for one class of clients
without updating RFC 2136, and without framing it as a "requirement
on UPDATE clients".

> Can you point to specific wording that needs changing?

Mainly, the "Updates: 2136", and each instance of "UPDATE client".
For example, in the Introduction, you could change

   While these methods interoperate well with DNS resolvers, they
   require some care from dynamic DNS UPDATE clients that are trying to
   change IN-ADDR.ARPA mappings.  The client needs to follow the CNAME
   and/or DNAME redirections so that its UPDATE request changes the
   canonical PTR record without disrupting the redirections.

to something like

   While these methods interoperate well with DNS resolvers, they
   require some care from entities that update IN-ADDR.ARPA mappings,
   such as DHCP servers and IP management systems.  These need to
   follow the CNAME and/or DNAME redirections so that the update
   changes the canonical PTR record without disrupting the redirections.

If you would like more text, let me know.

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

I think the need for a taxonomy of UPDATE clients is best avoided by
not using the term "UPDATE client" at all, as RFC 4703 does.

> 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 think that is the right choice - this draft is about reverse
mappings, so any discussion of managing forward mappings is out of
scope.  If it were in scope, I would make a similar argument as in the
reverse case, that the question of whether to update the CNAME or the
records it points to should not be resolved at the level of RFC 2136,
but in the higher-layer entity that manages the forward mapping (or,
as the case may be, manages the CNAME involved in the forward
mapping).

> > > 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 :-)

What details would you need?  My main point was just that DNS update
protocols other than RFC 2136 do exist, and now that you mentioned
Gandi, it reminds me that there's also the Amazon Route 53 API.
I'm sure there are many more.

> 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 :-)

Great, thanks!
-- 
Andreas Gustafsson, [e-mail]