Чи має 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це, мабуть, кілька машин, і що мене перенаправляють на найближчу мені (через цю нову технологію one-ip-multi-machine), але це просто означатиме, що кілька інших машин мають усі .comдомени.

EDIT: Дякую всім, хто відповів! Подальше запитання: якщо хтось «забиває» одну з цих машин, не зміг би отримати список усіх .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, отже, швидше, і такі сервери імен, як відомо, завжди означають, що з деякою удачею вам завжди мати одного "біля" тебе.

Я розумію, що a.gtld-servers.net, ймовірно, кілька машин

Ви можете видалити "ймовірно" :-) Ці сервери імен отримують стільки запитів, що жоден окремий ящик ніколи не зможе протистояти.

Якщо ви перейдете на сторінку https://stat.ripe.net/192.5.6.30#tabId=routing, ви побачите багато інформації, яка може бути складною для перетравлення, але в основному, бачачи, що це єдиний IP-код a.gtld-servers.net(насправді той блок, в якому це) оголошено декількома AS, які контролюються однією компанією, що є сильним показником будь-якого телеканалу, який прекрасно працює для більшості 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є gTLD і як такий укладається за контрактом з ICANN. ICANN доручає всім реєстрам gTLD публікувати свої зонні файли (це, в основному, те, що сервери імен використовують самі, тому записи NS плюс клей A / AAAA), принаймні один раз на день, і доступ вільний для всіх, поки ви підписуєте угоду щоб переконатися, що ви не використовуєте ці дані для "поганих" цілей (наприклад, перепублікуйте їх самостійно).

Детальну інформацію про це дивіться на https://czds.icann.org/en . Це може надати доступ до сотень зональних файлів gTLD.

Зауважте, що якщо ваше питання поширюється на "якщо хтось зламає одну з цих машин і змінить вміст, який додає або видаляє доменні імена .COM ...", ми можемо швидко відповісти:

1. зміни не будуть помічені у всьому світі, оскільки ви зламаєте лише одне поле і є численні сервери імен, спочатку по імені, а потім через anycasting
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, усі ваші зону та реконструюйте файл файлу. Для цього є інструменти.

Зауважте також, що різні провайдери в Інтернеті будуть продавати вам зони файлів та / або список усіх доменних імен для багатьох TLD, які вони придбали різними способами (одна ідея серед інших: ви берете відкриті зони файлів, як .COM, а для TLD .exampleви запитуєте один за одним все ім’я, яке ви знайшли .COM, що може дати вам декілька ідей, окрім звичайного словника, що базується на мовах, які використовуються в TLD, що шукається).