Join Log in
Score:0
Jack McCauley avatar Server

DNS - dig query - NS not returning for sub domain from one location but does for another

ru flag
Jack McCauley

I have DNS setup in x2 places and will be repointing NS shortly. Before I do that, I wanted to confirm DNS is correct at both locations.

I'm using dig and passing in a file.

When I query the NS of the current location, I get the DNS i'm expecting;

dig subdomain.domain.com NS +noall +answer

subdomain.domain.com.     3599    IN      NS      ns3.domain.com.
subdomain.domain.com.     3599    IN      NS      ns1.domain.com.
subdomain.domain.com.     3599    IN      NS      ns2.domain.com.
subdomain.domain.com.     3599    IN      NS      ns4.domain.com.

But when I pass the new location NS into the command, with the same file, i'm getting nothing back

'dig @some.NS.net. subdomain.domain.com. NS +noall +answer'

+noall +answer

; (2 servers found)

;; global options: +cmd

I'm most definitely an idiot, most of the time, but I'm failing to understand this behaviour, as the records i'm expecting to return definitely exist in the new location, and do actually return if I query them indivudally, but with the '+noall' omitted. Like;

'dig @some.NS.net. subdomain.domain.com. NS +answer'

Except I just want the 'simple' answer for output to use.

Please assist a fellow human being.

Thanks in advance.

41
0 + 0
dig
Patrick Mevzek avatar
cn flag
Patrick Mevzek
Why do you use `+noall +answer`? Do you understand a DNS response has 3 sections, beside the question: answer, additional and authority? You would get better answer by giving actual names, but for NS records, intended for delegation, an authoritative nameserver will put them in authority, not in answer (it is in answer on first dig as you query an implied recursive nameserver). So replace `+answer` by `+auth`. Also for online troubleshooting tool and prepare migration, use DNSViz. You can do an undelegated check to verify new configuration.
0
Reply
Patrick Mevzek avatar
cn flag
Patrick Mevzek
Also, instead of `+noall +answer` look at `+short` (but again, won't show records in authority or additional sections). Also `+all` is the default, so a lone `+answer` is not needed (you probably didn't look at the DNS reply properly to see that the results where in AUTHORITY section and that the ANSWER section was empty)
0
Reply
fr flag
Tomek
Start with checking SOA record in the new place (I am assuming you have a zone starting at subdomain.domain.com). Also: do you have DNSSEC active for that and parent zone? If yes, try to query with +cd flag.
0
Reply
Jack McCauley avatar
ru flag
Jack McCauley
@PatrickMevzek The reason I have used those option is that it gives me back the data in the format that I want it ```subdomain.domain.com. 1 IN NS 1.2.3.4 ``` which as I say, works for the one location and not the other. +auth works fine, but that's not the format I'm after. The answer I was really after was why does that work fine with one NS, but not the other.
0
Reply
Jack McCauley avatar
ru flag
Jack McCauley
@PatrickMevzek - Also, if I omit both these options from the query, as I say about, I get the results back as expected, the Authority brings back 4 entries, which is what I would expect, that's what's in the zone. But again, i use +noall +answer on one NS and the 4 records come back as I want ``` subdomain.domain.com. 3599 IN NS ns4.domain.com. (x4) ``` I use the same command against another name server, no results.
0
Reply
Jack McCauley avatar
ru flag
Jack McCauley
@Tomek - thanks for getting back. I'm not sure whether DNSSEC is enabled at service provider. I'll take a look. The SOA record is there and as I'd expect it to look, for the parent zone. I can query that and bring that back in this format I desire. I have tried with the +cd option, no dice i'm afraid.
0
Reply
Patrick Mevzek avatar
cn flag
Patrick Mevzek
"The answer I was really after was why does that work fine with one NS, but not the other. " It is exactly explained in my comment, it is the difference between ANSWER and AUTHORITY sections which comes from the difference between authoritative and recursive nameservers. `+ans` or `+auth` gives exactly the same format, but content comes from different part of the DNS message.
0
Reply
Patrick Mevzek avatar
cn flag
Patrick Mevzek
"I use the same command against another name server, no results." Because in one case you query a recursive nameserver by not specifying `@` using `dig` so the result is ALWAYS in the ANSWER section of the DNS message, hence `+answer` sees it, while on the other case you do specify the nameserver with `@` and you query an authoritative nameserver hence per design of the DNS the `NS` records are in the AUTHORITY section of the DNS message and hence can only be seen by `+all` or `+auth` as the ANSWER section will be empty (hence `+ans` shows nothing ,exactly as designed)
0
Reply
Patrick Mevzek avatar
cn flag
Patrick Mevzek
Do the first query by using `@` towards one of the nameserver and you will have the same behavior than the second dig command. You are not comparing two actual things. First query goes to a recursive nameserver where second one goes to an authoritative nameserver. The replies hence vary regarding what data is in what section of the DNS message.
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.