dnsmasq: кеш DNS і DHCP — чиста конфігурація без конфліктів із системою

December 24, 2025 • February 3, 2026 • Читання: 6 хв • Views: 6

Було корисно?

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

dnsmasq — рідкісний інструмент, який може змусити невеликі мережі поводитися як належить — швидке кешування DNS, розумні DHCP-лізи та достатньо функцій,
щоб ви не будували машину Руба Голдберга з трьох демонів і електронної таблиці.
Хитрість у тому, щоб налаштувати його так, щоб він не конфліктував із вашою системою: systemd-resolved, NetworkManager, resolvconf та інші.

Ментальна модель: хто відповідає за DNS, хто за DHCP

«Чиста» розгортка dnsmasq переважно про межі відповідальності. DNS і DHCP — окремі протоколи, але в операційній практиці вони зрощені:
DHCP роздає адреси (та DNS-сервери), а DNS відповідає на запити ваших клієнтів, коли ті починають користуватися цими адресами.

Ваше найбільше джерело болю — це дві різні компоненти, що вважають себе босом:
один демон перезаписує /etc/resolv.conf, інший демон прив’язується до порту 53, DHCP вашого роутера все ще працює у фоновому режимі,
і якийсь доброзичливий VPN-клієнт вставляє правила розділеного DNS.

Що означає «не конфліктувати з системою»

Одна відповідальна точка для DHCP на даному L2-сегменті. Без винятків. Не «приблизно».
Чітке володіння локальним резолвом на клієнтах: або systemd-resolved є локальним stub, або dnsmasq ним є.
Одне місце для визначення upstream DNS (або принаймні одне місце на клас клієнтів), з передбачуваними перевагами.
Логи, які можна увімкнути за потреби, але не постійний монумент, що споживає диск через цікавість.

dnsmasq може виконувати кілька ролей: бути форвардером/кешем DNS, авторитетним сервером для локальних зон, DHCP-сервером,
TFTP-сервером для PXE тощо. Сценарій відмови виникає, коли він робить половину кожної ролі, а щось інше — іншу половину.
Саме тоді з’являються «працює по Wi‑Fi, але не по Ethernet» і «ламається тільки по вівторках».

Цікаві факти та невелика історія, що має значення

dnsmasq проектувався для невеликих мереж: один демон, невелика пам’ять, мінімальні залежності, передбачувана поведінка під навантаженням.
Порт 53 був полем бою з 1990-х: «локальні кешуючі резолвери» стали популярні через те, що upstream-рекурсія була повільною й крихкою.
Справжня сила DHCP — централізація політик — не лише адрес, а й шлюзу за замовчуванням, DNS-серверів, NTP та опцій, специфічних для вендора.
systemd-resolved нормалізував паттерн «stub resolver»: додатки звертаються до локального слухача (127.0.0.53), а той форвардить upstream з політикою.
Кешування DNS може тимчасово приховати проблеми з upstream, що добре, поки не спливуть TTL і ваша «стабільна» система не впаде одразу.
Негативне кешування (NXDOMAIN) існує: кешування «ім’я не існує» може прискорити збої — і також подовжити їх.
Розділений DNS (Split DNS) старший за більшість VPN-клієнтів: підприємства вирішували «внутрішні зони вирішуються внутрішньо» ще до того, як ноутбуки стали модними.
Час оренди DHCP — це важіль: занадто короткий — завалює сервер; занадто довгий — затримує відновлення після поганих призначень або змін.
Пошукові домени DNS — це зброя з відкотом: один поганий список пошуку може перетворити один запит на шість і змусити затримку виглядати як втрата пакетів.

Одна переосмислена ідея, яку варто прикріпити до монітора: реліабельність походить від розуміння того, як системи виходять з ладу, а не від удавання, що вони цього не роблять — адаптація від John Allspaw.
DNS — система, яка винахідливо ламається.

Виберіть архітектуру (і дотримуйтеся її)

Архітектура A: dnsmasq володіє LAN кешем DNS + DHCP; клієнти використовують його безпосередньо

Це найчистіший варіант для домашніх лабораторій і малих офісів: клієнти отримують DHCP від dnsmasq і використовують dnsmasq як свій DNS-сервер.
dnsmasq форвардить до upstream-резольверів (ваш ISP, публічні резольвери або внутрішній рекурсивний резольвер).

Операційна перевага: одна машина є джерелом істини для «що є в моїй LAN», і ви можете додавати локальні імена.
Операційний ризик: якщо ви поставите його на ноутбук — ви самі винні. Помістіть його на щось нудне.

Архітектура B: systemd-resolved на клієнтах; dnsmasq — тільки DHCP (або тільки DNS)

