DNS и понимание корневых серверов


0

Во-первых, правильно ли это объяснение того, как работает DNS?

Когда мы посещаем сайт, скажем (www.example.com), мы проводим поиск, чтобы преобразовать доменное имя в адрес i.p. Итак, наш компьютер сначала смотрит на свой внутренний DNS, чтобы увидеть, есть ли там имя хоста. Если имя хоста отсутствует, оно отправляется на корневые серверы имен (.). Теперь корневые серверы имен получают запрос и сообщают нам, что запрос находится на серверах TLD, и дают нам IP-адрес серверов TLD. Теперь, когда мы запрашиваем серверы TLD, серверы TLD содержат расширение таких веб-сайтов, как .com, .org, .net и т. Д. В этом случае серверы TLD перенаправляют нас на com-серверы, и мы получаем IP-адрес com-серверы. Когда мы запрашиваем com-серверы, в их списке есть «пример» и перенаправляют нас на DNS-серверы примера. Когда мы запрашиваем сервер example.com, мы получаем IP-адрес и получаем доступ к Интернету.

Мой вопрос, например ,.com, авторитетный сервер имен будет com-сервер правильно? так как это тот, кто дает нам информацию?


Авторитетный сервер имен - это тот, который содержит записи. Это DNS-сервер для example.com. Кроме того, компьютеры не выполняют корневые операции поиска. У них настроен DNS-сервер, обычно ISP, и они запрашивают DNS-сервер ISP. Если требуется поиск в корне, то сервер DNS провайдера делает это. Не твой компьютер. Было бы очень неэффективно и обременительно иметь отдельные компьютеры для выполнения корневых поисков.
Appleoddity

Скажем, на моих DNS-серверах вообще нет кэшированных данных. Итак, он собирается перейти к корневому каталогу, затем к TLD, затем к com-серверам и, наконец, к серверам "example.com". «Официальный сервер имен - это тот, который хранит записи». Согласно этому утверждению, будут ли полномочные серверы имен ком-серверами?
john

Почему это было бы неэффективно? Это будет очень много времени?
john

DNS-серверы, на которых размещен домен example.com, являются официальными. Корневой сервер делегирует .com второму набору DNS-серверов. Эти DNS-серверы .com делегируют .example.com другому набору DNS-серверов, которые обычно являются серверами, которые вы указали при регистрации домена. Это официальные DNS-серверы - те, которые вы указываете при регистрации домена. Посмотреть здесь: docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/... это неэффективно, потому что существует система кеширования по очень конкретной причине, чтобы не перегружать интернет-DNS.
Appleoddity

Например, вы не единственный клиент вашего интернет-провайдера, который запрашивает google.com. Чрезвычайно неэффективно отправлять ваш компьютер или DNS-серверы на корневые серверы для рекурсивного поиска. Во-первых, у вас нет прямого подключения к магистрали Интернета, как у вашего интернет-провайдера, поэтому оно медленнее. Во-вторых, вы можете воспользоваться кешированными результатами, которые другие за вас взяли. Даже если вы используете свой собственный DNS, как в Active Directory, он должен быть настроен на использование серверов пересылки у вашего интернет-провайдера и использовать только корневые ссылки в качестве отказоустойчивых. Это быстрее и эффективнее, когда важны миллисекунды.
Appleoddity

Ответы:


1

Мой вопрос, например ,.com, авторитетный сервер имен будет com-сервер правильно?

Пусть dig Это:

# dig example.com SOA

 ;; ANSWER SECTION:
example.com.            3600    IN      SOA     sns.dns.icann.org. noc.dns.icann.org. 2018080109 7200 3600 1209600 3600

;; AUTHORITY SECTION:
example.com.            86400   IN      NS      a.iana-servers.net.
example.com.            86400   IN      NS      b.iana-servers.net.

Официальный сервер имен для example.com является:

a.iana-servers.net.
b.iana-servers.net. 

Это серверы, которые держат записи DNS для example.com

Теперь мы можем запросить их напрямую:

dig @a.iana-servers.net example.com A

;; ANSWER SECTION:
example.com.            86400   IN      A       93.184.216.34

DNS решатель разобрать Полное доменное имя (Полное доменное имя) справа налево.
Первый запрос к корневым DNS-серверам с вопросом, кто является официальным DNS-сервером в TLD за .com, а затем конкретный запрос резольвера TLD за example.com с этих серверов.

# dnstracer -4 -r1 -s. example.com

