While using Wireshark to troubleshoot a Domain Name System (DNS) issue for a server that sits behind a firewall that performs Network Address Translation (NAT), I noticed a DNS response coming back where Wireshark showed the following in the "Info" field for a packet:

Standard query response 0x21e1 No such name PTR SOA

The server for which I was performing the troubleshooting has an IP address of, 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.

Private IPv4 address spaces
RFC1918 nameIP Address RangeNumber of addressses Largest CIDR block (subnet mask) Host ID Size Mask Bits Classful Description
24-bit block10.0.0.0 -,777,216 ( bits8 bits single class A network
20-bit block172.16.0.0 -,048,576 ( bits12 bits 16 contiguous class B networks
16-bit block192.168.0.0 -,536 ( bits16 bits 256 contiguous class C networks

I suspected the DNS query for the 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 It could perform a reverse DNS lookup that would return a FQDN of 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 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 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 by submitting a query for - the convention is to reverse the octets of the address when requesting a PTR record. E.g.:

Default Server:  UnKnown

> set querytype=PTR
Server:  UnKnown

Non-authoritative answer:       name =  nameserver =  nameserver =  nameserver =  nameserver =  internet address =  internet address =  internet address =  internet address =

So that is why the response referenced "No such name PTR". So why does a query for an IP address in a private IP address block, e.g., a 192.168.x.x address, reference 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 < >.

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 subnet the server was located in.