Працює, коли у вас корпоративний флот, де systemd-resolved стандартний і VPN-клієнти інтегруються з ним.
У цьому режимі dnsmasq може служити DHCP і роздавати DNS-сервери, але клієнти все одно використовують локальний stub-resolver.

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

Архітектура C: dnsmasq як локальний кеш на кожній машині

Зазвичай цього не варто робити. Якщо ви це зробите, ви по суті створите N малих кешів з N наборами upstream-правил.
Налагодження перетворюється на інтерпретативний танець.

Думка: Для більшості малих мереж оберіть Архітектуру A. Вона простіша, придатна для налагодження і може бути високо надійною з мінімальними зусиллями.

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

Чиста конфігурація dnsmasq (кеш DNS + DHCP) для LAN

Припущення для цієї конфігурації:

Сервер Linux із запущеним dnsmasq
Інтерфейс LAN: eth0
Підмережа LAN: 192.168.50.0/24
LAN IP dnsmasq: 192.168.50.1
Локальний домен: lan
Upstream DNS: 1.1.1.1 та 9.9.9.9 (замініть за потреби)

Основні принципи, закладені в конфіг

Явно прив’язатися до інтерфейсу/IP LAN, щоб випадково не стати «DNS для всесвіту».
Не читати випадковий стан резолвера, якщо ви цього не маєте на меті. Якщо ви покладаєтесь на /etc/resolv.conf, ви успадковуєте його хаос.
Будьте явними щодо локального домену та локальних імен.
Логуйте лише те, що потрібно, і знайте, як увімкнути логування під час інцидентів.

dnsmasq.conf (чистий базовий)

cr0x@server:~$ sudo tee /etc/dnsmasq.d/lan.conf >/dev/null <<'EOF'
# ---- Identity & safety rails ----
domain-needed
bogus-priv
no-hosts
no-resolv

# Bind only where we intend to serve
interface=eth0
listen-address=192.168.50.1
bind-interfaces

# ---- Upstream DNS ----
server=1.1.1.1
server=9.9.9.9

# ---- Local DNS behavior ----
domain=lan
local=/lan/
expand-hosts
cache-size=10000
neg-ttl=60

# If you want local names from /etc/hosts, do it intentionally:
addn-hosts=/etc/dnsmasq.hosts

# ---- DHCPv4 ----
dhcp-authoritative
dhcp-range=192.168.50.50,192.168.50.199,255.255.255.0,12h
dhcp-option=option:router,192.168.50.1
dhcp-option=option:dns-server,192.168.50.1
dhcp-option=option:domain-name,lan
dhcp-option=option:ntp-server,192.168.50.1

# Example static lease: MAC,IP,hostname,lease-time
dhcp-host=AA:BB:CC:DD:EE:FF,192.168.50.10,nas,24h

# ---- Logging (keep default quiet; enable when diagnosing) ----
log-async=20
#log-queries
#log-dhcp
EOF

Кілька нотаток, що економлять реальний час:

no-resolv означає «я не довіряю /etc/resolv.conf». Добре. Вам не слід, якщо ви його не контролюєте.
bind-interfaces разом з listen-address запобігають випадковому оголошенню на VPN-інтерфейсах або docker-бриджах.
dhcp-authoritative — як ви перестанете клієнтів чіплятися за застарілі лізи після переконфігурації. Використовуйте лише якщо ви дійсно авторитет DHCP для цієї підмережі.
cache-size=10000 — розумно на сучасному обладнанні. Маленький кеш перетворює DNS на підсилювач затримки.

Локальні записи хостів (навмисно окремо)

cr0x@server:~$ sudo tee /etc/dnsmasq.hosts >/dev/null <<'EOF'
192.168.50.1   gw gw.lan
192.168.50.10  nas nas.lan
192.168.50.20  build build.lan
EOF

Тримати локальні імена dnsmasq окремо від /etc/hosts — операційний вибір: це зменшує випадкове зв’язування з поведінкою системного резолвера.
Коли ви налагоджуєте о 2-й ранку, ви хочете менше рухомих частин, а не більше.

Увімкнути і перезапустити

cr0x@server:~$ sudo systemctl enable --now dnsmasq
...output...

Якщо ви бачите «failed», не гадати. Перейдіть до розділу завдань і перевірте прив’язку порту, синтаксис конфігу та конкуренцію сервісів.

Припиніть конфлікт із ОС: systemd-resolved, NetworkManager, resolvconf

Корінь більшості конфліктів: порт 53 і /etc/resolv.conf

На багатьох сучасних дистрибутивах Linux systemd-resolved запускає stub-resolver на 127.0.0.53:53.
Це нормально — поки ви не намагаєтеся запустити dnsmasq на тому ж хості й також прив’язатися до порту 53 на 0.0.0.0 або localhost.

