Постановка задачи
Любой сервер имен в Интернете может стать «авторитетным» для законных и нелегитимных зон.
Например, я могу добавить microsoft.com на свой внутренний сервер имен. Пока я добавляю необходимые записи для www, msdn, technet.microsoft.com, все будет работать нормально. Однако я не являюсь законным владельцем microsoft.com (согласно .com DNS-серверы)
DNS имеет функцию, в которой он также будет включать Additional записи в ответ на эти поддельные NS легального сервера имен.
Когда это происходит, клиент DNS должен быть достаточно умен, чтобы отбросить дополнительную запись и пройти по иерархии DNS от корня до нужного места. В этом случае DNS-клиент (рекурсивный преобразователь) будет смотреть на:
Дополнительная информация
Я опрашивал множество DNS-серверов и заметил большое несоответствие в том, как Additional используется раздел записей.
Некоторые DNS-серверы включают информацию A Record (в дополнительном разделе) для серверов, для которых они не являются полномочными.
Example:
Question: CNAME (or ALL) for host.example.com.
Answer: host.otherguy.com (then in the additional -> A record for host.otherguy.com is 8.8.8.7)
Я бы подумал, что это будет попытка отравления кеша DNS, если запись A кешируется, а NS для "otherguy.com". говорит, что IP-адрес 7.7.7.7.
Есть ли краткий набор правил, описывающих 99% процентов респондентов, и чего ожидать?
И наоборот, существуют ли правила, определяющие, когда запросы DNS недействительны?
Пример ответа
Я думаю, что я ищу такой ответ:
Если DNS-сервер обнаруживает полное доменное имя, которое не совпадает с текущим местоположением обхода, он должен отбросить все дополнительные записи, отправленные в запросе, и пройти иерархию DNS от корня.
Проблема, о которой вы говорите, хорошо известна и представляет собой тип отравления. Примеры (1) «Алгоритм разрешения RFC 1034 позволяет любому серверу в Интернете уничтожить или захватить yahoo.com». - http://cr.yp.to/djbdns/notes.html (2) http://en.wikipedia.org/wiki/DNS_spoofing#Redirect_the_NS_record_to_another_target_domain
В основном, решение, используемое сегодня, таково: наборы RR в дополнительной информации игнорируются.
Неофициальное свидетельство: «Несмотря на то, что ссылка включает записи A для« ns1.example.net »и« ns2.example.net »в дополнительном разделе сообщения DNS, современные итеративные преобразователи игнорируют эти записи в качестве защиты от заражения кеша». - http://verisigninc.com/en_US/products-and-services/domain-name-services/domain-information-center/frequent-asked-questions/dns-behavior-changes/index.xhtml
«Уточнение» (то есть исправление) к RFC1034 находится в разделе 5.4.1 RFC 2181:
Unauthenticated RRs received and cached from the least trustworthy of
those groupings, that is data from the additional data section, and
data from the authority section of a non-authoritative answer, should
not be cached in such a way that they would ever be returned as
answers to a received query. They may be returned as additional
information where appropriate. Ignoring this would allow the
trustworthiness of relatively untrustworthy data to be increased
without cause or excuse.