Dig lookup not returning namservers

A recursive DNS resolver requires that the information it recursively acquires is authoritative to return it as a response to a query; it does not make inferences.

Authority is established in DNS using SOA and NS records. The former is used to establish authority among authoritative servers, and is served from within the zone. For instance, the SOA record indicates which copy of the zone data is newer when authoritative DNS servers for some zone are doing a zone transfer. The latter is used to establish authority when querying.

When an NS record for a subdomain is in a domain, and the server that has it is not an authoritative server for the name being queried, this NS record is a delegation record. So, the recursive resolver will query for delegation records starting with the root .. In your case, it goes up the chain toward this response from dns2.stabletransit.com.:

subdomain.codecrab.org. 300     IN      NS      ns1.macmonster.co.uk.

This is a delegation record, because this data does not exist:

subdomain.codecrab.org. 300     IN      NS      dns2.stabletransit.com

What actually existed was this:

codecrab.org.           86400   IN      NS      dns2.stabletransit.com.

So, the server at dns2.stabletransit.com. can give authoritative replies for codecrab.org., because the prior resolver delegated that zone to it. But it is not authoritative for subdomain.codecrab.org., so it cannot answer the query; it can only delegate.

DNS resolvers can of course be configured to be authoritative for any name the administrator wants. However, if they are configured to be authoritative for zones they are trying to delegate, they will instead give replies (without having the data), so this obviously is not done.

The way recursion works is simple, if not initially intuitive. The recursive resolver sends the full query to the nameservers for . (which it has in its hint file for the root zone). The . nameserver sends a reply, but a reply has two components we care about for this purpose: the authority section, and the answer section (there are also the additional section and the question section). The reply will contain records like:

org.                    172800  IN      NS      b0.org.afilias-nst.org.

This tells the recursive resolver to repeat its query over there, because the zone is delegated. It also includes "glue" in the additional section giving the IP addresses of the nameservers in the authority section, beacuse it knows you won't be able to find the nameserver to query it otherwise. This is an administrative decision in managing DNS; if glue records are not present the recursive resolver will query the AAAA or A records for one of the authoritative servers before proceeding.

So, you may notice that when you send your query IN NS subdomain.codecrab.org. to the last delegation, dns2.stabletransit.com., the reply looks like this:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35461
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;subdomain.codecrab.org.                IN      NS

;; AUTHORITY SECTION:
subdomain.codecrab.org. 300     IN      NS      ns2.macmonster.co.uk.
subdomain.codecrab.org. 300     IN      NS      ns1.macmonster.co.uk.

;; Query time: 104 msec
;; SERVER: 65.61.188.4#53(65.61.188.4)
;; WHEN: Sat Sep 28 14:50:45 MDT 2013

Notice how you get neither an additional section nor an answer section (but also NOERROR for the return status). This is because the record is a delegation to ns2.macmonster.co.uk. for subdomain.codecrab.org., for which dns2.stabletransit.com. knows it is not authoritative. There is no additional section because the namesevers are over in co.uk. and administratively it wasn't necessary to include glue because they are resolvable over there (though certainly, glue could have been included). So, to answer your query, because the answer has to come from an answer section (meaning it is identified by the replying server as an answer, coming from authority), your recursive resolver will try to find ns1.macmonster.co.uk., and finding it at 1.1.1.1, will send its query over there.

Of course (as this address is in a debogon prefix) there is no nameserver there (yet). As for ns2.macmonster.co.uk. at 2.2.2.2, if someone at Wanadoo France were to decide that there were to be a nameserver carrying authoritative records for subdomain.codecrab.org. and in particular:

subdomain.codecrab.org 99999999 IN NS now.go.away.or.i.will.taunt.you.a.second.time.

half the time (as often as that nameserver is chosen), the query will return now.go.away.or.i.will.taunt.you.a.second.time. as the nameserver for your zone even though common sense would suggest that it should be ns2.macmonster.co.uk. (and even though it was that latter nameserver which authoritatively gave that answer).