[dns-operations] IPv6 PTR best practice

[Paul Ferguson]

-----BEGIN PGP SIGNED MESSAGE-----
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.  1.2.3.4 can add a PTR
> record at 4.3.2.1.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
> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlryUeQACgkQKJasdVTchbI0vwD+Msxi/MPJiYXobygtk9jRYeg/
yEM06lMMpXey98Jy0C0BAMiA6T3rp9idu3FSVaJL1X2unHO0lJAwbQeuKi3rmaz1
=hADP
-----END PGP SIGNATURE-----