Рабочий домен без записи NS. Возможный?
Попробовать dig +trace example.com A или dig +trace example.com NS видеть, как направления происходят. .com сервер имен должен иметь записи NS, чтобы быть частью .com зоны, но серверам имен, к которым это относится, нельзя было настроить записи NS для зоны.
Обычно BIND отказывается загружать зоны без записей NS, но другое программное обеспечение DNS может быть более разрешающим.
После того, как поиск других доменов с тем же сервером имен, которым это кажется, весьма свойственно им вести себя таким образом:
; <<>> DiG 9.7.0-P1 <<>> @ns1.1morename.com keyzweb.com ns
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16653
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;keyzweb.com. IN NS
;; AUTHORITY SECTION:
keyzweb.com. 86400 IN SOA NS1.1MORENAME.com. hostmaster.keyzweb.com. 1 28800 7200 604800 86400
;; Query time: 123 msec
;; SERVER: 173.236.119.110#53(173.236.119.110)
;; WHEN: Sat Mar 5 11:06:05 2011
;; MSG SIZE rcvd: 90
Вот трассировка, показывая, что записи NS в точке делегации (в этом случае, записи NS, возвращенные .com серверами имен), не являются авторитетными. Поэтому они не обнаруживаются как ответ: они не существуют в авторитетном сервере имен.
; <<>> DiG 9.7.0-P1 <<>> +trace keyzweb.com ns
;; global options: +cmd
. 22664 IN NS l.root-servers.net.
. 22664 IN NS f.root-servers.net.
. 22664 IN NS h.root-servers.net.
. 22664 IN NS a.root-servers.net.
. 22664 IN NS g.root-servers.net.
. 22664 IN NS m.root-servers.net.
. 22664 IN NS i.root-servers.net.
. 22664 IN NS d.root-servers.net.
. 22664 IN NS c.root-servers.net.
. 22664 IN NS k.root-servers.net.
. 22664 IN NS j.root-servers.net.
. 22664 IN NS e.root-servers.net.
. 22664 IN NS b.root-servers.net.
;; Received 509 bytes from 10.19.12.20#53(10.19.12.20) in 0 ms
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
;; Received 492 bytes from 193.0.14.129#53(k.root-servers.net) in 22 ms
keyzweb.com. 172800 IN NS ns1.1morename.com.
keyzweb.com. 172800 IN NS ns2.1morename.com.
;; Received 107 bytes from 192.26.92.30#53(c.gtld-servers.net) in 102 ms
keyzweb.com. 86400 IN SOA NS1.1MORENAME.com. hostmaster.keyzweb.com. 1 28800 7200 604800 86400
;; Received 90 bytes from 173.236.119.110#53(ns2.1morename.com) in 124 ms
Пара вещей:
1) "example.com" является зарезервированным доменным именем на RFC 2606. Это имеет особый статус в зоне общего домена верхнего уровня из-за этой Лучшей существующей практики. Это резервируется главным образом так, чтобы у людей, пишущих документацию, книги, и т.д., было, ну, в общем, доменное имя 'в качестве примера' для использования/отношений, не смущая читателей (или притягивая нежелательный трафик).
2) Вышеупомянутый плакат корректен: example.com имеет два перечисленные сервера имен, оба по iana-servers.net. Лучший способ проверить это состоит в том, чтобы обойти дерево, как сопоставитель был бы.
-> роют @f.gtld-servers.net example.com не уточнено-> nslookup-type=a example.com. f.gtld-servers.net. ('тип' может быть любым из 'любого',/'aaaa', 'mx', txt', и т.д.)-> размещают example.com f.gtld-servers.net
Из Вашего исходного сообщения tho - я подозрителен. SOA не соответствует. "1morename" не корректный SOA для example.com. Этот Ваш ISP? Если так, интересно, уклоняются ли они от DNS для своего собственного преимущества. (Если не их, возможно, дистрибутив Linux Вы используете?)
Попробуйте NS запроса с корневого корневого сервера TLD:
$ dig com. NS
; <<>> DiG 9.7.0-P1 <<>> com. NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18638
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;com. IN NS
;; ANSWER SECTION:
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
$ dig example.com NS @c.gtld-servers.net
; <<>> DiG 9.7.0-P1 <<>> example.com NS @c.gtld-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28957
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 4
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;example.com. IN NS
;; AUTHORITY SECTION:
example.com. 172800 IN NS a.iana-servers.net.
example.com. 172800 IN NS b.iana-servers.net.
Затем запросите запись с корневого сервера TLD:
$ dig example.com A @c.gtld-servers.net
; <<>> DiG 9.7.0-P1 <<>> example.com A @c.gtld-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18291
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 4
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;example.com. IN A
;; AUTHORITY SECTION:
example.com. 172800 IN NS a.iana-servers.net.
example.com. 172800 IN NS b.iana-servers.net.
;; ADDITIONAL SECTION:
a.iana-servers.net. 172800 IN A 199.43.132.53
a.iana-servers.net. 172800 IN AAAA 2001:500:8c::53
Май, запись прибывает из сервера TLD.