Почему DNS работает так, как работает?

Это канонический вопрос о DNS (служба доменных имен).

Если я правильно понимаю систему DNS, в реестре.com содержится таблица, которая сопоставляет домены (www.example.com) с DNS-серверами.

  1. В чем преимущество? Почему бы не сопоставить напрямую с IP-адресом?

  2. Если единственная запись, которую необходимо изменить, когда я настраиваю DNS-сервер для указания другого IP-адреса, находится на DNS-сервере, почему процесс не мгновенный?

  3. Если единственной причиной задержки являются кеши DNS, можно ли их обойти, чтобы я мог видеть, что происходит в режиме реального времени?

Источник

5 ответов

Решение

На самом деле все гораздо сложнее - вместо одного "центрального реестра (который) содержит таблицу, которая отображает домены (www.mysite.com) на DNS-серверы", существует несколько уровней иерархии.

Существует центральный реестр (корневые серверы), который содержит только небольшой набор записей: записи NS (сервера имен) для всех доменов верхнего уровня - .com, .net, .org, .uk, .us, .au, и так далее.

Эти серверы просто содержат записи NS для следующего уровня вниз. Чтобы выбрать один пример, серверы имен для .uk В домене есть записи для .co.uk, .ac.ukи другие зоны второго уровня, используемые в Великобритании.

Эти серверы просто содержат записи NS для следующего уровня ниже - чтобы продолжить пример, они сообщают вам, где найти записи NS для google.co.uk, Именно на тех серверах вы, наконец, найдете соответствие между именем хоста, например www.google.co.uk и IP-адрес.

Как дополнительная складка, каждый слой также будет обслуживать "склеенные" записи. Каждая запись NS сопоставляет домен с именем хоста - например, записи NS для .uk список nsa.nic.uk как один из серверов. Чтобы перейти на следующий уровень, нам нужно выяснить записи NS для nic.uk есть, и они, как оказалось, включают nsa.nic.uk также. Итак, теперь нам нужно знать IP nsa.nic.uk, но чтобы выяснить это, нам нужно сделать запрос nsa.nic.uk, но мы не можем сделать этот запрос, пока мы не знаем IP для nsa.nic.uk...

Чтобы решить эту проблему, серверы для .uk добавить запись для nsa.nic.uk в ADDITIONAL SECTION ответа (ответ ниже обрезан для краткости):

jamezpolley@li101-70:~$dig nic.uk ns

; <<>> DiG 9.7.0-P1 <<>> nic.uk ns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21768
;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 14

;; QUESTION SECTION:
;nic.uk.                IN  NS

;; ANSWER SECTION:
nic.uk.         172800  IN  NS  nsb.nic.uk.
nic.uk.         172800  IN  NS  nsa.nic.uk.

;; ADDITIONAL SECTION:
nsa.nic.uk.     172800  IN  A   156.154.100.3
nsb.nic.uk.     172800  IN  A   156.154.101.3

Без этих дополнительных записей мы никогда не смогли бы найти серверы имен для nic.uk. и поэтому мы никогда не сможем искать какие-либо домены, размещенные там.

Чтобы вернуться к вашим вопросам...

а) В чем преимущество? Почему бы не сопоставить напрямую с IP-адресом?

С одной стороны, это позволяет распределять правки для каждой отдельной зоны. Если вы хотите обновить запись для www.mydomain.co.uk, вам просто нужно отредактировать информацию на вашем mydomain.co.ukсервер имен. Там нет необходимости уведомлять центральный .co.uk серверы или .uk серверы или корневые серверы имен. Если бы существовал только один центральный реестр, который отображал все уровни на всем протяжении иерархии, которую нужно было уведомлять о каждом отдельном изменении записи DNS на всем протяжении цепочки, он был бы просто завален трафиком.

