Хаос вирішення імен: hosts, LLMNR, NetBIOS — що вимкнути і чому

Ментальна модель: як імена стають IP (та брехні)

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

Порядок резолюції — це політика, а не фізика

На Linux /etc/nsswitch.conf визначає порядок: зазвичай files dns для hosts.
Це означає, що /etc/hosts може перебивати DNS. Навмисно. Випадково. Катастрофічно.

На Windows резольвер розглядає (приблизно) локальний hosts, кеш DNS, DNS‑сервери, а потім «запасні варіанти» як LLMNR і NetBIOS залежно від конфігурації.
Важливий операційний висновок: якщо залишити запасні механізми ввімкненими, збій DNS не обов’язково дасть чисту помилку. Він дасть іншу відповідь з іншого джерела.

LLMNR і NetBIOS — «останній засіб», який стає першопричиною відмов

LLMNR (Link‑Local Multicast Name Resolution) — це мультікаст‑пошук імен у локальному сегменті мережі. Думайте: «песимістичний DNS без сервера», використовує UDP/5355.
NetBIOS‑резолюція імен (NBNS) старіша і зазвичай використовує UDP/137.

Це не просто антикваріат. Це операційні ризики:

• Вони створюють неоднозначність. Кілька хостів можуть відповісти. «Переможець» визначається затримкою, а не правильністю.
• Вони розширюють довіру. Ви довіряєте своїм DNS‑серверам (сподіваюсь). З мультікастом ви довіряєте першому, хто вигукне.
• Вони невидимі для багатьох команд. Дашборди DNS не показують LLMNR. Відповіді NBNS не фіксуються у ваших логах AD.

Суха правда: ваші служби каталогів та сховище не піклуються про ваші наміри. Їх цікавить, до якого IP клієнт фактично підключився.

Жарт №1: LLMNR — це як запитати в офісі «хтось знає, де нарада?» — і йти до першої людини, яка впевнено вказала.

Чому це важливо для SRE та інженерії збереження даних

Відмови збереження часто є «відмовами імен». SMB‑маунти падають, бо ім’я хоста резолюється в неправильний сервер.
NFS‑клієнти зависають, бо постійно повторюють звернення до мертвого IP, закешованого десь.
iSCSI‑відкриття не вдається, бо ініціатор не може розв’язати ім’я хоста цілі, і падає до чогось, що «працює», але неправильно.

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

Факти та історія, що все ще болять у 2026

Це не тривіальні відомості. Вони пояснюють, чому у вашому середовищі є три різні системи «імен», які всі претендують на корисність.

1. До DNS HOSTS.TXT був інтернетом. Вузли ARPANET отримували централізовано підтримуваний hosts‑файл; локальні файли були первісною «службою каталогів».
2. DNS створили для делегування та масштабування. Він не зʼявився тому, що hosts‑файли дратували; його створили, бо централізована координація не масштабувалася.
3. NetBIOS передує сучасним IP‑мережам. Він виник у 1980‑х для імен у LAN і сесій, пізніше «пристосований» до TCP/IP як NetBIOS over TCP/IP.
4. WINS існував, щоб приборкати NetBIOS. Windows Internet Name Service був по суті «DNS для NetBIOS», щоб уникнути широкомовних бур і роздвоєння імен.
5. LLMNR стандартизували в середині 2000‑х. Це ініціатива Microsoft, щоб надати локальну резервну ім’ю без потреби в DNS, особливо для малих мереж.
6. mDNS і LLMNR — родичі, а не близнюки. mDNS (UDP/5353) використовує конвенцію .local і поширений на Apple/Linux/IoT; LLMNR більше орієнтований на Windows.
7. Мультікаст‑відкриття розширює поверхню атак. Отруєння LLMNR/NBNS — популярна техніка захоплення облікових даних в ентерпрайзі, бо жертви говоритимуть з неправильним відповідачем.
8. Сучасний Linux часто використовує systemd‑resolved. Це додає кешування і split DNS, але також ще одну рухому частину, яка може не погоджуватися з /etc/resolv.conf.
9. IPv6 додав нові нюанси, а не зменшив їх. Тепер є AAAA‑записи, link‑local адреси і більше шарів кешування, які можуть успішно відповідати несподіваними способами.

