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 ?