The Purpose of DNS Sub-Delegation

Let’s say you have acquired a static IP range from your ISP. Now that you have that range, you decide you also want to control the PTR records for these addresses as well. But, PTR records typically belong to the ISP. However, you do not want to depend on the ISP for each change you’d like to make; you want more control. How can your gain more control over those PTR records?

The way to gain this control is through DNS Sub-Delegation. DNS Sub-Delegation is when your ISP forwards PTR requests to your name server so that you can have control over your record updates. In other words, the ISP delegates their authority over their PTR records to your DNS server.

Prerequisites

If you understood the implications of that last sentence, you’ll realize that you will need your own local DNS service that controls your domain. After all, if you don’t control your own domain, how are you going to control the PTR records once they are delegated to you? In this post, we’ll assume that you will manage your PTR records with your own DNS server. If you don’t have your own DNS server, you should consult your hosting provider or domain registrar on how to take advantage of Sub-Delegation. But keep in mind, taking advantage of DNS Sub-Delegation will be next to impossible if you do not have control over your own domain. If you do not have your own DNS server, perhaps your hosting provide offers a web administration utility which can allow you to make your desired changes.

What You Need To Do First

Again– we’ll assume you have your own DNS server that controls your domains. You need to contact your ISP and request that your static IP range be Sub-Delegated to you. Confirm the network topology of your range so there won’t be any issues later. Also make sure you provide them with the host name of your master DNS server– as well as any slave servers that you use. Once they agree to delegate the PTR records to you, you’re halfway done.

What Comes Next?

After getting the ISP to agree to delegate the ranges to you, you need to configure your DNS server to be an authority for these ranges. Every IP range can be expressed as a zone, just as domain names are expressed as a zone in your main DNS configuration file.

For example, let’s assume your ISP has delegated to you the network 192.168.1.0/24. Normally, this would be a public address. However, it is conceivable that a large, private organization may delegate a range of private addresses between departments.

Let’s also assume the DNS server that you administer has an IP address is 172.16.118.4 with a host name of ns1.example.com. Again, this would normally have a public address but let’s continue to use private addresses for all of our examples.

So you’ll need to create the proper zone entry on your DNS server for this network. Log on to ns1.example.com— which is 172.16.118.4— and edit your main DNS configuration file and create the following zone stanza:

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

Save your changes.

What Does that Zone Entry Do?

Once the ISP delegates those PTR records to you, DNS queries will be forwarded to your name server from theirs. Because the queries will be forwarded to your name server, you must set up the appropriate zone information on your DNS server. However– until they make those necessary changes on their end, your zone entry will have no impact. But once the ISP makes those necessary changes on their side, your zone configuration will become authoritative for that network.

Let’s look at each line from the zone stanza to see what it all means.

1. The first line . . .

 zone "254/24.1.168.192.IN-ADDR.ARPA" {

This line defines the network you’ve been given as a zone. When IP addresses are expressed as a zone, the address is actually written backwards when compared to a human readable perspective. Take notice that (when read from left to right) the first number is the last usable network address of the network range. After the forward slash (/) we have the prefix or netmask that defines the network given to us by the ISP.

Following the network prefix, we have the first three octets of our network written in reverse order. Then we append .IN-ADDR.ARPA to the end of our address notation. IP addresses always have this information appended to them when they are expressed as a zone in the main DNS configuration file. Finally, we close off the notation with quotes and open our stanza with a curly bracket so we can specify the settings for this zone.

2. The next line designates the fact that the very name server we’re currently working on will be the master for this zone:

type master;

If you have a secondary name server, you’ll need to create a zone stanza there as well. The second and third line for a secondary server zone stanza would then read:

type slave;
masters { 172.16.118.4; };

With the above directive being the exception, the zone stanza for your secondary name server is identical to your primary server zone stanza.

3. The third line designates the db file that will contain the zone information.

file "db.192.168.1";

The db files on a DNS server hold all the resource records for a zone. In some cases, you may need to put the absolute path of the db file in your stanza like so:

file "/var/named/db.192.168.1";

How you’ve defined the root directory for named will decide whether or not you need to use the absolute path in this specific directive.

4. If your name server has an access list set up, then the directive . . .

allow-query { any; };

. . . permits other name servers to make queries concerning this zone. Without the allow-query directive, your access list in your main DNS configuration file may prevent other name servers from performing legitimate queries against your DNS server. This is not the same as client look-ups directly to your name server or zone transfers. This only applies to queries from other name servers working on behalf of their clients to know information about your zone.

5. The last bracket/semi colon combination: }; –closes the zone stanza. This is very important to do. Forgetting to close the stanza can cause your DNS server to fail upon restart. Or you’ll find in some cases that the DNS services will indeed start, but the daemon will ignore your stanza and your changes will not be realized as a result.

Create Your DB File

After creating the zone stanza in your DNS configuration file, you should build your db file. The db file needs to contain the actual resource records or PTR records that you wish to control. You designated the location of this file earlier when creating your zone stanza; therefore, make sure you create the db file in the appropriate directory. If you are using Redhat or CentOS, for instance, you would build this file in /var/named. A GUI intensive environment would have a wizard to guide you through creating the db file and populate it with the desired resource records.

If you were creating your db file from scratch on a Linux based system, you’d want to create the file something like this:

# vi /var/named/db.192.168.1

Then, add in the following lines:

