PTR record: How does the DNS record work?

The domain name system (DNS) sim­pli­fies online com­mu­nic­a­tion. Its most well-known function is probably name res­ol­u­tion. This enables a user to enter a URL in the browser and still establish a con­nec­tion via an IP address. For this to work, the DNS, or more spe­cific­ally, the re­spons­ible name servers, access the zone files. These are simple text files in which DNS records are listed line for line. At the same time, name res­ol­u­tion is performed via A records or AAAA records. E-mail con­nec­tions are enabled with MX records.

PTR records ef­fect­ively con­sti­tute the coun­ter­part to A records. Instead of assigning a domain name to an IP address, the link occurs the other way around. In this way, PTR records make reverse DNS possible.

PTR stands for “Pointer.” The name already gives you an initial idea of what is achieved with the record type. A PTR record refers to an object: the domain name. This makes the reverse DNS (rDNS) or reverse lookup possible. Typically, a user would like to establish a con­nec­tion to a server with a domain name that’s already known, but they do not have the correct IP address. In the case of a reverse request, the process occurs in the exact opposite direction: The IP address is already known and the user wishes to find out what the ap­pro­pri­ate domain is called or under which URL it can be reached.

A PTR record’s structure is similar to that of the other record types. The various pieces of in­form­a­tion are arranged in the record one after another in fields.

• <name>: The first field in the PTR record is filled with the IP address
• <ttl>: The time to live specifies the time in seconds that an entry is valid for, before it needs to be activated again
• <class>: This field contains the ab­bre­vi­ation of the network class being used
• <type>: In this case, PTR is located in the fourth position in order to define the record type
• <rdata>: Finally, the last field contains the resource data – the domain name

All fields are arranged according to the sequence within a line. The fields are not separated by a symbol; a space is suf­fi­cient. The line and hence the record are only ended through the use of a line break.

The syntax is struc­tured exactly as it is in an A record, only the field content is different. Initially, the IP address is specified. For this, both the IPv4 and IPv6 addresses are valid. But there is one special char­ac­ter­ist­ic to keep in mind: reverse mapping is used here. The IP address is therefore specified in reverse sequence.

If using an IPv4 address, however, it only involves octets. Within the specific groups, the serial number sequence remains unchanged. It is different with IPv6 addresses: With them, each number and/or letter is reversed and separated from the next value with a full stop. Even leading zeros, which are normally omitted in hexa­decim­al notation, are written out in PTR records.

The zone also has to be specified. Here, there are two that are possible, again depending on whether an IPv4 or IPv6 address is concerned. The former receives the extension in-addr.arpa., the latter ip6.arpa.

The time to live specifies the duration that a record is still valid for. If the time period has lapsed, the in­form­a­tion has to be requested again. This way, the DNS avoids the problem of having possibly outdated records held in the cache, which can then lead to con­nec­tion issues. Usually, however, this field does not appear in the record itself. Instead, with the directive $TTL at the beginning of the file, time is de­term­ined for the entire zone. The TTL is specified in seconds.

Today, the class field is only of his­tor­ic­al sig­ni­fic­ance. When the DNS was being developed, there were still two other network projects: Hesiod (with the ab­bre­vi­ation HS) and Chaosnet (rep­res­en­ted by CH)). Both are no longer used, which is why only internet is possible for the class. For this reason, this field normally contains the ab­bre­vi­ation IN or is com­pletely omitted. When left blank, the system is based on the usual standard, which in turn is the internet. For this kind of record, the type is un­der­stand­ably always PTR. In the final data field, the domain name can then be found – again in FQDN notation.

As an example, let’s assume that a user knows example.org’s IP address, but doesn’t know which domain is behind it. The address reads 2606:2800:220:1:248:1893:25c8:1946 and 93.184.216.34. In order for the user to use reverse DNS, we make PTR records available. These would then be struc­tured the following way in this example:

Here, we have de­term­ined the time to live at the beginning of the file so that it is valid for all records. Both PTR records then follow, each con­tain­ing the IP addresses ref­er­en­cing the domain names. These enable the reverse lookup.

The results appear under the “Answer” item. The service im­me­di­ately provides two different servers whose names can be found under “Data.” As you can see, both have the same value with respect to the TTL, which indicates an al­loc­a­tion for the entire zone.

For type, you’ll find a number instead of an ab­bre­vi­ation. The Internet Assigned Numbers Authority (IANA) has given each record type an in­di­vidu­al value, assigning each of them a serial number. The PTR record is as­so­ci­ated with the number 12.

The verified IP address is actually part of the google.com domain. The answers, however, point directly to internal server names that are not for public use and also don’t function as URLs.