Как должны работать таймауты DNS?

Недавно у меня возникла проблема, когда удаленная служба, запрашивающая IP-адрес для моего сервера (с размещенным поставщиком DNS), отвечала:

DNS problem: SERVFAIL looking up A for mysql.xavamedia.nl

(Обновление: удаленный сервис, упомянутый здесь: Let's Encrypt; я подал ошибку в их систему отслеживания проблем, которая привела меня на этот путь.)

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

Вот описание Wireshark пустого ответного сообщения:

Конечно, поскольку большинство DNS-запросов и ответов отправляются по протоколу UDP, локальный распознаватель просто подождет ответ, а затем сдастся. Что меня сейчас интересует, есть ли рекомендации по времени ответа DNS? Мой DNS-хостер как бы пожал плечами и сказал, что мой локальный распознаватель отправил пустой ответ слишком рано. У меня никогда раньше не было этой проблемы, но я удивлен режимом сбоя - пустым ответом DNS без кода ошибки.

Кто-нибудь знает некоторые рекомендации о том, как это должно работать, и когда / как я могу доказать, что мой DNS-хостинг делает что-то не так?

domain-name-system dns-hosting

— DJC
источник

Не могли бы вы обновить вопрос, чтобы предоставить больше информации о пустом ответе? Это может означать несколько вещей в зависимости от установленных флагов и того, как выглядит раздел полномочий. Мы будем либо потребность увидеть выход dig/ nslookupили рассечение Wireshark. ( tcpdumpне будет достаточно хорош) Если вы используете nslookup, set debugсначала выполните .

— Andrew B

У меня есть pcap, но я не уверен, как мне лучше показать это здесь?

— DJ

Откройте его в Wireshark, нажмите на пакет, затем разверните информацию для протокола DNS. Разверните также подкатегории, а затем опубликуйте снимок экрана с вашим вопросом, используя кнопку вставки изображения. Вы можете обрезать скриншот до материала протокола DNS.

— Андрей Б

Ответы:

Пустой ответ, на который вы смотрите, является синтетическим состоянием, известным как NODATA. NODATAи NXDOMAINоба указывают, что имя не существует, но также NXDOMAINотносится ко всем именам под указанной записью. NODATAрекомендует, чтобы это имя было связано с записями незапрошенного типа, или что есть другие записи, которые ниже того, что вы запрашиваете. (то есть example.test.xavamedia.nl.)

Ваш вынос NODATAи NXDOMAINфактически одинаков в этом контексте: запись запрошенного имени и типа не существует. Для запрошенного домена был достигнут авторитетный сервер имен, и он ответил, что запись такого имени и типа не существует. Это не ошибка связи. Авторитетный сервер сказал, что у него нет данных. Скорее всего, сервер, с которым вы разговаривали, уже обработал этот запрос, и отрицательно кэшировал отсутствие этой записи в течение последних четырех часов. (14400 секунд - это отрицательный интервал кэширования, определенный для записи SOA xavamedia.nl.)

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

Следует отметить, что ничто из этого не объясняет, почему вы встретили SERVFAILответ при поиске mysql.xavamedia.nl.. Это указывает на проблему с рекурсивным сервером, получающим ответ от авторитетных серверов. Либо уполномоченный сервер ответил SERVFAIL, рекурсивному серверу не удалось связаться ни с одним из доверенных серверов, либо рекурсивный сервер обнаружил, что возвращенные данные были недействительными. Ничто из этого не может быть подтверждено предоставленной вами информацией.

— Андрей Б
источник

Спасибо за ваш подробный ответ! Некоторые вещи все еще остаются неясными: если ответ NODATA инициируется каким-либо авторитетным сервером, у моего DNS-хостинга есть проблема, потому что эти домены существовали в течение долгого времени (благодаря записи подстановочного знака A). Итак, другой мой вопрос: как я могу доказать, что авторитетный сервер сделал что-то не так?

— DJ

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

— Эндрю Б

NODATAозначает , что имя действительно существует, но она не имеет запись типа требуется. Например, вы просите о Aзаписи, но она имеет только MXзапись. Это также может произойти, если имя относится к промежуточному узлу в иерархии DNS и не имеет собственных записей.

— Бармар

@ Barmar Да, здесь говорится, что авторитетный сервер сообщает об отсутствии пары «имя + тип записи», и djc выражает путаницу по этому поводу из-за записи с подстановочными знаками, которая присутствовала в течение некоторого времени.

— Андрей B

Мой комментарий адресован вашему первому пункту: «NODATA и NXDOMAIN оба указывают на то, что имя не существует». NXDOMAINозначает, что имя не существует, NODATAозначает, что имя существует, но запрошенный тип записи не существует.

— Бармар

Я не знаю каких-либо конкретных рекомендаций, кроме тех, которые определены в разделе «6.1.3.3 Эффективное использование ресурсов» RFC 1123 http://tools.ietf.org/rfcmarkup?rfc=1123#page-77.

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

Существует также тема Stackoverflow об этой теме, но она не содержит намного больше информации, за исключением некоторых реальных наблюдений. /programming/3036054/ideal-timeout-period-for-dns-lookup

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

— Янек Бевендорф
источник