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

Kulula ngenene, RFC1035 Icandelo 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.

Abalawuli benkqubo bagqibe kwelokuba baqwalasele inkqubo yabo ukuba ibuyise impendulo EYEKILEYO kunokwenza nantoni na eyenye.

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

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

Параметры, описанные в вопросе

Запретить запрос полностью

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

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

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

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

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

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

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

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

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

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

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

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

Другие параметры

Статус ОТКАЗАНО

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

Статус SERVFAIL

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

Вот частичный ответ, начиная с этого сообщения в блоге 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 или подобным. Я могу обновить этот ответ позже.