Служба DNS, невидимая обычному пользователю, периодически оказывается в фокусе интереса IT-специалистов. По разным поводам. Особенно актуальной эта тема становится в периоды, когда основные провайдеры DNS подвергаются DDoS-атакам. Именно тогда, когда DNS становится частично неработоспособной, приходит понимание, что DNS – это основа, костяк всей структуры интернета.

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

  • Реестры доменов
  • Глобальные домены верхнего уровня (gTLD)
  • Различные национальные домены верхнего уровня (ccTLD)
  • И растущий с каждым годом список всех прочих доменов высшего уровня (.space, .photography и так далее)

Все это делает и так не простую систему еще более сложной.

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

  • Root (.)
  • Серверы глобальных доменов
  • Авторитетные серверы имён доменов

Каждый уровень в этой иерархии играет важную роль в процессе определения нужного IP-адреса.

  • Реестры (например, Verisign, поддерживающая .com и .net)
  • Регистраторы (например, GoDaddy и NameCheap)
  • Все те, кто регистрирует доменные имена для своих сайтов
  • Интернет-провайдеры
  • DNS-провайдеры

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

Рассмотрим ниже важный аспект системы DNS — «добавочные записи» или «glue records».

Glue record или добавочные записи


Glue record, или добавочная запись — это А-запись, в которой хранится IP-адрес, присвоенный домену или поддомену. Эти записи становятся крайне важными, когда сервер имён домена находится на поддомене этого же домена.

Glue record может быть найдена в разделе «дополнительные записи» (Additional records) DNS-ответа.

Давайте посмотрим на примере, как работают эти дополнительные записи. Предположим, у вас есть домен yourdomain.com, серверы имён которого имеют адреса:
ns1.yourdomain.com
ns2.yourdomain.com

И тут возникает коллизия, чтобы определить адрес yourdomain.com, надо получить его у ns1.yourdomain.com, адрес которого надо получить у него же самого. Получается бесконечный цикл.

Чтобы его разорвать, как раз и нужны Glue record, которые прямо сообщают IP-адрес серверов имён в процессе обработки запроса на получение адреса для yourdomain.com.



В этом примере мы видим, как добавочные записи устраняют круговую зависимость, выдавая А-записи с IP-адресами для ns1.ctrls.in и ns1.ctrls.in серверов имён домена ctrls.in.

Для доменов, которые не используют свои же субдомены для адресов серверов имён, добавочные записи тоже полезны, они сокращают число шагов при определении адреса – вот, к примеру, как это устроено для Wikipedia.org



В этом примере Wikipedia.org возвращает ns1.wikimedia.org, ns2.wikimedia.org и ns3.wikimedia.org как имена серверов имён для своего домена. Дополнительные записи сразу же сообщают их IP-адреса, опуская этап поиска адреса для домена Wikimedia.org.

У одной крупной китайской CDN записи А возвращали некорректные IP-адреса для ее серверов имён.

Проверка DNS Expierence показала, что опрашиваемые в ходе теста различные авторитетные сервера имён возвращают правильный адрес IP. А вот проверка Direct DNS, когда опрашивается сервер имён уровня глобального домена, возвращал неправильный адрес IP.

Те же результаты дало исследование ситуации с помощью dig – dig «имя сервера» корневой_сервер — глобальный сервер имён давал неверные адреса.

Ошибка оказалась в том, что в какой-то момент регистратор доменных имен не передал выше по иерархии изменения в Glue record.

Представители CDN связались с регистратором доменного имени, и тот обновил Glue record для домена. Затем обновленная запись была транслирована на все gTLD сервера и проблема таким образом была решена.

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

Проверить корректность корневые (glue) записей DNS можно при помощи, например, Pingdom: в процессе проверки будут получены IP адресы NS-серверов домена и сравнены их записи в корневых DNS-серверами с теми, которые указаны непосредственно в DNS-записях зоны.
Поделиться с друзьями
-->

Комментарии (5)


  1. ast-pm-105
    08.05.2017 15:18

    Wikipedia.org возвращает ns1.wikimedia.org, ns2.wikimedia.org и ns3.wikimedia.org как имена неймсерверов для своего домена. Дополнительные записи сразу же сообщают их IP-адреса


    Что-то мне подсказывает, что так делать не совсем корректно.

    Допустим что в данном примере администрированием доменов Wikipedia.org и wikimedia.org занимаются одни и те же люди и они помнят о том, что когда происходит изменение А записи ns1.wikimedia.org, то надо отобразить эти изменения еще и в NS записях зоны Wikipedia.org.

    Но если домен в котором распологаются имена NS серверов «не твой», то в таких случаях не надо делать glue записи. Потому что:
    1) ускорение работы DNS запроса может быть улучшится на 0.00001% (зато наступают пункты 2 и 3).
    2) если поменяется A запись NS сервера не в твоей зоне — никто тебя не предупредит (потому что и не должен), и будут танцы с бубном плюс долгие поиски неисправности.
    3) в свете всяких там «Kaminsky DNS Vulnerability» DNS кеши/рекурсоры нещадно трут из DNS ответов все что не относится к запрашиваемому доменному имени (зачем мне ответ о A записях относящихся к wikimedia, если спрашивали о Wikipedia?!).


    1. monester
      08.05.2017 16:19

      Задача glue records избежать ситуаций когда NS находится внутри домена. Например что бы узнать адрес ns1.yandex.ru нужно знать адрес сервера ns1.yandex.ru. Glue records как раз возвращают при запросе NS сервера не только их имена, но и IP адреса.


  1. nikitasius
    08.05.2017 22:19

    Как бы и… логично. Для этого в панели регистратора указываются ns сервера и их айпи.
    Например тот же яндекс:


    domain: YANDEX.RU
    nserver: ns1.yandex.ru. 213.180.193.1, 2a02:6b8::1
    nserver: ns2.yandex.ru. 93.158.134.1, 2a02:6b8:0:1::1

    Которые затем дублируются в ns:


    ~$ dig ns1.yandex.ru ns2.yandex.ru A +short
    213.180.193.1
    ~$ dig ns1.yandex.ru ns2.yandex.ru AAAA +short
    2a02:6b8::1


  1. kirillaristov
    09.05.2017 00:27
    +1

    В этом примере Wikipedia.org возвращает ns1.wikimedia.org, ns2.wikimedia.org и ns3.wikimedia.org как имена неймсерверов для своего домена.

    Не будет ли более корректным:
    Корневой DNS-сервер зоны .org при запросе wikipedia.org возвращает инфо о серверах имён для этого домена ns1.wikimedia.org, ns2.wikimedia.org, ns3.wikimedia.org. Дополнительные записи сразу же сообщают их IP-адреса.


  1. freejoins
    09.05.2017 09:55

    Эта система позволяет провести проверки более полно Zonemaster, проверяются не только Glue Record, но и многие другие параметры, плюс даются рекомендации по оптимизации параметров.