Есть ли у a.gtld-servers.net список всех доменов .com?

Когда я это делаю dig @a.gtld-servers.net example.com, он быстро возвращает серверы имен example.comи IP-адреса для этих серверов имен (склеивать записи).

Означает ли это a.gtld-servers.net(и *.gtld-servers.net) наличие записи всех .comдоменов локально? Они отвечают очень быстро, поэтому я не думаю, что они сами делают дополнительный запрос. Точно так же запрос на example.comсервер имен не перенаправляет меня domains.starting.with.e.gtld-servers.netили что-то еще.

Я понимаю, что a.gtld-servers.netэто, вероятно, несколько машин, и что меня направляют на ближайшую ко мне (через эту новую технологию «один ip-несколько машин»), но это будет означать, что у нескольких других машин есть все .comдомены.

РЕДАКТИРОВАТЬ: Спасибо всем, кто ответил! Дополнительный вопрос: если кто-то «взломает» одну из этих машин, не сможет ли он получить список всех .comдоменов? Это кажется полезной информацией, разве что она уже доступна где-то бесплатно? Я понимаю, что информация о домене является общедоступной, но по-прежнему трудно получить ее оптом. Я предполагаю, *.gtld-servers.netчто не поддерживают передачу зон (хотя .eduсерверы имен сделали это, по крайней мере, несколько лет назад).

ПРИМЕЧАНИЕ. Я понимаю, что example.com не является действительным доменом - просто замените его на любой другой домен .com, указанный выше (у меня изначально был xyz.com, но кто-то правильно отредактировал его, чтобы избежать использования реального имени домена).

Да, "x.gtld-servers.net" являются официальными серверами для домена верхнего уровня com, поэтому у них есть все "указатели" для доменов .com. Вы можете увидеть серверы имен для TLD, запустив

dig -t ns com
dig -t ns us
dig -t ns dk
dig -t ns aero

Сделайте запрос для самого домена dig @a.gtld-servers.net com.- и найдите флаг «авторитетный ответ»:

snowflake ~ $ dig @a.gtld-servers.net com | grep flags
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
             ^^

Вы уже получили ответ давно, но я чувствую, что мы можем быть более точными, и у вас есть дополнительный вопрос, который на самом деле должен был стать другим вопросом.

Итак, давайте вернемся с самого начала.

Если вы запросите корневые серверы, чтобы узнать о .COMделегировании (обратите внимание, что все ниже применяется одинаково, так .NETкак оба обрабатываются одним и тем же реестром), вы получите этот ответ:

$ dig @a.root-servers.net com. NS +noall +auth

; <<>> DiG 9.12.0 <<>> @a.root-servers.net com. NS +noall +auth
; (1 server found)
;; global options: +cmd
com.            172800 IN NS e.gtld-servers.net.
com.            172800 IN NS b.gtld-servers.net.
com.            172800 IN NS j.gtld-servers.net.
com.            172800 IN NS m.gtld-servers.net.
com.            172800 IN NS i.gtld-servers.net.
com.            172800 IN NS f.gtld-servers.net.
com.            172800 IN NS a.gtld-servers.net.
com.            172800 IN NS g.gtld-servers.net.
com.            172800 IN NS h.gtld-servers.net.
com.            172800 IN NS l.gtld-servers.net.
com.            172800 IN NS k.gtld-servers.net.
com.            172800 IN NS c.gtld-servers.net.
com.            172800 IN NS d.gtld-servers.net.

Таким образом, в итоге любой из этих серверов имен является авторитетным, .COMи все они имеют одни и те же данные (так что вы можете расширить свой вопрос, a.gtld-servers.netэто ни в коем случае не является особенным, все ниже будет относиться к любому из этих серверов имен).

Когда вы будете запрашивать эти серверы имен для любого .COM/.NETдоменного имени, они должны ответить авторитетно с серверами имен, уполномоченными для доменного имени, которое вы запрашиваете.

Следовательно, по определению: «Означает ли это, что a.gtld-servers.net (и * .gtld-servers.net) имеют запись всех доменов .com локально?», Но это означает именно это! С некоторой оговоркой вокруг «всего», что рассматривается ниже.

Обратите внимание, что вы говорите о склеенных записях, это частный случай, и не самый частый. Обычно запрос домена на любом из вышеперечисленных серверов имен просто возвращает одну или несколько записей NS.

