Що таке DNS: як підключити домен до VPS

Що таке DNS і чому ваш домен ще не веде на VPS

DNS (domain name system) перетворює ім’я, наприклад example.com, на IP-адресу (internet protocol), наприклад 203.0.113.10. Браузер не може підключитися до імені. Він підключається до адреси, тому кожне завантаження сторінки починається із запиту DNS і відповіді. Якщо ви щойно придбали домен і власний VPS, але нічого не завантажується, можлива одна з двох причин: ще немає запису, який пов’язує ім’я з адресою вашого сервера, або такий запис є, але на одному з етапів маршруту все ще повертається старе значення.

Обидві ситуації є нормальними. Жодна з них не означає, що щось зламано. У наведених нижче розділах ці компоненти розглянуто в тому порядку, у якому ви з ними зіткнетеся. Спочатку розглянемо те, що найчастіше забирає час: яка саме панель керування містить ваші записи.

Для всіх перевірок у цьому розділі використовується dig. Цю утиліту не встановлено за замовчуванням на щойно встановленій системі Ubuntu або Debian.

sudo apt update && sudo apt install -y bind9-dnsutils

Реєстратор, nameservers, DNS-хост: що саме редагувати

Ці три назви позначають різні функції. Плутанина між ними — найпоширеніша причина, через яку зміни нічого не змінюють.

• Реєстратор — це компанія, у якої ви придбали домен. Його основна функція — делегування: він повідомляє реєстру, який обслуговує ваш TLD (домен верхнього рівня, частина .com), які nameservers є авторитетними для вашого домену.
• Авторитетні nameservers зберігають фактичні записи вашої зони. Зона — це ваш домен і доменні імена в ньому.
• DNS-хост — це оператор цих nameservers. Ним може бути реєстратор, окремий провайдер або bind9, запущений на сервері, яким ви володієте.

Домен купують у реєстратора. Записи редагують у DNS-хоста. Якщо ви перенесли домен на nameservers іншого провайдера, у власній DNS-панелі реєстратора все одно відображається зона, зміни зберігаються, але ніхто в інтернеті ніколи не надсилає запити до цієї зони. Записи існують. Просто їх ніхто не використовує.

З’ясуйте, до якої системи надходять запити:

dig example.com NS +short
dig +trace example.com

Перша команда показує nameservers, які відповідають за домен зараз. Друга проходить ланцюжок від кореневих серверів і показує делегування, яке TLD-сервери повертають у відповіді. Саме це делегування контролює ваш реєстратор. Якщо ці імена належать провайдеру, якого ви не впізнаєте, потрібна панель саме цього провайдера.

Як проходить один DNS-запит

У цьому беруть участь чотири сторони. Кожна з них зберігає копію отриманих даних.

1. Stub resolver на вашому комп’ютері. Він нічого не шукає. Він надсилає запит до одного налаштованого сервера та довіряє відповіді. В Ubuntu /etc/resolv.conf зазвичай є символічним посиланням на /run/systemd/resolve/stub-resolv.conf і вказує на 127.0.0.53, тобто на systemd-resolved, який працює локально та має власний кеш.
2. Рекурсивний резолвер. Це резолвер вашого ISP (інтернет-провайдера), публічний резолвер, наприклад 1.1.1.1, або резолвер, який ви запустили самостійно. Саме він виконує пошук відповіді.
3. Root- і TLD-сервери. Рекурсивний резолвер надсилає запит до root-сервера. Той не знає вашу адресу, але повертає делегацію на сервери .com. Вони, своєю чергою, повертають делегацію на ваші nameserver.
4. Авторитетний nameserver. Він ні в кого не запитує. Він відповідає на основі вашої зони та позначає відповідь як авторитетну.

dig +trace example.com показує цей процес, оскільки починає безпосередньо з root і виводить кожну делегацію, а не звертається до кешу. Це найшвидший спосіб перевірити, чи узгоджуються делегація та зона.

Записи DNS, які важливі під час запуску сервера

