The pointer (PTR) record and Reverse mapping Explained (2024)

Developers developed the DNS system mainly for forward mapping. In forward mapping, name servers translate names into IP addresses. Later, they added reverse mapping to the DNS system for security and diagnostic purposes. In reverse mapping, name servers translate IP addresses into names. It is an optional feature.

Although reverse mapping is optional, you should use it. In modern computer networks, many services use it to authenticate the source address. For example, email service uses it to verify the source email address. If you do not configure reverse mapping for a domain, other domains will not accept emails originating from it.

How does the name resolution process work in forward mapping?

In the DNS system, when an end device wants to know the IP address of a remote device or service, it sends a name resolution query to the resolver system. The resolver system forwards that query to all name servers in a sequence until it finds the answer.

This sequence is known as the DNS namespace. In other words, the DNS namespace is a sequence of domain names arranged in a hierarchy. A domain name is a text label for the domain. In this hierarchy, the root domain stands at the top. It uses a null character as the label.

You can write a resource name with or without its parent's domain name. If you write its name with parent domain names, it is called an FQDN (Fully Qualified Domain Name) name. An FQDN name uses dots (.) to separate domain names. It starts with the resource's name and ends with the root domain's name. Since the root domain uses a null character as the name, it always ends with a dot.

An example of the FQDN name is ftp.example.com. In this name, ftp is the resource name. It is the child of the example domain. The example domain is the child of the com domain. The com domain is the child of the root domain.

Each domain uses an authoritative name server to resolve queries for resources available inside it. If it has a child domain, it does not resolve queries for the child domain. It provides a referral to the child domain's authoritative name server.

Only authoritative name servers can resolve queries. If a name server is not authoritative for a domain, it provides a referral to the next authoritative name server in the sequence. Since all authoritative name servers work in a hierarchy, a resolver system can easily reach the authoritative name server that can resolve its queries.

If a resolver system wants to know the IP address of ftp.example.com., it will send its first query to the root name server. The root name server will provide a referral to the com name server. The com name server will provide a referral to the example name server. The example name will provide the IP address of the host running the ftp service.

The above process is an example of forward mapping. Developers developed the DNS system for it.

How does the name resolution work in reverse mapping?

Now, let us reverse the above process. Suppose the resolver system wants to know the name of the IP address 192.168.0.3. For this, it follows the same steps it uses in forward mapping. It sends the first query to the root name server and follows the referral until it gets the answer.

Unlike FQDN names, IP addresses do not include domain names. An IP address includes two types of addresses: the network address and the host address. For example, in the IP address 192.168.0.3, the network address is 192.168.0, and the host address is 3.

Network addresses are used to organize and find IP addresses. Host addresses are used to provide a unique identity to an endpoint or a resource. A network address is like a domain name. A host address is similar to a resource name.

Since IP addresses do not include domain names, developers used a different approach to build a domain tree for IP addresses in the DNS namespace. They created a domain called ARPA (Advanced Research Projects Agency) as a child domain of the root domain and used it to build a domain tree for IP addresses.

There are two versions of IP addresses: IPv4 and IPv6. To keep the IP addresses of both versions separate, they created two additional domains as the child domains of the ARPA domain. For IPv4 addresses, they created the in-addr domain. For IPv6 addresses, they created the ip6 domain. They constructed the domain tree for both versions inside their respective domains. To construct a domain tree for IP addresses, they used network addresses.

But there was a problem. Unlike domain names which are written from right to left in FQDN names, network addresses are written from left to right in IP addresses. To solve this problem, they flipped the IP addresses in the domain tree. For example, the IP address 192.168.0.3 will be written as 3.0.168.192 in the domain tree.

The DNS system uses FQDN names. An FQDN name includes all parent domain names. To convert this address into the FQDN address, we need to write its parent domain's name with it. 192.168.0.3 is an IPv4 address. The parent domain of IPv4 addresses is in-addr. The in-addr domain is the child of the ARPA domain. The ARPA is the child domain of the root domain. Because of this, the FQDN name of the IP address 192.168.0.3 will be 3.0.168.192.in-addr-arpa.

If the resolver system wants to know the name of the service or host using the IP address 192.168.0.3., it sends the first query to the root name server. The root name server provides a referral to the arpa name server. The arpa name server provides a referral to the in-addr name server. The in-addr name server provides a referral to the 0.168.192 name server. The 0.168.192 name server provides the name associated with host address 3.

The above process is an example of reverse mapping. Developers added it to the DNS system for security and diagnostic purposes.

Zone files

Authoritative name servers use zone files to provide the name resolution service. There are two types of zone files: forward lookup zone file and reverse lookup zone file. A forward lookup zone file maps names with IP addresses. A reverse lookup zone file maps IP addresses with names. If you do not want to provide reverse lookup for a domain, you do not need to create reverse lookup zone files for it.

There are two versions of IP addresses: IPv4 and IPv6. You can use a single forward lookup zone file to map names with IP addresses of both versions. But you cannot use a single reverse lookup zone file to map both versions' IP addresses with names. You need to use separate reverse lookup zone files for both versions.

You only need to create a reverse lookup zone file for the IP version your domain uses. For example, if your domain does not use IPv6 addresses, you do not need to create a reverse lookup zone file for IPv6 addresses.

Forward lookup zone files are compulsory. You need to create a forward lookup zone file for every domain. In that file, you need to add records for all resources whose names you want to translate.

