Відповіді DNS REFUSED: ACL і політики, що блокують вас (і як виправити)

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

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

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

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

Що насправді означає REFUSED (і чого воно не означає)

У термінах DNS REFUSED — це RCODE (код відповіді), який каже: «Я не відповідаю на цей запит через локальну політику».
Не «я не знаю», не «ім’я не існує», і не «я зламався». Політика.

Два найпоширеніші непорозуміння:

REFUSED — це не NXDOMAIN. NXDOMAIN означає, що сервер виконав роботу і вирішив, що імені не існує.
REFUSED означає, що сервер навіть не спробував (або не розкриває результат) для вас.
REFUSED — це не SERVFAIL. SERVFAIL означає «я намагався, щось пішло не так». REFUSED — «ні, навмисно».

Хороша модель уяви: REFUSED — це швейцар серверу DNS, який контролює список гостей. Ваш запит може бути цілком валідним.
Ви навіть можете отримати відповідь від того ж сервера, якщо запитаєте з іншого IP, через інтерфейс, з правильним TSIG-ключем
або з увімкненою рекурсією для вашої мережі.

Де ви це побачите

Ви побачите REFUSED у таких інструментах, як dig, як status: REFUSED, часто з невеликою відповіддю і без секції answer.
Деякі клієнти приховують це під неясними повідомленнями, наприклад «server refused» або «DNS name does not exist» (що є неточним, до речі).

Навіщо це важливо

REFUSED зазвичай означає, що безпека працює так, як задумано: немає відкритих резолверів, немає передач зон у світ, немає рекурсії для випадкових мереж,
немає витоку даних через split-horizon views. Інцидент відбувається, коли ця політика блокує не тих людей, або коли архітектура покладається
на поведінку (рекурсія, форвардинг, трансфер, оновлення), яка ніколи не була дозволена.

Одна перефразована ідея від Gene Kim (автор з експлуатації/надійності): робіть роботу видимою й зменшуйте невизначеність, бо приховані черги й сюрпризи спричиняють відмови.
REFUSED часто — це «прихована політика», що стала видимою.

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

RCODEи старі: коди відповіді DNS походять з ранніх робіт над DNS у 1980-х роках, коли концепція «відмови через політику» вже існувала.
Відкриті резолвери стали глобальною проблемою: широке використання відкритих рекурсивних резолверів у відображувальних/підсилювальних атаках змусило операторів
за замовчуванням забороняти рекурсію для недовірених клієнтів.
За замовчуванням BIND змінювався з часом: старі конфігурації та скопійовані з блогів приклади можуть залишити рекурсію випадково відкритою або закритою,
залежно від версії та пакету дистрибутива.
Split-horizon DNS існував до бренду «zero trust»: подавати різні відповіді різним клієнтам — старий корпоративний трюк для приховування внутрішніх імен і маршрутизації трафіку.
EDNS(0) змінив правила гри: розширення DNS для підтримки більших UDP-відповідей відкрили нові політичні точки: розміри буферів, відкат на TCP і фільтрацію «дивних» EDNS-клієнтів.
DNSSEC ускладнив роботу резолверів: помилки валідації зазвичай дають SERVFAIL, але багато середовищ додають політичні шари (фаєрволи, RPZ),
які навмисно перетворюють деякі запити в REFUSED.
RPZ популяризував відповіді, керовані політикою: Response Policy Zones дозволили резолверам переписувати або блокувати відповіді (NXDOMAIN, CNAME на walled garden або поведінка, схожа на REFUSED).
Anycast зробив «той самий IP, різна політика» реальністю: з anycast DNS два користувачі можуть потрапити на різні інстанси з різними ACL, через що REFUSED здається непостійним.

Швидка схема діагностики

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

1) Підтвердьте, хто відмовляє: який сервер, який шлях, який протокол

Ви отримуєте REFUSED від локального stub (наприклад, systemd-resolved), корпоративного резолвера чи від авторитетного сервера?
Це тільки UDP? тільки TCP? лише через VPN? лише в одній підмережі?
Це по одному імені, одній зоні чи для всього трафіку?

2) Порівняйте поведінку з двох IP-адрес

