[dns-operations] IPv6 PTR best practice

Paul Ferguson fergdawgster at mykolab.com
Wed May 9 01:41:56 UTC 2018

Hash: SHA256

On 5/8/2018 6:23 PM, Mark Andrews wrote:

>> On 9 May 2018, at 3:42 am, Jacques Latour
>> <Jacques.Latour at cira.ca> wrote:
>> Hi All,
>> I’m assisting a group to write a best practice document and we’re
>> wondering what is the best practice on IPv6 PTR for subscribers
>> and for enterprise?
>> - What are ISP doing in regards to responding to IPv6 PTR
>> requests? - Is not responding to PTR acceptable? When?
> Never.  The DNS is a query/response protocol.  Not responding is
> not part of the protocol.
>> - What applications are requiring IPv6 PTR support?
> The same set that require it for IPv4.
>> Any feedback appreciated,
> ISP’s really haven’t looked at what can work for populating PTR
> records.
> Companies using Active Directory have the end node populate the the
> PTR records using GSS-TSIG signed UPDATE requests.  Similar could
> work for ISP but every time someone mentions this they huff and
> puff and say it won’t work.
> They see their kludge of pre-populating the reverse address space
> as being “good enough” for IPv4 and just want to do the same for
> IPv6 rather than actually look for solutions that will work.
> In named today we have the ability to authorise the adding of PTR
> records based on the TCP source address. can add a PTR
> record at by sending the update request over
> TCP.  Similarly for IPv6.
> With DNSSEC named updates RRSIGs as they fall due.  Removing PTR
> records after a interval would be just as simple a process.  A heap
> structure and a timer that triggers a removal when the timer
> expires.  Resending the UPDATE request resets the timer.
> All the client has to do is send a UPDATE request to add a PTR
> record for the machines name whenever it renews its IP address
> (DHCP or via RA). Active Directory clients do a UPDATE request on
> every renewal.  There is zero reasons why non Active Directory
> clients can’t do similar.
> I’ve also described a procedure which would allow for automated
> delegation of the reverse space along with prefix delegation as
> well as removal of the delegation when the prefix delegation
> expires.
> https://www.ietf.org/archive/id/draft-andrews-dnsop-pd-reverse-02.txt
>  You can go from a pre-populated PTR records to client updated PTR
> record and back dependent on the client’s capabilities.  Rather
> than deleting on timeout you restore the generic PTR record.
> There is no reason we can’t go from kludges to a working reverse
> space other than a unwillingness to try.

And people say IPv6 is no fun!

- - ferg

- -- 
Paul Ferguson
ICEBRG.io, Seattle USA
Version: GnuPG v2


More information about the dns-operations mailing list