DNS A vs NS record
Solution 1:
Some examples out of the fictitious foo.com zone file
....... SOA record & lots more stuff .......
foo.com. IN NS ns1.bar.com.
foo.com. IN A 192.168.100.1
....... More A/CNAME/AAAA/etc. records .......
A Record = "The host called foo.com lives at address 192.168.100.1"
NS Record = "If you want to know about hosts in the foo.com zone, ask the name server ns1.bar.com"
Solution 2:
This is an old question, but I think the other answers aren't really touching on the source of the confusion. NS records at the apex follow a different set of rules than NS records beneath the apex.
- The
NSrecords at the apex do not define a referral. Instead, they provide the authoritative definition for thoseNSrecords. - Any
NSrecords beneath the apex do define a referral. ThisNSrecord is not considered authoritative, and neither is anArecord sharing the same name.
From those rules, we can derive two different behaviors for what happens when an A record exists on a DNS server with the same name:
- If the
NSrecord does not define a referral, other data can exist alongside of it in the same zone. Since the server considers itself authoritative for both theNSrecord and theArecord, there is no conflict. This is why other data commonly lives alongside theNSrecords at the apex of a zone. - If the
NSrecord does define a referral, then theArecord is effectively "masked" by a zone cut. ThisArecord is not authoritative, and must not show up in the answer section of an authoritative response. It can potentially be used as glue data which shows up in the additional section of the referral, but that's it.
Confusing? Yeah, it is. Drop a note in the comments if you have trouble following this and I'll see what I can do.
Solution 3:
an A record maps a name to an IP address. e.g.
binary.example.com. IN A 192.168.1.42
states that binary.example.com. resolves to 192.168.1.42
an NS record maps a name to another nameserver, i.e. another DNS server that serves that domain. i.e. "I've no idea of the IP address of this name, but if you go ask that nameserver over there, it might know"
binary.example.com. IN NS otherbox.example.com otherbox.example.com. IN A 192.168.1.2
If you ask a DNS server that has the above 2 records for binary.example.com. (or www.binary.example.com. or foo.bar.binary.example.com). it'll tell you that you'll have to go ask 192.168.1.2 to translate those names (well, or the dns server could do that for you, or it could have the resolved names cached and return them to you.)
Solution 4:
The NS records specify the servers which are providing DNS services for that domain name.
The A records point host names (such as www, ftp, mail) to one or more IP addresses.
Solution 5:
It is important to have both NS and A record in zone if you need to delegate sub-zone to different DNS server.
E.g. we have dns server ns1.bar.com authoritative for zone bar.com. And we need to delegate foo.bar.com to ns1.foo.bar.com. So we need to create zone foo.bar.com and put there this records:
foo.bar.com. IN NS ns1.foo.bar.com.
ns1.foo.bar.com. IN A 10.10.10.10
If we won't have A record delegation won't work. Such record pairs are called glue records.
Glue records is only way for DNS system to find the exact IP of authoritative DNS server for non-root zone.
If you check any domain for NS record using dig or see traffic dump with wireshark you'll see that there's 'additional' section in answer.
;; ANSWER SECTION:
foo.bar.com. 10800 IN NS ns1.foo.bar.com.
;; ADDITIONAL SECTION:
ns1.foo.bar.com. 7972 IN A 10.10.10.10
when doing recursive request, e.g. www.foo.bar.com your dns client will ask for DNS authoritative for foo.bar.com zone and get answer ns1.foo.bar.com.
To go further it needs to send A request for ns1.foo.bar.com, which is served by... ns1.foo.bar.com. To break out loop, delegating DNS server should add this additional section, with A record.
Server ns1.foo.bar.com should have the same records in its zone, so it can be authoritative for foo.bar.com zone.