Техническое: один практический пример ошибочных настроек DNS
Немного занятной и техничной практики DNS. Если взять зону kommersant.ru, то нетрудно выяснить, что с этой зоной что-то сильно не так. Вот “покрасневший” скриншот из отчёта открытого сервиса audit.statdom.ru:
Почему тут указаны только “адреса”, которые отмечены как недоступные? Во-первых, это не адреса, а имена хостов (хостнеймы), которые выглядят похожими на IP-адреса, но намётанный глаз сразу обнаружит подвох: всё выдаёт крайняя справа точка, отделяющая корневой домен; это так называемый FQDN – Fully Qualified Domain Name (“полное имя домена”). Во-вторых, серверы имён, обозначенные таким образом, доступны быть не могут, поскольку в глобальной DNS нет имени первого уровня “20.” (две цифры – 2 и 0).
Между тем, если попробовать зайти на соответствующий апексу зоны веб-сайт kommersant.ru браузером, то, скорее всего, сайт откроется. Получается, что всё работает? Нет, далеко не всё. Но это лишь очередное подтверждение того, что DNS, как сервис и совокупность технологий, в сочетании с вебом, обладает очень высокой степенью устойчивости к ошибкам настройки (кроме, конечно, DNSSEC).
Посмотрим, как же настроена зона kommersant.ru на момент написания данной записки. В домене верхнего уровня RU зона делегрована на два сервера имён (NS) с именами ns.kommersant.ru. и ns5.kommersant.ru., что, скажем, подтверждается следующим фрагментом скриншота того же отчёта:
Поскольку это так называемые “субординатные” имена NS, – то есть, находящиеся в той же зоне, которая делегируется, – серверы зоны RU возвращают соответствующие glue-записи (в отчёте они не показаны). Glue-записи содержат IP-адреса для имён делегирования (ns.kommersant.ru. и ns5.kommersant.ru.). В DNS, glue-записи необходимы для того, чтобы исключить возможность бесконечной рекурсии. Представьте, что зона test.ru делегирована на ns.test.ru. Как же определить IP-адрес ns.test.ru? Ведь для его определения нужно знать адреса NS-ов зоны test.ru, а чтобы их знать, нужно опросить зону test.ru. Как найти адреса? Верный ответ – никак не найти, если бы только не было glue-записей, которые-то и приносят нужные адреса сразу.
Почему здесь вообще возникает такая проблема с аресами/именами? Потому, что в качестве значения DNS-записи NS могут быть указаны только имена хостов. Но соединение и обмен данными в глобальном Интернете происходят по IP. То есть, для отправки запросов и получения ответов нужны именно IP-адреса. Можно ли всё же указать IP-адреса в NS-записях? Нет, нельзя. Причина в том, что значения записей в DNS не могут подразумевать какой бы то ни было протокол обмена данными. Это очень важный и логичный момент: DNS превратилась бы в непонятную путаницу, если бы какие-то дополнительные сведения об установлении соединения “подразумевались” бы: в той же NS-записи – получаем то адрес, то хостнейм, то “какие-то минусы”, то “здесь админы рыбу заворачивали”. Заметьте, сюда ещё накладывается и тот занимательный факт, что вообще невозможно вне контекста отличить запись IPv4-адреса от хостнейма. В практике DNS есть много случаев, когда тот или иной протокол доступа, да ещё и с параметрами, прямо указывается, но корректно это делается только при помощи префиксов в самом имени, например: _443._tcp.name.test.ru. (обратите внимание: предыдущая DNS-строка – не хостнейм!).
Итак, NS-запись должна содержать имя хоста, соответствующее серверу имён. Для разрешения возможных циклов – предусмотрены glue-записи.
Однако доверенным источником полного списка серверов имён для зоны является не делегирующий сервер, не glue-записи, а ответ авторитативного сервера зоны на запрос NS. По этой причине сервис тестирования DNS-узлов получает список этих узлов с авторитативного сервера. Ну, или пытается получить. Серверы, указанные для kommersant.ru в списке делегирования, на запрос NS возвращают те самые “подложные” хостнеймы, сформированные из IP-адресов четвёртой версии. То есть, так указано в файле зоны. Указано неверно. Распространённая ошибка. Видимо, ничего не поделать. Отличить тут адрес от хостнейма программное обеспечение не может, поэтому DNS-сервер будет отвечать тем, что ему написано. А написаны, как уже указано выше, заведомо “неразрешимые” имена (нет, это не IP-адреса; IP-адреса нельзя указывать в NS-записях, поэтому резолвер никак и не может понять, что это, якобы, “IP-адреса”, потому что это хостнеймы).
Почему же работает веб-сайт? Вот почему. Для большинства сценариев доступа к вебу нужен IP-адрес, который передаётся в A-записи DNS. По IP-адресам из glue-записей для обсуждающейся зоны kommersant.ru отвечают серверы имён, которые возвращают A-записи, содержащие корректный и доступный IP-адрес, который указывает на веб-узел. И тут многое зависит от рекурсивного резолвера. Если этот резолвер использует непосредственно адреса из glue-записей для того, чтобы запросить A-записи, то всё сработает. Но glue-записи небезопасно кэшировать – кэшировать следовало бы хотя бы минимально проверенные значения NS, которые требуется достать с авторитативных серверов. Если резолвер попробует получить список NS корректным способом, то он обнаружит дефектные записи, после чего попробует отправить ещё несколько запросов и, скорее всего, всё же найдёт A-запись, чтобы вернуть её клиенту. То есть, резолвер, обычно, настроен так, чтобы хоть что-то достать из DNS (не всегда это правильный выбор, поскольку регулярно служит фундаментом для целевых атак). Так что, спрашивая и переспрашивая, игнорируя и как-то исправляя ошибки в зоне, но резолвер, в большинстве случаев, сможет найти IP-адрес, чтобы потом по этому адресу попробовал подключиться браузер, если только способ достать данный IP-адрес существует. Что же касается других функций DNS – ну, они в данной зоне просто недоступны (тем более, что упомянутые серверы имён не поддерживают современный EDNS-доступ вообще).
Вот. У подобной некорректной настройки DNS есть ещё много неприятных побочных эффектов, связанных с надёжностью и безопасностью. А ведь существует ещё и QNAME Minimization.
(Недавно я описывал другую занятную ошибку настройки DNS, из “дикой природы”, наблюдающуюся в куда более популярной зоне vk.com. Представьте, кстати, куда все эти интернеты прикатятся, если DNSSEC, – несравнимо более требовательная к уровню аккуратности технология, – вдруг получит максимальное распространение.)
Адрес записки: https://dxdt.ru/2024/11/28/14282/
Похожие записки:
- Постквантовая криптография и рост трафика в TLS
- Техническое: связь SCT-меток с логами Certificate Transparency
- Неравенство треугольника в Интернете и anycast
- Новые атаки на SHA-256 (SHA-2): технические пояснения
- Нормализация символов Unicode и доменные имена
- Возможное обновление алгоритмов DNSSEC в корне DNS
- Симметрии и дискретное логарифмирование
- "Пасхалка" в экспериментальном сервере TLS
- Неверная интерпретация систем ИИ как "инструмента для анализа"
- Журнал "Интернет изнутри"
- DNS и TCP
Написать комментарий