Why nslookup or dig doesn't return nameservers for certain domains?
Example:
dig @8.8.8.8 NS zzy.pl
; <<>> DiG 9.9.5-9+deb8u10-Raspbian <<>> @8.8.8.8 NS zzy.pl
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9801
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;zzy.pl. IN NS
;; AUTHORITY SECTION:
pl. 1724 IN SOA ns1.dropped.net.pl. kontakt.dropped.pl. 2008121404 3600 1800 1209600 3600
;; Query time: 101 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Nov 30 19:15:36 UTC 2017
;; MSG SIZE rcvd: 103
.
nslookup -type=ANY -timeout=10 zzy.pl 8.8.8.8
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: zzy.pl
Address: 212.91.7.33
Name: zzy.pl
Address: 212.91.6.58
Authoritative answers can be found from:
From whois:
DOMAIN NAME:
zzy.pl
registrant type:
organization
nameservers:
ns1.aftermarket.pl.
ns2.aftermarket.pl.
(...)
Answer
TL;WR, the main takeaway from this is that when someone sets things up incorrectly, you get strange results.
The zzy.pl
domain is delegated to
ns1.aftermarket.pl.
ns2.aftermarket.pl.
These nameservers are misconfigured, rather than having a zone for zzy.pl
(expected) they have a zone for pl
(incorrect).
So when you ask these nameservers about zzy.pl IN NS
, they have no NS
records (as a direct result o the above mentioned misconfiguration) and answer with a NODATA
response (meaning that the requested name exists, but has no records of the requested type) with the SOA
record from their version of a pl
zone.
Any zone should have at least SOA
and NS
at the apex, so zzy.pl
is broken in this regard.
For reference:
Delegation (normal) from the pl
TLD nameservers:
$ dig @a-dns.pl zzy.pl NS +norec
; <<>> DiG 9.11.1-P3-RedHat-9.11.1-3.P3.fc26 <<>> @a-dns.pl zzy.pl NS +norec
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51524
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;zzy.pl. IN NS
;; AUTHORITY SECTION:
zzy.pl. 86400 IN NS ns2.aftermarket.pl.
zzy.pl. 86400 IN NS ns1.aftermarket.pl.
;; Query time: 25 msec
;; SERVER: 2001:a10:121:1::156#53(2001:a10:121:1::156)
;; WHEN: Thu Nov 30 20:29:50 UTC 2017
;; MSG SIZE rcvd: 83
$
Authoritative response (expected to match the above, but is instead NODATA
and looks as if response is from pl
zone, which we just moved on from in the previous step):
$ dig @ns1.aftermarket.pl. zzy.pl NS +norec
; <<>> DiG 9.11.1-P3-RedHat-9.11.1-3.P3.fc26 <<>> @ns1.aftermarket.pl. zzy.pl NS +norec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20464
;; flags: qr aa ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;zzy.pl. IN NS
;; AUTHORITY SECTION:
pl. 3600 IN SOA ns1.dropped.net.pl. kontakt.dropped.pl. 2008121404 3600 1800 1209600 3600
;; Query time: 23 msec
;; SERVER: 212.91.6.36#53(212.91.6.36)
;; WHEN: Thu Nov 30 20:24:23 UTC 2017
;; MSG SIZE rcvd: 103
$
Querying them for pl
confirms this:
$ dig @ns1.aftermarket.pl. pl NS +norec
; <<>> DiG 9.11.1-P3-RedHat-9.11.1-3.P3.fc26 <<>> @ns1.aftermarket.pl. pl NS +norec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63021
;; flags: qr aa ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;pl. IN NS
;; ANSWER SECTION:
pl. 3600 IN NS ns2.dropped.net.pl.
pl. 3600 IN NS ns1.dropped.net.pl.
;; ADDITIONAL SECTION:
ns1.dropped.net.pl. 86400 IN A 212.91.6.36
ns2.dropped.net.pl. 86400 IN A 212.91.7.38
;; Query time: 23 msec
;; SERVER: 212.91.6.36#53(212.91.6.36)
;; WHEN: Thu Nov 30 20:24:29 UTC 2017
;; MSG SIZE rcvd: 111
$
No comments:
Post a Comment