DNS між офісами: зробіть імена хостів доступними скрізь (Windows + Linux)

Що ви насправді вирішуєте: «ім’я» → «маршрут» → «політика»

«Зробіть імена хостів доступними скрізь» звучить як проблема виключно DNS. Насправді це ланцюжок з трьох частин:
резольвер клієнта обирає DNS‑сервер, цей DNS‑сервер повертає відповідь (або ні), а потім ваша мережево‑безпекова
система вирішує, чи доступна отримана IP‑адреса.

Ви можете мати ідеальний DNS і все одно зазнати невдачі, бо відповідь «правильна», але марна: філіал отримує внутрішню IP,
якої немає маршруту через VPN; або отримує старий запис через відставання реплікації; або отримує «публічну»
відповідь через неправильну конфігурацію split‑horizon. І навпаки: маршрутизація може бути в порядку, але резольвер повільний,
багато секунд очікувань сумуються, і додаток витрачає свій бюджет повторних спроб.

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

Факти та коротка історія, що важливі в продакшні

• DNS старший за сучасний інтернет, який ви знаєте. RFC для DNS вийшли в 1987 році, замінивши централізовану модель HOSTS.TXT, що не масштабується.
• «Split‑horizon DNS» — це не хитрість; це шаблон. Подача різних відповідей залежно від джерела запиту — звична практика в підприємствах і CDN.
• Windows зробив DNS проблемою для всіх. Active Directory залежить від DNS (SRV‑записи) для знаходження контролерів домену, Kerberos, LDAP тощо.
• TTL — грубий інструмент. Короткі TTL зменшують застарілі дані, але збільшують обсяг запитів і підкреслюють затримки через WAN‑лінки.
• Існує негативне кешування. Якщо клієнт запитав ім’я і отримав NXDOMAIN, цей провал може бути закешований; «я виправив» може не поширитися миттєво.
• Пошукові суфікси — і продуктивність, і рушій для помилок. «ping printer01» може швидко спрацювати… або викликати низку невдалих запитів по кількох суфіксах.
• systemd-resolved змінив стандартну ментальну модель у Linux. На багатьох дистрибутивах /etc/resolv.conf — це заглушка, а реальна логіка живе за локальним прослуховувачем.
• EDNS0 і більші DNS‑пакети — нормальна справа зараз. Мережеві екрани, що «допомагають» і блокують фрагменти або великі UDP‑відповіді, можуть вибірково ламати сучасний DNS.
• DNSSEC — не те саме, що «захищений DNS». DNSSEC підтверджує автентичність; він не шифрує запити. (DoH/DoT — це історія про шифрування.)

Один вислів вартий стікера, бо DNS‑збої люблять каскадувати: «Надія — не стратегія.» — Джин Кранц.
(Коротко, і це неприємно добре підходить до «зазвичай резолюється».)

Цільова архітектура, яка не зіпсується з часом

Визначте внутрішній простір імен серйозно

Використовуйте домен, яким ви володієте. Якщо у вас вже є Active Directory, зазвичай це ваш AD DNS‑домен, і ви маєте
розглядати його як внутрішній авторитет імен. Якщо AD немає, вам все одно потрібна внутрішня зона з чітким власником.
Епоха «просто використовуйте .local» має залишитися в 2006 році.

Розв’язання імен між офісами стає простим, коли ваші внутрішні імена:

• Авторитетні в одному місці (або на наборі синхронізованих авторитетних серверів)
• Доступні з усіх офісів (безпосередньо або через форвардинг)
• Узгоджені з маршрутизацією (відповіді досяжні з місця запиту)

Оберіть підхід і дотримуйтеся його

Ось підходи, що працюють у реальному світі. Оберіть один залежно від розміру та обмежень:

1. AD‑інтегрований DNS повсюди (рекомендовано, якщо у вас є AD).
   Розмістіть щонайменше один контролер домену з DNS у кожному офісі, використовуйте реплікацію AD і тримайте клієнтів направленими на локальний DNS.
   Це знижує чутливість до WAN і локалізує збої.
2. Центральний авторитетний DNS + гілкові форвардери.
   Філії запускають кешуючі резольвери, які форвардять запити для внутрішніх зон до HQ; усе інше йде на зовнішні резолвери.
   Це підходить, якщо ви не хочете контролерів домену у філіях.
3. Split‑horizon з внутрішнім та зовнішнім виглядом.
   Те саме ім’я, різні відповіді всередині та зовні. Корисно, коли публічний DNS для вашого домену існує, але внутрішні відповіді мають відрізнятися (VPN‑ендпоінти, внутрішні VIP тощо).