Друга проблема — /etc/resolv.conf. Воно може бути:

простим файлом, яким керуєте ви,
симлінком на stub-файл systemd-resolved,
керованим resolvconf,
перезаписуваним NetworkManager,
або всім вищезгаданим по черзі під час завантаження.

Як співіснувати з systemd-resolved (без драм)

Варіант 1 (поширений): dnsmasq обслуговує LAN на 192.168.50.1; systemd-resolved залишається для локального stub-резолвера. Конфлікту немає, якщо dnsmasq не прив’язується до 127.0.0.1.
Це те, що забезпечує listen-address=192.168.50.1.

Варіант 2 (якщо ви хочете, щоб dnsmasq був локальним резолвером): вимкніть systemd-resolved і керуйте /etc/resolv.conf самі.
Це добре на виділеному сервері. Погана ідея на ноутбуці з VPN, який очікує systemd-resolved.

Підводний камінь NetworkManager

NetworkManager може запускати власний екземпляр dnsmasq для кешування на клієнті. Це не те саме, що ваш серверний dnsmasq,
але може заплутати налагодження, бо «dnsmasq працює» може означати неправильний процес.

Якщо ваш сервер використовує NetworkManager, будьте явними щодо обробки DNS (або дозвольте NM керувати, або ні).
Не дозволяйте йому напівкерувати.

Жарт №2: Найпростіший спосіб протестувати DNS — запитати трьох людей, як це працює, — і спостерігати, як всі впевнено не погодяться.

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

Це реальні операційні завдання. Кожне включає: команду, що означає вивід, і наступні кроки.
Виконуйте їх на хості dnsmasq, якщо не зазначено інше.

Завдання 1: Підтвердити, що dnsmasq запущений і не перезапускається

cr0x@server:~$ systemctl status dnsmasq --no-pager
● dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
     Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2025-12-31 09:12:01 UTC; 2h 10min ago
   Main PID: 1324 (dnsmasq)
      Tasks: 1 (limit: 18956)
     Memory: 6.4M
     CGroup: /system.slice/dnsmasq.service
             └─1324 /usr/sbin/dnsmasq -k

Значення: «active (running)» із стабільним часом роботи означає, що демон не падає/не перезапускається.
Рішення: Якщо час роботи — секунди/хвилини, переходьте одразу до journalctl (Завдання 2) і тесту конфігу (Завдання 3).

Завдання 2: Прочитати останні помилки dnsmasq

cr0x@server:~$ sudo journalctl -u dnsmasq -n 80 --no-pager
Dec 31 09:11:59 server dnsmasq[1312]: failed to bind DHCP server socket: Address already in use
Dec 31 09:12:00 server systemd[1]: dnsmasq.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
Dec 31 09:12:00 server systemd[1]: dnsmasq.service: Failed with result 'exit-code'.

Значення: Інший DHCP-сервер вже прив’язаний (часто isc-dhcp-server або роутер все ще працює на сегменті).
Рішення: Визначте, хто володіє UDP/67 (Завдання 4) і зупиніть/вимкніть конкурента DHCP у цій мережі. Не «обходьте» це.

Завдання 3: Перевірити синтаксис конфігу dnsmasq перед перезапуском

cr0x@server:~$ sudo dnsmasq --test
dnsmasq: syntax check OK.

Значення: Синтаксис в порядку; runtime-помилки ймовірно через прив’язку портів, права або середовище.
Рішення: Якщо ви отримали «bad option» або помилку парсингу файлу — виправте її перед перезапуском; не грайте в рулетку з конфігом у проді.

Завдання 4: Перевірити, хто слухає порти DNS і DHCP

cr0x@server:~$ sudo ss -ulpn | egrep ':(53|67)\s'
udp   UNCONN 0      0             192.168.50.1:53        0.0.0.0:*    users:(("dnsmasq",pid=1324,fd=6))
udp   UNCONN 0      0               0.0.0.0:67        0.0.0.0:*    users:(("dnsmasq",pid=1324,fd=4))

Значення: dnsmasq володіє UDP/53 на LAN IP і UDP/67 для DHCP.
Рішення: Якщо ви бачите systemd-resolved на 0.0.0.0:53 або інший процес на :67, у вас є конфлікт, який треба вирішити передусім.

Завдання 5: Підтвердити, що /etc/resolv.conf — це те, що ви думаєте

cr0x@server:~$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Dec 31 08:58 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

Значення: Цей хост використовує stub-резолвер systemd-resolved.
Рішення: Це нормально, якщо dnsmasq — лише для LAN на 192.168.50.1. Якщо ви хочете, щоб сам хост використовував dnsmasq, змініть стратегію резольвера свідомо.

