7

or to re-phrase... How to determine to whom authority has been delegated to set rDNS?

Background

In a multi-tier environment, where a block of IP's is assigned, then further split and assigned (process repeats a few more times), how can one determine to which level responsibility has so far, been delegated for this task?

For example

To set the rDNS of 37.140.235.74 which nameserver should hold the authority record?

2 Answers 2

9

The in-addr.arpa zone is delegated in much the same way as other zones: by using delegation NS records.

Accordingly, suppose you were curious as to who had the authoritative DNS server for 192.0.2.0/24. This subnet mask is divisible by 8, and so you can do:

dig in ns 2.0.192.in-addr.arpa

Your answer will contain a list of nameservers serving the rDNS zone.

IPv4 rDNS delegation is one of the few things that does not behave well with CIDR; it is only delegateable at the octet level. So, if two different parties control /25 blocks which could be aggregated into the same /24, they would have to cooperate to provide rDNS, or someone would have to operate a (very awkward) DNS server that creates individual delegation records for every single address in the /24 block.

In consequence, you will reliably find the person operating rDNS servers (which may be different from the person responsible for the IP block in whois) by successively querying IN NS for 1.2.0.192.in-addr.arpa, 2.0.192.in-addr.arpa, 0.192.in-addr.arpa, and 192.in-addr.arpa (replace the documentation IP 192.0.2.1 with your target) until you find one.

That said, it is very likely that the technical contact for the IP block as shown in a whois query is the entity actually responsible for maintaining the rDNS data regardless of who is operating the rDNS authoritative nameserver.

You can also do a whois query on the delegated rDNS domain, typically:

whois 2.0.192.in-addr.arpa

This will give you the person who is responsible for the rDNS delegation, who is likely to be the person responsible for the rDNS itself too. This whois query is only really valid on the narrowest appropriate delegation for the block, and so if whois for the IP shows the delegation is a /23, typically the whois record will exist for the delegation at 3 octets, though it might also exist at 2 octets depending.

More information about how exactly this delegation works can be found in RFC2317, but it is very frequently done improperly or not at all, particularly outside of ARIN.

Another piece of data you can get is the SOA for the rDNS zone as queried. Simply do

dig -x 192.0.2.1

If rDNS has been set up properly, the first two strings in the SOA record returned in the authority section will indicate the authoritative nameserver and responsible person's email (replace the first . with @) respectively.

4
  • I tried dig in ns 235.140.37.in-addr.arpa but this (and successively decreasing the octets) always returns just ripe.net. I was kind of hoping it was going to say that the place to set the rDNS for this IP is on ns1.cwie.net or tell me an alternative server which is where the PTR should originate. I commend you for your very detailed & informative answer, but unfortunately it doesn't quite solve my problem yet. Sep 21, 2013 at 7:20
  • 1
    You might have a bit of trouble with this, I'm afraid - the people controlling the address block that is in haven't got an rDNS delegation set up, and so the nameserver you are looking for doesn't exist. You should complain at the people who delegated the address to you. Sep 21, 2013 at 7:48
  • My provider has attempted to set up rDNS on ns1.cwie.net (unsuccessfully). Are you saying that that is incorrect, because the above test dig in ns 235.140.37.in-addr.arpa does not return ns1.cwie.net? If so, am I correct in thinking that it's their providers responsibility? Sep 21, 2013 at 8:08
  • 1
    That is correct. Their records have no effect if the delegation is not set up from the in-addr.arpa root. I do see, however, that they have correctly configured your rDNS record on that server, so the delegation is the only thing missing. Sep 21, 2013 at 8:28
1
# dig +trace -x 37.140.235.74

or

# whois 37.140.235.74

37.140.232.0/21 belongs to PhoenixNAP

1
  • It does, but that doesn't tell me which nameserver needs to be configured for the rDNS PTR record. Sep 21, 2013 at 6:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .