Your computer's resolver library has no concept of what is private address space and what is not. Any request for a reverse DNS lookup is going to be sent to the DNS servers your machine is configured to use.
Likewise, your client applications have no knowledge of whether your configured DNS servers are operated by you, or some other entity. The best they can do is attempt to use DNS for autodiscovery, and hope that you are operating your own DNS infrastructure that is authoritative for your LAN.
In a residential/enthusiast scenario, the most common case is that you're using your ISP's DNS servers. The queries for private network reverse DNS are going to "leak" to your ISP. There's no way around that in the DNS specification; this is considered normal operation. How the ISP responds at that point is completely up to them. These are the most common cases:
- The ISP manages their own authoritative reverse DNS for private network space, and is exposing it to the customer. Often this results in you discovering the DNS entry for the machine holding that IP address on their network. (oops)
- The ISP doesn't consider itself authoritative for that IP space, and they "leak" the query up to IANA's top level nameservers for reverse DNS. The
prisoner.iana.org.
authority data that you're seeing comes from IANA's blackholing servers. You can read more about them in the provided link, but the short version is that leakage of private network reverse DNS is incredibly common and these servers are set up to take the load off of IANA's real ones. - The nameserver software (or server operators) are more considerate than most and blackhole the query themselves. This is by far the least likely scenario. BIND implemented such a feature in 9.4.1. It is controlled by
empty-zones-enable
(default: yes), and the data returned is influenced by theempty-server
andempty-contact
options.