Tracing to example.com[a] via A.ROOT-SERVERS.NET, maximum of 1 retries
A.ROOT-SERVERS.NET [.] (198.41.0.4)
 |\___ d.gtld-servers.net [com] (192.31.80.30)
 |     |\___ b.iana-servers.net [example.com] (2001:0500:008d:0000:0000:0000:0000:0053) Not queried
 |     |\___ b.iana-servers.net [example.com] (199.43.133.53) Got authoritative answer
 |     |\___ a.iana-servers.net [example.com] (2001:0500:008f:0000:0000:0000:0000:0053) Not queried
 |      \___ a.iana-servers.net [example.com] (199.43.135.53) Got authoritative answer

Давайте попробуем сейчас другой домен в .com TLD :

 # dig google.com SOA 

;; AUTHORITY SECTION:
google.com.             345600  IN      NS      ns3.google.com.
google.com.             345600  IN      NS      ns4.google.com.
google.com.             345600  IN      NS      ns1.google.com.
google.com.             345600  IN      NS      ns2.google.com.

мы увидим, что авторитетные серверы имен для SLD google.com сейчас другое.

так как это тот, кто дает нам информацию?

Нет, это цепочка авторитетных DNS-серверов.
Корневые DNS-серверы, содержащие только зоны верхнего уровня, также известные как TLD , - такие как .com, .net Когда решатель получил авторитетные DNS-серверы, отвечающие за TLD разрешить запрос конкретной зоны для SLD (Домен второго уровня, example в нашем случае) и когда он нашел авторитетный DNS-сервер для SLD он запрашивает этот сервер для Полное доменное имя (Полное доменное имя), например, www.example.com

Обычно люди, использующие DNS-серверы интернет-провайдеров, которые содержат кешированные разрешенные записи DNS. Такие DNS-серверы называются пересылочными DNS-серверами. Если у них есть записи в кеше, они немедленно отвечают клиенту, не беспокоя всех промежуточных серверов, начиная с root. Если на таких DNS-серверах пересылки нет записей в кеше (или срок действия записи DNS истек), то переадресация разрешается снова и результат кешируется. DNS-запросы клиента отправляются как рекурсивные, это означает, что клиент должен получать от поставщика DNS либо ошибку, либо разрешенную запись. Клиент не должен самостоятельно запрашивать цепочку промежуточных DNS-серверов, это задача пересылки DNS-сервера, который обслуживает запросы клиентов и кэшированные результаты. Таким образом, серверы пересылки уменьшают нагрузку на промежуточные DNS-серверы и отвечают клиентам как можно скорее, поскольку DNS-серверы поставщиков находятся ближе к клиентам.
(Кстати, общедоступный DNS-сервер Google также является пересылкой.)

В DNS-записях есть параметр TTL (время жизни), который устанавливается на авторитетных серверах владельцем домена, поэтому, если вы ожидаете, что ваш IP-адрес будет часто меняться, вы можете установить TTL = 5 минут или если вы не хотите, чтобы его DNS-сервер был надоело слишком часто, тогда TTL можно установить на несколько дней.


0

В основном правильно, но вы исключили кеширование, которое критично.

Когда вы впервые настраиваете простой сервер только для кэширования, единственные записи, о которых он знает, это root hints - это указывает на корневые серверы. Если вы попросите example.com корневые серверы сообщат, какой сервер запрашивать записи в .com - это авторитетные серверы. Ваш DNS-сервер затем кэширует эту информацию. Затем он спросит .com сервер (ы) для информации о example.com и они будут возвращать указатель на любые серверы имен example.com настроен для использования в базе данных регистратора. Эта информация также кэшируется. Затем ваш DNS-сервер запрашивает у серверов имен example.com для IP-адреса, который соответствует имени, которое вы просили - www.example.com или что-то еще.

Теперь, скажем, вы потом попросите example2.com - .com информация о сервере уже кэширована, поэтому вместо того, чтобы беспокоить корневой сервер, ваш DNS-сервер идет прямо к .com серверов, получает информацию о сервере имен для example2.com домен, и запрашивает их.


Вы пренебрегаете делегированием DNS. Серверы .com не являются полномочными для .example.com. Они просто делегируют этот домен тем DNS-серверам, которые были настроены при регистрации домена example.com. Тот же сервер, на котором вы конфигурируете все свои записи A и CNAME для example.com, является полномочным для самого домена example.com.
Appleoddity
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.