Завдання 6: Перевірити доступність upstream DNS із сервера

cr0x@server:~$ dig +time=1 +tries=1 @1.1.1.1 example.com A
; <<>> DiG 9.18.24 <<>> +time=1 +tries=1 @1.1.1.1 example.com A
;; ANSWER SECTION:
example.com.        86400   IN      A       93.184.216.34
;; Query time: 18 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)

Значення: Upstream досяжний і відповідає швидко.
Рішення: Якщо це таймаутить — проблема не в dnsmasq, а в маршрутизації, фаєрволі або проблемі upstream. Виправте це спочатку.

Завдання 7: Перевірити, що dnsmasq відповідає локально (на сервері)

cr0x@server:~$ dig +short @192.168.50.1 nas.lan
192.168.50.10

Значення: Локальне розв’язування імен працює.
Рішення: Якщо локальні імена не працюють, перевірте local=/lan/, domain=lan і чи читається файл addn-hosts.

Завдання 8: Переконатися, що кешування дійсно відбувається

cr0x@server:~$ sudo kill -USR1 $(pidof dnsmasq)
cr0x@server:~$ sudo journalctl -u dnsmasq -n 30 --no-pager
Dec 31 11:18:10 server dnsmasq[1324]: cache size 10000, 8121/10000 cache insertions re-used unexpired cache entries.

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

Завдання 9: Слідкувати за орендами DHCP в реальному часі

cr0x@server:~$ sudo tail -n 20 /var/lib/misc/dnsmasq.leases
1735643551 11:22:33:44:55:66 192.168.50.73 laptop *
1735644012 aa:bb:cc:dd:ee:ff 192.168.50.10 nas *

Значення: Лізи призначаються. Поля: епоха закінчення, MAC, IP, hostname, client-id.
Рішення: Якщо клієнт не отримує адресу, і його немає тут — проблема доступності DHCP (VLAN, фаєрвол, конкуренція DHCP).

Завдання 10: Підтвердити, що клієнт отримав правильний DNS-сервер від DHCP

cr0x@server:~$ ipconfig getpacket en0
...output...

Значення: На macOS це показує DHCP offer/ack включаючи DNS-сервери. На Linux використовуйте Завдання 11.
Рішення: Якщо DNS-сервер не 192.168.50.1, ваші DHCP-опції неправильні або інший DHCP-сервер перемагає.

Завдання 11: На Linux-клієнті перевірити, який DNS використовується

cr0x@server:~$ resolvectl status
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Link 2 (eth0)
    Current Scopes: DNS
         DNS Servers: 192.168.50.1
          DNS Domain: lan

Значення: systemd-resolved активний, але використовує dnsmasq як upstream DNS для цього лінку. Це нормально й здорово.
Рішення: Якщо показано тільки 127.0.0.53 без upstream, вам бракує DHCP-переданого DNS або конфігурації NM.

Завдання 12: Перевірити, що клієнт може розв’язувати через dnsmasq і виміряти затримку

cr0x@server:~$ dig @192.168.50.1 example.com A +stats
...output...
;; Query time: 3 msec

Значення: Низький час запиту вказує на hit кешу або швидкий upstream. Якщо запустити двічі, другий повинен бути швидшим (cache hit).
Рішення: Якщо час запиту сотні мс або таймаути, перевірте стан upstream, втрату пакетів, MTU/VPN і чи DNS перехоплюється.

Завдання 13: Перевірити, чи ви «витікаєте» DNS запити не на той інтерфейс

cr0x@server:~$ sudo tcpdump -ni eth0 udp port 53 -c 10
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
10 packets captured

Значення: Ви бачите DNS-трафік на LAN-інтерфейсі. Якщо нічого не бачите, поки клієнти скаржаться, вони не запитують ваш dnsmasq.
Рішення: Виправте DHCP-опції або налаштування резольвера на клієнті. Не налаштовуйте dnsmasq під трафік, якого він ніколи не бачить.

Завдання 14: Знайти «зловмисний» DHCP-сервер у LAN

