[dns-operations] IPv6 PTR best practice
fergdawgster at mykolab.com
Wed May 9 01:41:56 UTC 2018
-----BEGIN PGP SIGNED MESSAGE-----
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
> 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. 220.127.116.11 can add a PTR
> record at 18.104.22.168.in-addr.arpa 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
> 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
ICEBRG.io, Seattle USA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
-----END PGP SIGNATURE-----
More information about the dns-operations