Що вимкнути (і що лишити)

Ви хочете детерміноване вирішення імен. Детерміноване означає:
одна авторитетна система імен (DNS), відомі перебивання (hosts‑файл) і мінімум «вгадування».
Все інше має бути ввімкнено свідомо, а не випадково залишене.

Рекомендація за замовчуванням для більшості корпоративних мереж

• Залиште DNS. Очевидно. Зробіть його відмовостійким, під моніторингом і нудним.
• Тримайте hosts‑файли маленькими й свідомими. Лише для bootstrap, break‑glass або справді статичних інфраструктурних імен.
• Вимкніть LLMNR на керованих кінцевих точках і серверах. Це ризик безпеки і надійності.
• Вимкніть NetBIOS over TCP/IP, якщо немає задокументованої legacy‑потреби. А якщо є — ізолюйте його й зробіть WINS явним (або прийміть біль свідомо).
• Будьте обережні з mDNS. У корпоративних мережах mDNS корисний на dev‑ноутбуках і в лабораторіях; зазвичай це не те, що ви хочете на серверах.

Коли можна залишити LLMNR або NetBIOS

Якщо ви керуєте невеликою, некерованою LAN без DNS (думайте: лабораторна VLAN з випадковими пристроями), LLMNR/mDNS можуть бути прагматичними.
Але в ентерпрайзі з AD, PKI і контролями безпеки залишати LLMNR і NetBIOS увімкненими — це як залишати бокові двері відкритими, бо головні іноді заїдають.

Чому вимкнення «резервів» покращує доступність

Ось парадокс: вимкнення резервних механізмів часто зменшує кількість інцидентів.
При увімкнених LLMNR/NBNS збій DNS може перетворитися на підключення до неправильного хоста замість чистої помилки.
Чисті помилки викликають алерти і швидкі виправлення. Підключення до неправильного хоста створює довгі дивні інциденти з напів‑працюючими симптомами.

Кілька слів (парафраз), приписують John Allspaw: Надійність приходить від проєктування систем, що відмовляють передбачувано, а не від систем, що вдають, ніби відмови не трапляються.

Режими відмов, які ви справді побачите

1) «На моїй машині працює», бо ваша машина закешувала неправду

Ви змінили запис DNS, але один клієнт все ще потрапляє на старий IP. Інший клієнт потрапляє на новий IP.
Третій клієнт потрапляє кудись ще, бо впав на LLMNR.
Тепер ваш канал інцидентів повний суперечливих повідомлень — найгірший тип «даних».

2) Неправильний сервер, правильний порт

Найстрашніші відмови — це ті, що успішно зʼєднуються. Наприклад: fileserver резолюється в робочу станцію, що відповідає NBNS.
Порт SMB відкритий через локальний шарінг. Аутентифікація провалюється по‑іншому. Хтось звинувачує «Kerberos».

3) Роздвоєння між IPv4 та IPv6

DNS повертає AAAA і A. Один шлях працює, інший фільтрується. Клієнти вибирають AAAA першими, застрягають, а потім можливо відкатуються.
Резольвер‑фолбек може приховати справжню мережну проблему, що подовжує час виправлення.

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

Запит nas стає nas.corp.example, потім nas.lab.example, потім LLMNR. Існують різні відповіді.
Якщо неправильна відповідь досяжна, ви отримуєте тиху неправильну маршрутизацію.

5) Інцидент безпеки замаскований під «мережеву нестабільність»

Отруєння LLMNR і NBNS може перехопити запити і спровокувати спроби автентифікації до зловмисника.
Іноді ви бачите це як випадкові помилки аутентифікації. Іноді — як сплеск NTLM‑хендшейків.
Іноді ви не бачите нічого — поки не побачите повторне використання облікових даних.

Жарт №2: NetBIOS — це та «тимчасова обхідна доріжка», яка вже досить стара, щоб орендувати машину, але все ще приходить на сімейні зустрічі.

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

Це найшвидший спосіб, який я знаю, відповісти на єдине запитання, що має значення під час інциденту з іменами:
Звідки цей клієнт узяв ту відповідь?

По-перше: підтвердіть, чим справді користується клієнт

