DNS‑записи з підстановкою: зручність, що тихо ламає речі (і як це виправити)

Що насправді робить DNS‑підстановка (і чого не робить)

Запис‑підстановка — це DNS‑запис, чиє ім’я власника починається з *., наприклад *.example.com. Це не «збігається з усім де завгодно».
Це «збігається з одним лейблом у цій точці дерева, коли немає більш конкретного запису».

Оперативне визначення

Якщо резолвер питає foo.example.com і зона не має запису для foo.example.com, але має підстановку
*.example.com, то підстановка може відповісти.

Якщо зона явно має foo.example.com (навіть як пустий non‑terminal у деяких випадках), підстановка її не перекриває.
Підстановки — це «останній засіб», а не «перекриття».

Чого вона не робитиме

• Вона не зможе збігатися через декілька лейблів. *.example.com не відповідає a.b.example.com. Для цього потрібна
  *.b.example.com (і тоді ви вже керуєте таксономією жалю).
• Вона не створює делегацію DNS. Якщо ви делегуєте dev.example.com іншій зоні, підстановка в example.com
  не діє всередині дочірньої зони.
• Вона не «виправляє» відсутні сервіси. Вона лише робить неіснуючі імена резольвними. Ваш стек TCP все одно доставить погані новини.

Зручність реальна

Підстановки відмінно підходять для:

• Ефемерних середовищ з невідомими іменами наперед (preview apps, per-branch deployments).
• Маршрутизації для багатокористувацьких систем, де додаток читає заголовок Host і вибирає орендаря.
• CDN‑входів, де origin не цікавиться конкретними іменами хостів.
• Catch‑all UX («якщо ви описали, ми все одно посадимо вас десь корисному»).

Але компроміс тонкий: підстановки роблять DNS не джерелом істини про те, що існує. Це нормально, якщо у вас є інші запобіжні засоби.
Без них настає довга ніч.

Цікаві факти та історичний контекст

Кілька коротких, конкретних моментів, які мають значення на практиці:

1. Правила зіставлення підстановок були стандартизовані рано й уточнювалися з часом; RFC 1034 описував підстановки концептуально, а пізніші RFC
   прояснили крайові випадки навколо пустих non‑terminal та негативних відповідей.
2. DNS‑підстановки існували задовго до вебу. Вони були корисні для загального найменування та маршрутизації пошти ще до того, як «піддомени для всього» стали нормою.
3. «NXDOMAIN» — це сильний сигнал у DNS: він означає, що ім’я не існує. Підстановки навмисне зменшують кількість NXDOMAIN, що змінює кешування та виявлення помилок.
4. Негативне кешування (RFC 2308) означає, що NXDOMAIN може кешуватися. Підстановки зменшують NXDOMAIN, тож помилки та сканування можуть породити багато «валідних»
   відповідей — іноді навантажуючи ваш край.
5. DNSSEC додає нюанс: доведення відсутності використовує NSEC/NSEC3 записи. Підстановки взаємодіють з доказами «closest encloser»; невірні налаштування
   можуть створювати проблеми валідації, які проявляються лише для «випадкових» імен.
6. Автоматизація сертифікатів змінила ставки. ACME DNS‑01 челенджі зробили wildcard‑сертифікати простішими, що заохотило одночасне використання wildcard DNS і
   wildcard‑сертифікатів — іноді надто недбало.
7. Деякі провайдери реалізують «alias»/«flattening» на апексі як нестандартне розширення. Змішування цього з підстановками може давати сюрпризи,
   бо це не класичні DNS‑записи.
8. Режими «proxied» у CDN часто завершують TLS і відповідають HTTP для будь‑якого хоста, на який ви вказали. Поєднайте це з підстановками — і ви можете
   випадково «публікувати» імена, які не мали бути опубліковані.

Чому використовують підстановки (і коли це доречно)

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

LEGITIMATE use cases

Надійні випадки виглядають так:

• Preview середовища: pr-1847.preview.example.com з’являється й зникає на вимогу. DNS не повинен вимагати тикетів.
• Маршрутизація орендарів: tenant-a.app.example.com, tenant-b.app.example.com — всі потрапляють на один і той же інгрест, а
  ваш додаток маршрутизує за hostname.
• Service mesh / gateway абстракція: Усе йде через API‑gateway, який знає, що робити. DNS — лише вхідний покажчик.
• Досвід розробника: Люди часто вводять дивні речі. Підстановки знижують тертя, коли система спроєктована приймати це безпечно.

