Мой регистратор доменов и служба 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, который их серверы нарушают. Я знаю, что это странно, что они просят меня доказать, что их серверы должны отвечать на все запросы, но пусть будет так.
Вопросы:
Для меня плохо не отвечать на запрос DNS. Большинство клиентов отключаются, а затем повторно отправляют тот же запрос либо на тот же DNS-сервер, либо на другой сервер. Они не только замедляют работу клиентов, но и заставляют снова выполнять тот же запрос на их собственных или других серверах в зависимости от авторитетных серверов имен и записей NS.
В RFC 1536 и 2308 Я вижу много информации об отрицательном кэшировании из соображений производительности и для остановки повторной передачи того же запроса. В 4074 Я вижу информацию о возврате пустого ответа с RCODE, равным 0, поэтому клиент знает, что нет информации ipv6, которая должна заставить клиента спросить о 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), документ, разъясняющий язык МОЖЕТ, ДОЛЖЕН, ДОЛЖЕН и т. Д.
Итак, давайте начнем с того, что RFC 1034 §4.3.1 должен сказать:
- Самый простой режим для сервера - нерекурсивный, так как он может отвечать на запросы, используя только локальную информацию: ответ содержит ошибку, ответ или ссылку на какой-либо другой сервер, находящийся «ближе» к ответу. Все серверы имен должны реализовывать нерекурсивные запросы.
...
Если рекурсивный сервис не запрашивается или недоступен, нерекурсивный ответ будет одним из следующих:
Ошибка авторитетного имени, указывающая на то, что имя не существует.
Индикация временной ошибки.
Некоторая комбинация:
RR, которые отвечают на вопрос, вместе с указанием, поступают ли данные из зоны или кэшируются.
Отсылка к серверам имен, у которых есть зоны, которые являются более близкими предками к имени, чем сервер, отправляющий ответ.
RR, которые, по мнению сервера имен, могут оказаться полезными для запрашивающей стороны.
Язык здесь достаточно твердый. Нет «должно быть», но «будет». Это означает, что конечный результат должен быть либо 1) определен в приведенном выше списке, либо 2) разрешен более поздним документом в Standards Track, который изменяет функциональность. Мне не известно о существовании подобного словоблудия для игнорирования запроса, и я бы сказал, что ответственность за поиск формулировок, опровергающих результаты исследования, лежит на разработчике.
Учитывая частую роль DNS в сценариях злоупотреблений в сети, не следует говорить о том, что программное обеспечение DNS-сервера не позволяет выборочно прекратить движение транспорта на полу, что технически является нарушением этого правила. Тем не менее, это либо поведение не по умолчанию, либо с очень консервативными значениями по умолчанию; примерами обоих может быть пользователь, требующий от программного обеспечения удалить определенное имя (rpz-drop.) или превышены определенные числовые пороги (BIND's max-clients-per-query). По моему опыту, это почти неслыханно, чтобы программное обеспечение полностью изменить поведение по умолчанию для всех пакетов, нарушающее стандарт, если только опция не увеличивает терпимость для более старых продуктов, нарушающих стандарт. Здесь дело обстоит не так.
Короче говоря, этот RFC может и действительно нарушается по усмотрению операторов, но обычно это делается с некоторой точностью. Крайне редко полностью игнорируйте разделы стандарта, как это удобно, особенно при профессиональном консенсусе (пример: BCP 16 §3.3) ошибается в пользу нежелательности создания ненужной нагрузки на систему DNS в целом. Учитывая это, ненужные попытки отбросить все запросы, для которых отсутствуют достоверные данные, менее чем желательны.
Обновить:
Что касается того, что нежелательно оставлять запросы на обсуждение, конечно, @Alnitak поделился с нами, что в настоящее время существует Проект BCP подробно освещая эту тему. Немного преждевременно использовать это в качестве цитаты, но это действительно помогает укрепить согласие сообщества с тем, что здесь выражается. В частности:
Если сервер имен не подвергся атаке, он должен отвечать на все запросы, направленные ему в результате следующих делегаций. Кроме того, код не должен предполагать, что нет делегирования серверу, даже если он не настроен для обслуживания зоны. Нарушение делегирования - обычное явление в DNS, и получение запросов для зон, для которых сервер не настроен, не обязательно указывает на то, что сервер подвергается атаке. Предполагается, что операторы родительской зоны должны регулярно проверять соответствие делегированных записей NS с записями делегированной зоны и исправлять их, если они не соответствуют [RFC1034]. Если бы это делалось регулярно, количество прерванных делегаций было бы намного меньше.
Этот ответ будет обновлен при изменении статуса этого документа.
Когда вы перемещаете авторитетный DNS для домена к новому провайдеру, вы всегда должны (всегда!) Проводить явное тестирование с новым провайдером (и убедиться, что он отправляет точные, настроенные записи), прежде чем изменять информацию о регистрации домена (whois). чтобы указать на новые полномочные DNS-серверы.
Примерно шаги, которые вы предпримете:
Убедитесь, что новые официальные серверы работают правильно. Запросите их явно:
dig @new-ns.example.com mydomain.com
Судя по вашему вопросу, они не отвечают на эти запросы? Но вы сказали «неизвестные домены», которых на данном этапе быть не должно, они должны быть полностью настроены в их системе (и отвечать настроенными вами записями).
Но если ты иметь уже настроили домен в своей системе, на этом этапе он должен отвечать правильными записями. Если это не так, значит, они не размещают зону должным образом, и вы должны на них кричать; отвечает ли он на домен, который не был настроен, не должно иметь значения. (Если мне все еще не хватает того, что вы говорите, дайте мне знать).
Если новый провайдер абсолютно не может заполнить записи до того, как вы сделаете переключение, то то, как они ответят, действительно не будет иметь значения - указание пользователям на авторитетный источник, который полностью отклоняет запрос, приведет к простою вашего домена точно так же, как если бы вы были не получил никакого ответа.