cr0x@server:~$ sudo nmap --script broadcast-dhcp-discover -e eth0
Starting Nmap 7.94 ( https://nmap.org ) at 2025-12-31 11:41 UTC
Pre-scan script results:
| broadcast-dhcp-discover:
|   Response 1 of 2:
|     IP Offered: 192.168.50.120
|     DHCP Server Identifier: 192.168.50.1
|   Response 2 of 2:
|     IP Offered: 192.168.50.210
|     DHCP Server Identifier: 192.168.50.254

Значення: Відповіли два DHCP-сервери. Це ваша історія відмови ще до того, як вона стала інцидентом.
Рішення: Вимкніть DHCP на роутері (192.168.50.254) або перенесіть dnsmasq в інший VLAN/підмережу. Не запускайте змагання DHCP.

Завдання 15: Підтвердити, що фаєрвол дозволяє DHCP і DNS

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain input {
    type filter hook input priority 0;
    policy drop;
    iif "lo" accept
    ct state established,related accept
    iif "eth0" udp dport { 53, 67 } accept
    iif "eth0" tcp dport 53 accept
  }
}

Значення: DNS і DHCP дозволені на LAN-інтерфейсі.
Рішення: Якщо UDP/67 заблоковано — DHCP не працюватиме. Якщо UDP/53 заблоковано — більшість DNS не працюватиме. Виправте правила до того, як чіпати dnsmasq.

Завдання 16: Перевірити шлях DHCP-запиту з клієнта (Linux)

cr0x@server:~$ sudo dhclient -v -r eth0
...output...
cr0x@server:~$ sudo dhclient -v eth0
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3
DHCPOFFER of 192.168.50.73 from 192.168.50.1
DHCPREQUEST for 192.168.50.73 on eth0 to 255.255.255.255 port 67
DHCPACK of 192.168.50.73 from 192.168.50.1
bound to 192.168.50.73 -- renewal in 19958 seconds.

Значення: Клієнт отримує offers/acks від вашого сервера dnsmasq.
Рішення: Якщо ви бачите offers від іншого сервера — конкуренція DHCP. Якщо немає offers — проблема L2/VLAN/фаєрвол.

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

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

Спочатку: встановіть, хто відповідає

Запустіть Завдання 14 (broadcast DHCP discover). Якщо є два DHCP-сервери — зупиніться. Вирішіть це спочатку.
На хості dnsmasq запустіть Завдання 4 (хто володіє портами 53 і 67). Якщо dnsmasq не прив’язаний як очікується — зупиніться. Виправте конфлікти прив’язки.
На клієнті запустіть Завдання 11 (resolvectl status або еквівалент), щоб побачити, який DNS-сервер він фактично використовує.

По-друге: перевірте, що сервер здоровий

Завдання 1 + Завдання 2: статус сервісу і логи. Якщо він флапає, не чіпайте клієнтів поки не вирішите проблему.
Завдання 3: синтакс-чек конфігу. Це ловить «я поміняв один рядок опівночі» помилки.
Завдання 6: досяжність upstream DNS. Якщо upstream впав, кеш може тимчасово маскувати це; не обманюйтеся.

По-третє: перевірте шлях пакетів

Завдання 13: tcpdump на LAN-інтерфейсі для DNS-трафіку. Відсутність пакетів означає, що клієнти вас не питають.
Завдання 16: DHCP-хендшейк від клієнта. Якщо немає DHCPOFFER — проблема L2/VLAN/фаєрвол.
Завдання 15: перевірка правил фаєрволу.

По-четверте: ізолюйте «повільне» від «зламаного»

Завдання 12: dig +stats двічі. Перший виклик тестує upstream; другий — кеш.
Завдання 8: статистика кешу через USR1. Підтверджує, що кеш використовується.

Цей план навмисно нудний. У цьому суть: він дозволяє не витрачати час на неправильному рівні.

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

1) «DHCP працює, але DNS випадково час від часу таймаутить»

Симптом: Клієнти отримують IP, але розв’язування імен переривчасте або повільне.

Корінь проблеми: Клієнти не використовують dnsmasq для DNS (неправильна DHCP-опція) або використовують зламаний upstream-резольвер через політику VPN.

Виправлення: Перевірте, чи DHCP видав option:dns-server,192.168.50.1 (Завдання 10/11). Потім перевірте, чи трафік потрапляє на dnsmasq (Завдання 13). Якщо є split DNS VPN — вирішіть, чи VPN має перевизначати LAN DNS, і налаштуйте розділену переадресацію явно.

2) «dnsmasq не стартує: address already in use»

Симптом: systemd показує, що dnsmasq впав; логи згадують помилки bind.

Корінь проблеми: systemd-resolved (або інший DNS-сервер) займає порт 53, або інший DHCP-сервер займає порт 67.

Виправлення: Використайте Завдання 4, щоб ідентифікувати процес. Якщо вам потрібен dnsmasq лише на LAN IP — задайте listen-address=192.168.50.1 і уникайте localhost. Якщо потрібен localhost також — навмисно відключіть конкурентний сервіс.

3) «Клієнти отримують неправильний шлюз за замовчуванням»