До 1982 года так и происходило разрешение имен. Один центральный реестр был уведомлен обо всех обновлениях, и они распространили файл под названием hosts.txt который содержал имя хоста и IP-адрес каждой машины в Интернете. Новая версия этого файла была опубликована каждые несколько недель, и каждая машина в Интернете должна была бы загрузить новую копию. Задолго до 1982 года это начало становиться проблематичным, и поэтому DNS был изобретен для обеспечения более распределенной системы.

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

(Чтобы обеспечить дополнительную избыточность, на самом деле существует 13 отдельных кластеров серверов, которые обслуживают корневую зону. Любые изменения в записях домена верхнего уровня необходимо перенести на все 13; представьте, что нужно координировать обновление всех 13 из них для каждого отдельного изменения на любое имя хоста в любой точке мира...)

б) Если единственная запись, которую необходимо изменить при настройке DNS-сервера для указания другого IP-адреса, находится на DNS-сервере, то почему процесс не мгновенный?

Потому что DNS использует много кэширования, чтобы ускорить процесс и уменьшить нагрузку на NS. Без кэширования, каждый раз, когда вы посетили google.co.uk ваш компьютер должен был бы выйти в сеть, чтобы найти серверы для .uk, затем .co.uk, затем .google.co.uk, затем www.google.co.uk, Эти ответы на самом деле не сильно меняются, поэтому каждый раз искать их - пустая трата времени и сетевого трафика. Вместо этого, когда NS возвращает записи на ваш компьютер, он будет содержать значение TTL, которое говорит вашему компьютеру о необходимости кэшировать результаты в течение нескольких секунд.

Например, записи NS для .uk иметь TTL 172800 секунд - 2 дня. Google еще более консервативен - записи NS для google.co.uk TTL 4 дня. Сервисы, которые полагаются на возможность быстрого обновления, могут выбрать намного более низкий TTL - например, telegraph.co.uk имеет TTL всего 600 секунд на своих записях NS.

Если вы хотите, чтобы обновления в вашей зоне происходили почти мгновенно, вы можете понизить свой TTL до нужного уровня. Чем ниже его значение, тем больше трафика увидят ваши серверы, поскольку клиенты будут чаще обновлять свои записи. Каждый раз, когда клиенту приходится обращаться к вашим серверам для выполнения запроса, это вызывает некоторое отставание, поскольку это медленнее, чем поиск ответа в его локальном кеше, поэтому вам также следует рассмотреть вопрос о компромиссе между быстрыми обновлениями и быстрым обслуживанием.

в) Если единственной причиной задержки являются кеши DNS, можно ли их обойти, чтобы я мог видеть, что происходит в режиме реального времени?

Да, это легко, если вы тестируете вручную с dig или аналогичные инструменты - просто скажите ему, с каким сервером связаться.

Вот пример кэшированного ответа:

jamezpolley@host:~$dig telegraph.co.uk NS

; <<>> DiG 9.7.0-P1 <<>> telegraph.co.uk NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36675
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;telegraph.co.uk.       IN  NS

;; ANSWER SECTION:
telegraph.co.uk.    319 IN  NS  ns1-63.akam.net.
telegraph.co.uk.    319 IN  NS  eur3.akam.net.
telegraph.co.uk.    319 IN  NS  use2.akam.net.
telegraph.co.uk.    319 IN  NS  usw2.akam.net.
telegraph.co.uk.    319 IN  NS  use4.akam.net.
telegraph.co.uk.    319 IN  NS  use1.akam.net.
telegraph.co.uk.    319 IN  NS  usc4.akam.net.
telegraph.co.uk.    319 IN  NS  ns1-224.akam.net.

;; Query time: 0 msec
;; SERVER: 97.107.133.4#53(97.107.133.4)
;; WHEN: Thu Feb  2 05:46:02 2012
;; MSG SIZE  rcvd: 198

