7

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

SamErde
  • 3,324
  • 3
  • 23
  • 42
WoJ
  • 3,365
  • 8
  • 46
  • 75
  • @Hyppy You're correct, I skimmed it incorrectly. My apologies. – Andrew B Aug 25 '15 at 15:00
  • @AndrewB No problemo :-D – Hyppy Aug 25 '15 at 15:01
  • 1
    Not your exact question, but possibly related: [Do internet standards require reverse DNS for every device?](http://serverfault.com/questions/612833/do-internet-standards-require-reverse-dns-for-every-device/612834#612834) This my *opinion* (somewhat supported by standards), but I think it's preferable to have no PTR record over having bogus ones that ignore standardized recommendations or poorly maintained ones. – Andrew B Aug 25 '15 at 16:19
  • @AndrewB: I agree with you. I have plenty of bogus PTRs for IP addresses provided by hosters which point to old domains and our scans routinely seem to be scanning www.clearly-not-our-company.com (from the results, which include a reverse DNS, the scans being based on IP ranges). This is horrendous and I very much prefer to have bare IPs in that case. My question's background is quite specific, though, as i want to use DNS names as PTRs as a mean to communicate with the receiving operator of a system. My key concern was about MUST NOT in RFC terms. – WoJ Aug 25 '15 at 16:35
  • Unfortunately there is little of that verbiage to be had because the RFCs in question predate the standardized language. If nothing else you should still try to avoid pointing PTRs at CNAMEs. – Andrew B Aug 25 '15 at 16:42

2 Answers2

6

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.

Hyppy
  • 15,458
  • 1
  • 37
  • 59
  • Yes, I am aware of mail related issues. Some services (notably ssh) were also very sensitive to that (it was taking an awful long time to get the prompt after the key exchange). None of the cases would apply in my case - I was rather looking for possible cases where such a setting would break bind. Thanks for the RFC pointer. – WoJ Aug 25 '15 at 15:24
  • Well, already [RFC1035](https://tools.ietf.org/html/rfc1035#section-3.5) said "Address nodes are used to hold pointers to primary host names in the normal domain space." which implies the expectation of matching address records. (That is one of the early standards track DNS documents.) – Håkan Lindqvist Aug 25 '15 at 15:40
  • @HåkanLindqvist So, when I'm querying network nodes, I should primarily use them to find pointers to the host names of gateways attached to that network? – Hyppy Aug 25 '15 at 16:00
  • Where they're defined, yes. The standards make no requirement for their existence, but they *should* point at the closest thing to a uniquely identifying network entity that holds the IP. – Andrew B Aug 25 '15 at 16:15
4

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)

Andrew B
  • 31,858
  • 12
  • 90
  • 128
  • I think what is wrong, or at the very least in conflict with intended use, is that this name (if I read the question right) may not exist at all, much less be the primary hostname as per [rfc1035](https://tools.ietf.org/html/rfc1035#section-3.5) ("Address nodes are used to hold pointers to primary host names in the normal domain space.") – Håkan Lindqvist Aug 25 '15 at 16:00
  • @Håkan Thanks, I thought I had read something along those lines but couldn't find the RFC reference. – Andrew B Aug 25 '15 at 16:09