DNS-запит онлайн

Вісім типів записів за один прохід

Введіть домен, і сторінка запитає в публічного резолвера Cloudflare, 1.1.1.1, записи A, AAAA, CNAME, MX, NS, SOA, TXT і CAA. Запит іде через DNS-over-HTTPS із вашого браузера, тож ви бачите те, що публічний резолвер повертає вам, а не відповідь із серверів самої зони. Кожен результат виводиться у стилі dig: ім’я, TTL, що залишився, тип і дані. Типи без відповідей пропускаються, і це теж корисна інформація.

Разом вони відповідають на більшість запитань «чому не працює». A і AAAA визначають, куди йде веб-трафік. CNAME робить одне ім’я псевдонімом іншого. MX спрямовує пошту. NS каже, які сервери авторитетні. У TXT лежать SPF, підтвердження домену й політика DMARC. CAA обмежує, які центри сертифікації можуть видавати сертифікати.

Як читати TTL і чому відповіді різняться

Число біля кожного запису — це час у секундах, протягом якого цей резолвер ще може тримати його в кеші. Виконайте запит двічі: якщо в другому разі число менше, ви бачили кешовану копію, яка спливає. Різні резолвери тримають різні копії, тому Google, Cloudflare і ваш провайдер можуть розходитися годинами після правки. Ось і вся історія «поширення»: нічого нікуди не розсилається, кеші просто спливають.

Плануйте зміни з огляду на TTL. Якщо в запису TTL 86400 (доба), а перенести сайт треба сьогодні ввечері, спершу знизьте TTL до 300, зачекайте щонайменше добу, поки спливуть старі довгоживучі копії, внесіть зміну й після цього підніміть TTL назад. Якщо порушити порядок, половина відвідувачів на добу залишиться на старому сервері.

Записи, які часто читають неправильно

Кілька випадків, що повторюються в запитах до підтримки:

• CNAME не може стояти на вершині зони поруч із записами SOA і NS. Провайдери обходять це через ALIAS, ANAME або «сплющені» CNAME; для резолвера вони виглядають як звичайні записи A.
• CNAME на імені, де є також MX або TXT, ламає їх, бо псевдонім перехоплює всі типи для цього імені.
• Серійний номер SOA зазвичай складається з дати й лічильника, наприклад 2026110601. Якщо після правки він не змінився, правка не дійшла до первинного сервера імен.
• Записи NS у реєстратора й у зоні мають збігатися. Розбіжність («lame delegation») дає уривчасті збої, які здаються випадковими.
• Запис CAA на кшталт 0 issue "letsencrypt.org" забороняє видавати сертифікати будь-якому іншому центру. Забутий CAA — типова причина того, що замовлення сертифіката перестає проходити після зміни провайдера.
• Значення TXT довше за 255 символів треба розбити на кілька рядків у лапках; багато панелей роблять це автоматично.

Чого цей запит не покаже

Він не звертається до авторитетних серверів, тож свіжу зміну може бути не видно доти, доки не спливе TTL. Він не показує перевірку DNSSEC, а DNS-over-HTTPS блокують деякі корпоративні мережі — тоді сторінка радить виконати dig у терміналі (команду надруковано під інструментом). Він також відображає лише один резолвер: сервер імен, який відповідає неправильно тільки частині клієнтів або з окремих країн, він не виявить.

Відстежувати записи, а не просто дивитися на них

DNS-монітор повторює цей запит за розкладом і порівнює відповідь із очікуваними значеннями записів A, AAAA, CNAME, MX, NS або TXT. Несподівана зміна відкриває інцидент, а сповіщення показує, що знайдено, тож тиха підміна чи випадкове видалення стають сповіщенням. DNS-моніторинг починається з тарифу Starter. Як зіставляються очікувані значення, дивіться в розділі DNS-моніторинг. Для боку реєстрації є перевірка терміну дії домену.