Раздел флагов здесь не содержит aa флаг, поэтому мы можем видеть, что этот результат пришел из кэша, а не напрямую из авторитетного источника. На самом деле, мы можем видеть, что это произошло из 97.107.133.4, который является одним из локальных DNS-преобразователей Linode. Тот факт, что ответ был получен из кэша, очень близкого ко мне, означает, что мне потребовалось 0 мсек, чтобы получить ответ; но, как мы увидим через мгновение, цена, которую я плачу за эту скорость, состоит в том, что ответ почти на 5 минут устарел.

Чтобы обойти распознаватель Линоде и перейти прямо к источнику, просто выберите один из этих NS и скажите dig, чтобы связаться с ним напрямую:

jamezpolley@li101-70:~$dig @ns1-224.akam.net telegraph.co.uk NS

; <<>> DiG 9.7.0-P1 <<>> @ns1-224.akam.net telegraph.co.uk NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23013
;; flags: qr aa rd; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;telegraph.co.uk.       IN  NS

;; ANSWER SECTION:
telegraph.co.uk.    600 IN  NS  use2.akam.net.
telegraph.co.uk.    600 IN  NS  eur3.akam.net.
telegraph.co.uk.    600 IN  NS  use1.akam.net.
telegraph.co.uk.    600 IN  NS  ns1-63.akam.net.
telegraph.co.uk.    600 IN  NS  usc4.akam.net.
telegraph.co.uk.    600 IN  NS  ns1-224.akam.net.
telegraph.co.uk.    600 IN  NS  usw2.akam.net.
telegraph.co.uk.    600 IN  NS  use4.akam.net.

;; Query time: 9 msec
;; SERVER: 193.108.91.224#53(193.108.91.224)
;; WHEN: Thu Feb  2 05:48:47 2012
;; MSG SIZE  rcvd: 198

Вы можете видеть, что на этот раз результаты были предоставлены непосредственно из источника - обратите внимание на aa флаг, который указывает, что результаты получены из авторитетного источника. В моем предыдущем примере результаты пришли из моего локального кэша, поэтому им не хватает aa флаг. Я вижу, что авторитетный источник для этого домена устанавливает TTL 600 секунд. Результаты, которые я получил ранее из локального кэша, имели TTL всего 319 секунд, что говорит мне, что они сидели в кэше (600-319) секунд - почти 5 минут - до того, как я их увидел.

Несмотря на то, что TTL здесь составляет всего 600 секунд, некоторые интернет-провайдеры попытаются еще больше уменьшить свой трафик, заставляя свои распознаватели DNS более длительно кэшировать результаты - в некоторых случаях в течение 24 часов или более. Традиционно (по принципу "мы не знаем, если это действительно необходимо", но давайте будем в безопасности ") предполагается, что любое внесенное вами изменение DNS не будет видно повсюду на Интернет на 24-48 часов.

Источник

А ) Количество сопоставлений имен IP -> хостов в мире действительно очень велико. Эта система распределяет ответственность за размещение всех поддоменов и записей MX и всех других записей DNS для владельца доменного имени. Это было в значительной степени смысл доменного имени. .com проводится одним реестром, где как .uk может быть проведен другим. также example.com а также otherexample.com могут быть размещены отдельно, поэтому ресурсы могут быть распределены.

б) он кэшируется, что уменьшает количество обращений к вашему DNS-узлу до небольшой доли того, что было бы в противном случае. По умолчанию записи живут в кеше 2 дня, а затем удаляются. Это можно изменить, изменив TTL (время жизни) записи.

в) Вы можете эффективно остановить кэширование записей, установив очень короткий TTL. Это НЕ рекомендуется, если вы не используете его для динамического DNS. Кэширование значительно снижает количество обращений к DNS-серверу. Чтобы выбрать предполагаемое число из воздуха, мы говорим о сбивании 95% запросов.

Источник