Погані мотиви під виглядом інженерії

• «Ми не хочемо керувати DNS записами.» Звісно. Але тоді ви просто перемістили складність у відлагодження, моніторинг і рев’ю безпеки.
• «Це простіше, ніж відслідковувати інвентар.» DNS — не система інвентаризації. Якщо ви використовуєте його як інвентар, він буде вам красиво брехати.
• «Ми можемо вказати все на один load balancer і розібратися пізніше.» Ви не розберетесь пізніше. Ваш інцидент розбереться за вас.

Суха істина: якщо ви не можете пояснити, що саме має відповідати ваша підстановка, ви не готові її запускати.

Жарт №1: підстановка — це як папка «misc» — корисна, поки не стане вашою файловою системою.

Де підстановки тихо ламають систему

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

1) ACME‑челенджі і автоматизація сертифікатів

Якщо ви випускаєте сертифікати через ACME (Let’s Encrypt або внутрішній ACME), є різні типи челенджів:
HTTP-01, TLS-ALPN-01, DNS-01. DNS‑підстановки і wildcard‑сертифікати плутають людей, і тут починаються припущення.

Типова поломка: ви додаєте *.example.com, щоб вказати на новий інгрест, але _acme-challenge.example.com або
_acme-challenge.foo.example.com потребує спеціальних TXT‑записів. Якщо у вас є автоматизація, яка динамічно створює TXT, підстановка не обов’язково є прямою причиною,
але вона змінює шляхи резолюції і може виявити прогалини в делегації або split‑horizon DNS.

2) Пошта і «неочікувані поштові домени»

Підстановки прямо не керують MX‑записами для апексу зони (пошта для example.com), але вони можуть створити ілюзію, що поштові домени існують для кожного піддомену.
Деякі поштові системи трактують піддомени як окремі ідентичності і шукатимуть MX для sub.example.com.

Якщо у вас є *.example.com A 203.0.113.10 і немає явного MX для sub.example.com, поведінка залежить від реалізації: дехто
використовує fallback на A/AAAA за правилами RFC, якщо MX відсутній. Тепер ваш веб‑IP — це поштовий цільовий сервер. Це не «зламаний DNS».
Це DNS, який робить саме те, що ви попросили.

3) Трафік‑шейдування і просочування середовищ

Підстановка, що вказує на продакшен, може тихо захоплювати staging‑імена. Якщо ваша staging‑зона — split‑horizon (внутрішня проти публічної) і хтось
забуде додати запис внутрішньо, резолвер може впасти назад на публічний DNS. Тоді ваш staging‑додаток почне виклики до prod‑сервісів, бо DNS каже «так, це існує».

4) Описки резольвляться і моніторинг бреше

З підстановками описки не повертають NXDOMAIN. Вони резольвляться. Це змінює досвід користувача (іноді на краще) і моніторинг (часто на гірше). Перевірки здоров’я,
які спираються на «чи резольвиться DNS?», стають марними. Сканери безпеки, що шукають «висячі» DNS, також поводяться інакше, бо нічого не «висять», якщо
все резольвиться у щось.

5) Поведінка CDN і проксі

Якщо ваша підстановка вказує на CDN‑провайдера, який віддає сторінку за замовчуванням для невідомих хостів, ви можете випадково «опублікувати» імена,
які ніколи не мали бути публіковані. Це може збити з пантелику клієнтів, витекти внутрішні шаблони найменувань і створити заплутану поведінку сертифікатів/SNI,
якщо CDN не має сертифіката для цього хоста.

6) Делегації і часткові зони

Люди припускають, що *.example.com покриває все під example.com, потім делегують dev.example.com на інші NS.
Тепер foo.dev.example.com відповідається дочірньою зоною, а не батьківською підстановкою. Якщо дитяча зона порожня або неправильно налаштована,
ви отримаєте NXDOMAIN для «деяких» хостів, а підстановка батька все одно охоче відповідатиме для інших. Діагностика стає географічним уроком.

Збіг, пріоритети і «чому це резолвиться?»

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

Пріоритет: явне перемагає підстановку

Якщо api.example.com існує явно, воно виграє. Навіть якщо це інший тип запису. Це звучить очевидно — поки ви не усвідомите, що
ваша автоматизація могла створити явні записи, про які ви забули.

«Closest encloser» і негативні відповіді

Коли ім’я не існує, авторитетні сервери не просто знизують плечима. Вони доводять відсутність (особливо з DNSSEC) на основі найближчого існуючого
предка і правил підстановок. Тут ви отримуєте такі феномени:

