{"id":22,"date":"2013-08-27T07:49:58","date_gmt":"2013-08-27T07:49:58","guid":{"rendered":"http:\/\/muse.oneshot.in\/?p=22"},"modified":"2013-08-27T07:52:35","modified_gmt":"2013-08-27T07:52:35","slug":"22","status":"publish","type":"post","link":"https:\/\/muse.oneshot.in\/?p=22","title":{"rendered":"HOWTO &#8211; Delegate a Sub-domain \/ SUB-Zone"},"content":{"rendered":"<p>This HOWTO configures BIND to <b>fully<\/b> delegate the responsibility for a sub-domain to another name server. This is not the only possible method of defining sub-domains (virtual &#8211; or pseudo &#8211; subdomains). The following defines the hierarchy we want to create:<\/p>\n<ul>\n<li>zone (domain) name = example.com<\/li>\n<li>domain host name = bill.example.com<\/li>\n<li>sub-domain name = us.example.com<\/li>\n<li>sub-domain host name = ftp.us.example.com<\/li>\n<\/ul>\n<p>To ease the administration load we want to fully delegate the responsibility for the administration of the <i>us<\/i> sub-domain (and its reverse-lookup) to the the <i>us.example.com<\/i> management group.<\/p>\n<p>This HOWTO assumes that the name servers for our zone (example.com) are all in our domain. If they are not, the actual configuration is exactly the same but you will have to convince the name server administrator to carry out the configuration. If we own the name servers we can do what we like!<\/p>\n<p>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 <i>example.com<\/i> will be directed to the name-servers for the <i>example.com<\/i> zone. The example.com name servers are responsible for redirecting the query to any sub-domain name-servers.<\/p>\n<p>For want of any better terminology we call our servers the <b>domain name-server<\/b> (this one is visible to registration authorities) and the the <i>sub-domain name-server<\/i> (essentially visible only to the <i>domain name-server<\/i>).<\/p>\n<p>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 not apparent.<\/p>\n<h2>domain Name Server Configuration<\/h2>\n<p>The name servers for our domain are running BIND and has a named.conf file that defines the zone.<\/p>\n<h3>Domain Name-Server named.conf<\/h3>\n<p>The &#8216;named.conf&#8217; file will contain statements similar to the following fragment defining the main zone:<\/p>\n<pre>\/\/ named.conf file fragment\r\n....\r\noptions {\r\n  ....\r\n  \/\/ disable all zone transfers\r\n  allow-transfer {\"none\";};\r\n  ....\r\n};\r\nzone \"example.com\" in{\r\n  type master;\r\n  file \"master\/master.example.com\";\r\n  \/\/ explicitly allow slave zone transfer\r\n  allow-transfer {192.168.0.4;};\r\n};\r\n\/\/ optional - we act as the slave (secondary) for the delegated domain\r\nzone \"us.example.com\" IN {\r\n  type slave;\r\n  file \"slave\/slave.us.example.com\";\r\n  masters {10.10.0.24;};\r\n};<\/pre>\n<p>The optional definition of a slave (secondary) name server for our delegated <i>us.example.com<\/i> sub-domain is probably good practice but not essential &#8211; you can define it to be any name server.<\/p>\n<h3>Domain Name-Server Zone Files<\/h3>\n<p>The file &#8216;master.example.com&#8217; (or whatever naming convention you use) will contain our domain configuration with two name servers.<\/p>\n<pre>; zone fragment for example.com\r\n; name servers in the same zone\r\n$TTL 2d ; default TTL is 2 days\r\n$ORIGIN example.com.\r\n@              IN      SOA   ns1.example.com. hostmaster.example.com. (\r\n               2003080800 ; serial number\r\n               2h         ; refresh =  2 hours \r\n               15M        ; update retry = 15 minutes\r\n               3W12h      ; expiry = 3 weeks + 12 hours\r\n               2h20M      ; minimum = 2 hours + 20 minutes\r\n               )\r\n; main domain name servers\r\n              IN      NS     ns1.example.com.\r\n              IN      NS     ns2.example.com.\r\n; main domain mail servers\r\n              IN      MX     10 mail.example.com.\r\n; A records for name servers above \r\nns1           IN      A      192.168.0.3\r\nns2           IN      A      192.168.0.4\r\n; A record for mail server above \r\nmail          IN      A      192.168.0.5\r\n....\r\n\r\n; sub-domain definitions\r\n$ORIGIN us.example.com.\r\n; we define two name servers for the sub-domain\r\n@             IN      NS     ns3.us.example.com.\r\n; the record above could have been written without the $ORIGIN as\r\n; us.example.com. IN NS ns3.us.example.com.\r\n; OR as simply\r\n;      IN NS   ns3\r\n; the next name server points to ns1 above\r\n              IN      NS     ns1.example.com.\r\n; sub-domain address records for name server only - glue record\r\nns3           IN      A      10.10.0.24 ; 'glue' record\r\n; the record above could have been written as \r\n; ns3.us.example.com. A 10.10.0.24 if it's less confusing<\/pre>\n<p><b>Notes:<\/b><\/p>\n<ol>\n<li>The above fragment makes the assumption that <i>ns1.example.com<\/i> will act as a slave (secondary) for the <i>us.example.com<\/i> sub-domain. This is not a requirement and we could have defined any other name-servers in the same way.<\/li>\n<li>The A record for <i>ns3.us.example.com<\/i> for the sub-domain is the so-called <i>glue<\/i> record and MUST be present. It is necessary to allow a DNS query to succeed in a single transaction &#8211; which always requires an IP address defined in an A or AAAA RR.<b>Note:<\/b> 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. These glue records were captured when the domain was registered. The A record for the name server <i>ns2.example.com<\/i> is not strictly speaking a glue record but the A record for <i>ns1.example.com<\/i> IS a glue record for <i>us.example.com<\/i> but NOT, strictly speaking, for <i>example.com<\/i>.<\/li>\n<\/ol>\n<h2>Sub-domain Configuration<\/h2>\n<p>Assuming our sub-domain name-server is also running BIND we will have the following configuration.<\/p>\n<h3>Sub-domain named.conf<\/h3>\n<p>The &#8216;named.conf&#8217; file will contain statements similar to the following fragment defining the sub-domain zone:<\/p>\n<pre>\/\/ named.conf file fragment\r\n....\r\noptions {\r\n    ....\r\n    allow-transfer {\"none\";};\r\n    ....\r\n};\r\nzone \"us.example.com\" in{\r\n\ttype master;\r\n\tfile \"master\/master.us.example.com\";\r\n  \/\/ explicitly allow slave\r\n\tallow-transfer {192.168.0.3;};\r\n};<\/pre>\n<h3>Sub-domain Zone Files<\/h3>\n<p>The file <i>master.us.example.com<\/i> (or whatever convention you use) will contain our sub-domain configuration with, say, a couple of name servers.<\/p>\n<pre>; zone fragment for sub-domain us.example.com\r\n; name servers in the same zone\r\n$TTL 2d ; default TTL = 2 days\r\n$ORIGIN us.example.com.\r\n@              IN     SOA   ns3.us.example.com. hostmaster.us.example.com. (\r\n               2003080800 ; serial number\r\n               2h         ; refresh =  2 hours\r\n               15M        ; update retry = 15 minutes\r\n               3W12h      ; expiry = 3 weeks + 12 hours\r\n               2h20M      ; minimum = 2 hours + 20 minutes\r\n               )\r\n; sub-domain name servers\r\n                  IN      NS     ns3.us.example.com.\r\n                  IN      NS     ns1.example.com. ; see notes below\r\n; sub-domain mail server\r\n                  IN      MX 10  mail.us.example.com.\r\n; above record could have been written as \r\n;                 IN      MX 10  mail\r\n; A records for name servers above \r\nns3               IN      A      10.10.0.24\r\nns1.example.com.  IN      A      192.168.0.3 ; 'glue' record\r\n; A record for mail server above \r\nmail              IN      A      10.10.0.25\r\n; next record defines our ftp server\r\nftp               IN      A      10.10.0.28\r\n; the record above could have been written as \r\n; ftp.us.example.com. A 10.10.0.28 if it's less confusing\r\n....\r\n; other sub-domain records\r\n....<\/pre>\n<p><b>Notes:<\/b><\/p>\n<ol>\n<li>The above fragment makes the assumptions that our main zone name server will act as a slave (secondary) for <i>us.example.com<\/i>. If not we could have defined other name-servers in the same way.<\/li>\n<li>The A record for <i>ns1.example.com<\/i> is a so-called <i>glue<\/i> record and is not strictly necessary since this address will already be available from the initial query to the example.com domain i.e. all queries will descend the domain name hierarchy and already have received the IP for ns1.example.com.<\/li>\n<li>Our <i>ftp<\/i> service host (and any others we may define) are only defined in the sub-domain name server and are not visible in the zone name-server.<\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"<p>This HOWTO configures BIND to fully delegate the responsibility for a sub-domain to another name server. This is not the only possible method of defining sub-domains (virtual &#8211; or pseudo &#8211; 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 [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3,4],"tags":[],"class_list":["post-22","post","type-post","status-publish","format-standard","hentry","category-information-technology","category-redhat"],"_links":{"self":[{"href":"https:\/\/muse.oneshot.in\/index.php?rest_route=\/wp\/v2\/posts\/22","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/muse.oneshot.in\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/muse.oneshot.in\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/muse.oneshot.in\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/muse.oneshot.in\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=22"}],"version-history":[{"count":4,"href":"https:\/\/muse.oneshot.in\/index.php?rest_route=\/wp\/v2\/posts\/22\/revisions"}],"predecessor-version":[{"id":26,"href":"https:\/\/muse.oneshot.in\/index.php?rest_route=\/wp\/v2\/posts\/22\/revisions\/26"}],"wp:attachment":[{"href":"https:\/\/muse.oneshot.in\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=22"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/muse.oneshot.in\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=22"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/muse.oneshot.in\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=22"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}