Reverse DNS: Difference between revisions
imported>David MacQuigg (simplify example. LInk to FCrDNS) |
imported>David MacQuigg (Clarify "IP name") |
||
Line 12: | Line 12: | ||
== Examples == | == Examples == | ||
=== Email authentication === | === Email authentication === | ||
Here is what a reverse DNS query looks like | Here is what a reverse DNS query looks like after an email receiver gets a [[TCP]] connection request from a transmitter at [[IP address]] '''98.136.44.63.''' A reverse DNS query on that address returns an "IP name". In this example, the IP name is a hostname for an email transmitter. In general, it can be any fully-qualified domain name the network owner chooses to associate with that IP address. See [[Forward-confirmed reverse DNS]] for more discussion.<br /> | ||
$ dig ptr 63.44.136.98.in-addr.arpa | $ dig ptr 63.44.136.98.in-addr.arpa | ||
... | ... |
Revision as of 17:05, 28 October 2009
On the Internet, reverse DNS lookup or reverse DNS mapping (rDNS) is using the Domain Name System (DNS) to look up a name that is associated with a given IP address.
With normal, or forward DNS, a domain name is used to look up information associated with that domain, including the IP addresses of its nameservers, webservers, and mailservers, and any general text information the domain owner would like to publish, including authentication records for the domain's mail transmitters. With reverse DNS, an IP address is used to look up a name associated with that address.
Information in forward DNS is under the control of the domain owner. Information in reverse DNS is under the control of the network owner, or at least the lowest owner to which authority over a block of addresses has been delegated.
In general, reverse DNS is not as reliable as forward DNS. This is due to the communication barriers between owners of small domains and owners of large networks, and the lack of incentive for network owners to keep reverse DNS records up to date. Often they simply run a script which assigns numerical names in sequence to each address in their allocation. These automated names have no connection with the actual use of the address.
Another factor making reverse DNS problematic is the trend to Virtual Private Servers - using one machine and IP address to host many unrelated domains. While it is possible to publish multiple names for one IP address, the resulting uncertainty can frustrate an authentication method relying on reverse DNS.
Examples
Email authentication
Here is what a reverse DNS query looks like after an email receiver gets a TCP connection request from a transmitter at IP address 98.136.44.63. A reverse DNS query on that address returns an "IP name". In this example, the IP name is a hostname for an email transmitter. In general, it can be any fully-qualified domain name the network owner chooses to associate with that IP address. See Forward-confirmed reverse DNS for more discussion.
$ dig ptr 63.44.136.98.in-addr.arpa ... ;; ANSWER SECTION: 63.44.136.98.in-addr.arpa. 1200 IN PTR smtp108.prem.mail.sp1.yahoo.com. ...
Explanatory notes
The text forms shown here are from a terminal session using the BIND utility 'dig'. In a real mail receiver, the query and response would be packets of binary data.
in-addr.arpa is the branch of DNS holding all reverse query information. ARPA was the US government agency which started the Internet. The registry in now under the control of ICANN.
PTR is a "pointer" record in DNS. It "points" an address to a name, the opposite of an A record, which points a name to an address.
The numbers in the ptr query are reversed, because of the way authority is delegated from the largest blocks to smaller blocks of IP addresses. In the query, numbers are just treated as normal characters, so '63' is a subdomain of '44', which is a subdomain of '136', etc.