• Деякі випадкові імена резольвляться через підстановку, інші повертають NXDOMAIN, бо існує ближче ім’я, яке блокує розширення підстановки.
• Резолвери кешують NXDOMAIN на період (negative caching TTL). Якщо потім ви створите явні записи, деякі клієнти продовжуватимуть зазнавати невдач, поки негативний кеш не мине.

Підстановки не замінюють потребу в інвентарі

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

Перефразована думка Джона Оллспоу: «Невдачі рідко викликані однією помилкою; вони виникають із нормальної роботи в складних системах.»
(перефразовано)

Саме так трапляються інциденти з підстановками. Ніхто не «зламав DNS». Всі робили розумні речі, які перетнулися.

Три міні‑історії з корпоративного життя

Міні‑історія №1: Інцидент через хибне припущення

Середня SaaS‑компанія тримала *.app.example.com для маршрутизації орендарів через спільний інгрест. Це добре працювало. Новим орендарям не треба було міняти DNS,
лише налаштування в додатку. Хтось запропонував поширити ту ж схему для внутрішніх інструментів: *.tools.example.com.

Хибне припущення було тонким: «підстановки безпечні, бо явні записи їх перекривають». Це правда, але неповна. Їхній internal DNS був split‑horizon:
публічна зона для зовнішніх, приватна зона для внутрішніх. Приватна зона мала деякі явні записи інструментів, але не всі, а публічна зона мала підстановку.

Під час планових робіт у датацентрі внутрішні резолвери коротко перейшли на публічні рекурсивні резолвери (неправильно налаштований forwarder).
Раптом внутрішні хости, яким бракувало приватних записів, почали резольвитися через публічну підстановку на зовнішній інгрест IP.
Запити, що мали залишатися в приватній мережі, пішли в інтернет, потрапили під WAF і отримали 403. Інцидент виглядав як збій мережі,
потім як збій додатку, потім як «чому staging викликає prod?».

Виправлення не було «видалити підстановку». Виправлення полягало в тому, щоб зробити split‑horizon надійним: закріпити internal резолвери, додати моніторинг шляхів резолвера і
забезпечити «без підстановок для tools» через явні блоки типу NXDOMAIN (про це далі) і явні внутрішні записи.

Урок: підстановки — це не лише DNS‑функція; це політика. Якщо ви не знаєте, якими резолверами фактично користуються ваші клієнти під час відмов, ваша політика — фантазія.

Міні‑історія №2: Оптимізація, що дала боком

Інша компанія мала тисячі preview‑середовищ. Управління DNS стало вузьким місцем, тому вони ввели підстановку:
*.preview.example.com, що вказувала на єдиний Anycast‑edge, який маршрутизував запити за hostname. Чудове спрощення. Їхнє IaC перестало постійно оновлювати DNS.

Потім вони оптимізували кешування: підвищили TTL підстановки до години, щоб зменшити навантаження DNS. Ефект був миттєвий і поганий.
Preview‑середовища деактивовувалися часто, а шар маршрутизації оновлював карту за секунди. Але клієнти — особливо корпоративні проксі та мобільні мережі — тримали DNS‑відповідь годину.
Тому «видалені» середовища лишалися доступні (іноді потрапляли на іншого орендаря, якщо хости перерозподілялися).

Гірше: їхня реакція на інциденти залежала від швидкого блоку конкретних preview‑hostname при зловживанні. З високим TTL підстановки вони могли заблокувати на краю,
але DNS лишався стабільним, і деякі upstream‑компоненти продовжували штовхати трафік на той самий IP з поганими hostnames. Логи були шумними, ліміти спрацьовували,
і вся система preview виглядала нестабільною.

Вони понизили TTL, але не до початково крихітного значення. Зробили сегментацію: *.preview.example.com залишився з низьким TTL, а стабільні app‑hostname отримали довші TTL.
Додали на edge denylist на рівні host, що повертає швидкий 451/404 з коротким кеш‑заголовком, щоб «мертві хости» гинули швидко, навіть коли DNS цього не робить.

Міні‑історія №3: Сумно, але правильно — практика, що врятувала

Фінансова команда мала суворий процес змін DNS. Це не було гламурно. Кожна підстановка мала власника, діаграму й тест‑план. Також була політика: у кожній зоні з підстановкою
мав бути «канарковий» hostname з явним записом, який ніколи не мав відповідати через підстановку.