Чого я уникаю: «Кожен сайт використовує публічні резолвери (Google/Cloudflare), а ми підсовуємо hosts для внутрішніх імен.»
Це не дизайн; це майбутній інцидент.

Жарт №1: DNS схожий на офісні плітки: одна неправильна запис розповсюджується швидше, ніж виправлення.

Основи Windows: AD DNS, сайти та реплікація зон

AD DNS — не опція, якщо ви хочете, щоб AD працював коректно

У середовищі AD DNS виконує дві ролі: розв’язує A/AAAA‑записи, як будь‑який DNS, і публікує розташування сервісів за допомогою SRV‑записів.
Коли філії скаржаться «повільний логін», корінь проблеми часто в DNS: клієнти знаходять контролери домену через WAN, або не можуть знайти
глобальний каталог, або таймаути SRV‑запитів виникають через те, що вони спрямовані на резольвер, який не бачить AD‑зону.

Використовуйте Sites and Services, щоб контролювати, куди потрапляють клієнти

Якщо у вас декілька офісів і ви не використовуєте AD Sites правильно, ви лишаєте керування на даху машини. Визначте підмережі для кожного офісу,
прив’яжіть їх до сайтів і забезпечте, щоб кожен сайт мав локальні контролери домену (або хоча б локальні DNS‑форвардери для AD‑зон).
Інакше клієнти охоче будуть аутентифікуватися на «якомусь DC» через повільне з’єднання, а ви будете звинувачувати «VPN».

Область реплікації зон — це рішення з точки зору безпеки й продуктивності

Для AD‑інтегрованих зон вибір області реплікації (для домену, лісу або кастомних розділів) впливає на те, що копіюється куди.
Реплікуйте лише те, що потрібно. Мета — передбачуване розв’язання, а не «усе скрізь».

Умовні форвардери — дорослий спосіб крос‑розв’язування

Якщо у вас декілька AD‑лісів або окремих внутрішніх доменів (поширено після злиттів), умовні форвардери тримають вас в порядку.
Вони також уникають «повної рекурсії скрізь», яка повільна і важко безпечна.

Основи Linux: resolv.conf, systemd-resolved і DNS search

Знайте, який стек резольвера ви реально використовуєте

На сучасному Linux у вас може бути:

• glibc stub resolver, що читає /etc/resolv.conf напряму
• systemd-resolved, що виступає локальною заглушкою (часто 127.0.0.53) з per‑link DNS
• NetworkManager, що керує резольверами і записує resolv.conf або спілкується з resolved
• dnsmasq/unbound, які працюють локально як кеш/форвардер

Багато відмов — це просто невідповідні припущення: хтось править /etc/resolv.conf вручну, NetworkManager
«виправляє» його назад, і користувач думає «Linux ігнорує налаштування DNS». Ні, він ігнорує ваші ручні правки.

Пошукові домени і «ndots» можуть створювати фантомні відмови

Поведінка резольвера Linux включає search‑суфікси і опцію ndots. Якщо в конфігу встановлено ndots:5
(часто в Kubernetes і іноді випадково скопійовано на сервери), то запит для fileserver01 може спричинити кілька доповнених‑суфіксів
запитів перш ніж спробувати його «як є». Через WAN це множник затримки.

Зробіть Linux детермінованим у філіях

У мультиофісній конфігурації Linux‑сервери повинні в першу чергу вказувати на локальні резольвери. Якщо не можна розгорнути локальні резольвери,
принаймні переконайтеся, що віддалені резольвери доступні й мають низьку затримку. «Два випадкові DNS IP у resolv.conf»
без плану — це шлях до того, що половина ваших запитів піде через VPN через ротацію або відмову резольверів.

Практичні завдання: команди, виводи та рішення (Windows + Linux)

Це реальні перевірки, які ви можете виконати сьогодні. Кожна містить (1) команду, (2) що означає вивід, та
(3) рішення, яке ви робите далі. DNS — це не філософський семінар; це вид спорту з вимірювання.

Завдання 1 (Linux): Визначте, хто керує DNS на цьому хості

cr0x@server:~$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 May  3 10:12 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

Значення: Ця система використовує stub‑файл systemd‑resolved; редагування /etc/resolv.conf напряму не збережеться.

Рішення: Використовуйте resolvectl і налаштування менеджера мережі, а не ручні правки.

Завдання 2 (Linux): Показати ефективні DNS‑сервери та пошукові домени

cr0x@server:~$ resolvectl status
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
 resolv.conf mode: stub
Current DNS Server: 10.20.0.10
       DNS Servers: 10.20.0.10 10.20.0.11
        DNS Domain: corp.example.com

