Назад | Перейти на главную страницу

Кэшируется ли запись Glue рекурсивным преобразователем?

Кешируется ли рекурсивный преобразователь IP-адреса авторитетного сервера имен из записи Glue?
Сервер имен для домена верхнего уровня включает клей вместе с делегированием для доменного имени.
Теперь, кэширует ли рекурсивный преобразователь эту запись A / AAAA (связующую запись)? Я знаю, что кеширование применяется только в том случае, если ответ пришел от «авторитетного» сервера имен, но здесь сервер имен TLD дополнительно делегирует и не может считаться авторитетным.
Или
Предоставляет ли авторитетный сервер имен также свой собственный IP-адрес в виде записи A (вместе с записью A домена), и именно это кэширует рекурсивный преобразователь?

Обычно клейкие записи не даются как авторитетные ответы, что вы можете заметить, если посмотрите на флаги (наличие или отсутствие aa Авторитетный ответ; RFC 1035, 4.1.1) например из следующих запросов:

  • Авторитетный по отношению к родителю:

    dig com NS @f.gtld-servers.net
;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 27

  • Снятие контроля. Оба дают клей в дополнительный раздел. 

    dig google.com NS @f.gtld-servers.net
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 9

dig ns1.google.com A @f.gtld-servers.net
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 9

  • Авторитетные ответы авторитетного сервера:

    dig google.com NS @ns1.google.com
;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 9

dig ns1.google.com A @ns1.google.com
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

Базовый алгоритм от RFC 1034, 5.3.3 кэширует большую часть данных ответа; только неудачи и другое странное содержание (d) игнорируются (выделено мной):

  • а. если ответ отвечает на вопрос или содержит ошибку имени, кешируйте данные а также вернуть его клиенту.

  • б. если ответ содержит лучшее делегирование другим серверам, кэшировать информацию о делегированиии перейдите к шагу 2.

  • c. если ответ показывает CNAME, и это не сам ответ, кешировать CNAME, измените SNAME на каноническое имя в CNAME RR и перейдите к шагу 1.

  • d. если ответ показывает сбой серверов или другое странное содержимое, удалите сервер из SLIST и вернитесь к шагу 3.

В RFC также упоминается, что в некоторых реализациях может быть возможность заставить преобразователь игнорировать кэшированные данные и обращаться к авторитетному серверу. Что происходит на самом деле, зависит от реализации. В соответствии с Как DNS убивает Интернет от Kudelski Security Research:

Помимо ошибок, которые могут привести к непреднамеренным ложным срабатываниям, кеш-отравление (см. Уязвимость DNS Дэна Камински 2008 г. и Автостопом по отравлению кеша DNS) необходимо принять во внимание. Многие реализации кэша DNS кэшируют связующие записи как обычные записи, поэтому DNS-сервер может предоставить злонамеренный ответ и, как следствие, иметь неправильную запись в кеше.

Например:

evil.com.       IN NS ns.company.com.
ns.company.com. IN A 6.6.6.6

В то время как законный сервер говорит

company.com.    IN NS ns.company.com.
ns.company.com. IN A 1.2.3.4

Таким образом, неправильный IP-адрес останется в кеше на время существования записи. Чтобы избежать этой проблемы, большинство реализаций кэширующего преобразователя не доверяют и игнорируют необязательные связующие записи для NS-записей вне bailiwick и, таким образом, игнорируют ns.company.com. IN A 6.6.6.6 в примере выше. Примечание для администратора DNS: рекомендуется иметь только внутренние записи.

Независимо от того, является ли ответ авторитетным или нет, само по себе не является индикатором того, следует ли кэшировать записи или нет:

  • Серверы имен верхнего уровня являются частью той же структуры авторитетных серверов имен. Следовательно, поскольку они делегируют управление своими поддоменами, то есть в конечном итоге могут контролировать, кто может авторитетно отвечать, им следует доверять и они заслуживают доверия. Обычно связующие записи должны соответствовать записям в самой зоне, а все остальное будет ошибкой конфигурации в соответствии с IANA. Технические требования к авторитетным серверам имен:

    Согласованность между клейкими и авторитетными данными

    Для серверов имен, IP-адреса которых указаны в качестве связующего, IP-адреса должны соответствовать официальным записям A и AAAA для этого хоста.

    Согласованность между делегированием и зоной

    Набор NS-записей, обслуживаемых официальными серверами имен, должен совпадать с предложенным для делегирования в родительской зоне.

  • Не каждый рекурсивный сервер начинает разрешать имя с корневых серверов имен, но есть и более сложные рекурсивные инфраструктуры. Резолвер может иметь экспедиторы, другие рекурсивные серверы имен, которые они запрашивают вместо авторитетных серверов имен. Эти ответы никогда не являются авторитетными, но всегда кэшируются.

  • В сценариях отравления кеша DNS злоумышленником является не какой-либо из авторитетных серверов имен, а ложный ответ, полученный из надежного источника, будь то авторитетный сервер имен или сервер пересылки. Поскольку DNS использует UDP, подделать ответы проще. Против этого есть несколько решений:

    • Максимальный размер ответа UDP. Если ответ больше, чем один пакет UDP, DNS использует TCP. Имея дополнительный раздел, ответ, содержащий связующие записи, легко выходит за эту границу. TCP-соединения не так легко подделать, поскольку для этого потребуется позиция MitM.

    • Проверка DNSSEC. Поддельный ответ не может иметь совпадающих подписей DNSSEC для своих записей, поэтому они не будут кэшироваться.

    • Зашифрованный DNS. Есть два стандарта: DNS over TLS (RFC 7858) и DNS через HTTPS (RFC 8484).