Однієї ночі вони мігрували провайдера DNS. Зона передалася чисто, але новий провайдер інтерпретував апексний ALIAS плюс wildcard CNAME інакше, ніж старий.
Більшість імен резольвилися нормально, але кілька «неіснуючих» імен почали резольвитися там, де повинні були повернути NXDOMAIN.
Це той баг, що зазвичай займає дні користувацьких скарг.

Їхній моніторинг спіймав це за хвилини: канарковий hostname, який має повертати NXDOMAIN, почав повертати A‑запис. Це викликало пейдж із дуже точним повідомленням:
«Змінився обсяг дії підстановки». На виклику порівняли авторитетні відповіді старих і нових NS, знайшли відмінність у розширенні підстановки і виправили зону до ранку.

Без геройств. Просто нудна правильність: канарки, явні очікування і тести, що перевіряли відсутність записів, а не лише їх наявність.

Швидкий план діагностики

Коли починаються проблеми, пов’язані з підстановками, найшвидший шлях — припинити припущення й встановити три факти:
(1) який nameserver є авторитетним, (2) що саме він повертає, і (3) що кешує клієнт.

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

• Виконуйте запити безпосередньо до авторитетних nameserver‑ів. Якщо не можете — ви дебагуєте чутку.
• Запитуйте з «чистого» резолвера (або використовуйте +norecurse), щоб уникнути сховування змін рекурсивним кешем.

По‑друге: визначте шлях зіставлення і межі делегації

• Підіймайтесь по лейблах: чи делеговано dev.example.com кудись? Чи перетинаєте ви зони?
• Перевірте, чи існує явний запис, що блокує підстановку (включно з несподіваними записами, створеними автоматизацією).

По‑третє: ідентифікуйте, що саме зламалося (DNS vs маршрутизація vs TLS)

• Якщо DNS повертає IP, але HTTP падає, можливо, DNS‑підстановка «працює», але немає відповідного віртуального хоста, SNI‑сертифіката або маршруту в ingress.
• Якщо деякі клієнти працюють, а інші ні, підозрівайте TTL і негативне кешування.
• Якщо внутрішні клієнти поводяться інакше за зовнішніх, підозрівайте split‑horizon і відмову резолвера.

Жарт №2: DNS — єдина система, де «воно резольвиться» може означати «воно швидше неправе».

Практичні завдання: команди, результати та рішення (12+)

Це виконувані завдання, які можна робити під час проєктування, перевірки змін або інциденту. Кожне включає, що означає вивід і яке рішення прийняти.
Замініть example.com і IP nameserver‑ів за потреби.

Завдання 1: Подивіться, що підстановка повертає з вашого дефолтного резолвера

cr0x@server:~$ dig +short totallymadeup-12345.example.com A
203.0.113.10

Що це означає: Ім’я резольвиться у A‑запис, ймовірно через підстановку (або catch‑all у провайдера).

Рішення: Якщо ви очікуєте NXDOMAIN для невідомих хостів, потрібно видалити/звузити підстановку або заблокувати через явні записи.

Завдання 2: Доведіть, чи відповідь походить від підстановки (запит до авторитетного)

cr0x@server:~$ dig @ns1.example.net totallymadeup-12345.example.com A +noall +answer +authority
totallymadeup-12345.example.com. 300 IN A 203.0.113.10
example.com. 300 IN NS ns1.example.net.
example.com. 300 IN NS ns2.example.net.

Що це означає: Авторитетний сервер повертає A‑запис для імені, яке ймовірно не існує явно.

Рішення: Перевірте зону на наявність підстановки на найближчому рівні (часто *.example.com).

Завдання 3: Перевірте явні записи, що мають перекривати підстановку

cr0x@server:~$ dig @ns1.example.net api.example.com ANY +noall +answer
api.example.com. 300 IN A 203.0.113.20

Що це означає: Існує явний A‑запис для api.example.com; підстановка не має на нього впливати.

Рішення: Якщо api.example.com резольвиться неправильно для деяких клієнтів, підозрюйте кеш або split‑horizon, а не пріоритет підстановки.

Завдання 4: Визначте межі делегації з +trace

cr0x@server:~$ dig +trace foo.dev.example.com A
; <<>> DiG 9.18.24 <<>> +trace foo.dev.example.com A
.                       518400  IN      NS      a.root-servers.net.
...
example.com.            172800  IN      NS      ns1.example.net.
dev.example.com.        3600    IN      NS      ns-dev1.example.net.
foo.dev.example.com.    300     IN      A       198.51.100.44

