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

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

c) Если единственной причиной задержки являются кеши 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 flag, поэтому мы можем видеть, что этот результат был получен из кеша, а не напрямую из авторитетного источника. Фактически, мы видим, что это произошло из 97.107.133.4, который является одним из локальных преобразователей DNS Linode. Тот факт, что ответ был доставлен из кеша, очень близкого ко мне, означает, что мне потребовалось 0 мсек, чтобы получить ответ; но, как мы скоро увидим, цена, которую я плачу за такую ​​скорость, состоит в том, что ответ почти на 5 минут устарел.

Чтобы обойти распознаватель Linode и перейти прямо к источнику, просто выберите один из этих 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 (время жизни) записи.

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

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

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

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

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