NS record in bind9 zone file

binddomain-name-system

I met a strange scenario today.

Normally when we setup a bind9 zone record, we put the NS record same as our ORIGIN. However today I found one working bind9 setup in the production site which has the NS record pointing to another domain:

[data/cat_com.zone]

$ORIGIN cat.com.
$TTL 600
@       IN      SOA     ns.tree.com.    hostmaster.cat.com. (
                        2015030200
                        21600
                        3600
                        604800
                        86400 )

        IN      NS      ns.tree.com.
        IN      NS      ns2.tree.com.
        IN      MX      10      cat.com.

ns      IN      A       1.2.3.124
ns2     IN      A       1.2.3.124


host19  IN      A       1.2.3.66

And in the record of tree.com:
[data/tree_com.zone]

$TTL 600

@   IN  SOA ns.tree.com. hostmaster.tree.com. (
      2015030200 ; serial
      28800 ; refresh
      7200 ; retry
      3600000 ; expire
      86400 ; default_ttl
      )
@   IN  NS      ns.tree.com.
@   IN  NS      ns2.tree.com.
@   IN  MX  10  mail.tree.com.



tree.com.              IN  A 1.2.3.66

ns.tree.com.           IN A 1.2.3.124
ns2.tree.com.          IN A 1.2.3.124

And in the named.conf, it has this:

zone "tree.com" {
        type master;
        file "data/tree_com.zone";
};


zone "cat.com"  {
        type master;
        file "data/cat_com.zone";
};

So when I try to resolve an A record in cat.com, let say host19.cat.com, I can get the record 1.2.3.66. This is strange because according to the SOA zone file, the NS record is pointing to ns.tree.com, and in the SOA zone file of tree.com, there is no information of host19.cat.com. How does the dns resolving process can work without error in this case ? Does the NS record play a role here or it's only the named.conf that decide which SOA zone file should be used (in this case, cat.com will be referring to cat_com.zone file), and the NS record in cat.com SOA didn't mean anything ?

Best Answer

It is perfectly alright to have a domain name/zone-file pointing to name-servers outside of that domain i.e. it is perfectly alright to use ns1.example.com as the name-server for the example.org domain.

Not only means that you don't need Glue records in the example.org zone, it is often easier to administer as well.

I think you made a slight conceptual mistake in thinking that external NS records such as ns1.example.com imply that resource records for the example.org domain should also be retrieved from the example.com zone data. That is not the case, the NS record only points to a host running the name service for that domain, but the resource records will come from the zone data specific for the example.org domain.

Related Topic