Що це означає: dev.example.com делеговано окремим nameserver‑ам; батьківські підстановки не діють всередині.

Рішення: Виправляйте записи в дочірній зоні, якщо поведінка відрізняється всередині піддерева; не ганяйтесь за батьківською підстановкою.

Завдання 5: Підтвердіть, що підстановка не збігається з кількома лейблами

cr0x@server:~$ dig +short a.b.example.com A
203.0.113.10

Що це означає: Якщо це резольвиться, то не через *.example.com поодинці; або існує *.b.example.com, або b.example.com
делеговано/обробляється інакше.

Рішення: Пошукайте глибшу підстановку або поведінку «catch‑all» у провайдера; промапте піддерево.

Завдання 6: Перевірте TXT для ACME DNS‑01 челенджів

cr0x@server:~$ dig _acme-challenge.example.com TXT +noall +answer
_acme-challenge.example.com. 60 IN TXT "mM9vXkZlKfZy0Q2nq3...redacted..."

Що це означає: Існує TXT‑запис для DNS‑01 валідації.

Рішення: Якщо випуск не вдається, перевірте, що ви запитуєте правильну авторитетну зону і що TTL узгоджується з таймінгами ACME‑клієнта.

Завдання 7: Перевірте CNAME‑ланцюги, що можуть збити валідацію або маршрутизацію

cr0x@server:~$ dig www.example.com CNAME +noall +answer
www.example.com. 300 IN CNAME example.com.

Що це означає: www — це псевдонім; підстановка *.example.com не допоможе, якщо ви хотіли іншу поведінку для www.

Рішення: Вирішіть, чи потрібно мати явні записи для важливих hostname (рекомендовано) замість спиратися на підстановку.

Завдання 8: Підтвердіть, чи ім’я має бути NXDOMAIN (і чи є ним)

cr0x@server:~$ dig nosuchhost.example.com A +noall +answer +comments
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51142
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

nosuchhost.example.com. 300 IN A 203.0.113.10

Що це означає: Статус NOERROR з A‑записом; це не NXDOMAIN. Підстановка (або явний запис) відповідає.

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

Завдання 9: Перевірте негативний TTL кешування (SOA) для поведінки NXDOMAIN

cr0x@server:~$ dig example.com SOA +noall +answer
example.com. 300 IN SOA ns1.example.net. hostmaster.example.com. 2025123101 7200 3600 1209600 300

Що це означає: Останнє поле SOA (тут 300) часто використовується як negative caching TTL (залежить від сервера/конфігу).

Рішення: Якщо ви покладаєтеся на швидке поширення нових записів після NXDOMAIN, тримайте negative TTL невеликим. Якщо покладаєтеся на стабільність — підвищуйте обережно.

Завдання 10: Виявіть різниці split‑horizon (internal vs external)

cr0x@server:~$ dig @10.0.0.53 api.example.com A +short
10.20.30.40

cr0x@server:~$ dig @1.1.1.1 api.example.com A +short
203.0.113.20

Що це означає: Internal DNS повертає приватний IP, публічний резолвер — публічний IP. Це свідомий split‑horizon.

Рішення: Якщо клієнти іноді отримують публічну відповідь внутрішньо, виправте конфігурацію резолвера і правила egress DNS; не «заклеюйте» це додатковими підстановками.

Завдання 11: Перевірте SNI/розбіжність сертифіката, спричинену wildcard DNS до спільного edge

cr0x@server:~$ openssl s_client -connect 203.0.113.10:443 -servername typoedhost.example.com -brief
depth=0 CN = default.edge.example.net
verify error:num=62:Hostname mismatch
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384

Що це означає: DNS резольвиться, TCP з’єднання встановлене, TLS домовлено, але сертифікат не відповідає хосту. Класичний випадок wildcard DNS до спільного edge без покриття сертифікатами.

Рішення: Зупинити резолюцію невідомих hostname, забезпечити видачу сертифікатів або налаштувати edge, щоб відкидати невідомі SNI з чіткою відповіддю.

Завдання 12: Виявити несподіване розширення підстановки, порівнявши два авторитетні сервери

cr0x@server:~$ dig @ns1.example.net weirdname.example.com A +short
203.0.113.10

cr0x@server:~$ dig @ns2.example.net weirdname.example.com A +short
198.51.100.77

Що це означає: Авторитетні сервери не погоджуються. Це або лаг реплікації, або split brain, або різний вміст зони. З підстановками розбіжність може ховатися, поки не запитають випадкове ім’я.

