[dns-operations] IPv6 PTR best practice

[Andrew Boling]

 On Tue, May 8, 2018 at 1:42 PM, Jacques Latour <Jacques.Latour at cira.ca>
wrote:

> - Is not responding to PTR acceptable? When?
>

This really needs to be split into two questions. To a DNS expert this
question has a clear meaning, but to non-experts it can be ambiguous.


1) Is not responding to a PTR request acceptable?

When responding to a well-behaved client, Mark is correct: the software
should respond.

Most software authors reserve the right to drop a query in extreme
circumstances. (DDoS, etc.) This should be considered an exceptionally rare
condition. If this behavior is encountered by a legitimate client and the
remote server is not dealing with an unusual load scenario, it is a badly
written implementation. In the context of best practices surrounding PTR
records, the server should not ignore a legitimate request for a PTR record.

This is not to be confused with...


2) Is it acceptable for an authoritative server to respond with zero
answers when asked for a PTR record?

Per the DNS standard itself, yes. Nonexistence of these records is not by
itself an error, which means that both NXDOMAIN and NODATA (RFC 2308) are
acceptable responses to a request for a PTR record. There is a great deal
of misquoting to the contrary, mostly citing RFCs with a status of
Informational or UNKNOWN. (these do not define or augment Internet
Standards, see RFC 1796)

The huge caveat is that an absent PTR record will often be problematic if
it is associated with the static IP address of a server. The DNS standard
does not require the presence of a PTR record, but non-DNS services may
require one. In those cases, a missing PTR record will cause select remote
services to be refused to the client IP address associated with it. (examples:
SMTP, Kerberos, etc.)

This is the scenario that the oft-cited RFC 1912 (Informational) is
attempting to protect users against. Its recommendation to always create
matching PTR records is based on the fact that DNS admins can't be
reasonably expected to be aware of whether an absent PTR record will create
problems for a specific device. (requires understanding the role of the
device + services it will be communicating with) Blindly following the
practice without good automation creates its own problem: stale PTR records
that long outlive the hardware they were originally associated with.

The classic IPv4 solution utilized by most ISPs has been to pre-generate
generic PTR records for all of their assigned IPv4 space where PTR absence
might become a problem. You can observe within the other responses to this
topic how popular an idea it is to do the same with IPv6 (that's a lot of
uselessly generic data), and also note that a consensus/holistic solution
is not exactly forthcoming. PTR record synthesis reduces the bloat of the
authoritative DNS servers that host the data, but not the memory and wire
bloat of the recursive DNS systems that end up caching it.


It's hard to make all of the device owners involved happy on this one.
That's why we sometimes get a little cranky about it. :) To insert an
opinion into the mix: if you want to be "safe", authoritative servers that
implement PTR record synthesis is probably the way to go. (You'll have to
excuse me now, I need to change my residential address before several
recursive operators can assassinate me.)


On Tue, May 8, 2018 at 1:42 PM, 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?
>
> - What applications are requiring IPv6 PTR support?
>
>
>
> Any feedback appreciated,
>
>
>
> Thanks,
>
>
>
> Jacques
>
>
>
>
>
>
>
>
>
> Jacques Latour – CTO
>
> Canadian Internet Registration Authority (CIRA)
>
> Tel: (613) 237-5335 ext.294 | www.cira.ca
>
>
>
> [image: Cira K+186 H Tag]
>
>
>
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-operations mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20180509/63eacc50/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 8130 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20180509/63eacc50/attachment.png>