Що таке glue-записи DNS і коли вони потрібні
Що таке glue-запис?
Glue-запис — це IP-адреса неймсервера, опублікована не у вашій власній зоні, а на рівень вище — у батьківській зоні, в реєстрі, через вашого реєстратора. Він існує, щоб розірвати циклічну залежність.
Візьмімо example.com із неймсерверами ns1.example.com і ns2.example.com. Резолвер, якому потрібно знайти www.example.com, спершу запитує сервери .com, хто авторитетний за example.com. Відповідь: «ns1.example.com і ns2.example.com». Щоб про щось запитати ці сервери, резолверу потрібні їхні IP-адреси — але A-записи для ns1.example.com лежать усередині example.com, на тих самих серверах, які він намагається знайти. Без сторонньої допомоги пошук ніколи не зможе початися.
Glue-запис і є цією допомогою: разом із NS-записами сервери .com віддають IP-адреси ns1 і ns2 у секції additional відповіді. Резолвер використовує їх, досягає неймсерверів — і зона працює.
Побачити glue у справжньому делегуванні можна, запитавши сервер TLD про ваш власний домен (справжній example.com делеговано на зовнішні неймсервери, тому для нього glue не буде):
dig NS yourdomain.com @a.gtld-servers.netСекція authority перелічує імена NS; секція additional — їхні glue-адреси. Якщо ім'я неймсервера лежить усередині зони, а в секції additional для нього нічого немає, glue відсутній.
Коли glue-записи обов'язкові
Glue потрібен рівно тоді, коли хостнейм неймсервера лежить усередині зони, яку він обслуговує, — фахівці з DNS називають такий неймсервер in-bailiwick.
Потрібен: example.com делеговано на ns1.example.com і ns2.example.com. Обидва імена лежать під example.com, тож обом потрібен glue.
Не потрібен: example.com делеговано на ns1.hosting-provider.net і ns2.hosting-provider.net. Резолвер знаходить ці адреси через делегування hosting-provider.net у зоні .net; реєстратору example.com нічого додавати. Це щоденний випадок, коли ви користуєтеся стандартними неймсерверами свого DNS-провайдера.
Змішаний випадок: example.com делеговано на ns1.example.com і ns3.seconddns.com — одне in-bailiwick ім'я, якому glue потрібен, і одне зовнішнє, якому ні. Це типова конфігурація, коли ваш власний сервер є первинним, а хостований вторинний сервер відповідає під власним хостнеймом.
Правило застосовується до кожного імені неймсервера окремо, а не до зони загалом: перевірте кожен NS-запис і запитайте себе, чи лежить це ім'я всередині зони, яку делегують.
Де зберігаються glue-записи
Glue — це не запис, який ви додаєте до власного файлу зони. Він належить батьківській зоні — реєстру TLD, — і єдиний спосіб помістити його туди — через вашого реєстратора, бо саме реєстратор спілкується з реєстром від вашого імені.
Кожен реєстратор виводить цю функцію десь у налаштуваннях домену, під назвами, що дуже різняться:
- «Register a nameserver» / «Register host» - «Child nameservers» / «Child hosts» - «Host records» / «Glue records» - «Private nameservers» / «Custom nameservers»
Як би вона не називалася, форма запитує дві речі: хостнейм неймсервера (ns1.example.com) і його IP-адресу (IPv4, а також IPv6, якщо вона у вас є). Після надсилання реєстр публікує glue у зоні TLD; відтоді сервери .com відповідають із ним.
Звідси два наслідки. Glue — це копія адреси вашого неймсервера, яку підтримують вручну у реєстратора: якщо IP сервера змінюється, glue сам по собі не змінюється. А запис у вашій власній зоні (A-запис для ns1.example.com) усе одно має існувати і збігатися: резолвери використовують glue, щоб почати, а далі довіряють тому, що каже ваша зона.
Що ламається без glue
Відсутній glue. Делегування вказує на ns1.example.com, але в реєстрі немає адреси для нього. Резолвери не можуть дістатися неймсерверів; домен не резолвиться взагалі. Одні резолвери стараються більше за інших, тож збій часто непослідовний — «у мене працює, у клієнтів ні», — що ускладнює діагностику.
Застарілий glue. Ви перенесли сервер, оновили A-запис у зоні і забули про реєстратора. Реєстр далі віддає старий IP. Резолвери, що йдуть за glue, потрапляють на мертву адресу або, ще гірше, до того, хто тепер володіє цим IP. Оскільки більшість резолверів надовго кешує робочий неймсервер, ця поломка може проявитися через кілька днів після міграції.
Glue без відповідного A-запису. Реєстр каже, що ns1.example.com — це 192.0.2.10, а ваша зона мовчить або каже щось інше. Резолвери, які повторно перевіряють адресу всередині зони, отримують відповідь, відмінну від glue; glue не є авторитетним: щойно резолвер дізнається адресу із самої зони, він використовує її замість glue. Тож неправильний A-запис у зоні перемагає правильний glue, а відсутній лишає glue в дії. Тримайте обидва записи узгодженими.
Lame delegation. Glue правильний, адреса відповідає, але сервер насправді не обслуговує зону — типово, коли неймсервер вивели з експлуатації або зону так і не завантажили на вторинний сервер. Деякі ccTLD-реєстри перевіряють це при зміні делегування (gTLD-реєстри — ні), а інструменти моніторингу відзначають; резолвери вважають такий сервер зламаним і переходять на інші, якщо вони є.
Усі чотири випадки з боку оператора відмовляють тихо: у ваших журналах нічого не скаже «glue неправильний». Симптом завжди далі по ланцюжку — періодичні збої резолвінгу, повільні запити, затримки пошти, — тож варто перевіряти делегування явно.
Перевірка делегування та glue за допомогою dig
Простежте делегування від кореня вниз, щоб побачити, що саме віддає кожен рівень:
dig +trace www.example.com @1.1.1.1Резолвер вказано явно, бо +trace питає в нього лише кореневий набір NS, а далі проходить делегування сам; підійде будь-який резолвер, що повертає цей набір.
У виводі знайдіть крок, на якому сервери TLD відповідають за example.com: NS-записи там — це делегування. Зверніть увагу: +trace друкує лише саме делегування, без секції additional, тож glue він не показує. Щоб побачити glue, оберіть будь-який авторитетний сервер TLD і попросіть у нього набір NS напряму:
dig NS example.com @a.gtld-servers.net +norecurseСекція additional показує glue таким, яким його бачить батьківська зона; in-bailiwick неймсервер без запису там не має glue. Порівняйте з тим, що каже ваша власна зона:
dig A ns1.example.com @ns1.example.com +shortОбидві адреси мають збігатися. Нарешті, переконайтеся, що кожен перелічений неймсервер справді обслуговує зону і що всі вони згодні щодо її версії:
dig SOA example.com @ns1.example.com +short
dig SOA example.com @ns2.example.com +shortОбидва мають відповісти авторитетно з однаковим serial. REFUSED або SERVFAIL тут — це lame delegation; serial, що відстає на одному з серверів, означає, що передачі зони не встигають — див. Що таке SOA-запис DNS.
Glue-записи та вторинні неймсервери
Питання glue найчастіше постає, коли додають другий неймсервер під власним доменом. Дві конфігурації — дві різні відповіді:
Secondary під хостнеймом провайдера. Вашу зону делеговано на ns1.example.com (ваш сервер) і на власне ім'я провайдера вторинного DNS, наприклад ns3.seconddns.com. In-bailiwick тут лише ns1, тож glue потрібен лише для ns1. Коли адреси провайдера змінюються, у реєстратора нічого не змінюється.
Secondary під вашим власним хостнеймом — персональний, або vanity, неймсервер на кшталт ns2.example.com, що вказує на сервер провайдера. Тепер ns2 теж in-bailiwick, і йому потрібен glue з IP-адресою провайдера. Ви додаєте його у реєстратора так само, як ns1, і мусите підтримувати актуальним: якщо провайдер колись змінить цю адресу, glue має змінитися слідом. Також потрібен відповідний A-запис для ns2.example.com у вашій власній зоні, який далі потрапляє на вторинний сервер з кожною передачею зони.
Саме цей крок найчастіше пропускають, налаштовуючи брендовані неймсервери, і саме тому вторинний сервер, що ідеально синхронізований, усе одно не отримує запитів. Повне налаштування — хостнейм, glue, A-записи та перевірка — описано в гайді Персональні неймсервери: налаштування, glue records і підводні камені.
Поширені помилки
- Змінити A-запис, але не glue після переїзду сервера. Оновіть обидва і після цього перевірте батьківську зону за допомогою dig. - Додавати glue для out-of-bailiwick імен. Більшість реєстраторів це відхиляє; ті, що приймають, публікують дані, якими батьківська зона ніколи не скористається. Реєструйте лише імена в межах самого домену. - Glue із приватним або неправильним IP. Реєстратори майже нічого не перевіряють; одрук потрапляє в реєстр як є. Перевіряйте запитом до серверів TLD, а не лише до власного неймсервера. - Забути про IPv6. Якщо у вашого неймсервера є AAAA-запис, зареєструйте й IPv6-glue, інакше резолвери лише з IPv6 не зможуть його дістатися. - Очікувати миттєвого ефекту. Великі gTLD-реєстри публікують зміни за хвилини, а частина ccTLD перегенеровує зону щогодини або кілька разів на день — і резолвери кешують попереднє делегування аж до TTL батьківської зони — для .com це зазвичай 48 годин. Плануйте зміну IP неймсервера з перекриттям: тримайте стару адресу робочою, доки кеші не застаріють. - Glue лише для одного in-bailiwick неймсервера. Якщо ns1 має glue, а ns2 (теж in-bailiwick) — ні, зона працює лише доти, доки живий ns1, — а це зводить нанівець сенс мати два неймсервери.