Если вы работаете в системе *nix, загрузите копию djbdns Дэна Бернштейна с http://cr.yp.to/djbdns.html и запустите его программу dnstrace, чтобы увидеть, как работает система рекурсивных запросов. Это очень информативно.

Источник

a) Количество возможных доменных имен слишком велико для одного сервера. И это не просто.com; есть.net,.org,.se,.info и любое количество других. Добавьте к этому, вы можете делегировать ответственность за поддомен (что эффективно com делает). DNS является менее централизованным, что делает все это проще в управлении.

б) Машины на пути от пользователя к вам имеют кеши DNS, чтобы минимизировать количество необходимых запросов. Это предотвращает, например, спам в сети с запросами на адрес "faultserver.ru" каждый раз, когда вы получаете страницу от SF. Эти серверы могут даже кэшировать результаты "домен не существует", поэтому может потребоваться некоторое время, чтобы появился даже новый домен.

c) Несмотря на то, что вы можете отключить кэш, между вашим компьютером и DNS-сервером yourdomain.com часто находятся другие DNS-серверы. Например, DNS-сервер вашего провайдера будет пытаться кэшировать столько, сколько может. Единственные записи, которые обновляются относительно быстро по сети, - это записи с коротким TTL (который в основном говорит: "Я действителен только в течение нескольких секунд; после этого снова спросите меня о текущей информации"). Причиной того, что TTL так высоки, является то, что сервер, отвечающий за домен, может перенести часть работы на другие серверы. Если бы у вас была вся сеть, связывающаяся с вашим одним или двумя DNS-серверами Rinky-Dink для каждого попадания на ваш веб-сайт, они были бы практически бесполезны, если бы кто-то увидел ваш сайт на /, Digg и т. Д.

Источник

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

Точка не обязательно является делегированием

Эти серверы просто содержат записи NS для следующего уровня ниже. Возьмем один пример: серверы имен для домена .uk содержат только записи для .co.uk, .ac.uk и других зон второго уровня, используемых в Великобритании.

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

Точка в имени не обязательно подразумевает делегирование (записи).

Это имеет место здесь и сейчас для примера, приведенного ниже:

      $ dig uk. NS +short
dns1.nic.uk.
nsc.nic.uk.
dns3.nic.uk.
dns2.nic.uk.
nsb.nic.uk.
nsa.nic.uk.
dns4.nic.uk.
nsd.nic.uk.
$ dig @dns1.nic.uk. co.uk. NS +short
nsa.nic.uk.
nsb.nic.uk.
nsc.nic.uk.
nsd.nic.uk.
dns1.nic.uk.
dns2.nic.uk.
dns3.nic.uk.
dns4.nic.uk.

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

      $ dig fr. NS +short
g.ext.nic.fr.
d.nic.fr.
f.ext.nic.fr.
e.ext.nic.fr.
$ dig @d.nic.fr. gouv.fr. NS +short
$

Действительно нет отображения, потому что полный ответ только:

      ;; AUTHORITY SECTION:
