up vote 0 down vote favorite
share [g+] share [fb]

Is it possible to have a working A record (a working website) without having a NS record?

mylinux:~# dig example.com NS
; <<>> DiG 9.3.4-P1.2 <<>> example.com NS
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18501
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;example.com.                   IN      NS

;; AUTHORITY SECTION:
example.com.            336     IN      SOA     NS1.1MORENAME.com. hostmaster.example.com. 5 28800 7200 604800 86400

;; Query time: 1 msec
;; SERVER: 194.126.115.18#53(194.126.115.18)
;; WHEN: Mon Feb 28 12:17:56 2011
;; MSG SIZE  rcvd: 90

mylinux:~# telnet example.com 80
Trying 50.22.26.210...
Connected to example.com.
Escape character is '^]'.
GET /
<tml>
<head>
<title></title>
<meta name="description" content=" information from ekodomains.com.  Find the best      sites on the web." >
<meta name="keywords" content="" >
[....]
link|improve this question
89% accept rate
feedback

3 Answers

up vote 2 down vote accepted

Try dig +trace example.com A or dig +trace example.com NS to see how the referrals are happening. The .com nameserver must have NS records to be a part of the .com zone, but the nameservers it is referring to may not have NS records configured for the zone.

Normally BIND refuses to load zones with no NS records, but other DNS software may be more permissive.

After a search for other domains with the same nameserver, it seems is is not uncommon for them to behave in this way:

; <<>> DiG 9.7.0-P1 <<>> @ns1.1morename.com keyzweb.com ns
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16653
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;keyzweb.com.                   IN      NS

;; AUTHORITY SECTION:
keyzweb.com.            86400   IN      SOA     NS1.1MORENAME.com. hostmaster.keyzweb.com. 1 28800 7200 604800 86400

;; Query time: 123 msec
;; SERVER: 173.236.119.110#53(173.236.119.110)
;; WHEN: Sat Mar  5 11:06:05 2011
;; MSG SIZE  rcvd: 90

Here's a trace, showing that NS records at the delegation point (in this case, the NS records returned by the .com nameservers) are not authoritative. This is why they do not show up as an answer: they don't exist in the authoritative nameserver.

; <<>> DiG 9.7.0-P1 <<>> +trace keyzweb.com ns
;; global options: +cmd
.                       22664   IN      NS      l.root-servers.net.
.                       22664   IN      NS      f.root-servers.net.
.                       22664   IN      NS      h.root-servers.net.
.                       22664   IN      NS      a.root-servers.net.
.                       22664   IN      NS      g.root-servers.net.
.                       22664   IN      NS      m.root-servers.net.
.                       22664   IN      NS      i.root-servers.net.
.                       22664   IN      NS      d.root-servers.net.
.                       22664   IN      NS      c.root-servers.net.
.                       22664   IN      NS      k.root-servers.net.
.                       22664   IN      NS      j.root-servers.net.
.                       22664   IN      NS      e.root-servers.net.
.                       22664   IN      NS      b.root-servers.net.
;; Received 509 bytes from 10.19.12.20#53(10.19.12.20) in 0 ms

com.                    172800  IN      NS      a.gtld-servers.net.
com.                    172800  IN      NS      b.gtld-servers.net.
com.                    172800  IN      NS      c.gtld-servers.net.
com.                    172800  IN      NS      d.gtld-servers.net.
com.                    172800  IN      NS      e.gtld-servers.net.
com.                    172800  IN      NS      f.gtld-servers.net.
com.                    172800  IN      NS      g.gtld-servers.net.
com.                    172800  IN      NS      h.gtld-servers.net.
com.                    172800  IN      NS      i.gtld-servers.net.
com.                    172800  IN      NS      j.gtld-servers.net.
com.                    172800  IN      NS      k.gtld-servers.net.
com.                    172800  IN      NS      l.gtld-servers.net.
com.                    172800  IN      NS      m.gtld-servers.net.
;; Received 492 bytes from 193.0.14.129#53(k.root-servers.net) in 22 ms

keyzweb.com.            172800  IN      NS      ns1.1morename.com.
keyzweb.com.            172800  IN      NS      ns2.1morename.com.
;; Received 107 bytes from 192.26.92.30#53(c.gtld-servers.net) in 102 ms