Те саме запитання з різних клієнтських мереж. Якщо в одній працює, а в іншій — REFUSED, майже напевне це ACL, view або «рекурсія дозволена для А, але не для Б».

3) Визначте, чи є тут рекурсія

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

4) Шукайте політичні рушії (RPZ, DNS firewall, views, геоправила)

Якщо відмова специфічна для імені (тільки деякі домени), вважайте це політикою. Якщо вона специфічна для клієнта (тільки певні підмережі), вважайте це ACL/view/зв’язування інтерфейсів.

5) Перевіряйте логи в останню чергу — але робіть це правильно

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

Жарт #1: Політика DNS як кавоварка в офісі — всі залежать від неї, але ніхто не відповідає, і коли вона погана, продуктивність падає.

Де генерується REFUSED: резолвер, авторитетний сервер чи проміжні пристрої

Рекурсивні резолвери

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

Рекурсія вимкнена або обмежена: сервер відповідатиме авторитетно для своїх зон, але відмовляє у рекурсії для зовнішніх клієнтів.
ACL забороняє клієнта: «access-control» (Unbound) або «allow-query/allow-recursion» (BIND) блокують джерело.
Політична зона / DNS-фаєрвол: RPZ або еквівалент відмовляє (або переписує) на основі домену.
Обмеження за швидкістю / захист від зловживань: деякі стекі відмовляють, коли ви перевищуєте пороги.

Авторитетні сервери

Авторитетні сервери відмовляють, коли запит поза межами того, що вони обслуговують, коли views обмежують, хто може питати, або коли виконується спеціальна операція:

AXFR/IXFR відмовлено: трансфери зон зазвичай відмовляються без явного allow-transfer і іноді TSIG.
Динамічне оновлення відмовлено: RFC2136 оновлення вимагають allow-update і зазвичай TSIG. Інакше — відмова.
ACL на запити: деякі авторитетні розгортання обмежують, хто може запитувати внутрішні зони.

Форвардери та «DNS посередині»

REFUSED також може надходити від форвардера (наприклад, CoreDNS, dnsmasq, systemd-resolved або хмарного DNS-проксі), який застосовує правила перед форвардингом,
або повертає REFUSED, отриманий від upstream.

Є також проміжні пристрої: фаєрволи, що виконують інспекцію DNS, «брендові шлюзи безпеки», які відповідають від імені DNS, або балансувальники навантаження з логікою health-check.
Вони можуть створити поведінку, схожу на REFUSED, що виглядає як рішення DNS-сервера, але насправді це мережевий пристрій.

Політики, що блокують: ACL, контроль рекурсії, RPZ, views, TSIG та інші

1) ACL клієнтів: «allow-query» та «allow-recursion» (BIND)

У BIND два перемикачі, які плутають людей, — це allow-query та allow-recursion. Вони не взаємозамінні.

allow-query: хто взагалі може ставити питання (для зон, що обслуговуються, і інколи глобально).
allow-recursion: хто може користуватися рекурсією (отримувати відповіді звідкись ще).

Сервер може відповідати авторитетно для corp.example, але відмовляти у рекурсії для інтернет-імен. Це нормально і правильно.
Проблеми виникають, коли ви розгортаєте «один резолвер для всіх» і забуваєте, що половина ваших клієнтів не в списку дозволених підмереж.

2) Unbound access-control: оманливо просто

Unbound зазвичай ясніший: ви визначаєте правила access-control для кожної підмережі й дії (allow/refuse/deny).
Але «ясніший» не означає «складно помилитися».

Якщо ви додасте широке правило refuse перед вужчим allow (або неправильно зрозумієте пріоритети збігів), ви можете відрізати регіон.
І в anycast-флоті ви можете відрізати тільки ті вузли, що підхопили зміну.

3) Views і split-horizon: правильна ідея, гострі краї

Views (BIND) або подібні конструкції дозволяють різні відповіді залежно від адреси джерела. Вони чудово підходять для:

внутрішніх і зовнішніх записів
приватних зон, доступних тільки через VPN
міграцій у хмару, коли ви спрямовуєте певні мережі на нові кінцеві точки

Вони також створюють типовий патерн REFUSED: клієнти потрапляють у «неправильний view» і отримують REFUSED, бо в цьому view немає рекурсії,
немає доступу до зони або встановлені суворіші ACL.