$ORIGIN .
$TTL 86400      ; 1 day
254/24.1.168.192.IN-ADDR.ARPA IN SOA example.com. root.ns1.example.com.
 (
 201311180  ; serial YYYYMMDDX
 10800      ; refresh (3 hours)
 1800       ; retry (30 minutes)
 604800     ; expire (1 week)
 86400      ; minimum (1 day)
 )
 NS      ns1.example.com.
 NS      ns2.example.com.
$ORIGIN 254/1.168.192.IN-ADDR.ARPA.
 1     PTR     router.example.com.
 2     PTR     router2.example.com.
 3     PTR     mail1.example.com.
 4     PTR     mail2.example.com.
 5     PTR     webmail.example.com.
 6     PTR     www.example.com.
 ; ... (truncated)
 253   PTR     reserved-192.168.1.253.example.com.
 254   PTR     reserved-192.168.1.254.example.com.
 ;
 ;255 -- do not assign. this is the broadcast address.

You don’t have to create “place holder” records for unused addresses if you don’t want to. However, some organizations even want their unused records to resolve to something. Consider using a Perl script or a bash script to create your place holder entries if you feel compelled to create a record for each usable address.

Notice that each record has a dot (.) at the end of each line. This is essential. If you leave omit the dots, your name server will not read your db file as you intend.

After the Zone Stanza and DB File Are Created . . . Restart DNS

Assuming you have no typographical errors, you should now reload your DNS server. After that, your server is ready to answer requests for your new, sub-delegated PTR records. Now, the only thing holding you back is whether or not the ISP did their part and properly delegated the addresses to your name server.

Troubleshooting

If you think your delegation should be working– yet it’s not– then start retracing your steps. Contact your ISP and have them confirm that they made the necessary changes on their end. Confirm the network range that was delegated to you– just in case you accidentally set up your zone a slightly different network address. Also, keep in mind that a few hours may need to transpire before all changes between you and your ISP take effect. Next, double check your zone stanza and db file. Check your error logs– either /var/log/messages or /var/named/data/named.run for any clues which might indicate a typographical error or a poor configuration setting somewhere in your DNS configuration files.

If everything looks correct, wait a few hours. Then, check if all the changes have taken effect. Use you’re favorite search engine to find a website that verifies DNS delegation. Or, use the dig command to confirm delegation is working. Use the +trace option with dig to the output to show how your query traverses from the root servers to the final destination which answers your query. Also use the -x option as well, so you can run this trace as a reverse look-up for one of your PTR records. The command and output will be similar to this:

$dig +trace -x 192.168.1.4
; <<>> DiG 9.8.4-P1-RedHat-9.8.4-3.P1.fc16 <<>> +trace -x 192.168.1.4
;; global options: +cmd
.			80147	IN	NS	l.root-servers.net.
.			80147	IN	NS	h.root-servers.net.
.			80147	IN	NS	c.root-servers.net.
.			80147	IN	NS	i.root-servers.net.
.			80147	IN	NS	j.root-servers.net.
.			80147	IN	NS	g.root-servers.net.
.			80147	IN	NS	e.root-servers.net.
.			80147	IN	NS	d.root-servers.net.
.			80147	IN	NS	m.root-servers.net.
.			80147	IN	NS	a.root-servers.net.
.			80147	IN	NS	b.root-servers.net.
.			80147	IN	NS	k.root-servers.net.
.			80147	IN	NS	f.root-servers.net.
;; Received 449 bytes from 172.16.118.4#53(172.16.118.4) in 681 ms

in-addr.arpa.		172800	IN	NS	f.in-addr-servers.arpa.
in-addr.arpa.		172800	IN	NS	c.in-addr-servers.arpa.
in-addr.arpa.		172800	IN	NS	d.in-addr-servers.arpa.
in-addr.arpa.		172800	IN	NS	e.in-addr-servers.arpa.
in-addr.arpa.		172800	IN	NS	b.in-addr-servers.arpa.
in-addr.arpa.		172800	IN	NS	a.in-addr-servers.arpa.
;; Received 418 bytes from 2001:dc3::35#53(2001:dc3::35) in 424 ms

12.in-addr.arpa.	86400	IN	NS	ns1.your.isp.dns.server.com.
12.in-addr.arpa.	86400	IN	NS	ns2.your.isp.dns.server.com.
12.in-addr.arpa.	86400	IN	NS	ns3.your.isp.dns.server.com.
;; Received 142 bytes from 2001:500:87::87#53(2001:500:87::87) in 262 ms

3.1.168.192.in-addr.arpa. 83000	IN	CNAME	3.1/24.1.168.192.in-addr.arpa.
1/24.1.168.192.in-addr.arpa. 83000 IN	NS	ns1.example.com.
1/24.1.168.192.in-addr.arpa. 83000 IN	NS	ns2.example.com.
;; Received 116 bytes from 2001:1890:1ff:9f0:68:94:156:134#53(2001:1890:1ff:9f0:68:94:156:134) in 40 ms

Notice in the above output example how the dig command traces out your query starting with the main root name servers, then to your ISPs name servers and finally ends with yours. Results like these confirm that your ISP is referring queries to your name server for reverse look-up resolution. This is confirmation that sub-delegation is working. Now, you have control over the PTR records delegated from your ISP.

Recap

In this post, we have demonstrated how to request from your service provider control over PTR records that actually belong to them. This situation assumes you have requested a range of static IP addresses from your ISP, but you also desire control over their DNS records as well.

In a future post, we will discuss sub-delegation from the perspective of the ISP. What if you were working at a large private organization or administering a DNS server for an ISP? How would you configure sub-delegation from that perspective? We’ll discuss that aspect of sub-delegation in the second half of this post.