1. Розвʼяжіть імʼя на проблемному клієнті. Не робіть цього на своєму ноутбуці й не припускайте, що там те саме.
2. Перевірте, чи клієнт використовує DNS, hosts, LLMNR або NBNS. Ви зробите висновки за допомогою інструментів і знімків трафіку.
3. Перевірте шари кешування. systemd‑resolved, nscd, кеш клієнта DNS у Windows, браузери, JVM‑и.

По‑друге: перевірте авторитетну відповідь DNS

1. Запитайте безпосередньо у запланованих авторитетних DNS‑серверів.
2. Перевірте TTL, A/AAAA записи і що запис відповідає сервісу.
3. Переконайтесь, що зворотний DNS не використовується побічно вашим інструментом чи стеком аутентифікації.

По‑третє: полюйте на мультікаст/широкомовні фолбеки

1. Шукайте трафік LLMNR (UDP/5355) і NBNS (UDP/137) на сегменті.
2. Якщо бачите відповіді від несподіваних хостів — отримаєте генератор хаосу.
3. Рішення: вимкнути протокол, ізолювати VLAN або виправити DNS так, щоб фолбек ніколи не спрацьовував.

Коли підозрюєте «неправильний сервер»

1. Підключіться до розвʼязаного IP і ідентифікуйте банер/сертифікат сервісу.
2. Порівняйте очікуваний CN/SAN у сертифікаті та імʼя SMB‑серверу, або відбиток SSH host key.
3. Якщо це не той хост — зупиніться. Ви в зоні інциденту, можливо безпеки.

Практичні завдання: команди, виводи, рішення

Нижче — реальні завдання, які ви можете виконати під час інциденту або під час жорсткої конфігурації. Кожне містить:
команду, що означає вивід, і наступне рішення.
Команди показані з Linux‑промптом для послідовності; кілька завдань явно таргетують Windows‑середовища через знімки трафіку або політики, які можна виконати з адміністраторського jump‑host.

Завдання 1: Перевірити порядок резолюції в Linux (NSS)

cr0x@server:~$ grep -E '^(hosts|networks):' /etc/nsswitch.conf
hosts:          files dns
networks:       files dns

Значення: /etc/hosts перевіряється перед DNS. Модулів мультікасту не вказано.

Рішення: Якщо бачите mdns, resolve або інші модулі, підтвердіть, що це навмисно. Для серверів краще просте: files dns.

Завдання 2: Підтвердити, куди насправді вказує /etc/resolv.conf

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

Значення: Цей хост використовує systemd‑resolved stub‑резольвер (зазвичай 127.0.0.53). Ваш «DNS‑сервер» у resolv.conf може не бути реальним upstream.

Рішення: Використовуйте resolvectl, щоб побачити upstream‑сервери; не припускайте, що /etc/resolv.conf їх відображає.

Завдання 3: Перевірити upstream DNS, пошукові домени і налаштування LLMNR у systemd‑resolved

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

Значення: LLMNR і mDNS вимкнені. DNS‑сервери явні. Пошуковий домен — corp.example.

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

Завдання 4: Розвʼязати імʼя тим же шляхом, яким користується додаток

cr0x@server:~$ getent ahosts fileserver
10.50.12.34     STREAM fileserver
10.50.12.34     DGRAM
10.50.12.34     RAW

Значення: getent використовує NSS, тому відображає реальність nsswitch.conf. Це те, що багато додатків отримають через libc.

Рішення: Якщо це відрізняється від dig, у вас проблема політики/кешу/hosts, а не DNS‑серверів.

Завдання 5: Перевірити, чи /etc/hosts перебиває DNS

cr0x@server:~$ grep -nE 'fileserver|nas|db01' /etc/hosts
12:10.99.0.5 fileserver

Значення: Існує статичне відображення. Якщо воно застаріле, воно тихо перебиває DNS.

Рішення: Видаліть його або документуйте, чому воно існує. Для продакшену «таємні записи в hosts» — це повільні інциденти.

Завдання 6: Опитати авторитетний DNS‑сервер напряму (обійти локальні кеші)

cr0x@server:~$ dig @10.20.0.10 fileserver.corp.example A +noall +answer
fileserver.corp.example. 60 IN A 10.50.12.34

Значення: Авторитетна відповідь — 10.50.12.34 з TTL 60 секунд.