4) RPZ / DNS-фаєрвол: коли сервер відмовляє, бо ім’я «погане»

Багато підприємств запускають Response Policy Zones або подібні функції DNS-фаєрволу. Залежно від політики, заблокований домен може давати:
NXDOMAIN, IP walled-garden або інколи поведінку, схожу на відмову (або відмову з upstream політичного двигуна).

Якщо REFUSED специфічний для домену і послідовний для всіх клієнтів — підозрюйте RPZ або upstream безпековий резолвер. Якщо він доменно-специфічний і непослідовний —
підозрюйте кілька резолверів з різними версіями політик.

5) Передачі зон (AXFR/IXFR): за замовчуванням відмовлено

Якщо ви робите AXFR з випадкової робочої станції і отримуєте REFUSED — вітаю, хтось зробив щось правильно.
Трансфери повинні бути явно дозволені для вторинних серверів, часто з TSIG.

6) Динамічні оновлення: TSIG або нічого не відбудеться

RFC2136 оновлення потужні й небезпечні. Відмова тут зазвичай викликана відсутнім ключем, неправильним ключем, неправильним алгоритмом або неправильною політикою оновлення.

7) Зв’язування інтерфейсу та несподіванки з IP джерела

ACL DNS оцінюються за IP джерела. У NAT, VPN, Kubernetes і хмарних балансувальниках, «IP джерела, який ви думаєте, що маєте»
часто не відповідає IP, який бачить DNS-сервер.

REFUSED з’являється після зміни мережі, бо ACL не змінились разом із нею.

8) DNS через TCP / EDNS / фрагментація: політика випадково

Деякі середовища обмежують TCP/53 або блокують великі UDP-DNS відповіді. Коли резолвер пробує UDP, отримує truncation, повторює через TCP, а TCP блокується,
зазвичай ви бачите таймаути. Але деякі проміжні пристрої та проксі відповідають REFUSED або негайним відмовленням.

Не припускайте, що REFUSED — це виключно «проблема конфігурації DNS». Це може бути «мережна безпека вважає, що DNS має бути 512 байт назавжди».

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

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

Task 1: Reproduce with dig and capture the RCODE clearly

cr0x@server:~$ dig @10.20.30.40 www.example.com A +norecurse

; <<>> DiG 9.18.24 <<>> @10.20.30.40 www.example.com A +norecurse
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 59821
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;www.example.com.                IN      A

;; Query time: 2 msec
;; SERVER: 10.20.30.40#53(10.20.30.40) (UDP)
;; WHEN: Tue Dec 31 11:02:18 UTC 2025
;; MSG SIZE  rcvd: 56

Що це означає: DNS-сервер швидко відповів REFUSED. Мережевий шлях працює.

Рішення: Не витрачайте час на налагодження маршрутизації та файрволів першочергово. Почніть з перевірки ACL/політик на тому сервері або на шарі перед ним.

Task 2: Check if recursion is the issue (same query with recursion desired)

cr0x@server:~$ dig @10.20.30.40 www.example.com A +recurse

;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 3452
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

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

Рішення: Перевірте ACL клієнта та views. Якщо ви очікували авторитетну відповідь, переконайтеся, що ви запитуєте правильний сервер.

Task 3: Verify the server answers anyone else (compare from a known-good subnet)

cr0x@server:~$ dig @10.20.30.40 www.example.com A +short
93.184.216.34

Що це означає: З цього хоста відповідь працює. Отже DNS-сервер може відповідати; відмова специфічна для клієнта або шляху.

Рішення: Порівняйте IP джерел і NAT. Визначте, який IP сервер бачить від проблемного клієнта.

Task 4: Confirm what resolver your client is actually using

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

Що це означає: systemd-resolved задіяний; ваш «DNS-сервер» може бути stub, що форвардить далі.

Рішення: Запитуйте безпосередньо upstream резолвер, а не тільки 127.0.0.53, або перегляньте, куди resolved форвардить за допомогою resolvectl dns.

Task 5: Identify upstream DNS servers configured on the host (and surprises)