Рішення: Заморозьте зміни, перевірте serial зони і впевніться, що обидва авторитети подають однакові записи перед продовженням rollout‑у.

Завдання 13: Підтвердіть serial зони та поширення (порівняння SOA)

cr0x@server:~$ dig @ns1.example.net example.com SOA +noall +answer
example.com. 300 IN SOA ns1.example.net. hostmaster.example.com. 2025123101 7200 3600 1209600 300

cr0x@server:~$ dig @ns2.example.net example.com SOA +noall +answer
example.com. 300 IN SOA ns1.example.net. hostmaster.example.com. 2025123100 7200 3600 1209600 300

Що це означає: Розбіжність serial вказує на затримку реплікації або невдалий zone transfer/publish.

Рішення: Усуньте проблеми з поширенням, перш ніж дебагувати верхні шари. Зміна підстановки на одному сервері для клієнтів неможлива для розрізнення від хаосу.

Завдання 14: Підтвердіть конфлікт типів записів (CNAME vs інші)

cr0x@server:~$ dig @ns1.example.net foo.example.com CNAME +noall +answer
foo.example.com. 300 IN CNAME edge.example.net.

cr0x@server:~$ dig @ns1.example.net foo.example.com A +noall +answer
foo.example.com. 300 IN A 203.0.113.55

Що це означає: Якщо у вашому UI провайдера одночасно видно CNAME і A для одного й того ж імені, щось не так; стандарти цього не дозволяють.
Деякі провайдери маскують це через «flattening», але це може зламати резолвери або інструменти.

Рішення: Нормалізуйте набір записів: оберіть CNAME або A/AAAA. Уникайте хитрих провайдерських комбінацій там, де задіяні підстановки.

Завдання 15: Впіймайте ефекти підстановки на сервісне відкриття, тестуючи випадкові лейбли

cr0x@server:~$ for i in 1 2 3 4 5; do host "rand-$RANDOM.example.com"; done
rand-21483.example.com has address 203.0.113.10
rand-1207.example.com has address 203.0.113.10
rand-30061.example.com has address 203.0.113.10
rand-9229.example.com has address 203.0.113.10
rand-18022.example.com has address 203.0.113.10

Що це означає: Випадкові лейбли послідовно резольвяться. Ви фактично зробили «існування» марним на цьому рівні.

Рішення: Вирішіть, чи ваш моніторинг, інвентар і контролі безпеки припускають NXDOMAIN. Якщо так — адаптуйте їх або звузьте область підстановки.

Поширені помилки: симптоми → корінь → виправлення

Помилка 1: «Кожен піддомен резольвиться, отже все розгорнуто»

Симптоми: Нове середовище виглядає «up» у дашбордах, що лише перевіряють DNS; користувачі отримують 404/502/TLS помилки.

Корінь: Wildcard DNS відповідає за імена без відповідних маршрутів ingress, віртуальних хостів або сертифікатів.

Виправлення: Припиніть використовувати «DNS резолюється» як готовність. Додайте HTTP/TLS‑перевірки для конкретного hostname і вимагайте явної конфігурації маршруту. Розгляньте повернення NXDOMAIN для невідомих хостів.

Помилка 2: ACME‑видача «рандомно» падає для деяких імен

Симптоми: Деякі продовження сертифікатів вдаються, інші тайм‑аутяться або валідуються неправильними TXT.

Корінь: Запитано неправильну авторитетну зону через делегацію, split‑horizon або застарілі TXT у кеші; припущення щодо підстановки заплутують місце розміщення запису.

Виправлення: Трасуйте делегацію, запитуйте авторитетні nameserver‑и напряму і впевніться, що TXT створено у правильній зоні з адекватним TTL. Відокремте обробку _acme-challenge від загальної автоматизації підстановок.

Помилка 3: Пошта йде на веб‑сервер

Симптоми: Пошта для tenant.example.com потрапляє на веб‑інгрест IP; сканери спаму б’ють на сполох; SMTP‑помилки на краю.

Корінь: Немає MX для піддомену; відправник використовує fallback на A/AAAA; підстановка надає A/AAAA, роблячи веб‑IP фактичним поштовим ретейном.

Виправлення: Явно публікуйте MX для піддоменів, що мають приймати пошту, або опублікуйте null MX (MX 0 .) там, де пошти не повинно бути. Не дозволяйте wildcard A стати випадковою поштовою адресою.

