NS record in bind9 zone file

7,341

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.

Share:
7,341

Related videos on Youtube

sylye
Author by

sylye

GNU/linux and all others FOSS technology lover.

Updated on September 18, 2022

Comments

  • sylye
    sylye over 1 year

    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 ?

    • MadHatter
      MadHatter about 9 years
      It's best not to redact domain names and IP addresses in DNS questions, but if you feel you must, PLEASE redact domain names in accordance with RFC6761 and IP addresses in accordance with RFC5737. See meta.serverfault.com/questions/963/… for more complete details on local policy.