cr0x@server:~$ resolvectl dns
Global:
Link 2 (ens192): 10.20.30.40 10.20.30.41
Link 3 (tun0): 172.16.0.53

Що це означає: VPN-інтерфейс надав свій резолвер. REFUSED може виникати тільки коли VPN увімкнено і пріоритет маршрутів змінився.

Рішення: Повторно протестуйте, спрямовуючи запити на кожен резолвер IP безпосередньо. Визначте, чи неправильно застосовані правила split-DNS.

Task 6: Determine if you’re hitting an authoritative-only server

cr0x@server:~$ dig @10.20.30.40 corp.example SOA +norecurse

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11906
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
corp.example.     3600    IN      SOA     ns1.corp.example. hostmaster.corp.example. 2025123101 7200 3600 1209600 3600

Що це означає: Сервер авторитетний для corp.example (AA-флаг). Він може відмовляти у рекурсії для всього іншого за задумом.

Рішення: Якщо клієнти використовують цей сервер як загальний резолвер, виправте архітектуру: спрямовуйте клієнтів на рекурсивні резолвери, а не на авторитетні-only.

Task 7: Explicitly test recursion availability with a root hint style query

cr0x@server:~$ dig @10.20.30.40 . NS +recurse

;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 41223
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

Що це означає: Цей сервер відмовляє у рекурсії (або відмовляє вам). Запит кореня мав би обробляти рекурсивний резолвер.

Рішення: Перевірте налаштування recursion і ACL клієнтів. Підтвердіть, чи цей сервер має рекурсію для вашого джерела IP.

Task 8: Check BIND view matching and ACLs (server-side)

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

view "internal" {
        match-clients { 10.20.0.0/16; };
        recursion yes;
};

view "external" {
        match-clients { any; };
        recursion no;
};

Що це означає: Клієнти поза 10.20.0.0/16 потрапляють у «external» view з вимкненою рекурсією; вони можуть бачити REFUSED для рекурсивних запитів.

Рішення: Розширте match-clients, щоб включити потрібні мережі (VPN, NAT-діапазони), або спрямовуйте ті клієнти на правильний резолвер.

Task 9: Check Unbound access-control evaluation

cr0x@server:~$ sudo unbound-control list_local_zones
name type
. transparent
corp.example. transparent
blocked.example. static

Що це означає: Можуть існувати локальні зони і політики. Не всі відмови — це лише «ACL»; деякі — «локальна політика».

Рішення: Перегляньте unbound.conf на наявність access-control: і політичних зон; підтвердіть очікувану поведінку для заблокованих доменів.

Task 10: Inspect Unbound access-control lines quickly

cr0x@server:~$ sudo grep -nE '^(access-control|interface|do-tcp|do-udp)' /etc/unbound/unbound.conf
12:interface: 10.20.30.40
23:do-udp: yes
24:do-tcp: yes
41:access-control: 10.20.0.0/16 allow
42:access-control: 0.0.0.0/0 refuse

Що це означає: За замовчуванням відмовлено всім, крім 10.20.0.0/16. Якщо ваші клієнти тепер в 10.21.0.0/16, вони заблоковані.

Рішення: Додайте нову підмережу в allow або виправте NAT, щоб клієнти виглядали з дозволеного IP.

Task 11: Check if REFUSED is actually “AXFR denied”

cr0x@server:~$ dig @10.20.30.53 corp.example AXFR

; Transfer failed.

Що це означає: Трансфери заблоковані (і мають бути). Деякі сервери повертають REFUSED; dig лише повідомляє про невдачу.

Рішення: Якщо ви налаштовуєте вторинний сервер: реалізуйте allow-transfer на первинному та TSIG між ними. Не «тимчасово відкривайте для всіх».

Task 12: Validate BIND transfer permissions (server-side)

cr0x@server:~$ sudo named-checkconf -p | grep -n 'allow-transfer' -n
248:        allow-transfer { key "xfr-tsig"; 10.20.30.54; };

Що це означає: Трансфери дозволені тільки для 10.20.30.54 і тільки з TSIG-ключем. Якщо IP вторинного змінився — йому відмовлять.

Рішення: Оновіть список дозволених адрес і правильно розгорніть TSIG-ключ. Робіть це як контрольовану зміну, а не екстрений хаґ.