Рішення: Якщо авторитетний DNS правильний, а клієнти не погоджуються — розслідуйте кеші, split DNS або фолбеки як LLMNR/NBNS.

Завдання 7: Перевірити поведінку AAAA vs A (неочікуваний IPv6)

cr0x@server:~$ dig @10.20.0.10 fileserver.corp.example AAAA +noall +answer
fileserver.corp.example. 60 IN AAAA 2001:db8:50:12::34

Значення: IPv6 існує. Якщо IPv6‑маршрутизація/фаєрвола не працює, клієнти можуть зависнути, перш ніж спробувати IPv4.

Рішення: Або виправте IPv6 повністю, або навмисно видаліть AAAA‑записи/налаштуйте пріоритет клієнтів. Напівробочий IPv6 — класична витрата часу.

Завдання 8: Перевірити статистику локального кеша резольвера (systemd‑resolved)

cr0x@server:~$ resolvectl statistics
DNSSEC supported by current servers: no
Transactions: 1289
Cache Hits: 944
Cache Misses: 345

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

Рішення: Під час реагування на інцидент розгляньте очищення кешів після виправлення DNS — вибірково і краще лише на уражених клієнтах.

Завдання 9: Очистити кеш systemd‑resolved (хірургічно, а не як звичка)

cr0x@server:~$ sudo resolvectl flush-caches

Значення: Кеш очищено. Відсутність виводу — нормально.

Рішення: Якщо резолюція одразу змінилась, ви підтвердили симптом, повʼязаний з кешем. Тепер питання: чому були закешовані неправильні дані (помилковий DNS, фолбек, split DNS)?

Завдання 10: Інспектувати активні зʼєднання, щоб швидко виявити «неправильний IP»

cr0x@server:~$ ss -tnp | grep -E '(:445|:2049|:3260|:443)' | head
ESTAB 0 0 10.60.1.21:51244 10.99.0.5:445 users:(("mount.cifs",pid=2114,fd=3))
ESTAB 0 0 10.60.1.21:41290 10.50.12.34:443 users:(("curl",pid=9821,fd=5))

Значення: CIFS‑маунт насправді говорить з 10.99.0.5. Це може бути не ваш fileserver.

Рішення: Ідентифікуйте 10.99.0.5. Якщо це робоча станція або злоякісний хост, ймовірно у вас отруєння LLMNR/NBNS або застаріле перебивання.

Завдання 11: Ідентифікувати віддалений хост через TLS‑сертифікат (детекція неправильного сервера)

cr0x@server:~$ echo | openssl s_client -connect 10.99.0.5:443 -servername fileserver.corp.example 2>/dev/null | openssl x509 -noout -subject -issuer
subject=CN = laptop-23
issuer=CN = laptop-23

Значення: Це не ваш production‑сертифікат файлівого сервера. Це самопідписаний сертифікат ноутбука.

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

Завдання 12: Захопити трафік LLMNR і NBNS на лінії (Linux)

cr0x@server:~$ sudo tcpdump -ni eth0 'udp port 5355 or udp port 137' -c 10
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:10:41.101234 IP 10.60.1.21.51012 > 224.0.0.252.5355: UDP, length 42
12:10:41.101310 IP 10.60.1.99.5355 > 10.60.1.21.51012: UDP, length 86
12:10:41.101355 IP 10.60.1.88.5355 > 10.60.1.21.51012: UDP, length 86

Значення: Клієнт запитав через LLMNR мультікаст і дві різні машини відповіли. Ось ваша неоднозначність у вигляді пакетів.

Рішення: Вимкніть LLMNR на клієнтах та/або забезпечте надійність DNS. Кілька відповідачів — це баг дизайну, а не «крайній випадок».

Завдання 13: Знайти, хто володіє IP‑відповідачем (Linux + ARP + MAC‑vendor)

cr0x@server:~$ ip neigh show 10.60.1.99
10.60.1.99 dev eth0 lladdr 3c:52:82:aa:bb:cc REACHABLE

Значення: У вас є MAC‑адреса відповідача.

Рішення: Скористайтеся таблицею MAC‑портів комутатора або системою asset, щоб зіставити MAC → порт → пристрій. Якщо це кінцева точка — ви знайшли «заміну DNS».