Link 2 (ens160)
Current Scopes: DNS
     DNS Servers: 10.20.0.10 10.20.0.11
      DNS Domain: branch1.corp.example.com corp.example.com

Значення: DNS прив’язаний до інтерфейсу; машина надає перевагу цим серверам і додаватиме ці пошукові домени.

Рішення: Підтвердіть, що ці IP — локальні резольвери для сайту. Якщо це віддалені IP з HQ, очікуйте затримок і плануйте резольвер у філії.

Завдання 3 (Linux): Перевірте сирий конфіг резольвера (для сюрпризів з ndots/search)

cr0x@server:~$ cat /etc/resolv.conf
nameserver 127.0.0.53
options edns0 trust-ad
search branch1.corp.example.com corp.example.com

Значення: Додатки питатимуть локальну заглушку; пошукові домени будуть застосовані.

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

Завдання 4 (Linux): Підтвердіть, який сервер відповідає і чи він авторитетний

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

fileserver01.corp.example.com. 300 IN A 10.30.4.21

Значення: Прапорець aa вказує на авторитетну відповідь від сервера, що відповів.

Рішення: Якщо ви очікуєте авторитетну відповідь, але не бачите aa, можливо, ви натрапляєте на форвардер/кеш; перевірте ланцюжок форвардингу і джерело правди.

Завдання 5 (Linux): Вловіть «DNS працює, але повільно»

cr0x@server:~$ dig fileserver01.corp.example.com @10.20.0.10 +stats
;; ANSWER SECTION:
fileserver01.corp.example.com. 300 IN A 10.30.4.21

;; Query time: 412 msec
;; SERVER: 10.20.0.10#53(10.20.0.10)
;; WHEN: Sat Dec 28 10:12:55 UTC 2025
;; MSG SIZE  rcvd: 74

Значення: 412 мс — це WAN‑рівень затримки. Для локального резольвера бажано низькі десятки мілісекунд або менше.

Рішення: Якщо час запиту постійно високий, розгорніть локальний кешуючий резольвер у офісі або виправте маршрутизацію/MTU/правила файрволу щодо UDP/53.

Завдання 6 (Linux): Перевірте, що резольвер досяжний і не блокується (UDP і TCP)

cr0x@server:~$ nc -vz -u 10.20.0.10 53
Connection to 10.20.0.10 53 port [udp/domain] succeeded!
cr0x@server:~$ nc -vz 10.20.0.10 53
Connection to 10.20.0.10 53 port [tcp/domain] succeeded!

Значення: UDP і TCP 53 доступні. TCP важливий для великих відповідей і повторних спроб при усіченні.

Рішення: Якщо UDP працює, а TCP — ні, виправте правила файрволу; деякі записи (DNSSEC, багато SRV) періодично будуть ламатися.

Завдання 7 (Linux): Спостерігайте повтори DNS і які імена пробуються

cr0x@server:~$ sudo tcpdump -ni ens160 port 53 -c 8
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ens160, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:13:11.120134 IP 10.20.1.55.56621 > 10.20.0.10.53: 11209+ A? fileserver01.branch1.corp.example.com. (55)
10:13:11.170221 IP 10.20.1.55.56621 > 10.20.0.10.53: 28041+ A? fileserver01.corp.example.com. (45)
10:13:11.220401 IP 10.20.1.55.56621 > 10.20.0.10.53: 19901+ AAAA? fileserver01.corp.example.com. (45)

Значення: Клієнт спочатку пробує імена з пошуковими суфіксами, потім базовий домен, потім AAAA.

Рішення: Якщо ці перші спроби непотрібні і повільні (затримки через NXDOMAIN), скоротіть список пошукових доменів або використовуйте FQDN у конфігураціях.

Завдання 8 (Windows): Показати, якими DNS‑серверами і суфіксами клієнт реально користується

cr0x@server:~$ ipconfig /all
Windows IP Configuration

   Host Name . . . . . . . . . . . : WKS-221
   Primary Dns Suffix  . . . . . . .  : corp.example.com
   DNS Servers . . . . . . . . . . . : 10.20.0.10
                                       10.20.0.11
   Connection-specific DNS Suffix  . . : branch1.corp.example.com

Значення: Клієнт має первинний суфікс і суфікс, специфічний для з’єднання, і спробує їх під час розв’язання.

Рішення: Якщо DNS‑сервери не локальні для сайту, виправте налаштування DHCP або GPO; не дозволяйте ноутбукам у філіях за замовчуванням вказувати на DNS HQ.

Завдання 9 (Windows): Доведіть, чи DNS‑сервер може відповідати за зону