• A: ім’я на адресу IPv4. example.com. A 203.0.113.10. Це запис, який спрямовує ваш домен на VPS.
• AAAA: ім’я на адресу IPv6, наприклад 2001:db8::10. Публікуйте його лише тоді, коли ваш сервіс справді прослуховує цю адресу. Клієнти в мережах IPv6 спочатку перевіряють відповідь AAAA, тому адреса, на якій ніхто не відповідає, додає затримку під час кожного відкриття сайту.
• CNAME: псевдонім одного імені для іншого імені. www.example.com. CNAME example.com. спрямовує відвідувачів www туди, куди вказує кореневий домен. CNAME не може бути заданий для apex (кореневого example.com), оскільки apex має містити власні записи SOA (start of authority) і NS, а CNAME не може мати те саме ім’я, що й будь-який інший запис. Провайдери пропонують обхідні рішення під назвами ALIAS, ANAME або CNAME flattening.
• MX: визначає, куди доставляти пошту для домену. Він містить ім’я хоста та числовий пріоритет; спочатку перевіряється запис із меншим числом. MX має вказувати на ім’я, для якого існує запис адреси. Посилання на CNAME є недійсним, і деякі сервери-відправники відхилятимуть такий запис.
• TXT: довільний текст, який використовують для підтвердження та політик. Тут зберігаються записи автентифікації пошти (SPF, DKIM, DMARC), а також токен ACME (automatic certificate management environment), за допомогою якого випускають wildcard-сертифікат.
• NS: визначає, які сервери імен обслуговують зону. Копія, яка визначає, куди звертається весь світ, зберігається в батьківській зоні та надходить із делегування вашого реєстратора, а не з копії всередині вашої власної зони.

Два нюанси спричиняють більше плутанини, ніж самі типи записів. Ім’я, що закінчується крапкою, є абсолютним, тому www.example.com. означає саме це й нічого більше. Більшість панелей очікують відносне ім’я та самостійно додають домен, тому введення www.example.com у поле імені дає www.example.com.example.com, яке ні для кого не розв’язується. Інший нюанс — @, що майже в кожній панелі означає apex: сам домен без субдомену.

Налаштуйте A-запис для VPS

Спочатку отримайте адресу, яку інтернет бачить для вашого сервера:

curl -4 https://ifconfig.me
ip -brief -4 address show

Потім створіть один запис у свого DNS-провайдера: тип A, ім’я @, значення — ця адреса, TTL (час життя) — 300. Додайте другий запис для www: або ще один запис A із тією самою адресою, або запис CNAME, що вказує на apex.

Тепер перевірте, чи працює розв’язання імені. Бажано виконати перевірку з ноутбука, а не безпосередньо із сервера:

dig example.com A +short
dig @1.1.1.1 example.com A +short
dig @ns1.your-dns-host.net example.com A +short

Перша команда використовує звичайний маршрут вашого комп’ютера, включно з кешами. Друга оминає локальний кеш і надсилає запит публічному рекурсивному резолверу. Третя команда надсилає запит безпосередньо до авторитетного DNS-сервера, тому повертає актуальну відповідь без кешу на всьому маршруті. Якщо третя команда повертає вашу адресу, а перша — ні, DNS налаштовано правильно, і потрібно лише дочекатися завершення дії кешованої старої відповіді.

Розв’язання імен не завантажується

Успішне розв’язання імен підтверджує, що DNS працює. Воно нічого не доводить про ваш вебсервер. Коли dig повертає правильну адресу, перевірте з’єднання:

curl -I http://example.com

curl: (6) Could not resolve host: example.com — це проблема DNS. curl: (7) Failed to connect to example.com port 80 after 21 ms: Connection refused — не проблема DNS: ім’я було розв’язано, а пакет надійшов, отже проблема в тому, що на цьому порту нічого не прослуховувало з’єднання. Запит, який зависає, а потім завершується через тайм-аут, зазвичай означає, що firewall мовчки відкинув пакет, а не відхилив з’єднання. На цьому DNS перестає бути предметом перевірки, а далі потрібно перевірити порти та сокети, що прослуховують з’єднання, а також правила firewall ufw на вашому VPS. Після встановлення з’єднання решта завантаження сторінки — це робота HTTP.

Чому браузер досі показує старий хост

Нічого не поширюється автоматично. Жоден сервер не надсилає вашу зміну іншим користувачам. Авторитетний nameserver зберігає нове значення одразу після його збереження, а кожна кешована копія попередньої відповіді залишається дійсною, доки не завершиться її власний таймер. Цей таймер — TTL у секундах, який мав запис у момент його видачі.

Копії зберігаються в більшій кількості місць, ніж зазвичай очікують: у короткочасному кеші самого браузера, у stub resolver на машині, у recursive resolver, який використовує ця мережа, а також у будь-якому resolver, встановленому VPN на клієнті. Кожен із них зберігає свою копію не довше за отриманий TTL. Двоє людей у двох мережах можуть протягом кількох годин бачити різні відповіді, і обидві машини працюватимуть правильно.

Перевірте зворотний відлік у caching resolver:

dig @1.1.1.1 example.com +noall +answer