Симптом: Деякі клієнти можуть розв’язувати імена, але не можуть дістатися до інтернету або інших VLAN.

Корінь проблеми: Неправильна dhcp-option=option:router, або конкуренція DHCP, що роздає інший шлюз.

Виправлення: Запустіть Завдання 14, щоб знайти зловмисний DHCP. Потім виправте option:router. Підтвердіть на клієнті через інспекцію DHCP-пакету (Завдання 10/16).

4) «Локальні імена не резолвляться, а зовнішні — так»

Симптом: example.com резолвиться нормально; nas.lan — ні.

Корінь проблеми: Відсутній local=/lan/ або неправильний domain=lan; локальний hosts-файл не читається; або на клієнті не виставлено пошуковий домен.

Виправлення: Перевірте локальні відповіді dnsmasq (Завдання 7). Переконайтеся, що DHCP роздає option:domain-name,lan. Якщо ви не хочете пошукових доменів — навчіть користувачів використовувати FQDN, наприклад nas.lan, і рухайтеся далі.

5) «Після зміни нічого не оновлюється годинами»

Симптом: Ви змінили запис або upstream, але клієнти продовжують отримувати старі відповіді.

Корінь проблеми: TTL і кешування (dnsmasq, кеш клієнтів, кеши браузерів), плюс довгі DHCP-лізи при зміні DNS-сервера.

Виправлення: Зменште TTL для записів, які плануєте переміщувати. Для екстрених випадків перезапустіть dnsmasq (очищує кеш) і змініть лізи клієнтів. Не тримайте постійно 5-хвилинні лізи, щоб «вирішити» проблеми управління змінами.

6) «DNS добре з сервера, але з клієнтів — ні»

Симптом: dig @192.168.50.1 працює на сервері, але клієнти таймаутять.

Корінь проблеми: Фаєрвол блокує UDP/53, неправильна прив’язка інтерфейсу, VLAN-ізоляція або клієнт не вказує сервер.

Виправлення: Завдання 15 (фаєрвол), Завдання 4 (прив’язка), Завдання 13 (tcpdump), а потім перевірте DHCP-опції на клієнті.

7) «DNS ламається тільки при підключеному VPN»

Симптом: Внутрішні корпоративні імена резолвяться, але LAN-імена перестають (або навпаки).

Корінь проблеми: Політика split DNS перевизначає налаштування, або VPN-клієнт змінює порядок резолверів/пошукові домени.

Виправлення: Визначте політику: чи VPN має перевизначати все, чи лише певні домени? Реалізуйте розділену переадресацію в dnsmasq за допомогою доменно-орієнтованих server=/corp.example/10.0.0.53, або дозвольте systemd-resolved обробляти це і тримайте dnsmasq лише для LAN-клієнтів.

Три корпоративні історії з практики

Інцидент через неправильне припущення: «Роутер — лише роутер»

Середній офіс переїхав у нове приміщення. Мережевий підрядник лишив після себе блискучий роутер/фаєрвол-апарат.
Внутрішня команда разом підняла невеликий Linux VM для dnsmasq, бо хотіла послідовні імена для dev-китів і принтерів.
Вони припустили, що пристрій «лише маршрутизує» і що старий DHCP сервіс вимкнений під час переналаштування.

Вранці все працювало. Вдень почали зникати дисплеї в конференц-залі.
Деякі ноутбуки отримували очікуваний DNS-сервер. Інші — налаштування DNS від пристрою.
Люди звинувачували Wi‑Fi. Люди завжди звинувачують Wi‑Fi.

Підказка була нудною: у клієнтів з’являлися два різні шлюзи за замовчуванням, залежно від того, хто останнім оновив ліз.
Пристрій все ще працював як DHCP на тій же VLAN і роздавав власні опції шлюзу і DNS.

Виправлення було не винахідливим. Вони запустили broadcast DHCP discover, підтвердили двох респондентів і вимкнули DHCP на апараті.
Потім примусово оновили лізи на проблемних пристроях. «Випадковість» зникла миттєво.

Урок: ніколи не припускайте, що крайовий пристрій не виконує DHCP. Перевірте це. Пристрої люблять функції так само, як діти — фломастери.

Оптимізація, що вийшла боком: «Зменшимо запити upstream майже до нуля»

В іншій організації команда агресивно налаштувала кеш dnsmasq і додала списки пошукових доменів, щоб «покращити зручність».
Їхня ідея була проста: великий кеш, довгі TTL, і список пошуку, щоб люди могли вводити короткі імена.
Вони також увімкнули постійне логування запитів, бо «це корисно». І воно було корисним.

Через два тижні почали надходити відгуки про повільні входи в SaaS, переривчасті збої при розв’язуванні деяких доменів,
і періодичний високий IO wait на VM. CPU був в порядку. NIC був в порядку. Диск сумував.