Помилка 4: Staging просочується в прод під час відмови резолвера

Симптоми: Внутрішні додатки раптово влучають у публічні IP; WAF блокує внутрішній трафік; збільшується латентність через hairpinning.

Корінь: Split‑horizon DNS не забезпечений; internal резолвери падають на публічну рекурсію; публічна підстановка захоплює internal‑імена.

Виправлення: Заблокуйте конфігурацію резолверів, моніторте досяжність резолверів і впевніться, що внутрішні імена існують явно у внутрішньому DNS (або є явними NXDOMAIN). Додайте egress‑правила, що перешкоджають internal мережам користуватись публічними резолверами.

Помилка 5: «Ми підняли TTL, щоб зменшити навантаження» і стало дивно

Симптоми: Видалені середовища залишаються доступними; трафік іде не на той бекенд після redeploy; інциденти тривають після rollback.

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

Виправлення: Тримайте TTL підстановок низьким, якщо бекенди часто змінюються. Довгі TTL — лише для стабільних імен. Додайте контролі на edge, щоб відкидати невідомі hostnames швидко.

Помилка 6: DNSSEC валідація ламається лише для деяких імен

Симптоми: Деякі резолвери падають з SERVFAIL; інші працюють; відмови корелюють з «випадковими» іменами.

Корінь: Докази відсутності (NSEC/NSEC3) і поведінка підстановок неправильно налаштовані; авторитетний сервер повертає відповіді, які для певних запитів не валідні.

Виправлення: Перевіряйте DNSSEC авторитетними інструментами, впевніться в коректному підписанні і тестуйте випадкові і явні імена. Розглядайте зони з підстановками як підвищений ризик для DNSSEC‑крайових випадків.

Чеклісти / поетапний план

Чекліст: чи варто тут використовувати підстановку?

1. Визначте намір: На якій глибині лейбла працює підстановка (один лейбл)? Яка очікувана поведінка для описок?
2. Вирішіть політику NXDOMAIN: Ви хочете, щоб «невідоме ім’я падало» чи «невідоме ім’я маршрутизувалося на дефолт»?
3. Перерахуйте критичні hostnames: api, www, mail, _acme-challenge, адмін‑консолі. Зробіть їх явними.
4. План TLS: Чи буде edge мати сертифікати, що покривають кожен обслуговуваний hostname? Якщо ні, відкидайте невідомий SNI/Host рано й голосно.
5. Політика пошти: Для піддоменів публікуйте явні MX (включно з null MX), щоб wildcard A/AAAA не став поштовим ексченжером.
6. Перевірка split‑horizon: Якщо у вас є internal DNS, підтвердіть, що internal клієнти не можуть випадково використовувати публічну рекурсію.
7. План моніторингу: Додайте канарки «має бути NXDOMAIN» і «має резольвитися».
8. План відкату: Знайте, що зламає видалення підстановки (зазвичай preview apps і tenant routing). Документуйте це.

Покроково: як безпечно розгорнути підстановку

1. Спочатку створіть явні записи для критичних імен. Не дозволяйте підстановці визначати api, www, mail або префікси валідації.
2. Оберіть консервативний TTL. Якщо бекенд часто змінюється — починайте з 60–300 секунд.
3. Тестуйте авторитетні відповіді. Запитуйте кожен авторитетний nameserver напряму для: відомих hostname, відсутніх hostname, випадкових імен і ACME TXT.
4. Тестуйте з кількох точок бачення резолверів. Internal резолвер, публічний резолвер і «чистий» VM/мережа.
5. Реалізуйте поведінку на edge для невідомих hostname. Вирішіть: 404, 410, 451 або редирект. Не віддавайте дефолтну «it works» сторінку, якщо ви цього не маєте на увазі.
6. Додайте канаркові тести. Один hostname має обов’язково резольвитися через підстановку, один має повертати NXDOMAIN, один має резольвитися у явну ціль.
7. Слідкуйте за логами щодо описок і сканів. Підстановки можуть перетворити фоновий шум на реальне навантаження бекенду. Додайте rate limit.
8. Документуйте область дії. Люди забувають. Інциденти не забувають.

Покроково: як видалити або звузити підстановку без руйнування