Task 13: Check dynamic update refusal due to missing TSIG

cr0x@server:~$ nsupdate -v <<'EOF'
server 10.20.30.53
zone corp.example
update add test01.corp.example 60 A 10.20.40.10
send
EOF
update failed: REFUSED

Що це означає: Сервер відмовляє в оновленнях без належної автентифікації. Добре.

Рішення: Використовуйте TSIG і update-policy. Якщо це мало працювати, клієнт не використовує правильний ключ або ви потрапляєте в неправильний view.

Task 14: Check server logs for explicit “denied” reason (BIND example)

cr0x@server:~$ sudo journalctl -u bind9 -n 20 --no-pager
Dec 31 11:02:18 ns1 named[1442]: client @0x7f9a64012a00 10.21.5.18#43812 (www.example.com): query (cache) 'www.example.com/A/IN' denied
Dec 31 11:02:18 ns1 named[1442]: client @0x7f9a64012a00 10.21.5.18#43812 (www.example.com): query failed (REFUSED) for www.example.com/IN/A at query.c:7750

Що це означає: Сервер явно відхилив кешований (рекурсивний) запит від 10.21.5.18.

Рішення: Додайте 10.21.0.0/16 до allow-recursion / allow-query-cache (або спрямовуйте ці клієнти на правильний резолвер).

Task 15: Prove NAT/source-IP mismatch (capture at the server)

cr0x@server:~$ sudo tcpdump -ni any port 53 and host 10.21.5.18 -c 3
tcpdump: data link type LINUX_SLL2
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
11:02:18.412345 ens192 In  IP 192.0.2.45.53512 > 10.20.30.40.53: 59821+ A? www.example.com. (32)
11:02:18.412912 ens192 Out IP 10.20.30.40.53 > 192.0.2.45.53512: 59821 Refused 0/0/1 (56)

Що це означає: «Клієнт» 10.21.5.18 насправді NAT-ований до 192.0.2.45 з точки зору DNS-сервера.

Рішення: Виправте ACL, щоб включити діапазон egress NAT, або налаштуйте мережу так, щоб зберегти оригінальний IP клієнта (де це можливо).

Task 16: Verify if a forwarder is returning REFUSED upstream

cr0x@server:~$ dig @10.20.30.10 www.example.com A +comments

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 51001
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

Що це означає: Форвардер заявляє, що рекурсія доступна (RA), але все одно відмовляє. Часто це вказує на політику (RPZ/безпека) або відмову upstream.

Рішення: Запитайте upstream форвардера (якщо відомий) або перевірте конфіг форвардера на предмет блокувань доменів і ACL.

Три корпоративні історії з реальних випадків

Міні-історія 1: Відмова через невірне припущення

Середнє підприємство тримало по два BIND-сервери в кожному датацентрі. Їх у каталозі позначали «DNS1/DNS2» і всі вважали їх взаємозамінними.
Одна пара була авторитетною для внутрішніх зон і одночасно робила рекурсію для клієнтів. Інша пара була тільки авторитетною для кількох делегованих зон, що використовувалися старою платформою.

Під час оновлення мережі команда змінила DHCP-скопи й випадково спрямувала велику підмережу офісу на пару авторитетних-only серверів.
Симптоми були вибіркові: внутрішні імена в corp.example резолвилися нормально, бо авторитетні сервери були для них. Все інше — входи в SaaS, репозиторії, API — почало повертати REFUSED.

Перші, хто реагував, гналися за фаєрволами та каналами провайдера. Вони бачили «REFUSED» і думали, що «віддалений DNS нас блокує».
Насправді DNS-сервери робили те, для чого їх створили: «Я авторитетний для цих зон; я не ваш рекурсивний резолвер».

Виправлення було нудним: поправили DHCP-опції і додали моніторинг, що перевіряє саме рекурсію на VIP резолвера, а не тільки «порт 53 відкритий».
Урок був жорсткіший: не називайте сервери за ролями неоднозначно. «DNS1» — це не роль; це зізнання.

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

Інша організація хотіла зменшити навантаження на резолвери. Хтось запропонував «розумний» підхід: спрямовувати філіали на регіональний форвардер,
далі — на центральні резолвери. На діаграмі виглядало акуратно: менше раундів, більше кешування на краю.

