Reverse DNS

What is reverse DNS?

In the previous section we were introduced to a number of records which are used by the DNS system to resolve fully-qualified host-names to their associated IP address. It should therefore come as no great surprise to learn that there is a process whereby a DNS server can be used to resolve the fully-qualified host-name from an IP address. This process is generally referred to as reverse DNS.

This section should not be considered a complete discussion of, or configuration for, the implementation of reverse DNS. It is merely an example which should enable even a novice user to implement reverse DNS on their network. For a full discussion of reverse DNS please refer to the resources section at the end of this guide.

 

Creating a reverse DNS domain

For the following example we shall assume that we are configuring reverse DNS for an internal network using IP addresses in the 192.168.0.0/24 range. With this in mind the first task is to create an entry in the domains table so that the PowerDNS daemon knows that we are hosting such a domain and that native replication semantics shall be used.

postgres=# INSERT INTO domains(name, type) VALUES('0.168.192.in-addr.arpa', 'NATIVE'); 

INSERT 0 1 

As you can see the above values are slightly less obviously understood than those we used when we created a forward lookup domain earlier. Simply put the name field for a reverse lookup domain consists of the network portion of the address, so in our example the first 24 bits, reversed and entered as a sub-domain of the in-addr domain on the arpa TLD.

As before, when we created the forward DNS domain records, we need to know the value of the id field which will have been automatically assigned to this record by the PostgreSQL database. To do this we can issue the simple SQL query shown below which should result in output similar to that shown. As you can see the value of the id field for the 0.168.192.in-addr.arpa domain in this example is 2.

postgres=# SELECT * FROM domains; 

 id |         name           | master | last_check |  type  | notified_serial | account 

----+------------------------+--------+------------+--------+-----------------+--------- 

  1 | hacking.co.uk          |        |            | NATIVE |                 | 

  2 | 0.168.192.in-addr.arpa |        |            | NATIVE |                 | 

(2 rows) 

Creating SOA and NS records for a reverse DNS domain

In the same way that a forward zone requires an SOA record to indicate that this domain name server has authority to respond on behalf of a zone a reverse zone requires a very similar record. In fact, as you can see in the example below, the SOA record is identical except it is now being entered with the 0.168.192.in-addr.arpa domain instead of the hacking.co.uk domain in the name field.

postgres=# INSERT INTO records(domain_id, name, type, content, ttl, change_date) 

postgres-#   VALUES(2, '0.168.192.in-addr.arpa', 'SOA', 'ns1.hacking.co.uk hostmaster.hacking.co.uk', 86400, 2008032801); 

INSERT 0 1 

Likewise the reverse domain requires an NS record, which also differs only in the value of the name field as can be seen in the example. This record is primarily used to delegate reverse zones to other name servers although every reverse zone, delegated or not, still requires one.

postgres=# INSERT INTO records(domain_id, name, type, content, ttl, change_date) 

postgres-#   VALUES(2, '0.168.192.in-addr.arpa', 'NS', 'ns1.hacking.co.uk', 86400, 2008032801); 

INSERT 0 1 

Creating PTR records for a reverse DNS domain

Once the SOA and NS records have been added to the domain we can, as when we implemented forward DNS, begin to add entries in the records table so that we can resolve all the IP addresses of our hosts to their fully-qualified host names. Unlike when we implemented forward DNS in the previous section we shall not be using A records for this purpose but instead shall be using their reverse DNS equivalent the PTR record.

postgres=# INSERT INTO records(domain_id, name, type, content, ttl, change_date) 

postgres-#   VALUES(2, '3.0.168.192.in-addr.arpa', 'PTR', 'ns1.hacking.co.uk', 3600, 2008032801); 

INSERT 0 1 

You can see in the above example that the format of these records is very similar to that of the A record we used when we implemented forward DNS. The name field contains the name of the host which will be resolved, and in this case as we are configuring reverse DNS this is the IP address of the host reversed with the usual .in-addr.arpa domain appended to it. The address field therefore contains the fully-qualified host-name which belongs to this IP address.

Just like the A record a host may have multiple PTR records associated with it in the DNS system. In the case of reverse DNS this would indicate that multiple different A records point to the same IP address. Some applications will crash however if they receive a DNS response containing multiple PTR records.

 

Testing our configuration

Now that we have a complete configuration, albeit another rather minimal one, we are ready to test to see if our new DNS server is correctly answering reverse DNS queries for our network. To do this we shall, as always, use the dig application from the net-dns/bind-tools package we installed earlier. An example dig command to query the PTR record for the 192.168.0.3 network address is given below.

; <<>> DiG 9.4.1-P1 <<>> -x 192.168.0.3 

;; global options:  printcmd 

;; Got answer: 

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32449 

;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 

;; WARNING: recursion requested but not available 

;; QUESTION SECTION: 

;3.0.168.192.in-addr.arpa.        IN     PTR 

;; ANSWER SECTION: 

3.0.168.192.in-addr.arpa. 3600    IN     PTR    ns1.hacking.co.uk. 

;; Query time: 2 msec 

;; SERVER: 192.168.0.3#53(192.168.0.3) 

;; WHEN: Fri Mar 28 14:11:28 2008 

;; MSG SIZE  rcvd: 89 

Assuming everything has gone well thus far you should be presented with output similar to that shown above. The most important output, obviously, is the Answer Section which contains the answer to the PTR query we sent.