0

I'm confused by the DNS resolution. How is it possible that for a domain we can get an IP (A record) but no authoritative NS is returned for that domain. For example 

dig ns HDRedirect-LB3-890977680.us-east-1.elb.amazonaws.com

returns nothing but 

dig A HDRedirect-LB3-890977680.us-east-1.elb.amazonaws.com

returns 

HDRedirect-LB3-890977680.us-east-1.elb.amazonaws.com. 51 IN A 52.204.129.22
HDRedirect-LB3-890977680.us-east-1.elb.amazonaws.com. 51 IN A 54.85.127.70

If the domain can be resolved, it should have an authoritative NS, how can I get that?

Alex
  • 159
  • 2
  • 8
  • domain (subdman) and hostname in DNS-tree are different entites wth different properties. Lame "subdomain" usage for any FQDN is direct road to Hell. U wanna RTFM or re-read @hakan again and again – Lazy Badger Mar 17 '17 at 08:45

3 Answers3

8

It works as expected. The incorrect assumption here is that all names should have NS records.

Instead, the set of nameservers is defined on a per zone basis, with NS records at the zone apex only.

Eg, if you have example.com and have not delegated any subdomains elsewhere, then there are no further NS records anywhere under example.com.
If you delegate foo.bar.example.com elsewhere, then that name (by definition the start of a new zone) will have NS records.

There are several possible approaches for finding which zone a given name is part of. It's actually generally a two-step process.

One approach would be to start out with eg:

dig HDRedirect-LB3-890977680.us-east-1.elb.amazonaws.com NS

The idea here is that if this name happens to be the apex of a zone (something which you cannot generally know in advance) you get the response that you want.
If it is not the zone apex, you will get a negative response (as there are no NS records in that case), but that negative response includes the zone's SOA in the AUTHORITY section. That SOA record will actually tell you where the apex is.

In this case

;; AUTHORITY SECTION:
us-east-1.elb.amazonaws.com. 32 IN      SOA     ns-1119.awsdns-11.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 60

So the owner name (left-most column) of the SOA record tells you where the zone starts.

Ie, dig us-east-1.elb.amazonaws.com. NS will give you the relevant nameservers.


Another approach would be to follow the chain of delegations (eg dig +trace) but in the end that ends up being a case of remembering the last delegation point you saw. Also, if you take this approach and use dig +trace specifically, do keep in mind that the output of dig +trace by default is very limited and does not really distinguish between the NS records from AUTHORITY sections when it gets a referral from a parent zone compared to an NS record in the ANSWER section from the actual authoritative nameserver. (You may want to add +all to actually see clearly what is happening.)
In the end, if you only saw the referral (with NS records in the AUTHORITY section) and want to be sure you have the NS records that the authoritative server says, you will have to re-query for that particular name.

Håkan Lindqvist
  • 33,741
  • 5
  • 65
  • 90
  • Bravissimo!!! First *really good* hostmaster on SF after a long time, which don't mix hostname and subdomain. **I applaud you, sir!!!** – Lazy Badger Mar 17 '17 at 08:40
-1

You do realize that your not requesting which are the authoritative DNS servers for the domain when you do dig NS HDRedirect-LB3-890977680.us-east-1.elb.amazonaws.com , what you're asking there is if HDRedirect-LB3-890977680.us-east-1.elb.amazonaws.com itself is a DNS name server.

To find the DNS servers which are authoritative for HDRedirect-LB3-890977680.us-east-1.elb.amazonaws.com simply take a look at the Authority section that dig returns or request the SOA record or run dig with the trace option.

dig SOA HDRedirect-LB3-890977680.us-east-1.elb.amazonaws.com

Or 

dig +trace HDRedirect-LB3-890977680.us-east-1.elb.amazonaws.com
HBruijn
  • 72,524
  • 21
  • 127
  • 192
  • 3
    "what you're asking there is if HDRedirect-LB3-890977680.us-east-1.elb.amazonaws.com itself is a DNS name server" is not actually correct (why would the name of a nameserver have `NS` records?). The problem is rather that their query assumes that `HDRedirect-LB3-890977680.us-east-1.elb.amazonaws.com` is a zone of its own. – Håkan Lindqvist Mar 17 '17 at 06:51
-2

dig us-east-1.elb.amazonaws.com should return the SOA for that sub-domain.

what you are asking with "dig ns" is if the host is a NS record or rather what is the ns for that host/domain. the soa does not necessarily point to the NS server for that domain. in fact i thend to think it rarely does. it mostly points to the www host most of the time.

the ns is the nameserver so the dns that answer for the domain the soa is who responds when the domain is looked up ( the ip address for the whole domain)

ex:

dig SOA svdx.net +noall +answer

; <<>> DiG 9.9.5-3ubuntu0.13-Ubuntu <<>> SOA svdx.net +noall +answer ;; global options: +cmd svdx.net. 119 IN SOA ns2.dnsexit.com. admin.netdorm.com. 2000060701 604800 2400 1814400 1200 <<<<<<<< ns entries.

dig NS svdx.net +noall +answer

; <<>> DiG 9.9.5-3ubuntu0.13-Ubuntu <<>> NS svdx.net +noall +answer ;; global options: +cmd svdx.net. 119 IN NS ns3.dnsexit.com. svdx.net. 119 IN NS ns4.dnsexit.com. svdx.net. 119 IN NS ns1.dnsexit.com. svdx.net. 119 IN NS ns2.dnsexit.com.

dig svdx.net

; <<>> DiG 9.9.5-3ubuntu0.13-Ubuntu <<>> svdx.net ;; global options: +cmd

;; ANSWER SECTION: svdx.net. 119 IN A 192.0.225.94 <<<<<<<< not the ns

;; Query time: 78 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Fri Mar 17 03:39:27 EDT 2017 ;; MSG SIZE rcvd: 53

bob
  • 122
  • 2