Вони реалізували dnsmasq-форвардер на маршрутизаторах філій з агресивним кешуванням і мінімальним ACL: дозволено лише підмережа філіалу.
Потім впровадили VPN. Віддалені ноутбуки заходили у мережу філіалу через тунель, але їхні IP-джерела були з іншого пулу.
dnsmasq на маршрутизаторі бачив «невідоме джерело» і миттєво повертав REFUSED.

Інцидент був болючим, бо був періодичним: деякі користувачі були на Wi‑Fi (NAT в дозволену зону), інші — на дротовому (без NAT),
хтось віддалено (тунель). Та сама машина, різний результат у різний час.

Вони вирішили прибрати кешування і політику з маршрутизатора: клієнти філіалу стали використовувати центральні резолвери напряму через VPN,
а маршрутизатор лише давав DHCP. Оптимізація не була злою; вона просто перемістила політику в найненадійніше місце системи.

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

Глобальне підприємство запускало anycast-рекурсивні резолвери зі строгими ACL і RPZ. У них також була бюрократична звичка:
кожна зміна політики резолверів вимагала «diff політики», прикріплений до заявки на зміну, плюс канарний rollout до одного сайту.

Одного дня інженер оновив дозволені діапазони клієнтів, щоб включити новий cloud VPC. Намір був вірний, але були помилки в деталях:
CIDR VPC додали в один файл оточення, але не в згенерований ACL для production.

Канарний сайт відразу показав REFUSED для клієнтів з того VPC. У runbook було чітке правило: запустити запит з інстансу в VPC,
підтвердити, що він потрапляє на канарний вузол, і переконатися, що status: NOERROR для рекурсії.
Інженер помітив невідповідність до розгортання по всьому флоту.

Жодної драми. Жодних зустрічей на рівні виконавчої ради. Просто відкорегували зміну і повторно розгорнули з правильною генерацією. Нудна практика перемогла знову.

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

Цей розділ навмисно конкретний. Узагальнена порада породжує узагальнені відмови.

1) Симптом: REFUSED для зовнішніх імен, внутрішні імена працюють

Корінна причина: клієнт використовує авторитетний-only сервер; рекурсія вимкнена; або клієнт потрапляє в view без рекурсії.
Виправлення: спрямувати клієнтів на рекурсивні резолвери; або ввімкнути рекурсію для потрібного view і налаштувати allow-recursion правильно.

2) Симптом: REFUSED тільки для VPN-користувачів

Корінна причина: ACL не включає VPN-пул; split-DNS налаштовано неправильно; VPN штовхає інший резолвер зі строгішою політикою.
Виправлення: включити VPN CIDR до allow-recursion/access-control; переконатися, що VPN-клієнти використовують потрібний резолвер; валідувати поведінку NAT.

3) Симптом: REFUSED тільки для одного домену (або категорії доменів)

Корінна причина: RPZ/DNS-фаєрвол; upstream безпековий резолвер; домен додано до «local-zone» як static block.
Виправлення: підтвердити наміри політики; додати виняток; синхронізувати політику по резолверах; документувати, хто відповідає за блокування.

4) Симптом: REFUSED після перенесення резолверів за балансувальник навантаження

Корінна причина: змінюється IP джерела (SNAT), тому ACL більше не збігаються; health-check-и надходять з недовіреного діапазону і їм відмовляють.
Виправлення: зберігайте IP джерела, де можливо; інакше додайте egress-діапазони LB до ACL; встановіть явний дозвіл для джерел health-check.

5) Симптом: AXFR/IXFR не проходить з “Transfer failed” або REFUSED

Корінна причина: відсутній allow-transfer; IP вторинного змінився; TSIG не співпадає; mismatch view (вторинний потрапляє в неправильний view).
Виправлення: додайте allow-transfer для коректних IP; використовуйте TSIG; перевірте, що обидві сторони погоджені щодо імені/алгоритму ключа; переконайтеся, що match-clients включає вторинний.

6) Симптом: Динамічні оновлення повертають REFUSED

