Як повинні працювати тайм-аути 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спочатку.

— Андрій Б

У мене є pcap, але не впевнений, як я можу найкраще це показати тут?

— djc

Відкрийте його в 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-хостингу виникає проблема, оскільки ці домени існували вже давно (в силу запису «wild card A»). Тож інше моє запитання полягає в тому, як я можу довести, чи авторитетний сервер чинив щось не так?

— djc

NODATAУ вашому захопленні пакетів є доказом. Відповідне питання: "чому авторитетний сервер відповів і сказав, що такого запису не існує?" . На жаль, важко поставити питання, якщо ви не зможете довести це прямими переглядами авторитетних серверів (усуваючи здатність знизати плечима та звинувачувати операторів рекурсивних серверів), маючи на увазі, що лише один із трьох може періодично не поводитися.

— Андрій Б

NODATAозначає , що ім'я дійсно існує, але вона не має запис типу потрібно. Наприклад, ви запитуєте Aзапис, але він має лише MXзапис. Це також може статися, якщо ім'я є проміжним вузлом в ієрархії DNS і не має власних записів.

— Бармар

@Barmar Так, тут говорять про те, що авторитетний сервер повідомляє про відсутність цього імені запису + пара типів, а djc висловлює плутанину через це завдяки запису про підкреслення, який вже деякий час присутній.

— Андрій Б

Мій коментар адресовано вашому першому пункту "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

Це все, що я можу сказати на цю тему. Якщо хтось ще має додати, я також зацікавився б.

— Янек Бевендорф
джерело