cr0x@server:~$ nslookup
> server 10.20.0.10
Default Server:  dns-branch1.corp.example.com
Address:  10.20.0.10
> set type=soa
> corp.example.com
corp.example.com
        primary name server = dc1.corp.example.com
        responsible mail addr = hostmaster.corp.example.com
        serial  = 2457
        refresh = 900 (15 mins)
        retry   = 600 (10 mins)
        expire  = 86400 (1 day)
        default TTL = 3600 (1 hour)

Значення: Отримали SOA, отже сервер може говорити авторитетно (або принаймні надійно отримувати цю інформацію).

Рішення: Якщо SOA відмовляє або таймаутиться, це не проблема клієнта. Виправте доступність служби DNS або форвардинг/хостинг зони.

Завдання 10 (Windows): Перевірте, який сервер відповів і чи задіяна рекурсія

cr0x@server:~$ nslookup fileserver01.corp.example.com 10.20.0.10
Server:  dns-branch1.corp.example.com
Address:  10.20.0.10

Name:    fileserver01.corp.example.com
Address: 10.30.4.21

Значення: Ви змусили використовувати конкретний DNS‑сервер. Добре. Ви виключили «клієнт обирає неправильний сервер».

Рішення: Якщо це працює, а той самий запит без вказівки сервера — ні, виправте список DNS‑серверів на клієнті та порядок їх використання.

Завдання 11 (Windows Server / AD): Швидко перевірте стан DNS у AD

cr0x@server:~$ dcdiag /test:dns /v
Directory Server Diagnosis

Performing initial setup:
   Trying to find home server...
   Home Server = DC1
   * Identified AD Forest.
   Done gathering initial info.

Doing DNS tests...

   DNS Tests are running and not hung. Please wait a few minutes...
   PASS: Basic (Domain membership)
   PASS: Forwarders/Root hints
   PASS: Delegation
   PASS: Records registration

Значення: Базові DNS‑тести пройшли на цьому DC.

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

Завдання 12 (Windows Server): Перевірте умовні форвардери (після злиття доменів)

cr0x@server:~$ Get-DnsServerConditionalForwarderZone

ZoneName             MasterServers        ReplicationScope
--------             -------------        ----------------
corp.partner.example {192.0.2.53,192.0.2.54} Forest
lab.example.com      {10.50.0.10}          Domain

Значення: Існують умовні форвардери і вони реплікуються; область вказує, наскільки широко.

Рішення: Якщо DNS‑сервери у філіях не мають цього форвардера, виправте область реплікації або створіть його на потрібних ролях DNS.

Завдання 13 (Linux): Визначте, чи BIND/unbound правильно форвардить

cr0x@server:~$ sudo named-checkconf -p | sed -n '1,80p'
options {
        directory "/var/cache/bind";
        recursion yes;
        allow-recursion { 10.20.0.0/16; };
};

zone "corp.example.com" {
        type forward;
        forward only;
        forwarders { 10.10.0.10; 10.10.0.11; };
};

Значення: Цей резольвер форвардить внутрішню зону на DNS HQ і не намагається іншими шляхами (forward only).

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

Завдання 14 (Linux): Підтвердіть кешування і здоров’я TTL

cr0x@server:~$ dig fileserver01.corp.example.com @10.20.0.10 +noall +answer
fileserver01.corp.example.com. 300 IN A 10.30.4.21
cr0x@server:~$ dig fileserver01.corp.example.com @10.20.0.10 +noall +answer
fileserver01.corp.example.com. 297 IN A 10.30.4.21

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

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

Завдання 15 (Windows): Очищення кешу клієнта при тестуванні змін запису

cr0x@server:~$ ipconfig /flushdns
Windows IP Configuration

Successfully flushed the DNS Resolver Cache.

Значення: Кеш резольвера клієнта очищено.

Рішення: Використовуйте це при валідації виправлення. Якщо це «тимчасово вирішує», підлягає перевірці питання TTL/реплікації, а не клієнтського чарівництва.

Завдання 16 (Linux): Очищення кешу systemd-resolved (якщо застосовано)

cr0x@server:~$ sudo resolvectl flush-caches
cr0x@server:~$ resolvectl statistics
DNSSEC supported by current servers: no

Cache
  Current Cache Size: 0
          Cache Hits: 118
        Cache Misses: 54

Значення: Кеш очищено; статистика показує попередню поведінку хіт/міс.

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

Три корпоративні міні-історії (як це ламається в реальному житті)

Міні-історія 1: Інцидент через неправильне припущення