Корінна причина: nsupdate без TSIG; update-policy не дозволяє ім’я; сервер не є первинним для тієї зони; неправильний view.
Виправлення: налаштуйте TSIG на клієнті; скоригуйте update-policy з принципом найменших привілеїв; надсилайте оновлення на первинний; перевірте вибір view.

7) Симптом: Деякі anycast-сайти відмовляють; інші відповідають

Корінна причина: непослідовне розгортання конфігурації/політики; локальні ACL; різні upstream форвардери; неповна реплікація RPZ.
Виправлення: забезпечте збіг конфігів; додайте per-site smoke-тести; ідентифікуйте вузол, що обслуговував запит, через CHAOS TXT або тегування інстансу.

8) Симптом: REFUSED зростає лише під навантаженням

Корінна причина: rate limiting налаштовано на відмову; захист від зловживань; upstream відмовляє через поведінку вашого резолвера (занадто багато клієнтів за одним NAT).
Виправлення: налаштуйте rate limiting; виправте fan-in NAT; додайте більше egress IP; переконайтеся, що ви не поводитесь як ботнет.

Жарт #2: Якщо ви «тимчасово» дозволите рекурсію для any, інтернет негайно запрошує RSVP.

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

Покроково: ізолюйте шар, що відмовляє

Запитайте через dig на налаштований резолвер. Зафіксуйте IP сервера, статус, прапори, UDP/TCP.
Обійдіть stub. Якщо використовується systemd-resolved, запитуйте реальні upstream IP резолверів напряму.
Запитайте те саме ім’я з двох мереж. LAN офісу проти VPN, або один pod проти однієї VM. Зверніть увагу на відмінності.
Запитайте авторитетну зону, яку ви очікуєте. Переконайтеся, що AA-флаг з’являється там, де потрібно; підтвердіть роль сервера.
Перевірте рекурсію явно. Запитайте корінь або явно зовнішній домен з +recurse.
Перевірте логи сервера на «denied/refused». Підтвердіть IP джерела, який бачить сервер.
Валідуйте NAT і маршрутизацію. Захоплення пакетів на сервері може показати справжню адресу клієнта.
Визначте політичні шари. RPZ, views, DNS-фаєрвол upstream, ланцюги форвардингу.
Виправляйте з найменшими привілеями. Розширюйте ACL точно; уникайте відкриття рекурсії для широких діапазонів.
Регресійне тестування. Тестуйте з репрезентативного набору клієнтів. Потім моніторьте на предмет відкриття резолвера.

Чеклист: безпечні зміни, що зменшують інциденти REFUSED без послаблення безпеки

Визначте явні ролі резолверів: лише рекурсивний, лише авторитетний або змішаний (і задокументуйте це).
Підтримуйте інвентар клієнтських CIDR, яким дозволена рекурсія; оновлюйте його під час змін мережі.
Для VPN та хмари: вирішіть, чи зберігається IP джерела або NATиться; пишіть ACL відповідно до реальності.
Для anycast: забезпечте збіг конфігурацій і додавайте індикатор «версія політики» для кожного вузла.
Для RPZ: встановіть процес винятків і чітко призначеного власника політик.
Моніторьте зростання REFUSED і розбивайте за підмережею клієнта та типом запиту.
Тестуйте AXFR/IXFR і оновлення з вторинних/автоматизованих систем після кожної зміни DNS.

Чеклист: чого не робити (якщо ви не любите pager)

Не дозволяйте рекурсію для any, щоб «змусити працювати». Це шлях у звіт про відкритий резолвер.
Не виконуйте політику на маршрутизаторах філій, якщо ви не можете оновлювати й аудіювати їх як production.
Не припускайте, що «IP клієнта» — це те, що бачить сервер; перевіряйте логи або tcpdump.
Не змішуйте авторитетні й рекурсивні ролі легковажно; якщо змішуєте, документуйте намір і реалізуйте через views.

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

1) У чому різниця між REFUSED і NXDOMAIN?

NXDOMAIN означає, що сервер відповів і ім’я відсутнє в просторі імен, який він перевіряв. REFUSED означає, що сервер відмовився відповідати через політику.

2) Чи може авторитетний сервер повертати REFUSED на звичайні запити?