Виконайте команду двічі з інтервалом у кілька секунд. TTL у відповіді зменшиться. Коли він досягне нуля, resolver видалить запис і знову запитає ваш nameserver.

Є ще один кеш, про який майже ніхто не згадує: кеш негативних відповідей. Коли resolver отримує повідомлення, що ім’я не існує, він також кешує цей NXDOMAIN на час, визначений останнім полем запису SOA вашої зони.

dig example.com SOA +short

Останнє число в цьому рядку — negative TTL, часто 3600. Тому запит до staging.example.com до його створення може приховати запис на цілу годину після створення. Спочатку створіть запис, а потім перевірте його.

Зміна nameserver повільніша за зміну запису, і причина суто технічна. Записи делегування в зоні .com обслуговуються з TTL 172800 секунд, тобто дві доби, тому resolver, який закешував старі nameserver, може надсилати їм запити протягом усього цього часу. Звідси й порада «почекати до 48 годин». Вона стосується змін nameserver, а не звичайного редагування записів.

Плануйте міграцію з урахуванням TTL, а не намагайтеся його обійти:

1. Зменште TTL запису до 300 і збережіть його.
2. Зачекайте довше за старий TTL, щоб кожна кешована копія зі старим значенням стала недійсною.
3. Змініть адресу.
4. Коли трафік переміститься, збільште TTL назад до 3600 або більше, оскільки за низького TTL кожен resolver набагато частіше надсилає запити до ваших nameserver.

Щоб очистити дані, які зберігає ваша власна машина:

resolvectl flush-caches
resolvectl statistics

resolvectl statistics виводить секцію кешу з лічильниками влучань і промахів, тому одразу після очищення наступний запит буде показано як промах. Браузери мають окремий кеш, тому Chrome може використовувати стару відповідь навіть після очищення системного кешу. Очистіть кеш браузера в chrome://net-internals/#dns. Також перевірте /etc/hosts, оскільки залишковий рядок у цьому файлі має пріоритет над DNS на цій машині — і лише на ній. getent hosts example.com показує відповідь, яку насправді використовуватиме система, включно з /etc/hosts.

Wildcard-сертифікати підтверджуються записом TXT

Центр сертифікації (CA) перевіряє контроль над іменем, перш ніж видати сертифікат. Під час перевірки HTTP-01 файл передається через порт 80 для точно вказаного імені хоста. Це добре працює для одного імені. Wildcard-сертифікат охоплює *.example.com — необмежену множину імен хостів, з яких CA не може отримати файл. Тому Let’s Encrypt видає wildcard-сертифікати лише через перевірку DNS-01. Ви публікуєте запис TXT у _acme-challenge.example.com, що містить токен, наданий CA. Контроль над зоною є підтвердженням.

Тому ваш DNS-хост бере участь у поновленні сертифіката. Під час кожного поновлення Certbot має самостійно створювати та видаляти цей запис TXT. Для цього йому потрібні API і відповідний плагін вашого провайдера. Якщо перевірка не проходить, зазвичай з’являється повідомлення DNS problem: NXDOMAIN looking up TXT for _acme-challenge.example.com. Це означає, що CA виконав перевірку до того, як запис став видимим: його або не збережено, або негативну відповідь ще повертав кеш. Повна процедура описана в посібнику з wildcard-сертифікатів і перевірки DNS-01.

Коли VPN перехоплює ваш resolver

VPN-клієнт зазвичай замінює системний resolver, поки встановлено VPN-з’єднання, оскільки надсилання DNS-запитів до локальної мережі повідомило б цій мережі назву кожного відвіданого вами сайту. Це правильна поведінка, але вона може спричинити дві проблеми.

Якщо тунель встановлюється, а імена перестають визначатися, тоді як IP-адреси працюють, встановлений клієнтом resolver недоступний зсередини тунелю. ping 1.1.1.1 завершується успішно, а curl https://example.com повертає curl: (6) Could not resolve host: example.com. Якщо ж тунель встановлюється, але запити й далі надсилаються до мережі, до якої ви підключені, ваш трафік проходить через тунель, тоді як локальний resolver продовжує бачити кожне запитуване вами ім’я.

resolvectl status

Ця команда виводить resolver, який використовується для кожного з’єднання, щоб ви могли перевірити, який resolver встановив тунель і чи є він потрібним. Тунель WireGuard налаштовує це значення з рядка DNS = у конфігурації клієнта. Докладні відомості про випадки з systemd-resolved і resolvconf наведено в матеріалі як виправити DNS, коли WireGuard перехоплює resolver.