Завдання 14: Перевірити Windows‑повʼязані сервіси імен з Linux jump‑host (NBNS‑запит)

cr0x@server:~$ nmblookup -A 10.60.1.99
Looking up status of 10.60.1.99
        LAPTOP-23       <00> -         B <ACTIVE>
        WORKGROUP       <00> - <GROUP>  B <ACTIVE>

Значення: Цей IP — ноутбук, що рекламує NetBIOS‑імена.

Рішення: Якщо цей ноутбук відповідає за «fileserver» під час відмов, вимкніть NetBIOS/LLMNR і розгляньте мережні контролі, щоб обмежити зловживання широкомовленням/мультікастом.

Завдання 15: Підтвердити, яким DNS‑сервером користується Linux‑хост (не довіряючись resolv.conf)

cr0x@server:~$ resolvectl dns
Global: 10.20.0.10 10.20.0.11
Link 2 (eth0): 10.20.0.10 10.20.0.11

Значення: Це реальні upstream‑сервери.

Рішення: Якщо upstream неправильні (неправильний DHCP, VPN штовхає DNS) — виправте розповсюдження. Інакше ви «пофіксите DNS», але нічого не зміниться.

Завдання 16: Перевірити пошукові домени по інтерфейсу, що створюють суфіксне хаос

cr0x@server:~$ resolvectl domain
Global: corp.example
Link 2 (eth0): corp.example
Link 3 (tun0): dev.example

Значення: VPN‑інтерфейс має інший пошуковий домен. Короткі імена можуть резолюватися по‑різному на VPN і в LAN.

Рішення: Запровадьте використання FQDN для продакшен‑ендпоінтів або встановіть чіткі правила split DNS. Короткі імена — податок, що ви платитимете завжди.

Завдання 17: Перевірити, чи імʼя послідовне на кількох резольверах

cr0x@server:~$ for s in 10.20.0.10 10.20.0.11; do dig @$s fileserver.corp.example A +short; done
10.50.12.34
10.50.12.34

Значення: Ваші DNS‑сервери погоджуються.

Рішення: Якщо вони не погоджуються — у вас проблеми реплікації, split‑views або хтось «пофіксив» один сервер. Виправте це насамперед.

Завдання 18: Перевірити, чи додаток обходить OS‑резольвер (поширено для контейнерів/JVM)

cr0x@server:~$ strace -f -e trace=network,connect,getaddrinfo -p 9821 2>&1 | head
getaddrinfo("fileserver", "https", {ai_family=AF_UNSPEC, ai_socktype=SOCK_STREAM}, ...) = 0
connect(5, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("10.50.12.34")}, 16) = 0

Значення: Процес використовує getaddrinfo() (добре) і підключається до 10.50.12.34.

Рішення: Якщо ви не бачите getaddrinfo(), додаток може використовувати власний DNS‑клієнт/бібліотеку або хардкодені IP. Дебагуйте відповідно.

Три міні‑історії з корпоративного життя (імена змінені, біль реальний)

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

Середня за розмірами компанія мала файловий сервіс під назвою archive. Це були дві Windows‑машини за VIP, і DNS вказував archive.corp.example на той VIP.
Команда SRE припускала: «Якщо DNS неправильний, сервіс недоступний.» Це припущення працювало роками, що найнебезпечніше з усіх видів правильності.

Потім одного вівторка мережева зміна коротко заблокувала DNS з віддаленого поверху. Лише той поверх.
Користувачі повідомили дивні речі: дехто відкривав шаринги, дехто отримував запити на облікові дані, а дехто бачив порожні папки, що виглядали майже правильно.
Хелпдеск ескалував як «проблеми реплікації AD», бо був залучений Kerberos і всі люблять звинувачувати Kerberos.

Знімок пакетів на ураженій машині показав LLMNR‑запити для archive. Два хости відповіли.
Один — реальний сервер (через кешований IP); інший — ноутбук‑розробника з імʼям «ARCHIVE», бо там зберігалися артефакти збірки і комусь подобались прості імена.
Windows обирав відповідача. Не завжди той самий.

На ноутбуку був увімкнений SMB з цілком легітимною причиною, і Windows люб’язно показував «гостьову» поведінку огляду, що виглядала як порожні шаринги.
Користувачів не зламали. Вони просто були підключені до неправильної машини.
Доказати це зайняло більше часу, ніж виправити.

