RFC, требующий, чтобы DNS-серверы отвечали на запросы неизвестного домена

Мой регистратор доменов и DNS предоставляют в настоящее время игнорирует запросы DNS к неизвестным доменам. Под игнорированием я подразумеваю черные дыры и никогда не отвечаю, что заставляет мои DNS-клиенты и библиотеки распознавателя повторять, отключаться и, наконец, время ожидания.

dig @NS3.DNSOWL.COM somedomainthatdoesntexist.org
...
;; connection timed out; no servers could be reached

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

dig @DNS1.NAME-SERVICES.COM somedomainthatdoesntexist.org
dig @NS-284.AWSDNS-35.COM somedomainthatdoesntexist.org
dig @NS21.DOMAINCONTROL.COM somedomainthatdoesntexist.org

Все возвращают что-то вроде следующего:

;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 64732

или

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 31219

Возврат REFUSEDили NXDOMAINнемедленно подходит ИМХО, а не просто сбросить запрос на этаже серверной комнаты.

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

Вопросы :

• Я предполагаю, что если нет дублирующих идентификаторов запросов или какого-либо ответа DOS, сервер всегда должен отвечать на запрос. Это верно?
• Какой RFC и конкретный раздел я должен процитировать, чтобы поддержать мои условия?

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

В RFC 1536 и 2308 я вижу много информации об отрицательном кэшировании по соображениям производительности и прекращения повторной передачи того же запроса. В 4074 году я вижу информацию о возврате пустого ответа с RCODE 0, так что клиент знает, что нет информации ipv6, которая должна побуждать клиента спрашивать об A RR, что является еще одним примером пустого ответа.

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

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

Спасибо за помощь.

Редактировать:

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

Совет Шейна верен. Неспособность перенести данные с одного уполномоченного сервера на другой до начала переключения является приглашением к отключению. Независимо от того, что происходит с этого момента, это сбой, инициированный человеком, который качал записи NS. Это объясняет, почему больше людей не подают эту жалобу вашему поставщику.

Тем не менее, это все еще интересный вопрос, чтобы ответить, поэтому я собираюсь взять мою трещину в этом.

Основные функции DNS-серверов описаны в документах RFC 1034 и RFC 1035 , которые в совокупности образуют STD 13 . Ответ должен исходить от этих двух RFC или уточняться в более позднем RFC, который обновляет его.

Прежде чем мы продолжим, здесь есть огромная ловушка, выходящая за рамки DNS, которую необходимо вызвать: оба этих RFC предшествуют BCP 14 (1997), документу, в котором разъясняется язык MAY, MUST, SHOULD и т. Д.

• Стандарты, которые были созданы до того, как этот язык был формализован, МОГУТ использовать четкие формулировки, но в некоторых случаях этого не сделали. Это привело к различным реализациям программного обеспечения, массовой путанице и т. Д.
• STD 13, к сожалению, виновен в толковании в нескольких областях. Если язык не является устойчивым в области деятельности, часто необходимо найти уточняющий RFC.

После этого давайте начнем с того, что RFC 1034 §4.3.1 должен сказать:

• Самый простой режим для сервера нерекурсивный, поскольку он может отвечать на запросы, используя только локальную информацию: ответ содержит ошибку, ответ или ссылку на какой-либо другой сервер, «ближе» к ответу. Все серверы имен должны реализовывать нерекурсивные запросы.

...

Если рекурсивное обслуживание не запрашивается или недоступно, нерекурсивный ответ будет одним из следующих:

• Ошибка достоверного имени, указывающая на то, что имя не существует.

• Временная индикация ошибки.

• Некоторая комбинация:

  RR, которые отвечают на вопрос, вместе с указанием, поступают ли данные из зоны или кэшируются.

  Направление на серверы имен, у которых есть зоны, которые являются более близкими к имени предками, чем сервер, отправляющий ответ.

• RR, которые, по мнению сервера имен, окажутся полезными для запрашивающей стороны.

Язык здесь достаточно твердый. Нет «должно быть», но есть «будет». Это означает, что конечный результат должен быть: 1) определен в приведенном выше списке или 2) разрешен в более позднем документе на дорожке стандартов, который улучшает функциональность. Я не знаю ни о каком таком словесном выражении, которое могло бы игнорировать запрос, и я бы сказал, что ответственность за поиск языка, опровергающего исследование, лежит на разработчику.

Учитывая частую роль DNS в сценариях злоупотребления сетью, не стоит говорить, что программное обеспечение DNS-сервера не предоставляет ручки для выборочного отбрасывания трафика на полу, что технически является нарушением этого. Тем не менее, это либо поведение по умолчанию, либо с очень консервативными значениями по умолчанию; примерами обоих могут быть пользователь, требующий от программного обеспечения отбросить определенное имя ( rpz-drop.) или превышение определенных числовых порогов (BIND max-clients-per-query). По моему опыту, это почти неслыханно для программного обеспечения, чтобы полностью изменить поведение по умолчанию для всех пакетов таким образом, который нарушает стандарт, если только этот вариант не увеличивает допуск для старых продуктов, нарушающих стандарт. Это не тот случай, здесь.

Короче говоря, этот RFC может нарушаться по усмотрению операторов, но обычно это делается с некоторой точностью. Чрезвычайно необычно полностью игнорировать разделы стандарта, как это удобно, особенно когда профессиональный консенсус (пример: BCP 16 §3.3 ) ошибочен в пользу того, что нежелательно создавать ненужную нагрузку на систему DNS в целом. Ненужные попытки отбросить все запросы, для которых отсутствуют достоверные данные, менее чем желательно с учетом этого.

Обновить:

Относительно того, что нежелательно отбрасывать запросы на пол как само собой разумеющееся, @Alnitak поделился с нами, что в настоящее время существует проект BCP, подробно освещающий эту тему. Немного преждевременно использовать это как цитату, но это помогает укрепить согласие сообщества с тем, что здесь выражается. Особенно:

Если сервер имен не подвергся атаке, он должен отвечать на все запросы, адресованные ему в результате следующих делегаций. Кроме того, код не должен предполагать, что на сервере нет делегирования, даже если он не настроен для обслуживания зоны. Разбитое делегирование - обычное явление в DNS, и получение запросов для зон, для которых сервер не настроен, не обязательно указывает на то, что сервер подвергается атаке. Предполагается, что операторы родительской зоны регулярно проверяют, соответствуют ли записи делегирования NS записям таковой делегированной зоны, и исправляют их, когда они не совпадают [RFC1034]. Если бы это делалось регулярно, количество разбитых делегаций было бы намного ниже.

Этот ответ будет обновляться при изменении статуса этого документа.

Когда вы переносите официальный DNS для домена к новому провайдеру, вы должны всегда (всегда!) Явно проверять нового провайдера (и гарантировать, что они отправляют точные, настроенные записи), прежде чем изменять информацию о регистрации домена (whois). указать на новые авторитетные DNS-серверы.

Примерно, шаги, которые вы предпримете:

1. Настройте все на нового провайдера DNS. Вы должны создать и заполнить все зоны.

2. Убедитесь, что новые авторитетные серверы работают правильно. Запросите их явно:

   dig @new-ns.example.com mydomain.com
   

   На ваш вопрос это звучит так: они не отвечают на эти вопросы? Но вы сказали «неизвестные домены», которых не должно быть на данный момент, они должны быть полностью настроены в их системе (и отвечать настроенными вами записями).

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

3. Переключите авторитетные серверы имен с вашим регистратором доменов (whois), оставив старого DNS-провайдера включенным и работающим до тех пор, пока трафик больше не будет попадать на него (подождите не менее 24 часов).

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