Коди відповіді та що означає кожен із них

• NXDOMAIN: авторитетний сервер повідомляє, що ім’я не існує. Перевірте написання, переконайтеся, що суфікс домену не продубльовано, і перевірте, чи редагували ви ту зону, на яку вказує делегування.
• NOERROR з порожнім ANSWER SECTION: ім’я існує, але запису запитаного типу немає. Запит AAAA, коли існує лише A, дає саме такий результат.
• SERVFAIL: резолвер виконав спробу, але не зміг сформувати відповідь. Дві найпоширеніші причини — авторитетні сервери не відповідають або не пройшла перевірка DNSSEC (domain name system security extensions). Виконайте перевірку за допомогою dig @1.1.1.1 example.com A +cd, яка вимикає валідацію. Відповідь із +cd і SERVFAIL без цього параметра означає, що проблема в підписах. Таке трапляється після перенесення nameserver, коли батьківська зона все ще публікує старий запис DS (delegation signer).
• REFUSED: сервер, до якого ви звернулися, не відповідає на цей запит. Зазвичай це означає, що ви вказали dig на авторитетний сервер домену, який він не обслуговує.
• ;; connection timed out; no servers could be reached: dig не зміг дістатися резолвера. Це проблема мережі або резолвера на вашому боці, тому домен тут ні до чого.

ping: example.com: Temporary failure in name resolution — це той самий клас помилки, але його повідомляє glibc, а не dig.

Чи варто запускати nameserver на власному VPS?

Це можливо. bind9, knot або nsd обслуговуватиме вашу зону на сервері, і це дасть більше знань про DNS, ніж будь-яка панель керування. Але є практичні ризики. Для домену потрібно мати щонайменше два nameserver у різних мережах, тому один VPS стає єдиною точкою відмови для всіх сервісів домену, зокрема пошти. Для nameserver, назви яких належать до домену, що вони обслуговують, у реєстратора потрібні glue records. Це адреса ns1.example.com, збережена в батьківській зоні, оскільки інакше резолвер не зможе розпочати пошук. Якщо резолвер не може зв’язатися з вашим nameserver, він не переходить до вашого вебсайту: для цього користувача весь домен стає недоступним. Для більшості користувачів безпечнішим варіантом є керований DNS із API. Запуск caching resolver на VPS для власних машин — це інше завдання і значно менше зобов’язань.

FAQ

Чому моя зміна DNS ще не поширилася?

Нічого не «поширюється». Авторитетні сервери імен зберігають нове значення одразу після його збереження, а кожен резолвер, який уже надсилав запит, зберігає кешовану копію, доки не завершиться отриманий ним TTL. Безпосередньо запитайте авторитетний сервер за допомогою dig @ns1.your-dns-host.net example.com A +short. Якщо він повертає нову адресу, зміна вже активна, а затримка пов’язана лише з кешуванням. Якщо ви змінили сервери імен, а не записи, очікуйте значно довшої затримки, оскільки делегування TLD передається з TTL у два дні.

Як визначити, які сервери імен фактично використовує мій домен?

dig example.com NS +short виводить сервери імен, які зараз відповідають для домену, а dig +trace example.com показує ланцюжок делегування від root, зокрема делегування, яке передають сервери TLD. Якщо ці імена не належать провайдеру, у панелі якого ви редагували записи, саме це є причиною проблеми. Відредагуйте записи у провайдера, указаного в делегуванні, або змініть делегування у реєстратора, щоб воно вказувало на потрібні сервери.

Домен резолвиться, але сайт не завантажується. Що робити?

DNS налаштовано, щойно dig example.com A +short повертає адресу вашого сервера. Після цього проблему потрібно шукати в підключенні. Якщо curl -I http://example.com повертає Connection refused, це означає, що на цьому порту нічого не прослуховується. Якщо запит зависає до завершення тайм-ауту, пакет заблоковано firewall. Перевірте, що вебсервер запущений і прослуховує публічну адресу. Потім перевірте firewall на сервері та окремий мережевий firewall у панелі керування провайдера.

Чому я не можу додати CNAME для root-домену?

CNAME вказує, що ім’я є псевдонімом іншого імені, а ім’я з CNAME не може містити жодного іншого запису. Root-домен повинен містити записи SOA і NS, щоб існувати як зона, тому він не може одночасно бути CNAME. Використайте запис A, який містить адресу для root-домену, або функцію провайдера під назвою ALIAS, ANAME чи CNAME flattening. Вона зберігає ім’я та відповідає на запити адресою, на яку це ім’я наразі резолвиться.