Давайте уделим время рассмотрению других незначительных моментов в вашем тексте:

Они отвечают очень быстро, поэтому я не думаю, что они сами делают дополнительный запрос.

У авторитетного сервера имен, по определению, есть данные, с которыми он должен отвечать на запросы, не полагаясь на какой-либо внешний ресурс, в противном случае он не является действительно авторитетным.

Что касается скорости, то это отчасти субъективно и сильно зависит от того, что и как вы тестируете, но есть несколько факторов: по умолчанию DNS использует UDP, который легче, чем TCP, следовательно, быстрее, и такие серверы имен anycasted, что означает, что с некоторой удачей вы всегда есть один "рядом" с вами.

Я понимаю, что a.gtld-servers.net, вероятно, несколько машин

Вы можете удалить «вероятно» :-) Эти серверы имен получают так много запросов, что ни один из них никогда не сможет противостоять.

Если вы перейдете на https://stat.ripe.net/192.5.6.30#tabId=routing, вы увидите много информации, которую может быть трудно переварить, но в основном, видя, что этот единственный IP-адрес a.gtld-servers.net(фактически блок, в котором это так) объявляется несколькими AS, все из которых контролируются одной компанией, что является сильным показателем anycasting, который прекрасно работает для большинства DNS.

Если вы зайдете на http://www.root-servers.org/, вы можете узнать больше. Это относится к корневым серверам имен, а не к .COMтем, что больше, но технически это одно и то же. Например, вы можете обнаружить, что 13 корневых серверов управляются 12 различными организациями в 930 экземплярах (экземпляр - это не просто один сервер, это местоположение, «точка присутствия», где у оператора есть «узел», который обычно механизм маршрутизации, несколько серверов для балансировки нагрузки / отработки отказа при настройке, некоторые возможности мониторинга / удаленных рук и т. д.). Fнапример в 222 местах.

и что меня направляют к ближайшему мне (через эту новую технологию «один ip-несколько машин»), но это будет означать, что у нескольких других компьютеров есть все домены .com.

Да, на многих машинах есть список всех .COMдоменных имен. Но сначала точность: на этих серверах имен вы получите список всех серверов имен для всех доменных имен .COM ... что означает, что для доменных имен, не делегированных, вы не найдете их здесь. Это может произойти в нескольких случаях:

1. когда вы регистрируете доменное имя, вы можете отказаться от установки серверов имен или удалить их позже.
2. ваш регистратор, например, из-за платежного спора может добавить статус clientHoldвашего доменного имени, что делает его исчезающим из DNS
3. реестр может включить домен по serverHoldтем или иным причинам.