Середньої величини компанія мала два офіси і невеликий датacenter. Вони швидко додали третій офіс з «тимчасовим» VPN,
«тимчасовою» DHCP‑конфігурацією, «тимчасовим» всім. DHCP нового офісу роздавав публічні резолвери, бо «DNS — це DNS».
Вважали, що внутрішні імена працюватимуть через hosts на кілька тижнів.

У понеділок пройшло оновлення Windows, і ноутбуки почали віддавати перевагу IPv6. Публічні резолвери повернули
публічний AAAA‑запис для імені, яке мало бути внутрішнім (хтось випадково створив співпадаючий запис під час міграції сайту місяцями раніше).
Результат: клієнти намагалися дістатися внутрішньої служби через інтернет, зазнавали невдачі, і додаток інтерпретував це як «сервіс впав», запустивши ланцюг викликів.

Неправильне припущення було не в «IPv6 дивний». Неправильне припущення було: внутрішні імена не просочуються.
Вони просочуються — через колізії, помилки split‑horizon, копіпаст записів між зонами. Коли команді змусили всі клієнти філії
використовувати внутрішні резольвери (і створили належну внутрішню зону зі split‑horizon), проблема зникла.

Урок: «тимчасовий DNS» стає постійним, просто з гіршою документацією.

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

Інша організація боролася з проблемами продуктивності у філії. Інженер зменшив TTL в усій внутрішній зоні до дуже малих значень, щоб
«зміни поширювалися швидше». Це спрацювало — зміни поширювалися швидше. Але це також перетворило DNS на постійний WAN‑потік,
бо філія не мала локального кешу, а єдині DNS‑сервери були в HQ.

Ніхто не помітив, поки рутинне оновлення файрволу не додало трохи більшу затримку на UDP/53 через нові правила інспекції.
Раптом додатки, що робили кілька запитів за транзакцію, почали падати. Не тому що DNS упав, а тому що сумарний час розв’язання перевищив таймаут додатка.

Вони підняли TTL назад, додали невеликий кешуючий резольвер у філії і ввели правило: зміни TTL потребують огляду продуктивності при участі WAN.
«Швидке поширення» — добре; «підсилена залежність від затримки WAN» — ні.

Жарт №2: Встановити TTL в 5 секунд скрізь — як планувати щоденні пожежні тренування: технічно всі готові, практично ніхто не працює.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Велике підприємство вело AD‑інтегрований DNS з одним DC на сайт і простою політикою: клієнти використовують лише локальні DNS‑сервери,
і ці сервери форвардять зовнішні запити на невеликий набір контрольованих upstream‑резолверів. У них була операційна звичка:
кожен тикет зміни сайту включав чек‑лист DNS і еквівалент скріншота «dig з філії».

Одного вечора проблема оператора частково деградувала MPLS між двома регіонами. Затримка зросла, з’явилася втрата пакетів, і низка
команд почали повідомляти «випадкові відмови». Команда DNS не панікувала. У них були локальні резольвери, тому більшість запитів залишилися в сайті.
Аутентифікація залишилася стабільною, бо клієнти не шукали віддалені контролери домену.

Невеликі відмови, які вони побачили, швидко відслідкували: умовні форвардери для партнерської зони вказували лише на резольвери у постраждалому регіоні.
Вони додали другий target‑форвардер в інший регіон, протестували і продовжили роботу.

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

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

Коли в чергу потрапляє «ім’я хоста не розв’язується в офісі B», мета — знайти вузьке місце за хвилини, а не медитувати над теорією DNS.
Виконуйте це в порядку.

По‑перше: підтвердіть, що це DNS, а не досяжність

• З проблемного клієнта: розв’яжіть FQDN, вказавши сервер (nslookup/dig). Якщо це не вдається, шлях DNS зламаний.
• Якщо розв’язує, спробуйте дістатися IP (ping/curl/перевірка порту). Якщо це не вдається, проблема в маршрутизації/файрволі/політиці.

По‑друге: знайдіть, яким DNS‑сервером клієнт реально користується

• Windows: ipconfig /all і підтвердіть список DNS‑серверів і суфікси.
• Linux: resolvectl status або перевірте /etc/resolv.conf залежно від стеку.
• Шукайте split‑brain: VPN штовхає DNS, DHCP штовхає інший DNS, NetworkManager ротує тощо.

По‑третє: визначте, чи DNS‑сервер авторитетний або форвардить

• Запитуйте SOA/NS для зони проти конкретного сервера.
• Якщо він форвардить, перевірте доступність форвардерів з того DNS‑сервера (не з вашого ноутбука).
• Перевірте провали TCP‑fallback і проблеми з EDNS‑усіченням.