1. Зробіть інвентар тих, хто викликає. Проаналізуйте логи краю: які hostname фактично використовуються?
2. Створіть явні записи для активного набору. Перекладіть з implicit wildcard на явні записи де можливо.
3. Впровадьте нову, вужчу підстановку. Наприклад, замініть *.example.com на *.preview.example.com.
4. Скоротіть TTL перед зміною. Зробіть це принаймні за одне вікно TTL до cutover, щоб кеші спорожніли.
5. Реалізуйте відповідь «невідомий хост» на edge. Це страховка під час переходу.
6. Видаліть підстановку і моніторьте рівень NXDOMAIN. Спайк очікуваний; стійкий спайк може вказувати на відсутні явні записи.

FAQ

1) Чи відповідає *.example.com на example.com?

Ні. Апекс example.com не покривається *.example.com. Потрібні явні записи на апексі.

2) Чи відповідає *.example.com на a.b.example.com?

Саме по собі — ні. Воно відповідає одному лейблу: anything.example.com. Якщо a.b.example.com резольвиться, щось інше дає ту відповідь.

3) Якщо в мене є явний запис для foo.example.com, чи може підстановка його перекрити?

Ні. Явне перемагає підстановку. Якщо ви бачите інше — ймовірно, має місце split‑horizon DNS, кілька зон або невідповідність у поширенні.

4) Чи ті самі wildcard DNS записи і wildcard сертифікати?

Це різні шари. Wildcard DNS робить імена резольвними. Wildcard‑сертифікати роблять TLS валідним для багатьох hostname. Ви можете використовувати одне без іншого,
але wildcard DNS без покриття TLS — поширена причина помилок hostname mismatch.

5) Чому підстановки ускладнюють відлагодження?

Бо відсутність перестає бути помітною. NXDOMAIN корисний: він каже, що ім’я відсутнє. З підстановкою все «існує» в DNS, тож треба відлагоджувати на рівні HTTP маршрутизації, TLS SNI і логіки додатку.

6) Чи можуть підстановки збільшити навантаження або вартість?

Так. Описки, сканування та випадкові піддомени перетворюються на реальний трафік до вашого краю. Якщо edge форвардить невідомі hostnames upstream, ви можете підсилити шум у бекенди.
Додавайте rate limit і відкидання невідомих хостів рано.

7) Як не допустити, щоб пошта використовувала wildcard A/AAAA для піддоменів?

Публікуйте явні MX для піддоменів, що повинні приймати пошту. Для піддоменів, де пошти не повинно бути, публікуйте null MX (MX 0 .), щоб сигналізувати «пошти тут немає».
Це запобіжить fallback на A/AAAA у багатьох реалізаціях.

8) Який TTL використовувати для wildcard‑запису?

Якщо ціль змінюється або маршрутизація динамічна, тримайте TTL низьким (60–300 секунд загалом). Якщо ціль стабільна і ви протестували rollback, можна підвищити.
Не підвищуйте TTL з метою «оптимізації», не розуміючи, наскільки швидко вам потрібні зміни.

9) Чи можу я «заблокувати» підстановку для конкретного hostname?

Ви можете перекрити її явними записами. Щоб змусити поведінку «не існує» для певного імені, може знадобитися трюк із дизайном зони або функції провайдера; класичний DNS не дозволяє опублікувати «NXDOMAIN як запис».

10) Чи безпечні підстановки з DNSSEC?

Можуть бути безпечними, але тестуйте ретельно. DNSSEC додає вимоги для валідації відсутності та розширення підстановок. Неправильні налаштування можуть спричиняти резолвер‑специфічні відмови, що виглядають як інтермітентні.

Висновок: конкретні наступні кроки

DNS‑підстановки не є за своєю суттю злими. Вони потужні. Саме ця потужність робить їх небезпечними: вони змінюють семантику «існування», приховують описки
і зміщують режими відмов з DNS у TLS, маршрутизацію та логіку додатку.

Практичні наступні кроки:

1. Аудитуйте ваші зони на предмет підстановок на верхньому рівні. Якщо у вас є *.example.com, припустіть, що це впливає на все, що ви забули.
2. Створіть явні записи для критичних імен (API, логін, пошта, адмін, префікси для валідації), щоб підстановка не «допомагала» їм відповідати.
3. Додайте дві канарки: один hostname, що має резольвитися через підстановку, і один, що має бути NXDOMAIN. Настройте алерти на зміни.
4. Перевірте split‑horizon запитами напряму до internal і public резолверів. Якщо internal клієнти можуть дістатися до публічного DNS — виправляйте це першим.
5. Змушуйте edge відкидати невідомі hostnames швидко і чітко. Якщо ви віддаєте сторінку за замовчуванням — робіть це свідомо і моніторьте наслідки.

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