Standard query response 0x21e1 No such name PTR 5.1.168.192.in-addr.arpa SOA prisoner.iana.org
The server for which I was performing the troubleshooting has an IP address of 192.168.1.5, which is a private IP address. There are 3 private IP address ranges; these ranges are also sometimes referred to as "RFC 1918 addresses", since the private IP address space is defined in RFC 1918 . A Request for Comments (RFC) is a document published by the Internet Engineering Task Force (IETF). Some RFCs, such as RFC 1918 become Internet Standards.
| RFC1918 name | IP Address Range | Number of addressses | Largest CIDR block (subnet mask) | Host ID Size | Mask Bits | Classful Description |
|---|---|---|---|---|---|---|
| 24-bit block | 10.0.0.0 - 10.255.255.255 | 16,777,216 | 10.0.0.0/8 (255.0.0.0) | 24 bits | 8 bits | single class A network |
| 20-bit block | 172.16.0.0 - 172.31.255.255 | 1,048,576 | 172.16.0.0/12 (255.240.0.0) | 20 bits | 12 bits | 16 contiguous class B networks |
| 16-bit block | 192.168.0.0 - 192.168.255.255 | 65,536 | 192.168.0.0/16 (255.255.0.0) | 16 bits | 16 bits | 256 contiguous class C networks |
I suspected the DNS query for the 192.168.1.5 address was triggered by software that logs connections to the system. E.g., web servers typically record the source IP address from which browser queries originate to websites on the server in a log file on the server. Sometimes the software performing the logging function will also perform a reverse DNS lookup to translate an IP address into a fully qualified domain name (FQDN). E.g., suppose the server sees a connection from the IP address 66.249.65.40. It could perform a reverse DNS lookup that would return a FQDN of crawl-66-249-65-40.googlebot.com. That would reveal that the request it saw for the webpage from that IP address was by a Googlebot system indexing the content of a website on the server.
But a system shouldn't be attempting to do a reverse DNS lookup by querying external DNS servers on the Internet for any private IP address space, since there is no public FQDN corresponding to private IP addresses, since those addresses can be used on many systems at many locations. E.g., the Acme corporation might use 192.168.1.5 for one of its systems that sit behind a router or firewall performing NAT while the Ajax corporation might do the same. And the IP address could be used by hundreds of thousands of others as well, including home users. The DNS response I saw returned was from a DNS server provided by the Internet Service Provider (ISP) that provides the Internet service to the server for which I was performing the troubleshooting. That server would pass the query on to a relevant DNS server that might be able to return a FQDN for the address, though for a private IP address, it is not going to be able to actually get a FQDN associated with the address. But where would it forward the query? The reverse DNS database for the Internet is rooted in the .arpa top-level domain (TLD). The arpa domain is used for Internet infrastructure purposes. ARPA is an acronym that stands for Advanced Research Projects Agnecy (ARPA), which was a U.S. government funding organization that developed the precursor to today's Internet known as ARPANet. The arpa top-level domain was actually the first domain installed in the Domain Name System (DNS), which supplanted the early hosts table method of matching host names to IP addresses. The domain name was to be a temporary one to facilitate the transition of ARPANET host names to the new DNS method of managing IP addresses and their associated names. But it lives on because in-addr.arpa was used for reverse DNS lookups for IP addresses. E.g., a DNS query could be performed for a DNS pointer (PTR) record for the IP address 66.249.65.40 by submitting a query for 40.65.249.in-addr.arpa - the convention is to reverse the octets of the address when requesting a PTR record. E.g.:
C:>nslookup Default Server: UnKnown Address: 192.168.2.1 > set querytype=PTR > 40.65.249.66.in-addr.arpa Server: UnKnown Address: 192.168.2.1 Non-authoritative answer: 40.65.249.66.in-addr.arpa name = crawl-66-249-65-40.googlebot.com 65.249.66.in-addr.arpa nameserver = ns2.google.com 65.249.66.in-addr.arpa nameserver = ns1.google.com 65.249.66.in-addr.arpa nameserver = ns3.google.com 65.249.66.in-addr.arpa nameserver = ns4.google.com ns2.google.com internet address = 216.239.34.10 ns1.google.com internet address = 216.239.32.10 ns3.google.com internet address = 216.239.36.10 ns4.google.com internet address = 216.239.38.10 >
So that is why the response referenced "No such name PTR 5.1.168.192.in-addr.arpa". So why does a query for an IP address in a private IP address block, e.g., a 192.168.x.x address, reference prisoner.iana.org. The Internet Assigned Numbers Authority (IANA) coordinates the delegation of top-level domains and maintains the Root Zone Database. It maintains the following name servers that will respond to queries for priate-use IP addresses:
These servers are AS112 Project nameservers, which are separate non-root servers for answering such private IP address queries. Though these servers will return responses indicating that no FQDN can be returned for a PTR query on a private IP address, the nameservers for IPv4 and IPv6 reverse zones should not recieve such queries, since they can't return any meaningful host name information. The Internet Engineering Task Force (IETF) RFC 6305 notes:
Despite the fact that the public DNS cannot provide answers, many sites have misconfigurations in the way they connect to the Internet; this results in such queries relating to internal infrastructure being sent outside the site. From the perspective of the public DNS, these queries are junk -- they cannot be answered usefully and result in unnecessary traffic being received by the nameservers which underpin the operation of the reverse DNS (the so-called reverse servers [RFC5855], which serve "IN-ADDR.ARPA").
To isolate this traffic and reduce the load on the rest of the reverse DNS infrastructure, dedicated servers have been deployed in the Internet to receive and reply to these junk queries. These servers are deployed in many places in a loosely coordinated effort known as the "AS112 project". More details about the AS112 project can be found at < http://www.as112.net/ >.
To resolve the problem with the particular Linux server for which I was troubleshooting, I could set up an internal name server with a zone for the 192.168.1.0/24 subnet the server was located in.