По‑четверте: перевірте затримки і повтори

• Вимірюйте час запиту за допомогою dig +stats.
• Використовуйте tcpdump/Wireshark, щоб побачити повторні запити, розгортання пошукових суфіксів і таймаути.
• Якщо затримка висока — впровадьте локальне кешування і тримайте внутрішній авторитет максимально близько до користувачів.

По‑п’яте: перевірте коректність даних (застаріла/неправильна відповідь)

• Порівняйте повернутий IP з очікуваною маршрутизацією по офісу.
• Перевірте TTL і негативне кешування.
• Якщо AD‑інтеграція: підтвердіть здоров’я реплікації AD і що запис існує там, де ви думаєте.

Вибір архітектури: форвардери vs stub-зони vs рекурсія всюди

Умовні форвардери: стандартна відповідь для крос‑офісного DNS

Умовні форвардери кажуть: «для запитів у зоні X — запитуйте ці конкретні сервери». Вони прості, аудитовані та передбачувані.
У філіях локальний кешуючий резольвер з умовними форвардерами дає хорошу продуктивність без дублювання авторитету зони.

Сценарій відмови: якщо цільові форвардери розміщені лише в одному сайті, цей сайт стає прихованою залежністю. Додавайте принаймні два
цільові адреси в різних доменах відмов, коли це можливо.

Stub‑зони: корисні, коли потрібна логіка делегування, а не повний форвардинг

Stub‑зони підтягують NS (і іноді glue A‑записи) для зони й тримають їх в актуальному стані. Вони зручні, коли ви хочете, щоб резольвер
динамічно навчився авторитетних серверів, замість жорстко фіксованого списку форвардерів.

Сценарій відмови: stub‑зони все одно потребують доступності авторитетних серверів. Якщо маршрутизація асиметрична або фільтрується,
ви отримаєте «періодичну» резолюцію, яка змусить всіх сперечатися.

Повна рекурсія всюди: спокусливо, але брудно

Дозволити кожному DNS‑серверу повну рекурсію в інтернет може працювати, але це розширює вашу поверхню атаки, ускладнює логування
і робить фільтрацію еґрезу складнішою. В підприємствах зазвичай чистіше централізувати рекурсію в невеликому наборі резольверів
і форвардити на них.

Split‑horizon: робіть це свідомо або не робіть взагалі

Split‑horizon DNS доречний, коли та сама зона існує публічно і внутрішньо, але з різними відповідями.
Єдиний розумний спосіб працювати з ним — чітке володіння, тестування і явні політики про те, які клієнти бачать який вигляд.

Сценарій відмови: хтось оновлює публічний DNS, але забуває внутрішній (або навпаки). Так ви отримуєте «працює у мобільного хоста»
і «падає на VPN» одночасно.

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

1) «nslookup працює, але застосунок все одно падає»

Симптом: Ручний запит вдається; додаток повертає помилки «host not found» або таймаути.

Корінь проблеми: Додаток використовує інший шлях резольвера (DNS контейнера, кеш JVM, відмінності /etc/nsswitch.conf),
або додаток спочатку пробує AAAA і таймаутиться через проблеми з IPv6‑маршрутизацією.

Виправлення: Перевірте розв’язання в середовищі виконання додатка (всередині контейнера, тим же користувачем, у тій же мережевій неймспейс).
Перевірте поведінку AAAA і маршрутизацію IPv6. Розгляньте зменшення TTL кешу JVM лише якщо розумієте витрати.

2) «Тільки в одному офісі розв’язуються короткі імена»

Симптом: ping fileserver01 працює в HQ, але падає у філіях; FQDN працює скрізь.

Корінь проблеми: Конфігурація пошукових суфіксів відрізняється між сайтами (DHCP/GPO/NetworkManager), або в філії бракує первинного DNS‑суфікса.

Виправлення: Стандартизувати список суфіксів через DHCP‑опції і/або GPO; зменшити розповсюдження суфіксів. Віддавати перевагу FQDN у критичних конфігураціях.

3) «Розв’язання повільне тільки через VPN»

Симптом: Запити займають 500–2000 мс; додатки таймаутять; у пакетних дампах видно повтори.

Корінь проблеми: Клієнти філії звертаються до DNS HQ через VPN; немає локального кешу; MTU/фрагментація призводить до втрати DNS‑відповідей; TCP/53 блокується.

Виправлення: Розгорніть локальний кешуючий резольвер або локальний DC/DNS; виправте MTU і дайте дозвіл на TCP/53; переконайтеся, що EDNS UDP size не ламається середніми коробками.

4) «Іноді повертає неправильний IP»

