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

Какой RFC побуждает DNS-серверы отвечать ОТКАЗАНО на запросы о неизвестных доменах?

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

Похоже, что это стандартная практика, когда полномочный DNS-сервер отвечает rcode. REFUSED на любой запрос доменного имени, для которого сервер не является авторитетным. Например:

$ dig @ns1.google.com yahoo.com A | grep status
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 53533

Есть несколько альтернативных вариантов поведения, которые априори могут иметь здесь смысл:

Есть ли RFC или аналогичный документ, в котором говорится: «Вы должны вернуть REFUSED в таком случае"?

Я ожидал увидеть обсуждение этой ситуации в RFC 1034, разделы 4.3.1 и 4.3.2, но я этого не делаю.

Я не верю, что в документах стандартов (по крайней мере, в исходных RFC DNS) есть четкое заявление о том, как действовать в этом конкретном сценарии.
Тем не менее, с годами консенсус более или менее стал таким: REFUSED - лучший вариант из имеющихся у нас инструментов.

Я изложу некоторые мысли о некоторых вариантах ниже:

Варианты, указанные в вопросе

Полностью закройте запрос

Это плохо для оператора авторитетного сервера, так как при таком подходе сервер будет казаться неработающим, что открывает возможности для сценариев, когда рекурсивные серверы постоянно наблюдают, что он не отвечает на их запросы, и полностью отказываются от него, независимо от QNAME.

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

(Я бы счел это худшим вариантом.)

Вернуть неавторизованный NXDOMAIN ответ

Это не соответствует тому, как NXDOMAIN иначе используется. NXDOMAIN используется, чтобы указать, что вы знаете, что имени не существуетне то ты ничего не знаешь об имени.

Вернуть неавторизованный NOERROR ответ (это глупо, но я упоминаю его для полноты)

Прежде всего отмечу, что альтернатива «обращение к корню» является частным случаем этой.

Аргумент против NXDOMAIN относится к NODATA (NOERROR + SOA в разделе полномочий), а также с незначительной корректировкой; это статус, который используется, чтобы указать, что вы знаете что такого RRset нетне то тебе не хватает знаний.
Дополнительно, NODATA предполагает, что вы знаете, что это имя существует в некоторой форме или форме (например, оно может содержать записи других типов или может быть пустым нетерминальным).

NOERROR указывает, что запрос был признан действительным и заслуживающим ответа, поэтому должна быть какая-то форма ответа. Если это вопрос, на который невозможно ответить, NOERROR похоже, плохо подходит.

Вернуть шаблонный реферал корневым серверам имен (это еще глупее)

В прошлом это был очень распространенный способ решения этой проблемы. Содержание ответа само по себе бесполезно, но это правильно сформированный реферальный ответ, который, по крайней мере, дает понять, что запрашиваемый сервер не знает об этом имени.

(Я думаю, что это наименее глупая форма NOERROR использовать в этом контексте.)

Другие варианты

Положение дел REFUSED

REFUSED обычно считается лучшим подходом, означает, что сервер настроен не отвечать на этот запрос. В целом хорошо подходит, независимо от того, явно ли указано, что его следует использовать в данном конкретном случае.

Положение дел SERVFAIL

Также используется некоторыми реализациями серверов.
Менее ясно, чем REFUSED в том, что это явно не указывает на то, что отказ от ответа является преднамеренным; SERVFAIL обычно используется для неожиданных ошибок, возникающих при обработке допустимых запросов.

Это действительно просто, RFC1035 Раздел 4.1.1 RCODE 5 

Refused - The name server refuses to perform the specified operation 
for policy reasons.  For example, a name server may not wish to
provide the information to the particular requester, or a name server 
may not wish to perform a particular operation (e.g., zone transfer) 
for particular data.

Администраторы системы решили сконфигурировать свою систему так, чтобы она возвращала ОТКАЗАННЫЙ ответ, а не что-то еще.

Вот частичный ответ, начиная с это сообщение в блоге DynDNS Я нашел.

С точки зрения сервера имен, его просят ответить на вопрос, выходящий за рамки его настроенной способности ответа (DNS каламбур!). У него нет файла зоны для этого доменного имени, и поэтому ему нечего ответить. Следующий RFC 1035, соответствующий сервер имен должен выдать ответ RCODE 5 (ОТКАЗАНО). Это отказ, потому что «сервер имен отказывается выполнять указанную операцию по политическим причинам».

В принципе, должно быть действительно странно, что сервер имен получает запрос на имя, для которого он не является авторитетным. В конце концов, сам акт делегирования сервера имен от родителя включает в себя утверждение (авторитетно), что серверы имен, названные записями NS, являются правильными серверами имен. Итак, исторически многие серверы имён отвечали ссылкой на корень.

Сегодня похоже, что этот ответ широко презирается операторами DNS (отчасти потому, что он может использоваться в атаках с усилением), и многие серверы имен в наши дни возвращают ошибку. Ошибка часто имеет вид RCODE 5 (ОТКАЗАНО) на том основании, что сервер имен отказывается выполнять указанную операцию по политическим причинам. Иногда вы увидите RCODE 2 (SERVFAIL), по той же причине, по которой вы видите, что когда зона находится в процессе загрузки сервером имен: сервер еще не может ответить на запрос и не знает, сможет ли он когда-либо это сделать.

Поиск в Google по запросу "обращение к корню" обнаружил публикацию DNS-OARC под названием «Перенаправления снизу вверх считаются вредными»:

Недавно хостинговая компания ISPrime стала жертвой DDoS-атаки на базе DNS с использованием поддельных адресов источника. Некоторые называют это атакой с усилением, потому что запрос ". IN NS" довольно мал (47 октетов), в то время как ответ восходящей ссылки немного больше (256 октетов). ... Атака возвращает на свет старые дебаты: Каков соответствующий ответ авторитетного сервера имен на запрос, на который невозможно ответить? Конфигурация и / или реализация некоторых авторитетных серверов имен заставляет их возвращать восходящую ссылку в корневую зону. Мы не рекомендуем такое поведение по ряду причин:

  • Направления вверх обычно бесполезны. Решатель, который просматривает пространство, уже знает, с чего начать.
  • Надлежащий итеративный преобразователь должен учитывать восходящую ссылку «вне залога» и в любом случае игнорировать данные.
  • «Подсказки» корневой зоны авторитетного сервера имен могут со временем устареть, если не будут поддерживаться должным образом, что приведет к доставке запросов на списанные адреса корневых серверов.
  • Известно, что восходящие ссылки вызывают «циклы переадресации», которые приводят к сотням бесполезных запросов.

Мы считаем, что код ответа ОТКАЗАН лучше, чем направление вверх. ...

Также в RFC 7719 (опубликовано в декабре 2015 г.) мы находим:

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

Итак, «обращение к корню» - явно ужасная идея, но, честно говоря, это уже была моя «глупейшая» альтернатива. Я еще не понял, что может быть не так с неавторитетным NXDOMAIN или подобным. Я могу обновить этот ответ позже.