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

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

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

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

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

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

На самом деле все гораздо сложнее - вместо одного «центрального реестра (который) содержит таблицу, которая отображает домены (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.ukare, и они, как оказалось, также включают nsa.nic.uk. Итак, теперь нам нужно знать IP-адрес nsa.nic.uk, но чтобы выяснить это, нам нужно сделать запрос nsa.nic.uk, но мы не можем сделать этот запрос, пока не узнаем IP-адрес для nsa.nic.uk...

Чтобы разрешить эту проблему, серверы для .ukдобавления записи A 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 для .ukTTL имеют 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, чтобы минимизировать количество необходимых запросов. Это предотвращает, например, спам в сети с запросами на адрес «serverfault.com» каждый раз, когда вы получаете страницу от SF. Эти серверы могут даже кэшировать результаты «домен не существует», поэтому может потребоваться некоторое время, чтобы появился даже новый домен.

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