Постійне логування запитів породило великий потік у journald і на підлеглий накопичувач.
Списки пошуку множили запити: помилки і короткі імена розширювалися в кілька невдалих запитів за спробу.
Негативне кешування завершило справу — тимчасові NXDOMAIN відповіді upstream зависали довше, ніж команда очікувала.

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

Виправлення: відключити постійне log-queries, зберігати його як перемикач під час інцидентів, і обрізати списки пошуку.
Вони залишили розумний розмір кеша, але припинили намагатися зробити DNS невидимим через хитрощі.

Нудна, але правильна практика, що врятувала ситуацію: «Явно прив’язуй, документуй власність»

Фінансова компанія мала невеликий флот філіальних серверів. Кожна філія мала локальний dnsmasq, що надавав DHCP і кеш DNS,
бо WAN-лінії були ненадійні і затребувані додатки були чутливі до затримок.
Стандарт конфігу був нудним: dnsmasq прив’язувався тільки до LAN-інтерфейсу, upstream-резольвери були явні,
і DHCP був авторитетним точно на одній VLAN на філію.

Одного дня аварійний розгорт VPN додав новий тунельний інтерфейс до кожного сервера. Раптом багато сервісів почали прив’язуватися до додаткових інтерфейсів.
Ось як «тільки-внутрішній» стає «доступним з місць, яких ви не уявляли».

dnsmasq не втрався. Воно вже було прив’язане до LAN IP через listen-address і bind-interfaces.
Воно не стало відповідати на DNS на VPN-інтерфейсі і не витікало локальні імена в невідповідне місце.

Інші сервіси проявили некоректну поведінку і були оперативно виправлені. DNS і DHCP продовжували працювати тихо у фоні.
Філії помітили зміни VPN; вони не помітили стабільності своїх базових мережевих сервісів.
Це комплімент, який не отримаєш у системі тикетів.

Урок: нудна практика — явні прив’язки, явні upstream, явна власність — окупається саме тоді, коли середовище несподівано змінюється.

Контрольні списки / покроковий план

План A: Розгорнути dnsmasq як LAN кеш DNS + DHCP (рекомендується)

Визначте межу відповідальності.
Вирішіть, за які підмережі dnsmasq буде відповідати в DHCP. Вимкніть DHCP в інших місцях на цьому сегменті.
Виберіть область прослуховування.
Оберіть LAN IP і інтерфейс. Використайте listen-address і bind-interfaces.
Напишіть мінімальний конфіг.
Почніть з базового конфігу з цієї статті. Уникайте розростання функцій.
Перевірте синтаксис.
Запустіть dnsmasq --test перед перезапуском.
Запустіть сервіс і перевірте порти.
Використайте ss -ulpn, щоб підтвердити, що dnsmasq володіє UDP/53 і UDP/67 як планувалося.
Перевірте пропозиції DHCP.
Використайте клієнт з dhclient -v або запустіть broadcast DHCP discover-скан.
Перевірте відповіді DNS.
Тестуйте як локальні імена (наприклад, nas.lan), так і зовнішні домени.
Увімкнюйте логування лише при потребі.
Тримайте log-queries закоментованим за замовчуванням; вмикайте під час інцидентів, потім вимикайте.
Задокументуйте, як ніби забудете.
Одна сторінка: які підмережі обслуговуються, де живе конфіг, хто відповідає за upstream DNS і як виявити зловмисний DHCP.

План B: Міграція з «DHCP на роутері» до dnsmasq без сюрпризного простою

За день до міграції тимчасово зменшіть час ліз роутера (наприклад, до кількох годин).
Підніміть dnsmasq у режимі «тільки DNS» спочатку (не вмикайте DHCP). Перевірте поведінку DNS.
Заплануйте коротке вікно переключення.
Вимкніть DHCP на роутері.
Увімкніть DHCP dnsmasq з dhcp-authoritative і правильними опціями.
На кількох тестових клієнтах оновіть лізи і перевірте DNS/шлюз.
Спостерігайте файл ліз і логи першу годину. Очікуйте, що деякі клієнти вперто триматимуть старі лізи; примусово оновіть при потребі.
Поверніть розумний час ліз (наприклад, 12h або 24h) після стабілізації.

План C: Зробити систему стійкою (без перетворення на проєкт)

Розмістіть dnsmasq на стабільному хості (невеликий VM, NUC або енергозалежний сервер) з UPS, якщо це важливо.
Тримайте конфіг в репозиторії. Навіть приватний git на боксі краще, ніж «я думаю, що я змінював це минулого місяця».
Резервуйте /etc/dnsmasq.d і файли ліз, якщо статичні відповідності важливі.
Моніторте: стан сервісу, затримку запитів (синтетичний dig) і втрату пакетів у LAN.

