Вы уже получили ответ давно, но я чувствую, что мы можем быть более точными, и у вас есть дополнительный вопрос, который должен был быть другим вопросом на самом деле.
Итак, давайте вернемся с самого начала.
Если вы запрашиваете корневые серверы, чтобы узнать о .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 ... это означает, что для доменных имен, не делегированных, вы не найдете их здесь.
Это может произойти в нескольких случаях:
- когда вы регистрируете доменное имя, вы можете отказаться от установки серверов имен или удалить их позже.
- ваш регистратор, например, из-за платежного спора может добавить статус
clientHold на ваше доменное имя, что делает его исчезающим из DNS
- Реестр может поставить домен на
serverHold по тем или иным причинам.
(см. https://www.icann.org/resources/pages/epp-status-codes-2014-06-16-en, если вы хотите узнать больше об этих и других статусах).
В зависимости от того, как вы определяете "все" и что вы будете делать с такими данными, вы можете получить не совсем все из них.
Во всех вышеперечисленных случаях домен не будет отображаться на DNS-серверах реестра, но появится, когда вы выполните запрос к whois. Так что серверы whois (опять же, не один ящик) также будут иметь ... список всех .COM и даже больше данных, чем на серверах имен, потому что:
- у вас действительно есть все доменные имена, в том числе не разрешенные и, следовательно, не на серверах имен реестра
- Whois предоставляет гораздо больше информации, такой как контактные данные
И это все еще только общедоступные службы реестра, имеющие, так или иначе, список (или его часть) доменных имен.
Что касается вашего продолжения:
Дополнительный вопрос: если кто-то "взломает" одну из этих машин, не сможет ли он получить список всех доменов .com?
Технически да. Но:
- Это, конечно, не самая простая цель, которую вы найдете в Интернете
- И в этом конкретном случае данные уже доступны бесплатно.
.COM является gTLD и, как таковой, находится на контракте с ICANN. ICANN обязывает все реестры рДВУ публиковать свои файлы зон (в основном это то, чем сами серверы имен пользуются, поэтому записи NS плюс клеи A/AAAA), по крайней мере, один раз в день, и доступ к ним бесплатный для всех, пока вы подписываете соглашение чтобы убедиться, что вы не используете эти данные в "плохих" целях (например, перепубликуете их самостоятельно).
Смотрите https://czds.icann.org/en для всех деталей об этом. Это может дать вам доступ к сотням файлов зон gTLD.
Обратите внимание, что если ваш вопрос расширен на «если кто-то взломает одну из этих машин и поменяет добавляемый или удаляемый контент .COM ... "тогда мы можем быстро ответить:
- изменения не будут видны во всем мире, так как вы взламываете только один ящик, и существует множество серверов имен, сначала по имени, а затем по любому каналу.
- 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 , а для TLD .example вы запрашиваете одно за другим все найденные вами имена .COM , который может дать вам некоторые идеи, помимо, конечно же, хождения по словарю на основе языков, наиболее часто используемых при поиске в TLD).
