myip
🇺🇦 UK

DNS-запит

Усі поширені типи записів домену одним запитом.

Що насправді показує запит до DNS

Система доменних імен — це шар, який перетворює імена, зрозумілі людям, на адреси, якими насправді користуються машини. Її описали 1987 року в RFC 1034 і 1035, і конструкція виявилася настільки вдалою, що майже все додане відтоді — маршрутизація пошти, дозвіл на видачу сертифікатів, автентифікація листів, пошук служб — прикрутили новими типами записів, а не новою системою.

Запит питає, які записи прив'язані до імені. Ця сторінка питає поширені типи одразу, і це корисний спосіб: майже кожна реальна проблема виявляється як розбіжність між типами записів, а не всередині одного. Пошта не ходить, а сайт працює — це питання MX. Сертифікат не поновлюється — питання CAA. Сайт працює в одних людей і не працює в інших — зазвичай питання A проти AAAA.

Одне застереження до всього іншого: тут ви бачите те, що щойно сказали нашому резолверу. Якщо запис нещодавно змінили, резолвери світу ще віддаватимуть стару відповідь, доки не спливе їхня збережена копія. Це не наша застаріла інформація — це задуманий режим роботи, і розділ про TTL пояснює, як його передбачити.

Типи записів і для чого кожен

A і AAAA
Адреси, на які вказує ім'я: A — IPv4, AAAA — IPv6. Кілька записів кожного типу — норма й означає або просте розподілення навантаження, або мережу доставки. Якщо в імені є обидва типи, а один із них недосяжний, ви отримуєте класичне «у мене працює» — чому вибір браузера тут вирішальний, пояснює тест IPv6.
CNAME
Псевдонім: «це ім'я насправді он те, питай там». Правило, на якому ловляться всі: ім'я з CNAME не може мати жодних інших записів, — тому CNAME заборонений на вершині домену. Не можна зробити псевдонімом сам example.com, тільки www.example.com. Провайдери обходять це функцією, яку зазвичай називають ALIAS або сплощенням: вона розв'язує ціль за вас і віддає звичайні адреси.
MX
Куди йде пошта домену. Кожен запис несе число переваги, і виграє менше — поширене й дороге хибне прочитання. Домен, який пошти не шле взагалі, має сказати це явно одним «нульовим» записом, самотньою крапкою з пріоритетом нуль: вона каже відправникам спинитися, а не повторювати спроби днями.
NS
Авторитетні сервери зони. Звірте їх із тим, що публікує реєстр у реєстровому записі домену: коли ці два списки розходяться, частина світу потрапляє на одні сервери, а частина на інші, і симптоми стають до нестями непослідовними.
TXT
Довільний текст, а на практиці — місце, де живе поштова політика. SPF стоїть тут, на вершині домену, ключі DKIM — під іменем селектора, DMARC — під _dmarc. Тут же накопичуються рядки підтвердження власності від кожної служби, у якій ви колись реєструвались.
SOA
Власні метадані зони: який сервер головний, серійний номер, за яким вторинні розуміють, що щось змінилося, таймери оновлення й повтору, а також час зберігання заперечних відповідей — тобто скільки пам'ятається «такого імені немає».
CAA
Які центри сертифікації мають право видавати сертифікати для домену. З вересня 2017 року кожен публічний центр зобов'язаний перевіряти цей запис перед видачею, — тож це єдиний запис DNS, здатний прямо заблокувати сертифікат.
SRV
Пошук служб: на якому вузлі й порту працює конкретна служба. Активно використовується чатами, голосовими й каталоговими протоколами, а надто середовищами Microsoft.

TTL і чому «поширення DNS» — хибний вислів

Кожен запис несе час життя в секундах. Це вказівка кешам: тримай цю відповідь стільки і лише потім питай знову. Нікуди нічого не розсилають. Коли кажуть, що зміна «поширюється», насправді відбувається інше: резолвери світу досі тримають відповідь, яку їм дозволили тримати, і візьмуть нову, коли дозвіл спливе.

Це робить затримку передбачуваною, а не загадковою, — і робить очевидним стандартний порядок: знижувати TTL треба до зміни, а не після. Опустіть його до кількох хвилин, дочекайтеся, доки скрізь спливе старий довгий TTL, тоді вносьте зміну, а тоді підніміть TTL назад. Пропустіть перший крок — і ви приречені чекати рівно стільки, скільки було опубліковано; для комфортних добових TTL це доба, протягом якої ходять дві різні відповіді.

Заперечні відповіді теж кешуються. Якщо хтось запитав ім'я до того, як воно з'явилося, відповідь «не існує» запам'ятовується на строк із запису SOA, — тож створення імені не полагодить ситуацію для цієї людини негайно. За цим стоїть неабияка частка повідомлень «я додав запис, а воно й далі не працює».

Поштові записи: те, що ламається найчастіше

Якщо проблема в пошті, майже все вирішують чотири записи, і приймальна система перевіряє їх у такому порядку.

  1. MX — куди доставляти. Відсутність MX узагалі означає, що відправники впадуть назад на A-запис домену, а це зазвичай вебсервер і зазвичай не те, чого хтось хотів.
  2. SPF — TXT-запис, що починається з v=spf1: які сервери мають право слати від імені домену. Він мусить бути рівно один; два SPF-записи — це стала помилка, а не об'єднання. Крім того, під час перевірки діє жорсткий ліміт у десять DNS-запитів, і кілька складених include: від різних поштових постачальників тихо його перевищують. Після цього все ламається незалежно від того, наскільки правильно воно виглядає.
  3. DKIM — відкритий ключ, яким перевіряють підпис на вихідних листах; публікується під селектором, що його обирає система-відправник.
  4. DMARC — TXT-запис на _dmarc: що робити приймальній стороні, коли SPF і DKIM не узгоджуються з видимою адресою відправника, і куди слати звіти про це. Опублікувати його з політикою none — правильний перший крок: на доставку це не впливає ніяк, зате запускає звіти, з яких видно, хто шле від вашого імені.

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