(см. https://www.icann.org/resources/pages/epp-status-codes-2014-06-16-en, если вы хотите узнать больше об этих и других статусах).

В зависимости от того, как вы определяете «все» и что вы будете делать с такими данными, вы можете получить не совсем все из них.

Во всех вышеперечисленных случаях домен не будет отображаться на DNS-серверах реестра, но будет отображаться при выполнении запроса whois. Так что серверы whois (опять же, не один блок) также будут иметь ... список всех доменных имен .COM и даже больше данных, чем на серверах имен, потому что:

1. у вас действительно есть все доменные имена, в том числе не разрешенные и, следовательно, не на серверах имен реестра
2. Whois предоставляет гораздо больше информации, такой как контактные данные

И это все еще только общедоступные службы реестра, имеющие, так или иначе, список (или его часть) доменных имен.

Что касается вашего продолжения:

Дополнительный вопрос: если кто-то «взломает» одну из этих машин, не сможет ли он получить список всех доменов .com?

Технически да. Но:

1. Это, конечно, не самая простая цель, которую вы найдете в Интернете
2. И в этом конкретном случае данные уже доступны бесплатно.

.COMявляется рДВУ и, как таковая, находится на контракте с ICANN. ICANN обязывает все реестры рДВУ публиковать свои файлы зон (что, в основном, и используют сами серверы имен, так что записи NS плюс клеи A / AAAA), по крайней мере, один раз в день, и доступ для всех является бесплатным, пока вы подписываете соглашение чтобы убедиться, что вы не используете эти данные в «плохих» целях (например, перепубликуете их самостоятельно).

Смотрите https://czds.icann.org/en для всех деталей об этом. Это может дать вам доступ к сотням файлов зон gTLD.

Обратите внимание, что если ваш вопрос расширен на «если кто-то взломает одну из этих машин и изменит содержимое, которое добавляет или удаляет доменные имена .COM ...», то мы можем быстро ответить:

1. изменения не будут видны во всем мире, так как вы взламываете только один ящик, и существует множество серверов имен, сначала по имени, затем по anycast
2. DNSSEC может привести к тому, что ваши изменения появятся как ошибки и, следовательно, будут быстро обнаружены (помимо любых локальных контрмер, конечно, самим оператором).

Короче говоря, это не лучшая идея, чтобы связываться с .COMдоменными именами, и есть другие способы.

Я понимаю, что информация о домене является общедоступной, но по-прежнему трудно получить ее оптом.

См. Выше для программы ICANN. Что касается ccTLD, ситуация меняется, но чаще они не предоставляют доступ к своему файлу зоны, а не в режиме реального времени.

Иногда вы можете получить к нему доступ через некоторое время, например, с помощью движений «открытых данных». Один пример: https://opendata.afnic.fr/en/products-and-services/services/opendata-en.html для .FRдоменных имен.

Я предполагаю, что * .gtld-servers.net не поддерживает передачу зон (хотя серверы имен .edu сделали это, по крайней мере, несколько лет назад).

Легко проверить:

$ for ns in $(dig NS . +noall +ans | grep 'IN NS' | awk '{print $5}') ; do echo $ns ; dig @$ns com. AXFR; done
c.root-servers.net.

; <<>> DiG 9.12.0 <<>> @c.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
m.root-servers.net.

; <<>> DiG 9.12.0 <<>> @m.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
i.root-servers.net.

; <<>> DiG 9.12.0 <<>> @i.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
e.root-servers.net.

; <<>> DiG 9.12.0 <<>> @e.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
j.root-servers.net.

; <<>> DiG 9.12.0 <<>> @j.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
l.root-servers.net.

; <<>> DiG 9.12.0 <<>> @l.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
g.root-servers.net.

; <<>> DiG 9.12.0 <<>> @g.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
k.root-servers.net.

; <<>> DiG 9.12.0 <<>> @k.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
b.root-servers.net.

; <<>> DiG 9.12.0 <<>> @b.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
h.root-servers.net.

; <<>> DiG 9.12.0 <<>> @h.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
d.root-servers.net.

; <<>> DiG 9.12.0 <<>> @d.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

;; Connection to 199.7.91.13#53(199.7.91.13) for com. failed: timed out.
;; QUERY SIZE: 44

;; Connection to 199.7.91.13#53(199.7.91.13) for com. failed: timed out.
;; QUERY SIZE: 44

;; connection timed out; no servers could be reached
;; Connection to 199.7.91.13#53(199.7.91.13) for com. failed: timed out.
a.root-servers.net.

; <<>> DiG 9.12.0 <<>> @a.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
f.root-servers.net.

; <<>> DiG 9.12.0 <<>> @f.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.

Нет, сейчас ни один .COMавторитетный сервер имен не принимает запросы AXFR. Но это не обязательно везде одинаково. Если вы запросите f.root-servers.netсервер имен, вы можете выполнить запрос AXFR, чтобы опубликовать все TLD. Некоторые другие TLD могут также разрешить это.

Обратите внимание, что существует множество рекомендаций, запрещающих публичные запросы AXFR. Факты в том, что они являются огромными ответами по определению, и могут повредить сервер, если его повторить, это правда. Он может бесконечно спорить о том, почему / если общественность нуждается в этой информации. В начале DNS он больше использовался для копирования зон между серверами имен (сейчас есть гораздо лучшие альтернативы). Таким образом, AXFR часто отключается ... за исключением того, что если вы выполняете DNSSEC одновременно, каким-то особым образом (т. Е. NSEC, а не вариантом NSEC3), легко пройти через стандартные запросы DNS и без AXFR все ваши зоны и восстановить файл зоны. Инструменты существуют для этого.

Также обратите внимание, что различные провайдеры онлайн будут продавать вам файлы зон и / или список всех доменных имен для многих доменов верхнего уровня, которые они приобрели различными способами (одна идея среди других: вы берете открытые файлы зон, например .COM, и для доменов верхнего уровня .exampleвы запрашиваете один за другим все имена, которые вы нашли .COM, которые могли бы дать вам некоторые идеи, кроме, конечно же, хождения по словарю на основе языков, наиболее часто используемых при поиске в ДВУ).