fr.         1h30m IN SOA nsmaster.nic.fr. hostmaster.nic.fr. (

показывая этоне делегируется из.

Короче говоря, на любом уровне DNS у вас может быть любое имя, определенное ниже (владелец зоны может полностью опубликовать запись дляесли пожелает, без необходимости иметь какие-либо записи где-нибудь "посередине"), ИЛИ делегирование в любой точке (владелец зоны может делегироватьно нетнапример).

Приклеиваем пластинки

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

Опять же, возможно, это просто упрощение текста, но в нынешнем виде это неправда.

Первые склеивающие записи появляются только при наличии делегирования. По причинам предыдущего пункта не все слои имеют делегирование имен ниже.

Тогда связующие существуют и необходимы ТОЛЬКО в том случае, если используемые серверы имен находятся в зоне ответственности.

Если делегировано, то авторитетному серверу имен НЕОБХОДИМО публиковать как записи, так и/записи непосредственно для. Эти записи называются связующими записями по той простой причине, что они находятся на родительской стороне и касаются имени на дочерней стороне.

Напротив, еслиделегируетсятогда НЕТ склеенных записей вавторитетные серверы имен, которые будут публиковать толькозаписывать.

Для дальнейшего обсуждения и подробностей по этому поводу обратитесь к RFC 8499 «Терминология DNS» , в котором есть целый раздел, посвященный связям и серверам имен «в бейливике», начиная с §7. Зоны.

Просто другие связанные быстрые наблюдения:

  • использование клеевых пластинок имеет как преимущества, так и недостатки; разумной рекомендацией было бы для любого важного имени использовать смесь серверов имен, где некоторые из них находятся в сфере бейливика (следовательно, нуждаются в связях), а некоторые нет; таким образом вы теоретически нивелируете недостатки каждого случая
  • Связывающие записи являются проблемой в мире DNSSEC, как и в мире DNSSEC.раздел, который НЕ подписан, поэтому его можно подделать, даже если и родительский, и дочерний раздел полностью включены DNSSEC (именно поэтому наличие всех серверов имен в качестве in-bailiwick представляет собой угрозу безопасности в этом отношении)

"база данных"

До 1982 года разрешение имен происходило именно так. Один центральный реестр был уведомлен обо всех обновлениях, и они распространили файл под названием hosts.txt, который содержал имя хоста и IP-адрес каждой машины в Интернете.

Да, в самом деле. И вы можете увидеть, как это выглядело, перейдя на https://rscott.org/OldInternetFiles/ , где собраны старые версии этого файла.

Например, в самой ранней версии 1983 года есть такие строки (синтаксис со временем менялся):

      HOST : 14.0.0.4 : UCL-VTEST ::::
HOST : 14.0.0.6 : UK-SATNET ::::
HOST : 14.0.0.7 : WISC-IBM : IBM-4341 : VM/CMS : TCP/TELNET,TCP/FTP,TCP/SMTP,ICMP :
HOST : 14.0.0.8 : RAND-TN : VAX-11/750 : UNIX : TCP/FTP,TCP/SMTP,TCP/TELNET :
HOST : 14.0.0.11 : CHALMERS-SUNET ::::

TTL

Если вы хотите, чтобы обновления в вашей зоне были практически мгновенными, вы можете уменьшить значение TTL настолько, насколько захотите.

Теоретически да, на практике нет. В противном случае у некоторых может возникнуть соблазн поставить 0 или 1 (секунду) и подумать, что это будет означать отсутствие кэша.

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

Трудно точно сказать, кто и что здесь делает, но я думаю, что разумным будет сказать, что менее чем «5 минут» для TTL могут не соблюдаться преобразователями. Поэтому не используйте ничего ниже 300.

Совет в: используйте опцию (подсказка в подсказке: добавьте опцию раз и навсегда в свойфайл, и вам никогда не придется вводить его снова) для более удобного вывода TTL.

Как в:

      $ dig serverfault.com A +noall +ans +nottlunits
serverfault.com.    291 IN A 151.101.1.69
serverfault.com.    291 IN A 151.101.193.69
serverfault.com.    291 IN A 151.101.129.69
serverfault.com.    291 IN A 151.101.65.69

против

      $ dig serverfault.com A +noall +ans +ttlunits
serverfault.com.    4m56s IN A 151.101.193.69
serverfault.com.    4m56s IN A 151.101.1.69
serverfault.com.    4m56s IN A 151.101.129.69
serverfault.com.    4m56s IN A 151.101.65.69

Обход TTL

Да, это легко, если вы тестируете вручную с помощью dig или подобных инструментов — просто укажите, к какому серверу обращаться.

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

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

Рекурсивный сервер имен, напротив, почти всегда работает с кешем и, следовательно, пытается сначала отвечать на запросы из кеша, чтобы выполнять меньше сетевых вызовов. Кэш управляется TTL записей (+ локальные политики). Таким образом, каждый раз, когда вы запрашиваете рекурсивный сервер имен, вы увидите ответы с разными (фактически уменьшающимися, вплоть до вытеснения кэша, а затем возвращением к исходному значению или близким к нему) TTL.

Пример:

  1. Сначала запросим его (один из них) авторитетный сервер имен:
      $ dig NS serverfault.com +short
ns-cloud-c2.googledomains.com.
ns-860.awsdns-43.net.
ns-1135.awsdns-13.org.
ns-cloud-c1.googledomains.com.

$ date; dig @ns-1135.awsdns-13.org. serverfault.com A +noall +ans
Fri Jul 29 18:06:39 EST 2022
serverfault.com.    5m IN A 151.101.65.69
serverfault.com.    5m IN A 151.101.1.69
serverfault.com.    5m IN A 151.101.129.69
serverfault.com.    5m IN A 151.101.193.69
$ date; dig @ns-1135.awsdns-13.org. serverfault.com A +noall +ans
Fri Jul 29 18:06:42 EST 2022
serverfault.com.    5m IN A 151.101.129.69
serverfault.com.    5m IN A 151.101.1.69
serverfault.com.    5m IN A 151.101.193.69
serverfault.com.    5m IN A 151.101.65.69
 date; dig @ns-1135.awsdns-13.org. serverfault.com A +noall +ans
Fri Jul 29 18:06:49 EST 2022
serverfault.com.    5m IN A 151.101.1.69
serverfault.com.    5m IN A 151.101.65.69
serverfault.com.    5m IN A 151.101.129.69
serverfault.com.    5m IN A 151.101.193.69

Кроме того, проницательные читатели заметят, что 1) я использовалнеявно (в файле конфигурации) и 2) порядок записей меняется, что является очень важным моментом, поскольку DNS работает с наборами , а не списками , поэтому фиксированного порядка не существует.

  1. Теперь делаем то же самое, но запрашиваем конкретный общедоступный преобразователь DNS:
      $ date; dig @8.8.8.8 serverfault.com A +noall +ans
