Если я попытаюсь запросить корневой сервер с помощью dig, Я никогда не получаю ответа.
Например, вывод для dig @b.root-servers.net www.ubuntu.com является
; << >> DiG 9.8.1-P1 << >> @ b.root-servers.net www.ubuntu.com
; (Найден 1 сервер)
;; глобальные параметры: + cmd
;; время соединения истекло; серверы недоступны
Но если я запрашиваю другие серверы (один из моих интернет-провайдеров или 8.8.8.8), они отвечают правильно. Зачем?
P.S. Используя Wireshark, я могу видеть исходящие запросы на правильный IP-адрес корневого сервера, но нет входящих пакетов с того же IP-адреса.
Похоже, ваш интернет-провайдер должен заблокировать доступ к корневым серверам имен. Они, очевидно, не блокируют доступ к своим собственным преобразователям, и они, вероятно, освобождают пару других популярных внешних преобразователей, таких как Google Public DNS, но могут заблокировать все domain-порт доступ в противном случае.
Это обычное дело? Это зависит. Я думаю, что такие блоки довольно часто присутствуют в университетских и корпоративных сетях, но я бы сказал, что это не должно быть особенно распространенным явлением с обычными жилыми провайдерами. (Большинство провайдеров блокируют исходящие smtp-порт, однако.)
Зачем кому-то блокировать внешние серверы имен? Вероятно, это связано с различными атаками типа «злоумышленник в середине», которые возможны, если взломанные серверы имен заменены законными. Чтобы избежать подобных атак и уменьшить количество жалоб пользователей, большинство провайдеров обычно перенаправляют все domain-портировать запросы на свои собственные серверы: когда они это сделают, вы больше не сможете запускать свой собственный рекурсивный сервер или dig +trace устранение неполадок, но, по крайней мере, в противном случае вам не пришлось бы менять настройки DNS.
В любом случае, действительно, в самой вашей команде нет ничего плохого: вы должны получить ответ, как показано ниже, что позволит вам сделать еще один запрос по ручному рекурсивному пути к разрешению данного имени.
# dig @b.root-servers.net www.ubuntu.com
; <<>> DiG 9.7.3 <<>> @b.root-servers.net www.ubuntu.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20828
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 14
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;www.ubuntu.com. IN A
;; AUTHORITY SECTION:
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
;; ADDITIONAL SECTION:
a.gtld-servers.net. 172800 IN A 192.5.6.30
b.gtld-servers.net. 172800 IN A 192.33.14.30
c.gtld-servers.net. 172800 IN A 192.26.92.30
d.gtld-servers.net. 172800 IN A 192.31.80.30
e.gtld-servers.net. 172800 IN A 192.12.94.30
f.gtld-servers.net. 172800 IN A 192.35.51.30
g.gtld-servers.net. 172800 IN A 192.42.93.30
h.gtld-servers.net. 172800 IN A 192.54.112.30
i.gtld-servers.net. 172800 IN A 192.43.172.30
j.gtld-servers.net. 172800 IN A 192.48.79.30
k.gtld-servers.net. 172800 IN A 192.52.178.30
l.gtld-servers.net. 172800 IN A 192.41.162.30
m.gtld-servers.net. 172800 IN A 192.55.83.30
a.gtld-servers.net. 172800 IN AAAA 2001:503:a83e::2:30
;; Query time: 12 msec
;; SERVER: 192.228.79.201#53(192.228.79.201)
;; WHEN: Sat Jan 12 22:52:12 2013
;; MSG SIZE rcvd: 492
Корневые серверы должны ответить на ваш вопрос о том, где вы можете найти .com. Причина, по которой b.root-servers.net не отвечает, может заключаться в том, что ваш файл корневых подсказок устарел. Попробуйте обновить этот файл.