Так. Авторитетні сервери можуть обмежувати, хто може запитувати певні зони (тільки внутрішні), і звично відмовляють у AXFR/IXFR та динамічних оновленнях без дозволу.

3) Чому я отримую REFUSED тільки з певних підмереж?

Це майже завжди проблема ACL або match у view. Або ті підмережі не в allow-recursion/access-control, або вони потрапляють у view з вимкненою рекурсією.
NAT може зробити це випадковим, якщо видимий IP змінюється.

4) Чому dig показує «ra» (recursion available), але статус — REFUSED?

«RA» — це прапор можливості; це не означає, що рекурсія дозволена для вашого джерела. Багато резолверів здатні робити рекурсію, але відмовляють для неавторизованих клієнтів.
Деякі форвардери також пропускають RA, але застосовують власну політику.

5) Чи завжди REFUSED означає неправильну конфігурацію?

Ні. REFUSED часто — правильна позиція безпеки: відмовляти рекурсії в інтернеті, відмовляти трансфери зон широкому колу, відмовляти непідписаним оновленням.
Це стає проблемою, коли політика і очікувані користувачі розбігаються.

6) Як RPZ та DNS-фаєрволи пов’язані з REFUSED?

RPZ — це механізм політики, що може блокувати або переписувати DNS-відповіді на основі імені або відповіді. Залежно від реалізації та вибору політики,
клієнти можуть бачити NXDOMAIN, walled-garden запис або відмову, отриману від upstream політичного резолвера.

7) Чому Kubernetes-поди інколи бачать REFUSED, коли ноди — ні?

Поди зазвичай питають CoreDNS, який форвардить до upstream резолверів. Upstream може бачити IP ноди, NAT IP або IP хмарного NAT-шлюзу.
Якщо ACL рекурсії не включає той видимий IP, ви отримаєте REFUSED. Інша причина: плагіни політики CoreDNS або налаштування stub-доменів.

8) Який найбезпечніший спосіб «виправити» REFUSED для легітимних клієнтів?

Визначте точний діапазон IP джерел клієнтів так, як їх бачить сервер, потім додайте найвужче потрібне правило allow (для allow-recursion/access-control),
бажано в правильному view. Перевірте, що ви не створили відкритий резолвер. Тестуйте з кількох мереж.

9) Чи може DNSSEC спричинити REFUSED?

Помилки валідації DNSSEC зазвичай приводять до SERVFAIL, а не REFUSED. Але політичні шари навколо DNSSEC (резолвери безпеки, DNS-фаєрволи) можуть вирішити відмовити
певні поведінки або клієнтів. Розглядайте DNSSEC як фактор ускладнення, а не базову причину REFUSED.

10) Що краще: повертати REFUSED чи скидати пакети для заблокованих клієнтів?

Повернення REFUSED оперативно зручніше: клієнти швидко відпадають, і діагностика простіша. Скидання пакетів може виглядати як мережевий збій.
Якщо ви блокуєте зловмисний трафік у великому масштабі, скидання може бути доцільним, але для внутрішньої політики REFUSED зазвичай зменшує час інциденту.

Висновок: наступні кроки, що справді зменшують інциденти

REFUSED — це не таємничий код. Це рішення політики, а DNS повний політики: хто може робити рекурсію, хто може трансферити, хто може оновлювати,
які імена блокуються, які клієнти — для якого view. Коли REFUSED вам заважає, зазвичай це тому, що мережева реальність змінилася швидше, ніж ваша DNS-політика.

Зробіть наступне:

Визначте ролі резолверів (рекурсивний vs авторитетний) і припиніть спрямовувати клієнтів не туди.
Зробіть інвентар дозволених клієнтських діапазонів так, як їх бачить резолвер (включаючи NAT і VPN-пули).
Додайте регресійний тест, який запускає dig з кожного ключового клієнтського середовища і попереджає про сплески REFUSED.
Ставтеся до політики як до коду: конфіги, що можна дифити, канарний rollout і ясний власник правил RPZ/DNS-фаєрволу.

Мета не в тому, щоб усунути REFUSED. Мета — зробити відмови навмисними, задокументованими та передбачуваними — щоб блокувати було тільки небажаний трафік,
а не ваш бізнес.