Симптом: Іноді розв’язується в 10.x, іноді в 192.168.x, іноді в публічний IP.

Корінь проблеми: Неправильне застосування split‑horizon, або клієнти використовують змішані DNS‑сервери (один внутрішній, один публічний), або застарілі записи з різними TTL.

Виправлення: Нав’язуйте DNS‑сервери через DHCP/VPN/GPO; видаліть публічні резолвери з внутрішніх клієнтів; аудитуйте політики split‑horizon і забезпечте узгодженість виглядів.

5) «Новий запис існує в HQ, але не у філії»

Симптом: DC1 розв’язує його; DC2 у філії повертає NXDOMAIN.

Корінь проблеми: Проблеми реплікації AD, невідповідність області реплікації зони, або DNS‑сервер у філії не веде цю зону.

Виправлення: Перевірте здоров’я реплікації AD; підтвердіть, що зона AD‑інтегрована й область реплікації включає потрібний DNS‑сервер; виправте сайти, лінки і розклади при потребі.

6) «Linux‑сервери ігнорують налаштування DNS, які ми роздали»

Симптом: Ви задали resolv.conf; він повертається до попереднього; поведінка змінюється після перезавантаження.

Корінь проблеми: systemd‑resolved/NetworkManager керують resolv.conf, або DHCP перезаписує налаштування на інтерфейсі.

Виправлення: Налаштуйте DNS через відповідний менеджер (resolvectl/налаштування NetworkManager), або запустіть локальний резольвер і вкажіть 127.0.0.1.

7) «Приєднання до домену працює, але логіни повільні в одному офісі»

Симптом: Приєднання вдається; пізніше логіни довгі; оновлення групових політик повільні.

Корінь проблеми: Клієнти знаходять DC в іншому сайті через відсутні/неправильно налаштовані підмережі в AD Sites, або філія вказує на не‑AD DNS.

Виправлення: Визначте підмережі і зіставте їх із сайтами; забезпечте локальні DC/DNS або форвардинг для AD‑зон; перевірте локальне розв’язання SRV‑записів.

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

План поетапно: зробіть імена хостів доступними скрізь (план «робити так, а не так»)

1. Виберіть внутрішній авторитет.
   Якщо у вас є AD, внутрішній DNS‑авторитет — це AD DNS. Якщо ні — оберіть BIND/Windows DNS як авторитет і документуйте власника.
2. Проведіть інвентар зон і колізій.
   Перелічіть внутрішні зони, зовнішні зони і будь‑які колізії (те саме ім’я використовується в кількох місцях).
3. Визначте DNS локальний для кожного офісу.
   Найкраще: DNS‑здатний DC у кожному офісі. Добре: невелика VM з кешуючим резольвером у кожному офісі з умовними форвардерами до HQ.
4. Стандартизуйте роздачу DNS клієнтам.
   DHCP для десктопів, профілі VPN для віддалених користувачів і GPO там, де доречно. Видаліть публічні резолвери з внутрішніх клієнтів.
5. Впровадьте умовні форвардери (або stub‑зони) для крос‑доменних потреб.
   Особливо після злиттів або коли існують партнерські зони.
6. Приведіть split‑horizon під контроль.
   Якщо потрібен, формалізуйте: внутрішній вигляд vs зовнішній, узгоджений контроль змін і тестування з кожного офісу.
7. Вирівняйте маршрутизацію.
   Не повертайте IP, до яких сайт запиту не має маршруту. Якщо у вас є site‑specific VIP, можливо, потрібні гео/сайт‑чутливі відповіді.
8. Тестуйте з кожного офісу за відтворюваними командами.
   Використовуйте ті самі імена хостів, вимірюйте час запиту і перевіряйте, який сервер відповів.
9. Додайте логування і базовий алертінг.
   Алертуйте на таймаути резольверів, сплески SERVFAIL і недоступність форвардерів. DNS‑проблеми рідко безшумні; їх просто ігнорують.
10. Документуйте нудні частини.
    Які DNS‑сервери «дозволені», які зони внутрішні, як додавати записи і як валідовувати з кожного офісу.

Операційний чеклист: перш ніж оголосити «DNS виправлено»

• Клієнти в кожному офісі використовують передбачені DNS‑сервери (немає публічних резолверів).
• Внутрішні імена розв’язуються в рауттабельні IP з кожного офісу.
• Затримка запитів прийнятна (виміряно, а не вгадано).
• TCP/53 працює наскрізь для резольверів.
• Списки пошукових суфіксів узгоджені і не переповнені.
• Реплікація AD (якщо є) здорова і зони реплікуються в потрібну область.
• Кеші зрозумілі: TTL, негативне кешування і коли очищати під час тестів.

