Home / server / Questions / 716642
Accepted
WoJ
Asked: 2015-08-26 06:15:50 +0800 CST

Is it valid to have several IP addresses resolving back (PTR) to one name that doesn't match either of the relevant A records?

  • 772

I have several devices, each with its own IP address. There are various names pointing to these addresses (in several different domains). As an example the device with

  • IP address 10.0.0.1 is known as dev1.example.com and abc.example.net
  • IP address 192.168.1.1 is known as dev2.example.com and xyz.example.net

in the respective DNS authoritative for example.com and example.net (A records).

I would like to understand if there are DNS implications of having both IP addresses pointing back (PTR) to a single name (say, contact-john-doe.example.org).

The rationale for this is to ensure that someone who sees one of the IP addresses in their logs, monitoring, etc. gets contact-john-doe.example.org as the resolved name. This resolved name may or may not point back to a real IP address/CNAME, it should not matter due to the nature of the service behind the IP addresses (these are scanners and they do not offer any service for the end user).

domain-name-system

2 Answers

  1. Best Answer

    While the informational (non-standard) RFC 1912 from 1996 suggests:

    Make sure your PTR and A records match. For every IP address, there should be a matching PTR record in the in-addr.arpa domain. If a host is multi-homed, (more than one IP address) make sure that all IP addresses have a corresponding PTR record (not just the first one). Failure to have matching PTR and A records can cause loss of Internet services similar to not being registered in the DNS at all.

    In spite of that isn't a requirement for PTR records to match A records. The most common issue you will see from PTR mismatches are in mail delivery. That said, I'd ensure that you at least point the records to domains you actually own and control.

    • 6

  2. The guidelines imposed by the standard defining RFCs are that the PTR record should point at the canonical hostname for the associated IP, and that it not point at an alias. This is important since your question seems to suggest that you're thinking of having one point at a CNAME in some cases, and bogus values in many of them.

    RFC1034 §3.5 (kudos to @Håkan Lindqvist, who keeps me honest as always)

    Address nodes are used to hold pointers to primary host names in the normal domain space.

    RFC1034 §3.6.2:

    Domain names in RRs which point at another name should always point at the primary name and not the alias. This avoids extra indirections in accessing information.

    Both RFCs were written before clear definitions for SHOULD NOT and MUST NOT existed (RFC2119). This is unfortunate because DNS is the glue of the internet and it's common for many recommendations in the original standards to be bent until further reinforced by supplementary RFCs. That said, the intent is fairly obvious here. It's one thing to use DNS as a general purpose hierarchical database when using the appropriate record types, it's another to ignore the recommendations completely.

    Will you break things if you proceed? Probably not, but it's still not a terribly good approach, especially if you intend for this to not map back to a value that is useful to the user or software. (making DNS recursors do more work for no added value)

    • 4