Reverse lookup zone files are optional. You only need to create a reverse lookup zone file for the domain which runs services that need reverse mapping. In that file, you need to add records only for those services that need reverse mapping.

A reverse lookup zone file uses the same configuration style as a forward lookup zone file. You can easily create a reverse lookup zone file from the forward lookup zone file.

I have already explained the directives, resource records, and configuration settings used in forward lookup zone files in previous tutorials of this series. If you have not checked them yet, I suggest you check them with this tutorial. Previous tutorials of this series are the following.

The following points provide a brief recap of previous tutorials.

• Authoritative name servers use zone files to resolve DNS queries.
• You can store three things in a zone file: comments, directives, and resource records.
• A comment starts with a semicolon and goes to the end of the line. If you put a semicolon at the start of a line, the name server ignores the entire line. If you put a semicolon in the middle of the line, the name server ignores everything that comes after the semicolon.
• A directive works as a variable. You can use it to store a value you want to use later in the file.
• The TTL directive defines the maximum time a resource served from the file can be cached.
• The ORIGIN directive defines the domain name. The name server uses it to convert all relative names that come after it into FQDN names.
• In a zone file, the name server considers all names that do not end with a dot as relative names.
• An FQDN name ends with a dot. The name server uses it as it is.
• A zone file uses resource records to map names and IP addresses.
• There are many types of resource records. The vital resource record types are the SOA, NS, MX, A or AAAA, CNAME, and PTR.
• An SOA record defines the characteristics and properties of the domain.
• An NS record defines the authoritative name servers for the domain.
• An MX record defines mail servers for the domain.
• An A or AAAA record maps a name with the IP address.
• A CNAME record maps an alias name with the canonical name.
• A PTR record maps an IP address with the name.

Creating a reverse lookup zone file

Administrators configure the name server to handle forward and reverse mapping separately. They configure two separate zone files for forward and reverse mapping. In forward mapping, the query will be for a resource available within the example.com domain. In reverse mapping, the query will be for a resource available within the 192.168.0 network.

If the name server receives a query for the resource available within example.com, it uses the forward zone file to resolve the query. If it receives a query for the resource available within network 192.168.0, it uses the reverse zone file to resolve the query.

The following image shows the forward zone file of the example.com domain.

The following is a reverse lookup zone created from this forward lookup zone file. The name server will use to resolve queries for the resources available in the network 192.168.0.

Let us understand this file's configuration in detail.

The first line is a comment. The name server will ignore it.

The next is the TTL directive. It defines the maximum time other name servers or resolver systems can cache records severed from this file.

The next is the ORIGIN directive. It defines the domain name. As explained earlier, in reverse mapping the domain name is the network address of the domain. To convert it into an FQDN name, we need to follow two steps. First, we need to flip it then we need to add the parent domain's name to it. In our example, the domain's network address is 192.168.0. If we flip this address, we get 0.168.192. With the parent domain's name, it will be 0.168.192.in-addr-arpa.. Zone files are not case-sensitive. You can specify a name in both upper and lower cases.

The next is an SOA record. It defines the characteristics and properties of the domain.

The next is the NS record. It defines authoritative name servers for this domain.

The SOA and NS are compulsory records. These records are the same in both the forward and reverse zone files. You can copy them from the forward zone file. To learn more about these records, you can check previous tutorials of this series.

The next is PTR records.

As mentioned earlier, developers developed the DNS system to translate resource names into IP addresses or alias names. At that time, there was no requirement to translate IP addresses into resource names. Since this feature was not required, they did not develop it in the original DNS system.

When the need for this feature arose, they developed a method to use IP addresses as alias names. Since the existing DNS system already had the necessary functionality for translating alias names, they did not require to modify it.

The existing system uses CNAME records to map alias names with canonical names. They created a new resource record type called PTR from this resource record type.

PTR records do the same thing in the reverse lookup zone file that CNAME records do in the forward lookup zone file. They map alias names (which are actually IP addresses) to canonical names (resources' original names).

A PTR record uses the following syntax.

name (host portion of the IP address) TTL class resource-record-type name (name of the resource)

Let us understand the above syntax field-by-field.

The name Field

This field defines the resource's IP address as the name. You can convert the resource's IP address into the FQDN name and use it in this field or you can type only the host portion of the IP address and the name server will automatically convert it into the FQDN name using the $ORIGIN directive's value.

For example, the IP address of ns1.example.com. is 192.168.0.1. If you want to specify the FQDN of this IP address, you need to use the following.

1.0.168.192.-in-addr-arpa.

If you want to specify only the host portion of the IP address, you need to type 1 in this field.

The name server considers all names that do not end with a dot as relative names. It automatically attaches the value of the $ORIGIN directive to it to convert it into the FQDN name.

The TTL Field

This field defines the maximum time the resolver system can cache this record. If we leave this field empty, the name server uses the $TTL directive's value.

The class Field

This field defines the class type of this record. There are three classes: IN, CH, and HS. Currently, only the IN class is used. The CH and HS classes were used when the Internet was an in-house project in the MiT lab. CH stands for CHAOS. It is an MIT LAN protocol. HS stands for Hesiod. It is an information service used at MIT. IN stands for the Internet that we use today.

The resource-record-type Field

This field defines the type of record. A PTR (Pointer Record) record maps an IP address (defined as a name in the first name field) to the name (resource's name defined in the last name field.)

The name Field

This field defines the resource's name. The name server provides this name when it receives a query for the IP address defined in the first name field. You can not use the relative name in this field. You must use the FQDN name of the resource in this field.