Виправлення було нудним і рішучим: вимкнути LLMNR через політику, вимкнути NetBIOS де можливо і впровадити вимогу FQDN у скриптах та ярликах.
Також додали моніторинг: якщо будь‑який несервер відповідає на LLMNR/NBNS для ключових імен сервісів — алерт. Припущення змінилось з «збій DNS означає, що сервіс вниз» на «збій DNS означає непередбачуваність».

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

Інша організація страждала від хронічної латентності DNS в філіях. Хтось запропонував «оптимізацію»: заповнити /etc/hosts на Linux‑серверах критичними внутрішніми іменами,
щоб базові сервіси не залежали від WAN‑DNS під час відмов. Це звучало відповідально. В лабораторії навіть працювало.

Вони розгорнули це через конфіг‑менеджмент. Сотні хостів отримали охайний кураторований hosts‑файл: контролери домену, mirrors пакетів, вузли збереження.
Перші місяці були тихими. Успіх пахнув компетентністю.

Потім вони мігрували збереження. Нові IP, ті самі імена. DNS оновили правильно, з розумними TTL.
Але маунти на половині флоту продовжували йти на старі IP. Команда збереження бачила трафік на виведених вузлах і думала «зомбі‑клієнти».
Команда обчислювальної платформи бачила падіння маунтів і думала «нестабільність збереження».

Корінь був болісно простий: ті імена були закріплені в /etc/hosts, і ніхто не мав чистого інвентарю, де саме.
«Оптимізація» усунула залежність від DNS — усунувши сам DNS.
Тепер вони працювали зі тіньовою системою імен без TTL і без авторитетного джерела правди.

План відновлення теж був простий, але не швидкий: почистити записи hosts крім мінімального bootstrap‑набору, відновити довіру до DNS
і додати запобіжники, щоб майбутні зміни не могли мовчки розгалужувати реальність імен.
Урок не в тому, щоб ніколи не використовувати hosts‑файли. Урок у тому, що hosts — це конфігураційний борг з нескінченними відсотками.

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

Фінансова компанія використовувала AD‑інтегрований DNS і мала внутрішнє правило: всі продакшен‑ендпоінти повинні адресуватися через FQDN, ніколи короткими іменами.
Інженери жалілися. Це нудно. Команди довші. Здавалося педантично.
Правило пережило, бо безпека його підтримувала, а SRE контролював у ревʼю.

Під час великого офісного переїзду стався хаотичний період: два DHCP‑домени, тимчасові VLAN і VPN, який штовхав альтернативні пошукові домени.
Короткі імена стали неоднозначними за ніч. db01 міг бути db01.corp.example або db01.temp.example.
DNS був правильним в обох місцях. Проблема була в людських очікуваннях.

Команди, що використовували FQDN, не помітили нічого. Їх клієнти завжди просили точне імʼя, яке мали на увазі.
Команди, що використовували короткі імена, мали дивні збої: невідповідність сертифікатів, зміни known_hosts у SSH і «база даних хитка» заявки.
Це не була хиткість. Це був неправильний адрес.

Виправлення було не героїчним. Не треба було воєнної кімнати для DNS. Потрібна була дисципліна:
оновити рукописи, вимагати FQDN у автоматизації, заборонити короткі імена в конфігураціях і тримати LLMNR/NBNS вимкненими, щоб неоднозначність не «допомагала».
Нудна практика не запобігла всім проблемам. Вона запобігла найгіршим: тим, що виглядають як пʼять різних проблем одночасно.

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

1) Симптом: періодична «неправильний сертифікат» або помилки TLS‑handshake

Корінна причина: імʼя іноді резолюється в інший хост (відповіді LLMNR/NBNS, split DNS або застарілий запис у hosts), тому SNI потрапляє на невірний сертифікат.

Виправлення: вимагайте FQDN, вимкніть LLMNR/NBNS на кінцевих точках, видаліть застарілі записи в /etc/hosts і перевірте консистентність DNS на всіх резольверах.

2) Симптом: SMB‑маунти несподівано запитують облікові дані

