[dns-operations] IPv6 PTR best practice

[Grant Taylor]

On 05/08/2018 07:23 PM, Mark Andrews wrote:
> Never.  The DNS is a query/response protocol.  Not responding is not 
> part of the protocol.

Agreed.

> The same set that require it for IPv4.

Agreed.

> ISP’s really haven’t looked at what can work for populating PTR 
> records.

I've seen a lot of ISPs that don't bother populating PTR records for 
IPv4.  I'm not holding my breath for them to do so for IPv6.

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

To be fair, Active Directory, and GSS-*, implies that Kerberos 
authentication is in play.  That's something that ISPs are quite 
unlikely to have in play between them and their clients.

That being said, there are other methods of authentication that can be 
used between ISPs and clients.

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

Oh God!

The *MASSIVE* number of /unneeded/ records would be astonishing.  Not to 
mention the amount of resources that said records would consume.

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

*nod*  This is the primary way that I as referring to above.

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

Agreed.

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

Do you now if this is initiated by the DHCP client or if it's by chance 
done by the SERVER or WORKSTATION service?  I'm guessing that neither of 
the latter two would be in play for ISP clients.

> 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

$ReadingList++

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

I didn't see you mention having the DHCP server perform the dynamic DNS 
update on the client's behalf.

One problem that I've run into during Disaster Recovery exercises was 
clients not being able to communicate with the Master Name server (from 
the SOA record) to send dynamic DNS updates to.  Further, not all 
intermediate DNS servers will forward dynamic DNS updates.  (Like if you 
try to make the mname server resolve to the local DNS server that 
clients can reach.)

> There is no reason we can’t go from kludges to a working reverse space 
> other than a unwillingness to try.

Agreed.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20180508/0fe1b2d2/attachment.bin>