HOWTO - Delegate a Sub-domain (a.k.a. subzone)
This page describes configuring BIND to fully delegate the responsibility for a sub-domain to another name server(s). This is not the only possible method of defining sub-domains (virtual - or pseudo - subdomains). The following defines the hierarchy we want to create:
- zone (domain) name = example.com
- domain host name = bill.example.com
- sub-domain name = us.example.com
- sub-domain host name = ftp.us.example.com
To ease the administration load we want to fully delegate the responsibility for the administration of the us sub-domain (and its reverse-lookup) to the us.example.com management group.
This HOWTO assumes that the name servers for our zone (example.com) are all in our domain (in-zone). If they are not, the actual configuration is exactly the same but you will have to convince the out-of-zone name server administrators to carry out the configuration changes. If we own the name servers we can do what we like!
Finally, it is important to remember that as far as the internet registration authorities and root/TLD name-servers are concerned sub-domains do not exist. All queries for anything which ends with example.com will be directed to the name-servers for the example.com zone. The example.com name servers are responsible for referring (redirecting) the query to any sub-domain name-servers.
For want of any better terminology we use the terms domain name-servers (these are visible to registration authorities) and sub-domain name-servers (visible only to the domain name-servers).
We received some mail which suggested that we show the explicit use of the allow-transfer statement. The samples in Chapter 6 all show this statement in use but for anyone just using this section it is included for the same of consistency.
domain Name Server Configuration
The name servers for our domain are running BIND and have a named.conf file that defines the zone.
Domain Name-Server named.conf
The 'named.conf' file will contain statements similar to the following fragment defining the main zone:
// named.conf file fragment
....
options {
....
// disable all zone transfers
allow-transfer {"none";};
....
};
zone "example.com" in{
type master;
file "master/master.example.com";
// explicitly allow zone transfer from slave
allow-transfer {192.168.0.4;};
};
// optional - we also act as the slave (secondary) for the delegated domain
// if both name servers for the delegated subdomain are in the subdomain
// this is not required
zone "us.example.com" IN {
type slave;
file "slave/slave.us.example.com";
masters {10.10.0.24;};
};
The optional definition of a slave (secondary) name server for our delegated us.example.com sub-domain is probably good practice but not essential - you can define it to be any name server.
Bad Practice: Techically you only need 2 (or more) name servers for globally visible services (TLD name servers), in this case the main domain. A subdomain could use only 1 name server saving a lot of configuration. Bad news: the domain is non-resilient. The name server is down, the subdomain is dark (ain't reachable). Not good practice for any but perennial optimists.
Domain Name-Server Zone File
The file 'master.example.com' (or whatever naming convention you use) will contain our domain configuration with two name servers.
; zone fragment for example.com
; name servers in the same zone
$TTL 2d ; default TTL is 2 days
$ORIGIN example.com.
@ IN SOA ns1.example.com. hostmaster.example.com. (
2003080800 ; serial number
2h ; refresh = 2 hours
15M ; update retry = 15 minutes
3W12h ; expiry = 3 weeks + 12 hours
2h20M ; minimum = 2 hours + 20 minutes
)
; main domain name servers
IN NS ns1.example.com.
IN NS ns2.example.com.
; main domain mail servers
IN MX 10 mail.example.com.
; A records for name servers above
ns1 IN A 192.168.0.3
ns2 IN A 192.168.0.4
; A record for mail server above
mail IN A 192.168.0.5
....
; sub-domain definitions
; zone fragment for us.example.com
$ORIGIN us.example.com.
; we define two name servers for the sub-domain
@ IN NS ns3.us.example.com.
; the record above could have been written without the $ORIGIN as
; us.example.com. IN NS ns3.us.example.com.
; OR as simply
; IN NS ns3
; the next name server points to ns1 in the example.com zone above
IN NS ns1.example.com.
; sub-domain address records for name server only - glue record
ns3 IN A 10.10.0.24 ; 'glue' record
; the record above could have been written as
; ns3.us.example.com. A 10.10.0.24 if it's less confusing
....
; WARNING: $ORIGIN us.example.com. affects all subsequent RRs until
; either another $ORIGIN or EOF
; adding $ORIGIN example.com. resets the $ORIGIN to the base domain name
Notes:
The above fragment makes the assumption that ns1.example.com will act as a slave (secondary) for the us.example.com sub-domain. This is not a requirement and we could have defined any other name-servers, including out-of-zone servers, in the same way.
The A record for ns3.us.example.com for the sub-domain is the so-called glue record and MUST be present. It is necessary to allow a DNS query to succeed in a single transaction - which always requires an IP address defined in an A or AAAA RR.
Note: All name server queries require both a name and an IP address (a glue record) in the response (answer). In the case of the gTLD or ccTLD servers they provide the glue (IP address) record in responses. These glue records were captured when the domain was registered.
The A record for the name server ns2.example.com is not strictly speaking a glue record but the A record for ns1.example.com IS a glue record for us.example.com but NOT, strictly speaking, for example.com.
Sub-domain Configuration
Assuming our sub-domain name-server is also running BIND we will have the following configuration.
Sub-domain named.conf
The 'named.conf' file will contain statements similar to the following fragment defining the sub-domain zone:
// named.conf file fragment
....
options {
....
// disable all zone transfers
allow-transfer {"none";};
....
};
zone "us.example.com" in{
type master;
file "master/master.us.example.com";
// explicitly allow zone transfer from slave
allow-transfer {192.168.0.3;};
};
Sub-domain Zone Files
The file master.us.example.com (or whatever convention you use) will contain our sub-domain configuration with, say, a couple of name servers.
; zone fragment for sub-domain us.example.com
; name servers in the same zone
$TTL 2d ; default TTL = 2 days
$ORIGIN us.example.com.
@ IN SOA ns3.us.example.com. hostmaster.us.example.com. (
2003080800 ; serial number
2h ; refresh = 2 hours
15M ; update retry = 15 minutes
3W12h ; expiry = 3 weeks + 12 hours
2h20M ; minimum = 2 hours + 20 minutes
)
; sub-domain name servers
IN NS ns3.us.example.com.
IN NS ns1.example.com. ; see notes below
; sub-domain mail server
IN MX 10 mail.us.example.com.
; above record could have been written as
; IN MX 10 mail
; A records for name servers above
ns3 IN A 10.10.0.24
; A record for mail server above
mail IN A 10.10.0.25
; next record defines our ftp server
ftp IN A 10.10.0.28
; the record above could have been written as
; ftp.us.example.com. A 10.10.0.28 if it's less confusing
....
; other sub-domain records
....
Notes:
- The above fragment makes the assumptions that our main zone name server will act as a slave (secondary) for us.example.com. If not we could have defined other name-servers, including out-of-zone name servers, in the same way.
- The A record for ns1.example.com is a so-called glue record for the us.example.com zone and is defined in the zone example.com and therefore will already be available from the initial query to the example.com domain, that is, all queries will descend the domain name hierarchy (through root > delgation to .com > delegation to example.com > delegation to us.example.com) and thus the A RR (IP Address) of this server will already be available. In the bad old days defining an A RR for ns1.example.com in the zone us.example.com would have been accepted and indeed it was originally shown. Modern BIND9 releases are (rightly) much pickier in what they accept and it would now be rejected as an out-of-zone RR.
- Our ftp service host (and any others we may define) are only defined in the sub-domain zone file and are not visible in the zone name-server.
Problems, comments, suggestions, corrections (including broken links) or something to add? Please take the time from a busy life to 'mail us' (at top of screen), the webmaster (below) or info-support at zytrax. You will have a warm inner glow for the rest of the day.