Корінна причина: клієнт підключився до робочої станції чи неправильного сервера, що відповідав на запити імен; шлях автентифікації змінився (NTLM vs Kerberos) і політики відрізняються.

Виправлення: підтвердіть розвʼязаний IP, ідентифікуйте відповідача через знімок трафіку, вимкніть NetBIOS/LLMNR і обмежте експозицію SMB на кінцевих точках.

3) Симптом: «DNS в порядку», але додаток все ще падає

Корінна причина: додаток використовує кешовану резолюцію, вбудований резольвер або /etc/hosts перебиває; dig показує DNS, але додаток користується NSS/кешами.

Виправлення: використовуйте getent, щоб відтворити поведінку додатка, перевірте кеші (systemd‑resolved, nscd) і перезапустіть або очистіть кеші вибірково після виправлення джерела правди.

4) Симптом: повільні підключення тільки з певних підмереж

Корінна причина: існують AAAA‑записи, але IPv6‑маршрутизація в цих підмережах зламана; клієнти спочатку пробують IPv6 і затримуються.

Виправлення: або виправте IPv6 енд‑ту‑енд, або видаліть AAAA‑записи там, де IPv6 не підтримується; перевіряйте прямі AAAA‑запити і час TCP‑підключення.

5) Симптом: імʼя резолюється по‑різному у VPN і в офісі

Корінна причина: пошукові домени за інтерфейсами і split DNS; короткі імена стають неоднозначними і потрапляють у різні зони.

Виправлення: використовуйте FQDN; затягніть політику VPN DNS; перегляньте resolvectl domain і забезпечте однозначність авторитетних зон.

6) Симптом: випадкові помилки аутентифікації і сплески NTLM

Корінна причина: отруєння LLMNR/NBNS або неправильна конфігурація, через що клієнти автентифікуються на непередбачені хости.

Виправлення: вимкніть LLMNR/NBNS, моніторьте мультікаст/широкомовний трафік і негайно розслідуйте відповідачів.

7) Симптом: при cutover міграції «переважно працює», але деякі клієнти ні

Корінна причина: застарілі закріплення в hosts‑файлах або кешах, плюс припущення про низькі TTL, які не вірні для всіх шарів.

Виправлення: зробіть інвентар і видаліть статичні відображення; заплануйте вікна очищення/перезапуску кешів для ключових типів клієнтів; валідуйте за допомогою getent і огляду живих зʼєднань.

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

План жорсткості (enterprise‑дефолти)

1. Визначте вашу правду: DNS — авторитет для продакшен‑імен. Запишіть це.
2. Забороніть короткі імена в автоматизації: вимагайте FQDN для продакшен‑ендпоінтів і сертифікатів.
3. Вимкніть LLMNR на керованих Windows‑ендпоінтах і серверах: через Group Policy. Валідируйте знімками трафіку (UDP/5355 має зникнути).
4. Вимкніть NetBIOS over TCP/IP там, де можливо: через DHCP‑опції, налаштування адаптера або політику. Валідируйте (UDP/137 має зникнути).
5. Мінімізуйте hosts‑файли: залишайте лише записи, потрібні для bootstrap або незмінної інфраструктури. Відслідковуйте їх у конфіг‑менеджменті з власником і обґрунтуванням.
6. Моніторьте консистентність DNS: опитуйте кілька резольверів; алерт на split‑brain.
7. Моніторьте трафік LLMNR/NBNS: його не повинно бути на VLAN‑ах серверів. На користувацьких VLAN має тенденція йти до нуля.
8. Виправляйте IPv6 свідомо: або підтримуйте його правильно, або не рекламувати його в DNS для сервісів, недоступних по IPv6.
9. Документуйте стек резольверів: systemd‑resolved проти традиційного resolv.conf, поведінка DNS у контейнерах, інʼєкція DNS від VPN‑клієнта.
10. Проводьте game days: симулюйте збій DNS у тестовому VLAN; підтвердіть, що клієнти падають чисто, а не «відкатуються» до мультікаст‑неладностей.

Чекліст реагування на інцидент (коли користувачі кажуть «не можу дістатись X»)

