Перевірка DNS-записів домену
DNS-записи визначають, куди веде домен: на який сервер іде сайт, куди надходить пошта, хто може надсилати листи від вашого імені. Найшвидше перевірити DNS-записи домену онлайн — ввести домен у перевірку DNS: інструмент безкоштовно й без реєстрації покаже записи A, AAAA, CNAME, MX, NS, TXT, SOA і SRV разом з їхніми значеннями та TTL. Нижче — як читати результат, як перевірити те саме через nslookup і dig та що робити, якщо записи «не оновлюються».
Як перевірити DNS-записи домену онлайн
- Відкрийте перевірку DNS і введіть домен:
example.com. Протокол і шлях можна не прибирати — інструмент сам виділить ім'я хоста з адреси. - Для піддомену вводьте його повністю:
www.example.com,shop.example.com. Записи в кожного імені свої, і CNAME зазвичай стоїть саме на піддомені. - Звірте результат із тим, що видав хостинг або поштовий сервіс: IP в A-записі, імена в MX, рядки в TXT.
- Зверніть увагу на стовпець TTL — він підкаже, через скільки секунд оновиться кеш, якщо ви щойно щось змінили.
Інструмент запитує записи через резолвер нашого сервера, тобто показує, що бачить одна точка мережі просто зараз. Щоб перевірити поширення змін, порівняйте відповідь із публічними резолверами командами з наступного розділу.
Імена з підкресленням, як-от _dmarc.example.com, у загальну перевірку не вводяться — для поштових записів є окремі інструменти: перевірка MX-записів покаже поштові сервери з пріоритетами та IP, перевірка SPF розбере механізми й ланцюжки include, перевірка DMARC — політику та адреси звітів.
Перевірка DNS через nslookup і dig
nslookup є у Windows, macOS і Linux, dig — у macOS і більшості дистрибутивів Linux. Останній параметр nslookup або аргумент @ у dig задає, який DNS-сервер запитувати.
nslookup -type=A example.com
nslookup -type=MX example.com
nslookup -type=TXT example.com 8.8.8.8
nslookup -type=CNAME www.example.comdig example.com A +short
dig www.example.com CNAME +short
dig example.com MX +short
dig example.com NS +short
dig example.com TXT +short
dig _dmarc.example.com TXT +short
dig selector1._domainkey.example.com TXT +short
dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com AУ PowerShell те саме робить Resolve-DnsName example.com -Type MX. Щоб побачити, що реально записано в зоні, без кешів дорогою, запитайте авторитативний сервер напряму: спершу dig example.com NS +short, потім dig @ns1.ваш-провайдер.net example.com A. Команда dig +trace example.com пройде весь ланцюжок від кореневих серверів і покаже, на якому кроці відповідь розходиться з очікуваною.
Типи DNS-записів і що в них перевіряти
| Запис | За що відповідає | Приклад значення | На що дивитися |
|---|---|---|---|
| A / AAAA | IPv4 / IPv6-адреса сайту | 203.0.113.10 | Чи збігається з вашим сервером; чи немає зайвих адрес |
| CNAME | Псевдонім на інше ім'я | shop.example.net. | Чи немає ланцюжків і конфліктів з іншими записами |
| MX | Поштові сервери та пріоритет | 10 mx1.example.net. | Чи є взагалі й чи ті, що потрібно |
| TXT | Підтвердження та поштові політики | v=spf1 ... ~all | SPF в єдиному екземплярі, наявність DMARC |
| NS | Хто обслуговує зону | ns1.example.net. | Чи збігаються з провайдером, де ви редагуєте записи |
| SOA | Параметри зони | серійний номер, таймаути | Чи зростає серійний номер після змін |
| SRV | Адреси сервісів | _sip._tcp | Потрібен лише для окремих сервісів |
Перевірка CNAME-запису
CNAME каже: «це ім'я — псевдонім іншого імені, питайте там». Його ставлять на піддомени, що вказують на зовнішній сервіс: конструктор сайтів, CDN, магазин на платформі. Перевірити CNAME-запис домену можна онлайн, вказавши піддомен у перевірці DNS, або командою dig www.example.com CNAME +short.
- CNAME не може співіснувати з іншими записами на тому самому імені. Тому на корені домену (
example.com, де обов'язково є NS і SOA) звичайний CNAME ставити не можна. Деякі DNS-провайдери пропонують заміну — ALIAS, ANAME або «вирівнювання» CNAME (flattening): ззовні такий запис виглядає як звичайний A. - Ланцюжки CNAME → CNAME → CNAME працюють, але сповільнюють розв'язання імені й ускладнюють пошук помилок.
- CNAME на неіснуюче ім'я — часта причина того, що піддомен «не відкривається» після відключення зовнішнього сервісу.
- Крапка в кінці. У деяких панелях значення треба писати із завершальною крапкою, інакше до нього допишеться ваш домен і вийде
shop.example.net.example.com.
TXT-записи: SPF, DKIM і DMARC
Якщо листи з домену потрапляють у спам, дивіться три TXT-записи:
example.com. TXT "v=spf1 include:_spf.google.com ~all"
selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBg..."
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:[email protected]"- SPF — список серверів, яким дозволено надсилати пошту від домену. Запис
v=spf1має бути один: два SPF-записи роблять перевірку недійсною. Кількість DNS-запитів під час перевірки SPF обмежена десятьма, і довгі ланцюжки include легко її перевищують. - DKIM — публічний ключ підпису, розміщений за адресою
селектор._domainkey.домен. Селектор задає поштовий сервіс, без нього запис не знайти. - DMARC — політика для листів, що не пройшли SPF і DKIM:
none(лише звіти),quarantine(у спам),reject(відхилити).
У TXT також зберігаються підтвердження володіння: наприклад, доменний ресурс у Search Console підтверджується TXT-записом — див. статтю про підключення ресурсу.
TTL і поширення DNS
TTL — час у секундах, на який резолвери кешують відповідь. За TTL 3600 провайдер, який одного разу запитав ваш A-запис, годину віддаватиме старе значення, навіть якщо ви його вже змінили. Так зване «поширення DNS» — це і є поступове закінчення терміну кешів по всьому світу. Зміна NS-серверів у реєстратора зазвичай триває довше: у записів у зоні домену верхнього рівня свій, як правило довгий, TTL.
- Перед плановими змінами знизьте TTL до 300 секунд — заздалегідь, не пізніше ніж за час старого TTL.
- Якщо ви перевіряли ім'я до того, як запис створили, негативна відповідь теж кешується — на час із SOA-запису зони.
- Локальний кеш теж заважає: у Windows його скидає
ipconfig /flushdns, у macOS —sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. - Якщо авторитативний сервер відповідає правильно, а публічні резолвери — ні, помилки немає: треба дочекатися закінчення TTL.
Коли це потрібно перевіряти
- Сайт відкривається не в усіх. Часта причина — записи змінили нещодавно, і в частини провайдерів ще старі дані.
- Листи йдуть у спам. Дивіться SPF, DKIM і DMARC у TXT-записах.
- Переїзд на інший хостинг. Перед перемиканням корисно зафіксувати поточні записи.
- Підключення зовнішнього сервісу: пошти, CDN, конструктора — майже завжди це CNAME або TXT.
Типові помилки
- Записи редагують не там. Якщо NS домену вказують на одного провайдера, зміни в панелі іншого (наприклад, реєстратора) ні на що не впливають. Спершу перевірте NS.
- Два SPF-записи після підключення другого поштового сервісу замість об'єднання в один.
- CNAME на корені домену, що ламає MX і TXT.
- Забуті MX під час переїзду: сайт працює, а пошта перестала надходити.
- Старий IP у www: A-запис кореня оновили, а для www залишили попередній.
Чек-лист переїзду на інший хостинг
- За добу знизьте час життя записів — тоді перемикання підхопиться швидко.
- Зафіксуйте поточні записи: A, MX, TXT і NS мають бути виписані до змін.
- Запустіть сайт на новому сервері й перевірте його за IP, не чіпаючи домен.
- Перемкніть A-запис і стежте за відповіддю різних резолверів.
- Переконайтеся, що пошта не відпала: MX і SPF під час переїзду забувають найчастіше.
- Поверніть попередній час життя записів і перевірте SSL-сертифікат на новій адресі.