Поширені питання (FAQ)

1) Чи варто вимикати systemd-resolved на клієнтах?

Зазвичай ні. У керованих парках і на ноутбуках з VPN-клієнтами systemd-resolved часто є точкою інтеграції.
Дозвольте йому працювати і просто переконайтеся, що він використовує ваш dnsmasq як upstream DNS для LAN-лінку.

2) Чи варто вимикати systemd-resolved на сервері dnsmasq?

Якщо dnsmasq виділений і ви хочете, щоб він був також резольвером самого сервера, вимкнення systemd-resolved може спростити речі.
Але не обов’язково — просто переконайтеся, що dnsmasq не прив’язується до localhost, якщо systemd-resolved його займає.

3) Чому використовувати `no-resolv` і явні `server=` записи?

Бо /etc/resolv.conf часто керується іншими компонентами і може змінитися під час завантаження, підключення VPN або зміни лінка.
Явні upstream роблять поведінку передбачуваною і пришвидшують налагодження.

4) Який розмір кеша обрати?

Для малих мереж 5 000–20 000 зазвичай достатньо. Якщо у вас мало RAM, менший кеш теж підходить — просто не чекайте дива.
Оцінюйте за допомогою статистики USR1 і вимірювань затримки запитів до і після.

5) Чи може dnsmasq робити split DNS?

Так. Ви можете пересилати конкретні домени до специфічних upstream-резольверів за допомогою server=/corp.example/10.0.0.53.
Будьте явними і задокументуйте це, бо майбутній ви не згадає, чому тільки один домен поводиться інакше.

6) Як дізнатися, чи клієнти обходять dnsmasq?

Запустіть tcpdump на інтерфейсі сервера для UDP/53 (Завдання 13). Якщо клієнти скаржаться, а ви не бачите трафіку — вони вас не питають.
Потім перевірте DNS-настройки клієнта (Завдання 11) і DHCP-опції.

7) Чи безпечно запускати dnsmasq на хості з Docker або Kubernetes?

Може бути, але потрібно прив’язати dnsmasq до потрібного інтерфейсу/IP. Контейнерні стеки створюють додаткові інтерфейси,
і «слухати всюди» перетворюється на «відповідати DNS там, де не варто». Використовуйте listen-address і bind-interfaces.

8) Що з IPv6 (SLAAC, RA, DHCPv6)?

dnsmasq може допомогти з IPv6, але IPv6 вводить більше рухомих частин (router advertisements, DHCPv6, DNS через RDNSS).
Якщо ви тільки починаєте, спочатку зробіть IPv4 стабільним. Потім додайте IPv6 свідомо і тестуйте з захопленням пакетів.

9) Чи варто вмикати валідацію DNSSEC у dnsmasq?

Лише якщо ви розумієте режими відмов і маєте час їх налагоджувати. DNSSEC може підвищити цілісність,
але неправильні конфігурації і проблеми upstream можуть створити інциденти «все впало», що виглядають як мережеві проблеми.

10) Чи можна запустити два dnsmasq-сервера для відмовостійкості?

Для кешуючого/форвардингового DNS — так, клієнти можуть мати кілька DNS-серверів. Для DHCP відновлення складніше.
Можна розділити діапазони або використовувати механізми DHCP failover з іншим софтом, але dnsmasq сам по собі не є повноцінним enterprise DHCP HA рішенням.
Для малих мереж практичним рішенням часто є другий холодний запас і гарні резервні копії.

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

Якщо хочете, щоб dnsmasq поводився, припиніть дозволяти йому торгуватися за авторитет з тим, що встановлено в системі.
Виберіть архітектуру, прив’яжіть до правильного інтерфейсу, зробіть upstream DNS явними і переконайтеся, що DHCP має одного власника.
Це 80% історії надійності.

Запустіть перевірку на зловмисний DHCP (Завдання 14) у вашій LAN і усуньте дублювання серверів.
Впровадьте базовий конфіг і перевірте порти (Завдання 4) та синтаксис (Завдання 3).
Перевірте шлях клієнта: DHCP-хендшейк (Завдання 16) і активний DNS-сервер (Завдання 11).
Тримайте логування як інструмент за вимогою, а не як спосіб життя.
Запишіть власність: яка коробка DHCP, яка коробка DNS і яким має бути «нормальний» стан.

Вам не потрібен вишуканий стек, щоб мати надійне іменування та адресацію. Потрібна одна нудна коробка, що виконує свою роль, і система, яка їй не заважатиме.