1. На ураженому клієнті виконайте: getent ahosts name (Linux) або еквівалент на Windows. Зафіксуйте IP.
2. Опитайте авторитетний DNS: dig @dns-server fqdn A/AAAA. Порівняйте.
3. Перевірте overrides hosts: grep по hosts‑файлах на предмет імені.
4. Перевірте активні зʼєднання: підтвердіть, до якого IP клієнт фактично підключився.
5. Захопіть трафік: шукайте UDP/5355 та UDP/137. Ідентифікуйте відповідачів.
6. Підтвердіть ідентичність: предмет сертифіката, SSH host key, імʼя SMB‑сервера — усе, що доведе, що ви на правильному хості.
7. Виправте джерело правди: запис DNS, пошуковий домен, розповсюдження DNS через DHCP або політику.
8. Очищуйте кеші вибірково: після виправлення даних. Не очищуйте спочатку й «подивіться, що трапиться».
9. Замкніть коло: переконайтесь, що LLMNR/NBNS вимкнені там, де потрібно, щоб наступний збій DNS давав чисту помилку.

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

1) Чи потрібно вимкнути LLMNR повсюди?

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

2) Чи зламає вимкнення LLMNR щось легітимне?

Це зламає робочі процеси, що залежали від розвʼязування коротких незареєстрованих імен без DNS.
У продакшені це зазвичай не «легітимне», а випадкове. Замініть це на DNS і FQDN.

3) Що з mDNS? Його теж вимкнути?

На серверах: зазвичай так, якщо ви явно не використовуєте сервіс‑дискавері (рідко в enterprise‑VLANах серверів).
На ноутбуках розробників і в лабораторіях: mDNS може бути корисним. Ключ — сегментація і намір, а не загальна дозволеність.

4) Чому dig і getent дають різні результати?

dig звертається безпосередньо до DNS. getent слідує політиці OS‑резольвера (NSS), яка може включати hosts‑файли і локальні демоні.
Для поведінки додатків більше довіряйте getent.

5) Якщо у нас AD‑інтегрований DNS, чи потрібен все ще NetBIOS?

Зазвичай ні. NetBIOS вижив через legacy‑системи й старі звички.
Якщо є задокументована залежність (якісь давні додатки, дивні workflow для виявлення) — ізолюйте й заплануйте вихід.

6) Чи можуть LLMNR/NBNS викликати витік облікових даних?

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

7) Чи погана практика використовувати hosts‑файл?

Ні. Це інструмент. Але це також «зброя», що влучає точно.
Використовуйте його для bootstrap і break‑glass, тримайте мінімально і керуйте ним як кодом з власниками й ревʼю.

8) Як дізнатися, чи клієнти падають на LLMNR?

Захопіть трафік на VLAN клієнтів і шукайте UDP/5355 запити та відповіді.
Якщо бачите це в нормальній роботі, DNS і конвенції імен не такі стабільні, як думаєте.

9) Чому короткі імена спричиняють стільки проблем?

Короткі імена провокують поведінку пошукових суфіксів, неоднозначність split DNS і фолбеки.
FQDNs однозначні, краще сумісні з сертифікатами і їх легше аудитити.

10) Яка найбезпечніша операційна позиція під час DNS‑інциденту?

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

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

Вирішення імен не гламурне. Це сантехніка. І, як сантехніка, ви помічаєте її лише коли вона бризкає загадковою водою в стіни.
Виправлення не в «бути обережним». Виправлення — зробити систему нудною.

1. Зробіть інвентар поведінки резольвера на ваших основних OS‑образах: NSS‑порядок, налаштування systemd‑resolved, демони кешування, інʼєкція DNS від VPN.
2. Вимкніть LLMNR і NetBIOS на керованих кінцевих точках і серверах, якщо немає письмового винятку і плану ізоляції.
3. Впровадьте FQDN в автоматизації, конфігах сервісів, сертифікатах і рукописах. Короткі імена — джерело неоднозначності.
4. Аудитуйте hosts‑файли у вашому флоті. Приберіть дрейф. Вимагайте обґрунтування для кожного запису, що не localhost.
5. Додайте два монітори: консистентність DNS між резольверами і виявлення «неочікуваних відповідачів LLMNR/NBNS» на ключових VLAN‑ах.

Зробіть ці пʼять речей — і ви перетворите вирішення імен з надприродної сили на те, чим воно має бути: передбачуваною залежністю з очевидними режимами відмов.