Fri Jul 29 18:08:45 EST 2022
serverfault.com.    5m IN A 151.101.129.69
serverfault.com.    5m IN A 151.101.193.69
serverfault.com.    5m IN A 151.101.1.69
serverfault.com.    5m IN A 151.101.65.69
$ date; dig @8.8.8.8 serverfault.com A +noall +ans
Fri Jul 29 18:08:48 EST 2022
serverfault.com.    4m38s IN A 151.101.65.69
serverfault.com.    4m38s IN A 151.101.193.69
serverfault.com.    4m38s IN A 151.101.1.69
serverfault.com.    4m38s IN A 151.101.129.69
$ date; dig @8.8.8.8 serverfault.com A +noall +ans
Fri Jul 29 18:08:53 EST 2022
serverfault.com.    5m IN A 151.101.129.69
serverfault.com.    5m IN A 151.101.193.69
serverfault.com.    5m IN A 151.101.65.69
serverfault.com.    5m IN A 151.101.1.69
$ date; dig @8.8.8.8 serverfault.com A +noall +ans
Fri Jul 29 18:08:58 EST 2022
serverfault.com.    4m54s IN A 151.101.129.69
serverfault.com.    4m54s IN A 151.101.193.69
serverfault.com.    4m54s IN A 151.101.65.69
serverfault.com.    4m54s IN A 151.101.1.69

Внимательные читатели заметят, что действительно TTL больше не являются постоянными, но и не являются строго монотонно убывающими. Это можно объяснить тем фактом, что, используя большой общедоступный преобразователь, я могу каждый раз сталкиваться с разными его экземплярами, которые используют разные кеши, и, следовательно, состояние, сохраняемое и извлекаемое для получения моего ответа, может не совпадать.

Источник
Другие вопросы по тегам