Почему nslookup или dig не возвращает серверы имен для определенных доменов?
Пример:
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:
Из whois:
DOMAIN NAME:
zzy.pl
registrant type:
organization
nameservers:
ns1.aftermarket.pl.
ns2.aftermarket.pl.
(...)
TL; WR, главный вывод из этого состоит в том, что когда кто-то настраивает что-то неправильно, вы получаете странные результаты.
В zzy.pl домен делегирован
ns1.aftermarket.pl.
ns2.aftermarket.pl.
Эти серверы имен неправильно настроены, вместо того, чтобы иметь зону для zzy.pl (ожидается) у них есть зона для pl (неверно).
Итак, когда вы спрашиваете этих серверов имен о zzy.pl IN NS, у них нет NS записи (как прямой результат вышеупомянутой неправильной конфигурации) и ответьте NODATA ответ (означающий, что запрошенное имя существует, но не имеет записей запрошенного типа) с SOA запись из их версии pl зона.
В любой зоне должно быть не менее SOA и NS на вершине, так что zzy.pl нарушена в этом отношении.
Для справки:
Делегирование (нормальное) от pl Серверы имен TLD:
$ 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
$
Авторитетный ответ (ожидается, что он будет соответствовать указанному выше, но вместо этого NODATA и выглядит так, как будто ответ от pl зона, из которой мы только что перешли на предыдущем шаге):
$ 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
$
Запрашивая их для pl подтверждает это:
$ 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
$