Имена в NS-записях вместо адресов - неприятная особенность DNS

#dns

Чтобы разобраться в работе DNS, я попытался написать простой resolver без кэша, который
бы мог выполнять рекурсивные запросы, начиная с корневых серверов. Возникла проблема:
если сервер не располагает запрашиваемыми данными, то он возвращает нам в Authority-секции
NS-записи с именами тех серверов, которые "ближе к ответу", но он не обязан возвращать
A-записи в Additional-секции, соотв. NS-записям в Authority-секции. Он просто может
не знать адреса этих серверов - не обязан. Они могут быть не в его зоне. Исключение
- glue-записи.

Таким образом, что получается: имеем имя, адрес которого мы должны получить. Обращаемся
к одному из корневых серверов (его адрес мы берём из конфига). Он нам возвращает имена
серверов, которые "ближе к ответу" (вероятно, это те, зона которых включает Top-Level-
Domain). А вот адресов их он нам не сообщает. Пусть и сообщит, но на следующей итерации
- один из этих серверов сообщит нам имя сервера "ближе к ответу", но не его адрес.
Т.о. у нас на руках будет уже 2 имени, адреса которых нужно получить, причём адрес
первого мы не получим не зная адреса второго. Будем пытаться получить адрес 2-ого,
получим ещё одно имя. Рекурсия, чёрт! Как бы всё было проще, если бы в NS-записях был
адрес, а не имя. Но нет, в теории по любому имени с помощью системы DNS мы можем получить
сооотв. адрес, но на практике это усложняет процесс.

Вопрос: почему в NS-записях содержится имя, а не адрес? Разве так часто меняются
адреса DNS-серверов, что сложно обновлять файл зоны? Удобство здесь маленький плюс,
по сравнению с усложнением всей схемы.
Почему эта рекурсия (которую описал) вообще конечна?

P.S: знаю, что поэкспериментировав, выполняя вручную последовательные запросы, м.б.
я бы разобрался в чём тут дело, но руки не доходят. Может кому ещё будет полезно мой
комментарий/замечание по системе DNS.
    

Ответы

Ответ 1

почему в NS-записях содержится имя, а не адрес?


потому что именно так изложено в rfc1035.

это даёт определённую гибкость и обратную совместимость: например, даже в рамках
той же arpanet не так давно была добавлена совершенно иная схема адресов, и у a resource
record появилось «дополнение» в виде aaaa resource record. а ведь (в принципе) на arpanet
свет клином не сошёлся, и добавление новых схем адресации легко впишется в текущую
реализацию протокола.

дополнение про масштабируемость

одно и то же имя может «обслуживаться» произвольным количеством физических устройств:

$ dig -t a ya.ru
;ya.ru.             IN  A
ya.ru.          5833    IN  A   93.158.134.3
ya.ru.          5833    IN  A   213.180.193.3
ya.ru.          5833    IN  A   213.180.204.3


дополнение про расширяемость

одно и то же имя может «обслуживаться» физическими устройствами, доступными из разных
сетей:

$ dig -t aaaa ya.ru
;ya.ru.             IN  AAAA
ya.ru.          22  IN  AAAA    2a02:6b8::3


дополнение про совместимость

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

$ dig -t xyz ya.ru
...