Питання та відповіді

1) Чи має кожен офіс мати власний DNS‑сервер?

Так, якщо ви не отримуєте задоволення від включення WAN‑затримки до кожного логіну й виклику додатка. Локальний кешуючий резольвер на офіс часто достатній.
Якщо у вас є AD, локальний DC/DNS у кожному офісі — найчистіший підхід.

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

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

3) Що краще: умовні форвардери чи stub‑зони?

Умовні форвардери простіші і передбачуваніші. Stub‑зони корисні, коли ви хочете автоматично оновлювати списки авторитетних серверів.
Якщо не впевнені, оберіть умовні форвардери і зробіть список цілей резервованим.

4) Чому в офісі A працює, а в офісі B — ні?

Зазвичай одне з: різні DNS‑сервери від DHCP/VPN, різні списки пошукових суфіксів, відсутня реплікація зони у філії,
або невідповідність маршрутизації (філія не може дістатися до повернутої IP). Виміряйте, який шар ламається, і виправляйте конкретно його.

5) Як безпечно працювати зі split‑horizon DNS?

Трактуйте його як production‑код: контроль змін, тестування зовні й всередині, і чітке розділення керування внутрішньою та зовнішньою зоною.
Не дозволяйте двом командам оновлювати «одно й те саме ім’я» без координації.

6) Чому DNS‑запити повільні, хоча VPN «підключений»?

«VPN підключений» означає тільки, що пакети можуть проходити. DNS чутливий до затримки, втрати пакетів, MTU/фрагментації і TCP‑fallback.
Виміряйте час запиту, підтвердіть UDP і TCP 53, і додайте локальний кеш, щоб зменшити залежність від WAN.

7) Як стандартизувати пошукові суфікси між Windows і Linux?

Windows: опція DHCP для DNS‑суфікса і GPO для списку пошукових суфіксів там, де доречно.
Linux: налаштовуйте через NetworkManager/systemd‑resolved (або інструменти вашого дистрибутива), а не правкою resolv.conf вручну.
Тримайте список коротким; кожен додатковий суфікс — потенційна затримка.

8) А DoH/DoT — чи мають філії використовувати шифрований DNS?

Для внутрішніх зон зазвичай хочеться plain DNS на довірених сегментах мережі з чітким вибором серверів і логуванням.
DoH/DoT корисні для приватності клієнтів щодо зовнішніх доменів, але можуть обходити корпоративні політики DNS, якщо ними не керують.
Рішення має бути свідомим; не давайте браузерам самостійно обирати ваш резольвер.

9) Скільки DNS‑серверів має бути налаштовано у клієнтів?

Зазвичай два, бажано локальні для сайту. Більше — не завжди краще; деякі клієнти ротує або переключаються способом, що створює трафік між сайтами.
Правильна відповідь: «два доступні сервери в одному домені відмов», плюс належна надлишковість на бекенді.

10) Як уникнути застарілих записів у мультиофісному DNS?

Використовуйте динамічні оновлення DNS там, де доречно, налаштовуйте scavenging/aging в AD DNS обережно і моніторте здоров’я реплікації.
Тримайте TTL розумними; не ставте їх крихітними, щоб компенсувати неакуратне управління життєвим циклом записів.

Наступні кроки, які ви можете зробити цього тижня

Якщо ви хочете, щоб імена хостів розв’язувалися скрізь між офісами, перестаньте ставитися до DNS як до фонової утиліти і почніть
розглядати його як продакшн‑систему з топологією. Помістіть резольвер близько до користувачів. Зробіть внутрішні зони авторитетними там, де ви контролюєте.
Використовуйте умовні форвардери для крос‑доменного розв’язування. Тримайте конфіг клієнтів узгодженою і аудитованою.

Практичні кроки:

• Оберіть одну філію і виміряйте сьогодні затримку DNS (dig +stats / nslookup проти передбачених серверів).
• Аудитуйте DHCP/VPN/GPO, щоб клієнти цієї філії використовували лише передбачені резольвери.
• Розгорніть локальний кешуючий резольвер (або DC/DNS) у цій філії і повторно перевірте час запитів.
• Стандартизуйте списки пошукових суфіксів; видаліть випадкові суфікси і загадкові ndots‑налаштування.
• Напишіть односторінковий DNS‑руубук: «які сервери, які зони, як тестувати, як змінювати». І використовуйте його на практиці.

Ваша нагорода — нудне, узгоджене розв’язання. Саме таким має бути DNS: непомітний, швидкий і ніколи не в заголовках новин.