keyzweb.com.            86400   IN      SOA     NS1.1MORENAME.com. hostmaster.keyzweb.com. 1 28800 7200 604800 86400
;; Received 90 bytes from 173.236.119.110#53(ns2.1morename.com) in 124 ms
link|improve this answer
feedback
up vote 2 down vote

A couple things :

1) "example.com" is a reserved domain name, per RFC 2606. It has special status in the GTLD zone, because of this Best-Current-Practice. It's reserved mostly so that people writing documentation, books, etc, have, well, an 'example' domain name to use/refer, without confusing readers (or attracting unwanted traffic).

2) The above poster is correct : example.com has two nameservers listed, both at iana-servers.net. The best way to verify this is to walk the tree just as a resolver would.

-> dig @f.gtld-servers.net example.com ns -> nslookup -type=a example.com. f.gtld-servers.net. ( 'type' can be any of 'any','a'/'aaaa','mx',txt', etc ) -> host example.com f.gtld-servers.net

From your original post, tho - I am suspicious. The SOA doesn't match. "1morename" is not the correct SOA for example.com. Is this your ISP? If so, I wonder if they're fudging DNS for their own benefit. (If not them, perhaps, the Linux distro you're using?)

link|improve this answer
I think he may have masked the domain on purpose. I hope, too, that he didn't name his linux box "mylinux". – Cakemox Feb 28 '11 at 12:03
If he did, there could be an entirely different answer. Host objects can be registered with registries, and if they are associated as being a nameserver of an active domain, they could automatically get an "A" record /at the GTLD server level/. – jamie rishaw Feb 28 '11 at 12:06
Right, but this is not the case. Glue records are not answers, they are part of the additional section; queries for www.somedomain.com against the com nameservers will not return an answer, only an authority section with the nameservers you should be getting an answer from and the glue records for those nameservers. More importantly in this instance, the poster is getting an SOA record, which a gtld-server would never return even if it were an issue with glue. – Cakemox Mar 5 '11 at 10:03
Yes I did mask both my hostname and the domain name I was querying, for examplifying. I'm aware that example.com does indeed exist. I was warned then that I should not use domain names that do not belong to me. However, I still saw no harm in that, thinking that surely everyone understands that example.com is just a placeholder. I guess I was wrong and people do think that I literally mean example.com. :) – Henno Mar 11 '11 at 8:41
feedback
up vote 1 down vote

Try request NS from root TLD root server:

$ dig com. NS

; <<>> DiG 9.7.0-P1 <<>> com. NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18638
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;com.               IN  NS

;; ANSWER SECTION:
com.            172800  IN  NS  c.gtld-servers.net.
com.            172800  IN  NS  b.gtld-servers.net.
com.            172800  IN  NS  h.gtld-servers.net.

$ dig example.com NS @c.gtld-servers.net

; <<>> DiG 9.7.0-P1 <<>> example.com NS @c.gtld-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28957
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 4
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;example.com.           IN  NS

;; AUTHORITY SECTION:
example.com.        172800  IN  NS  a.iana-servers.net.
example.com.        172800  IN  NS  b.iana-servers.net.

Then query A record from TLD root server:

$ dig example.com A @c.gtld-servers.net

; <<>> DiG 9.7.0-P1 <<>> example.com A @c.gtld-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18291
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 4
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;example.com.           IN  A

;; AUTHORITY SECTION:
example.com.        172800  IN  NS  a.iana-servers.net.
example.com.        172800  IN  NS  b.iana-servers.net.

;; ADDITIONAL SECTION:
a.iana-servers.net. 172800  IN  A   199.43.132.53
a.iana-servers.net. 172800  IN  AAAA    2001:500:8c::53

May by, A record come from TLD server.

link|improve this answer
I did so and found that indeed TLD nameserver gives a NS record for the domain. How is this possible and is this a misconfiguration? – Henno Feb 28 '11 at 10:43
@Henno: The com. and example.com. zones are completely separate – even the NS records they have. (When resolving example.com. resolver will only look for NS addresses in the parent (com.) zone – after all, it cannot look in example.com. itself.) But yes, this is a misconfiguration. – grawity Mar 5 '11 at 11:08
feedback

Your Answer

 
or
required, but never shown
discard

Not the answer you're looking for? Browse other questions tagged or ask your own question.