Відмови і як їх розрізняти

Імені не існує (NXDOMAIN)
Авторитетно й однозначно: такого імені в зоні немає. Перевірте написання, а тоді — чи створювали ви запис у тій зоні, у якій думаєте.
Ім'я є, але записів такого типу немає
Зовсім інша річ, і це нормальна відповідь на запит AAAA до імені, у якого є тільки IPv4. Це не помилка.
Відмова сервера (SERVFAIL)
Резолвер не зміг отримати придатну відповідь. Дві звичайні причини: авторитетні сервери недосяжні або не пройшла перевірка DNSSEC — прострочений підпис прибирає зону з інтернету цілком для всіх, хто перевіряє, і водночас вона бездоганно працює для всіх, хто не перевіряє.
Тайм-аут без жодної відповіді
Часто це мережева проблема або фаєрвол, а не DNS. Великі відповіді не влазять в один UDP-пакет і вимагають переходу на TCP, а обладнання, яке блокує DNS через TCP, дає відмови, що виглядають випадковими і зачіпають лише частину доменів.

Дві перевірки, які варто робити щоразу

Чи збігаються NS-записи з реєстром? Делегування в реєстрі — це те, за чим іде решта світу; NS-записи всередині зони — це те, що зона каже про себе сама. Старі сервери імен, залишені після переїзду, продовжують відповідати старими даними, а оскільки резолвери обирають між ними, виходить, що сайт наче працює — у половини ваших колег.

Чи вказують адреси туди, куди ви думаєте? Подивіться A- і AAAA-записи, а тоді перевірте, хто тримає ці адреси. Запис, який досі вказує на хостинг, покинутий два роки тому, — поширена й тихо небезпечна знахідка: ім'я делеговане на інфраструктуру, якою ви більше не керуєте, і хто отримає цю адресу після вас, той успадкує й ім'я.

Часті запитання

Я змінив DNS-запис. Чому досі показується старий?

Бо кожен запис несе час життя, і резолвери мають право тримати попередню відповідь, доки він не спливе. Нікому нічого не розсилають — слово «поширення» описує спливання кешів, а не подорож даних. Якщо в старого запису був TTL у добу, частина резолверів віддаватиме його ще добу. Уникнути цього можна лише одним способом: знизити TTL за день до планової зміни, а не після неї.

Чим A-запис відрізняється від CNAME?

A-запис одразу дає адресу. CNAME каже: «це ім'я — псевдонім он того, питай там». Наслідок, на якому ловляться всі: ім'я з CNAME не може мати жодних інших записів, — тому його не можна поставити на вершину домену. Сам example.com не може бути CNAME, а www.example.com може. Хостинги обходять це функцією, яку зазвичай називають ALIAS або сплощенням.

Який MX-запис головний — з більшим числом чи з меншим?

З меншим. Число є перевагою, а не рангом: відправники пробують найменше значення першим і переходять до більших, лише якщо воно не відповідає. Однакові числа означають, що навантаження ділиться між тими серверами. Якщо домен не шле й не отримує пошти взагалі, правильно опублікувати один нульовий MX — самотню крапку з пріоритетом нуль, — щоб відправники здавалися одразу, а не повторювали спроби днями.

Запит нічого не повертає для AAAA. Щось не так?

Ні. Це означає, що в імені немає адреси IPv6, а так і досі живе чимала частина інтернету. Це інший результат, ніж «імені не існує», і обидва вони є нормальними відповідями, а не помилками. Значення це має лише тоді, коли ви очікували роботи через IPv6: до імені без AAAA-запису через IPv6 не звертаються ніколи.

Чому я отримую SERVFAIL для домену, який відкривається в браузері?

Дві найпоширеніші причини — недосяжні авторитетні сервери й невдала перевірка DNSSEC. Про другу варто знати окремо: коли підписи зони прострочені, кожен резолвер, який перевіряє, відмовляється відповідати, а кожен, який не перевіряє, працює як завжди. Виходить домен, цілком мертвий для одних людей і цілком справний для інших, — тому свідчення ніколи не сходяться.

Скільки SPF-записів має бути в домену?

Рівно один. Два SPF-записи не об'єднуються — це стала помилка, і приймальні системи вважають результат непридатним. Крім того, під час перевірки діє ліміт у десять DNS-запитів, і ланцюжок із кількох include: від різних поштових постачальників тихо його перевищує; після цього запис не працює, хоч би яким правильним він виглядав при читанні.

Що робить запис CAA?

Він називає центри сертифікації, яким дозволено видавати сертифікати для домену. З вересня 2017 року кожен публічний центр зобов'язаний перевіряти його перед видачею, — тож запис CAA, залишений від постачальника, яким ви більше не користуєтесь, прямо заблокує новий сертифікат. Виглядає ця відмова як проблема центру сертифікації, хоча нею не є.

Чиє це бачення DNS — моє чи ваше?

Наше. Запит іде з нашого резолвера, тож ви бачите те, що авторитетні сервери кажуть нам зараз. Якщо ваш комп'ютер отримує іншу відповідь, звичайні причини такі: збережений раніше запис на вашому боці, резолвер провайдера, який відповідає інакше, або локальний файл hosts, що перекриває ім'я повністю.

Пов'язані перевірки