From the Service Provider’s Perspective

In part one of this topic, we discussed how to manage a sub-delegation for reverse DNS records once your ISP provides this service for you. Here in part two, we’ll discuss how to provide the sub-delegation of a reverse DNS range to another user. So in this situation, think of yourself as the provider offering the service for a customer or end user.

What You’ll Need

After you have received the request from the customer, you will need to confirm that they have created the proper zone for the delegated network.To see examples of how their zone should look, refer to part one of this post. You will also need to have the host name of their DNS server(s); Have that information handy when you configure your DNS settings.

You will also need to have the zone in question properly set up in your DNS server as well. Keep in mind that the end user’s zone entry will look different from yours. Again, see part one as a guide to how their zone should look.

Configure the Zone

Let’s use the network 192.168.1.1/24 as the range the you’re sub-delegating; In this example, your zone in /etc/named.conf should look like this:

zone "1.168.192.IN-ADDR.ARPA" {
     type master;
     file "db.192.168.1";
     allow-query { any; };
};

Let’s assume your master DNS server has an IP of 10.0.0.3. If that were the case, your secondary DNS zone file would look like this:

zone "1.168.192.IN-ADDR.ARPA" {
     type slave;
     masters { 10.0.0.3; };
     file "db.192.168.1";
     allow-query { any; };
};

Remember to reload your DNS daemon so the configuration file can be re-read. In most Red Hat based distributions the command would be:

service named reload

Check your logs for any errors. Usually a typographical error will prevent named from loading your changes. In such an event, check for a missing semi-colon or a missing bracket from either the whole stanza or one of your directives.

Configure the DB File for the Zone

Now that your zone is configured, you need to properly set up your records so that any reverse queries will be forwarded to the delegated DNS server of choice– which should be the end user’s DNS server.

This syntax will be reminiscent of the zone set up in part one. Let’s assume we’re delegating all the usable addresses in 192.168.1.1/24 to our customer. Our customer’s DNS server is dns1.example.com. Our DNS server will be ns1.hostprovider.com and ns2.hostprovider.com respectively. Here’s how the delegation syntax would look inside our DB file /var/named/db.192.168.1:

$ORIGIN .
$TTL 86400      ; 1 day
1.168.192.IN-ADDR.ARPA IN SOA hostprovider.com. root.ns1.hostprovider.com.
 (
 201312300  ; serial YYYYMMDDX
 10800      ; refresh (3 hours)
 1800       ; retry (30 minutes)
 604800     ; expire (1 week)
 86400      ; minimum (1 day)
 )
 NS      ns1.hostprovider.com.
 NS      ns2.hostprovider.com.

$ORIGIN 1.168.192.IN-ADDR.ARPA.

; designate the DNS server that will handle lookup requests \
for the delegated network:
1/24    IN NS    dns1.example.com.
1        IN CNAME    1.1/24.1.168.192.IN-ADDR.ARPA.        
2        IN CNAME    2.1/24.1.168.192.IN-ADDR.ARPA.
3        IN CNAME    3.1/24.1.68.192.IN-ADDR.ARPA.
. . .
254        IN CNAME    254.1/24.1.168.192-IN-ADDR.ARPA.
; 255    BROADCAST ADDRESS -- DO NOT ASSIGN

Let’s say we only wanted to delegate the usable addresses from 192.168.1.128/27 and use the rest of the range for something entirely unrelated. How would that look? Your DB file would look like this, instead:

$ORIGIN .
$TTL 86400      ; 1 day
1.168.192.IN-ADDR.ARPA IN SOA hostprovider.com. root.ns1.hostprovider.com.
 (
 201312300  ; serial YYYYMMDDX
 10800      ; refresh (3 hours)
 1800       ; retry (30 minutes)
 604800     ; expire (1 week)
 86400      ; minimum (1 day)
 )
 NS      ns1.hostprovider.com.
 NS      ns2.hostprovider.com.

$ORIGIN 1.168.192.IN-ADDR.ARPA.
1          IN     PTR        router.hostprovider.com.
2          IN     PTR        router2.hostprovider.com.
. . .
126        IN     PTR        placeholder-126.hostprovider.com.
127        IN     PTR        placeholder-127.hostprovider.com.
; the lines above are not delegated to our end user
; then next line designates the DNS server that will \
; handle lookup requests for the delegated network:
128/27    IN    NS    dns1.example.com.

; remember, the line just above is the customer's DNS server
;128    NETWORK ADDRESS - DO NOT ASSIGN
129        IN CNAME    129.128/27.0.0.10.IN-ADDR.ARPA.
130        IN CNAME    130.128/27.0.0.10.IN-ADDR.ARPA.
131        IN CNAME    131.128/27.0.0.10.IN-ADDR.ARPA.
. . .
158        IN CNAME    158.128/27.0.0.10.IN-ADDR.ARPA.
; 159    BROADCAST ADDRESS - DO NOT ASSIGN
; this ends the delegation network delegation range.
; the following records are not delegated to the end user.
160        IN PTR        placeholder-160.hostprovider.com.
. . .

So here, we see delegated ranges can be mix in with non-delegated ranges. Or, you can take several subnets from a /24 network and delegate them to various customers.

Watch Out!

Make sure your customer has everything set up on their end before you commit the changes on your server. Otherwise, their DNS server will not properly respond to the referrals which are redirected by your DNS server. Be sure that your customer or end user is aware that you’re committing your changes before hand.

You can verify everything is working using the dig command:

$dig +trace -x 192.168.1.130

The output should show that your DNS servers have referred you to the end user’s DNS server. Their DNS server is now able to resolve the PTR record because you delegated their server to do so. If you notice in your dig output that you were referred to their DNS server– yet the PTR record still fails to resolve– then the end user needs to double check their zone configuration and ensure they reloaded their DNS service after making changes. If you were not referred to their DNS server at all and dig still resolves the PTR record from your DNS server– then double check your DB file in /var/named. Did you change the serial number near the top of your DB file and reload DNS? Did you leave off a trailing (but essential) dot on one of your CNAME records? Did you see any syntax errors or failure messages in /var/log/messages after reloading named? Be sure to check your zone file for any missing brackets, dots, or semicolons. Once you’ve cleared up any of these common issues, you should see the desired results verified by dig.

The Usefulness of Reverse DNS Sub-Delegation

Sub-Delegation for Reverse DNS is useful because it can empower the customer while freeing up the hands of the provider to perform other administrative tasks. The set-up can be a bit tricky on either side due to syntax that might seem unintuitive at first. However, taking the time to understand how to accomplish this sub-delegation can be a worthwhile effort.