[dns-operations] Alternate IPv6 address to hostname mapping, Re: IPv6 PTR records

Paul Vixie vixie at isc.org
Wed Dec 22 18:14:52 UTC 2010

> From: "Mark Scholten" <mark at streamservice.nl>
> Date: Wed, 22 Dec 2010 18:16:07 +0100
> > ...
> > in IPv6 the same pressures exist but that workaround does not work
> > anymore.
> With some name servers (at least PowerDNS) you could create a script
> that generates the PTR/AAAA record on the fly (after checking for
> static configured PTR/AAAA records). Isn't that a good option for this
> "problem"?

yes and no.  any RFC2136-capable name server can accept dynamic updates
to establish and maintain name/address bindings.  the problem is not in
the name service, it's in the initiator.  a dhcp client knows its name
and could possibly have update permissions on the A/AAAA at that name.
a dhcp server knows what address it's handing out and could possibly have
update permissions on the PTR at that address.  no one update-initiator
has complete information and complete permissions to make updates.  and
if IPv6 autoconf is used, there isn't even a dhcp server in the equation,
and since autoconf is stateless then only the client will know when a new
name/address binding should be memorialized.  this is why BIND now has an
ACL syntax allowing a dns operator to express that 'if the update is 
coming from address X, then it should be allowed to manage the PTR RRset
for address X'.  this would allow clients to maintain their bindings, but
there is no IETF standard for it and i'm not even sure there ought to be.

 I also only like to require it for emails, from a mail
> server to another mail server (as it limits some abuse). For mail
> clients to mail servers it is also possible to use some authentication
> options.

to me any discussion of why name/address bindings aren't useful or how
apps ought to stop depending on them is off-topic.  i'm here to make it
work not to explain why it doesn't need to be made to work.  YMMV.

More information about the dns-operations mailing list