Postfix “host not found”: проблеми DNS, що мовчки вбивають пошту

Що насправді означає “host not found” у Postfix

Postfix тут не метафорує. «Host not found» зазвичай означає, що він звернувся до резолвера із запитом і не отримав придатної відповіді. Така відповідь може бути «NXDOMAIN» (не існує), або «SERVFAIL» (сервер імен здався), або «timeout» (відсутня відповідь), або «no data» (домен існує, але запитуваного типу запису немає).

Найтиповіші місця, де ви побачите це:

• Вихідна доставка до віддалених отримувачів: Postfix намагається знайти MX для example.com, а потім A/AAAA для хостів MX.
• Вхідні SMTP-обмеження, такі як reject_unknown_client_hostname або reject_unknown_sender_domain, де Postfix робить запити під час SMTP-розмови.
• Локальний роутинг, коли ви використовуєте транспортні мапи або правила relayhost на основі DNS.

Звідки береться це повідомлення про помилку

Postfix використовує бібліотеки системного резолвера для більшості запитів. Тому формулювання «name service error» — це не дивацтво Postfix; воно часто піднімається з поведінки libc-резолвера, на яку впливають:

• вміст /etc/resolv.conf і search-домени
• локальні кешуючі резолвери (systemd-resolved, unbound, dnsmasq)
• мережевий шлях до зовнішніх резолверів
• збої валідації DNSSEC (якщо в ланцюжку)
• поведінка IPv6 (AAAA-запити можуть давати несподівано «гучний» ефект)

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

Переказна ідея (приписано): Джон Оллспо (John Allspaw) давно наголошує на операційному підході: надійність приходить через вивчення реальних способів відмов, а не через припущення, що вони не відбудуться.

Сприйміть це серйозно. Збої DNS — нормальна річ. Ваша поштові система має трактувати їх як звичайну турбулентність, а не як рідкісну катастрофу.

Швидкий план діагностики (перший/другий/третій)

Це послідовність «припиніть гадати». Виконуйте в порядку. Вона спроектована, щоб швидко знайти «вузьке місце»: то це конфіг Postfix, то локальний резолвер, то upstream DNS, чи віддалений домен?

Перший: підтвердьте помилку та ізолюйте цільовий домен

1. Знайдіть одне нещодавнє повідомлення в черзі та зафіксуйте домен отримувача й точний текст помилки.
2. Перевірте, чи це один домен чи багато. Один домен вказує на віддалений DNS; багато доменів — на проблему в шляху вашого резолвера.

Другий: тестуйте DNS з хоста, де працює Postfix (не з вашого ноутбука)

1. Виконайте dig MX та A/AAAA для домену отримувача і для цільових MX-хостів.
2. Повторіть запити до вашого налаштованого резолвера, а потім до відомого хорошого публічного резолвера (тимчасово, для діагностики). Відмінності мають значення.
3. Перевірте коди відповіді: NXDOMAIN, SERVFAIL та timeout — це різні типи відмов.

Третій: перевірте ланцюг локального резолвера і таймаути

1. Перегляньте /etc/resolv.conf та сервіси локального резолвера.
2. Перевірте збої DNSSEC, невідповідності split-horizon і проблеми маршрутизації IPv6.
3. Підтвердіть, що Postfix не ізольований у мережевому неймспейсі/контейнері з іншим DNS.

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

Факти й історія, що пояснюють сьогоднішні дивності

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

1. MX-записи ввели, щоб відокремити маршрутизацію пошти від адресації хостів. До появи MX доставка покладалася на A-записи та імпліцитні домовленості.
2. TTL у DNS задумували для ефективного кешування, а не для операційної прозорості. Коли хтось каже «ми виправили DNS», треба уточнювати «де і який TTL?»
3. Негативне кешування існує. NXDOMAIN теж кешується, тож транзієнтна помилка може тягнутися як поганий запах.
4. Резолвери часто повторюють запити по кількох серверах. Один ненадійний резолвер плюс один хороший може створювати інтермітентні відмови, що виглядають як «випадкові проблеми Postfix».
5. SMTP спроектовано для затримки. Тимчасові відмови очікуються; MTA ставлять у чергу й повторюють спроби. Це чудово — поки це не маскує інцидент.
6. Впровадження IPv6 спричинило «happy eyeballs» у багатьох стеків, але не завжди так, як хотілося б. Затримки на AAAA-пошуках все ще можуть нашкодити, навіть якщо маршрутизація IPv6 не працює.
7. DNSSEC може перетворити «працює на моєму резолвері» на «SERVFAIL скрізь». Збої валідації проявляються як SERVFAIL для клієнтів, що виглядає як «домен зламаний», хоча записи існують.
8. Split-horizon DNS поширений у великих організаціях. Той самий домен може резолвитися по-різному всередині і зовні. Поштові сервери, що «світяться» на межах, часто потерпають.
9. Великі провайдери публікують складні DNS-схеми. Багато MX-записів, geo-DNS і короткі TTL можуть посилити будь-яку слабкість вашого ланцюга резолверів.

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

Жарт #1: DNS — єдина база даних, де «це залежить» — це функція, а не баг.

Як Postfix використовує DNS (і де це може піти не так)

Вихідна доставка: спочатку MX, потім A/AAAA

Для user@recipient.tld Postfix робить приблизно таке:

1. Шукає MX для recipient.tld.
2. Якщо MX відсутній — використовує A/AAAA для recipient.tld як запасний варіант (залежно від політики та RFC-поведінки).
3. Для кожного MX-хоста шукає A/AAAA.
4. Пробує доставити SMTP до отриманих IP-адрес, враховуючи пріоритети та логіку повторних спроб.

«Host not found» може траплятися на різних етапах: не вдається знайти MX, MX існує, але вказує на хост без A/AAAA, або ваш резолвер повертає помилкові відповіді.

Вхідні: політики, що викликають DNS-запити під час SMTP

Сучасні конфігурації Postfix часто включають обмеження, які роблять DNS-запити:

• reject_unknown_sender_domain призводить до перевірки A/AAAA (а іноді й MX).
• reject_unknown_client_hostname робить PTR, а потім перевірку зворотного та прямого запису (FCrDNS).
• RBL-перевірки теж виконуються через DNS; вони можуть гальмувати, якщо резолвери повільні.

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

Локальний шлях резолвера: ваша реальна залежність

Postfix зазвичай покладається на те, що використовує хост для розв’язування імен. Отже ваш «дизайн DNS» включає:

• Stub-резолвер (127.0.0.53 з systemd-resolved, або локальний unbound тощо)
• Upstream резолвери (корпоративні DNS, VPC DNS, ISP, публічні)
• Firewall-правила і маршрутизацію (особливо UDP/53, TCP/53 та фрагментовані UDP-пакети)
• EDNS0 і поведінку DNSSEC

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

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

Це завдання, які я справді виконую, коли з’являється «host not found». Кожне завдання містить: команду, що ви можете побачити, що це означає, і рішення, яке слід прийняти.

Завдання 1: Визначте точну причину відкладання в черзі

cr0x@server:~$ postqueue -p | sed -n '1,40p'
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
9C2E12A3B5      3123 Fri Jan  3 10:21:54  sender@example.net
(connect to mx1.recipient.tld[203.0.113.10]:25: Connection timed out)
                                         user@recipient.tld

B1A7F0D91C      2210 Fri Jan  3 10:22:09  sender@example.net
(host mx2.recipient.tld[198.51.100.77] said: 450 4.1.8 <user@recipient.tld>: Recipient address rejected: Domain not found)
                                         user@recipient.tld

C4F9A3D2E1      1444 Fri Jan  3 10:22:32  sender@example.net
(host or domain name not found. Name service error for name=recipient.tld type=MX: Host not found, try again)
                                         user@recipient.tld

Що це означає: Ви бачите різні класи відмов. Лише остання — це помилка DNS-запиту. Не змішуйте їх.

Рішення: Виберіть одне репрезентативне повідомлення з DNS-помилкою і зосередьтесь на цьому домені та типі запиту.

Завдання 2: Витягніть один файл черги для повного контексту

cr0x@server:~$ postcat -q C4F9A3D2E1 | sed -n '1,80p'
*** ENVELOPE RECORDS ***
message_size:           1444            1444
message_arrival_time:   Fri Jan  3 10:22:32 2026
sender:                 sender@example.net
named_attribute:        rewrite_context=remote
recipient:              user@recipient.tld
*** DELIVERED TO THIS RECIPIENT ***
remote:                 recipient.tld
offset:                 1234
status:                 deferred
reason:                 host or domain name not found. Name service error for name=recipient.tld type=MX: Host not found, try again

Що це означає: Виклик резолвера зазнав невдачі для MX-запиту самого домену, а не для хосту MX.

Рішення: Тестуйте розв’язування MX для recipient.tld з цього хоста, використовуючи той самий шлях резолвера.

Завдання 3: Читайте логи пошти для виявлення патернів і масштабу

cr0x@server:~$ sudo grep -E "Name service error|host not found|type=MX" -n /var/log/mail.log | tail -n 15
38412:Jan  3 10:22:32 server postfix/smtp[21903]: C4F9A3D2E1: to=<user@recipient.tld>, relay=none, delay=12, delays=0.1/0.01/12/0, dsn=4.4.3, status=deferred (host or domain name not found. Name service error for name=recipient.tld type=MX: Host not found, try again)
38458:Jan  3 10:24:10 server postfix/smtp[21922]: 7A11B7D4C2: to=<ops@another.tld>, relay=none, delay=10, dsn=4.4.3, status=deferred (Host or domain name not found. Name service error for name=another.tld type=MX: Host not found, try again)

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

Рішення: Переключіться з «debug recipient.tld» на «debug наш DNS-клієнтський шлях».

Завдання 4: Підтвердіть, які резолвери хост використовуватиме

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

Що це означає: Ви використовуєте заглушку systemd-resolved. Postfix питатиме 127.0.0.53, який пересилає запити туди, куди systemd-resolved вважає за потрібне.

Рішення: Перегляньте стан systemd-resolved і upstream-сервери далі. Також зверніть увагу на search-домени, які можуть спричиняти несподівані запити.

Завдання 5: Перегляньте upstream DNS systemd-resolved і налаштування на лінку

cr0x@server:~$ resolvectl status | sed -n '1,120p'
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (ens3)
Current Scopes: DNS
     Protocols: +DefaultRoute
Current DNS Server: 10.20.0.10
       DNS Servers: 10.20.0.10 10.20.0.11
        DNS Domain: corp.internal

Що це означає: Upstream-резолвери — 10.20.0.10 і 10.20.0.11. Якщо вони недоступні або неправильно налаштовані, Postfix не зможе робити запити.

Рішення: Тестуйте запити безпосередньо проти кожного upstream-сервера, щоб виявити split-brain або відмову одного сервера.

Завдання 6: Зробіть MX-запит безпосередньо до налаштованих резолверів

cr0x@server:~$ dig +time=2 +tries=1 @10.20.0.10 MX recipient.tld

; <<>> DiG 9.18.24 <<>> +time=2 +tries=1 @10.20.0.10 MX recipient.tld
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 45123
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; Query time: 1998 msec
;; SERVER: 10.20.0.10#53(10.20.0.10) (UDP)
;; WHEN: Fri Jan 03 10:31:22 UTC 2026
;; MSG SIZE  rcvd: 56

Що це означає: Це не NXDOMAIN. SERVFAIL означає, що резолвер не зміг виконати запит (помилка DNSSEC, upstream-проблема, некоректна делегація, рекурсія зламано).

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

Завдання 7: Порівняйте з другим резолвером

cr0x@server:~$ dig +time=2 +tries=1 @10.20.0.11 MX recipient.tld

; <<>> DiG 9.18.24 <<>> +time=2 +tries=1 @10.20.0.11 MX recipient.tld
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6112
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
recipient.tld.   300 IN MX 10 mx1.recipient.tld.
recipient.tld.   300 IN MX 20 mx2.recipient.tld.

;; Query time: 28 msec
;; SERVER: 10.20.0.11#53(10.20.0.11) (UDP)

Що це означає: Один резолвер зламаний. Ваш хост усе ще використає його час від часу, залежно від вибору резолвера й таймаутів.

Рішення: Видаліть або виправте 10.20.0.10. Не «чекайте, поки воно само заживе». DNS-сервери, що інколи повертають SERVFAIL, — причина переслідувань у чергах.

Завдання 8: Перевірте, чи MX-цілі розв’язуються до адрес

cr0x@server:~$ dig +short A mx1.recipient.tld.
203.0.113.10

Що це означає: Для MX-хоста є IPv4-адреса. Зробіть те саме для AAAA, навіть якщо ви «не використовуєте IPv6».

Рішення: Якщо A є, але AAAA-запит тупцює через зламаний IPv6-шлях, можливо треба виправити IPv6 або налаштувати поведінку резолвера; див. Завдання 12.

Завдання 9: Точно перевірте NXDOMAIN vs NODATA

cr0x@server:~$ dig @10.20.0.11 MX nonexistent-example.tld

; <<>> DiG 9.18.24 <<>> @10.20.0.11 MX nonexistent-example.tld
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 13255
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; AUTHORITY SECTION:
. 300 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2026010300 1800 900 604800 86400

Що це означає: NXDOMAIN — це остаточно: домен не існує в DNS. Це принципово постійна відмова, але Postfix може трактувати її як тимчасову залежно від контексту.

Рішення: Для вихідної пошти: поверніть помилку відправникові, якщо домен справді неправильний; для вхідних перевірок: розгляньте, чи варто відхиляти листи на основі існування домену-відправника (це може дати хибні спрацьовування під час DNS-інцидентів).

Завдання 10: Підтвердіть, чи запити таймаутять (мережа/файрвол/MTU)

cr0x@server:~$ dig +time=2 +tries=1 @10.20.0.10 MX recipient.tld
;; connection timed out; no servers could be reached

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

Рішення: Тестуйте TCP/53 і базову досяжність до резолвера.

Завдання 11: Тест DNS через TCP (ловить «UDP працює до певного моменту»)

cr0x@server:~$ dig +tcp +time=2 +tries=1 @10.20.0.10 MX recipient.tld
;; connection timed out; no servers could be reached

Що це означає: Якщо і UDP, і TCP таймаутять — резолвер недосяжний або заблокований. Якщо UDP падає, а TCP працює — можлива проблема з фрагментацією UDP/EDNS0.

Рішення: Виправте правила фаєрвола та MTU/фрагментацію. Для швидкого пом’якшення деякі оточення зменшують розмір EDNS0 UDP на резолверах, але це тимчасова заплатка, яку треба відстежити і прибрати пізніше.

Завдання 12: Виявлення зламаного IPv6, що гальмує розв’язування

cr0x@server:~$ dig +time=2 +tries=1 AAAA mx1.recipient.tld. +stats

; <<>> DiG 9.18.24 <<>> +time=2 +tries=1 AAAA mx1.recipient.tld. +stats
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9001
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; Query time: 1995 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; MSG SIZE  rcvd: 49
;; Query time: 1995 msec

Що це означає: «NOERROR з 0 відповідей» (NODATA) — це нормально. Погано інше — затримка в ~дві секунди. Зазвичай це резолверна затримка (upstream timeout, проблема v6-шляху або повтори DNSSEC).

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

Завдання 13: Підтвердіть, що Postfix не використовує інший DNS-вид (контейнери/неймспейси)

cr0x@server:~$ sudo postconf -n | grep -E "smtp_host_lookup|smtp_dns|inet_protocols|resolve"
inet_protocols = all
smtp_host_lookup = dns

Що це означає: Postfix робить DNS-запити як зазвичай. Якщо це контейнерна розгортка, він все ще може використовувати resolv.conf контейнера.

Рішення: Якщо Postfix працює в контейнері — виконайте ті самі dig-команди всередині контейнера. Якщо він на хості — продовжуйте відлагодження на хості.

Завдання 14: Перевірте таймаути бібліотеки резолвера і поведінку ротації

cr0x@server:~$ grep -E "nameserver|options" /etc/resolv.conf
nameserver 127.0.0.53
options edns0 trust-ad

Що це означає: Ви явно не контролюєте timeout і attempts тут. За замовчуванням вони різні в різних середовищах. Деякі системи також ставлять rotate, що може рівномірно розподілити біль по резолверах.

Рішення: Якщо один upstream-резолвер хворий — видаліть його або виправте. Налаштування retry-параметрів не замінить здоровий DNS.

Завдання 15: Переконайтеся, що ваше власне ім’я хоста й HELO розв’язуються

cr0x@server:~$ postconf -n | grep -E "myhostname|mydomain|myorigin"
myhostname = mail01.corp.internal
myorigin = /etc/mailname

cr0x@server:~$ dig +short A mail01.corp.internal
10.30.4.21

Що це означає: Якщо ваше власне ім’я хоста не резолвиться в тій DNS-виді, який ви використовуєте, ви отримаєте дивні відмови віддалено і іноді локальні політики відмовлятимуть.

Рішення: Переконайтеся, що ідентичність, яку Postfix представляє (myhostname, smtpd_banner, TLS-імена) має запис у тій DNS-виді, яка важлива.

Завдання 16: Якщо відкладання накопичується, перевірте ріст черги і поведінку повторів

cr0x@server:~$ postqueue -p | tail -n 1
-- 12753 Kbytes in 2843 Requests.

Що це означає: У вас є накопичення. Postfix буде повторювати спроби, але треба керувати операційним впливом: використання диску, хвилі відмов і затримки бізнес-процесів.

Рішення: Виправте DNS спочатку. Потім розгляньте акуратне очищення черги (postqueue -f) у спокійний період і стежте за обмеженнями на стороні отримувачів.

Три корпоративні міні-історії (анонімізовано, болісно реальні)

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

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

За годину черга пошти почала розростатися. Ніяких тривог, бо SMTP-сервіс був піднятий. CPU та диски в нормі. Ззовні виглядало як повільний вівторок. Зсередини — вихідна пошта накопичувалась із помилками host not found по багатьох доменах.

Припущення їх підвело: «Якщо curl резолвить імена, то й Postfix теж» — але Postfix жив у захищеному образі контейнера з прив’язкою /etc/resolv.conf до старої внутрішньої IP-адреси резолвера, яка в новому VPC не існувала. DNS на хості працював; у контейнері — ні.

Виправлення виявилося соромно простим: перебудувати контейнер, щоб використовував платформений DNS, і додати тест, що виконує реальний MX-запит під час розгортання. Найбільше болю принесло час на дебаг «Postfix», тоді як корінь проблеми був у DNS.

Вони також додали алерт по глибині черги. Не тому, що це круто, а тому, що це каже правду, коли все інше брешеться.

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

Команда з безпеки впровадила агресивні SMTP-обмеження, щоб зменшити спам і спуфінг. Добрі цілі. Вони включили reject_unknown_sender_domain і деякі додаткові перевірки хостів клієнтів. Логи пошти почали виглядати чистішими. Менше очевидного сміття. Усі почувались досяглими.

Потім під час планового технічного вікна корпоративні DNS-резолвери пережили частковий збій. Не повний простій — лише інтермітентне SERVFAIL одного резолвера, інший був у порядку. Вебтрафік не помітив, бо браузери й стек застосунку повторювали спроби й кешували відповіді. SMTP же приймає рішення в режимі реального часу під час з’єднання. Поштові релеї почали відхиляти легітимні листи періодично під час цього DNS-коливання.

Ця «оптимізація» була дорогою: вони перемістили відмову з «deferred для вихідної доставки» (відновлювально) в «rejected для вхідної пошти» (можливо, втрачену, залежно від поведінки відправника). Деякі відправники повторили спробу; деякі — ні. Це не їхній моральний провал, це екосистема.

Вони зберегли перевірки, але змінили підхід: DNS-залежні відхилення застосовували лише там, де була висока впевненість і низький ризик втрат. Додали моніторинг здоров’я резолверів у поштовому шарі. Найважливіше — вирішили, що коли DNS деградує, MTA має деградувати грамотно: більше відкладань, менше жорстких відхилень.

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

Інша компанія мала нудне правило: кожне продакшн-поштове реле запускало локальний кешуючий резолвер (unbound) на localhost з двома upstream-резолверами і суворими таймаутами. Також був маленький синтетичний чек: щохвилини робити MX-запит для трьох відомих зовнішніх доменів і одного внутрішнього, безпосередньо з поштового хоста. Чек не був розумним. Він був постійним.

Одного ранку upstream DNS почав втрачати UDP-фрагменти через зміну фаєрвола. Деякі запити працювали — дрібні. Інші таймаутили — великі відповіді, DNSSEC-важкі відповіді, певні набори MX. Синтетичні перевірки спіймали це одразу, бо MX-відповіді зазвичай «більші», ніж прості A-запити.

Черга почала рости, але вони вже мали алерти по глибині черги і по затримці розв’язування DNS. Інцидент вирішили нудно: відкотити політику фаєрвола, очистити кеш резолвера, дивитися, як черга спадає, і не чіпати чужі налаштування.

Нагород вони не отримали. Вони доставили пошту. У оперціях це і є нагорода.

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

1) «Host not found» для багатьох доменів одразу

Симптом: Кілька не пов’язаних доменів відмовляють з помилками при MX-запитах.

Корінна причина: Ваш шлях резолвера зламаний (один upstream-резолвер впав, systemd-resolved збентежено, фаєрвол блокує DNS або відбуваються DNSSEC-помилки).

Виправлення: Визначте, який резолвер повертає SERVFAIL/timeout, виведіть його з ротації або відновіть мережеву доступність, перевірте через dig @resolver MX domain.

2) «Host not found» лише для одного домену

Симптом: Один домен стабільно відмовляє, інші доставляються.

Корінна причина: Віддалений домен неправильно налаштований у DNS (відсутній MX і немає A-fallback, зламана делегація, застарілий DS-запис, що спричиняє DNSSEC-помилку).

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

3) Інтермітентні відмови: працює половину часу

Симптом: Той самий домен чергується між роботою і «host not found».

Корінна причина: Декілька резолверів поводяться по-різному; вибір резолвера/таймаутів створює рулетку. Іноді також це split-horizon DNS залежно від мережевого шляху.

Виправлення: Запитайте кожен резолвер напряму. Видаліть поганий. Якщо split-horizon — забезпечте, щоб поштове реле було в потрібній DNS-виді постійно.

4) Повільна доставка пошти, але не повна відмова

Симптом: Пошта зрештою доходить, але з затримкою в хвилини; SMTP-сесії здаються повільними.

Корінна причина: DNS-запити таймаутять перед успіхом (типово зламані IPv6-шляхи, перевантажені резолвери або таймаути RBL).

Виправлення: Виміряйте час запиту з dig +stats. Виправте продуктивність резолвера, переконайтесь, що IPv6 або повністю працює, або коректно обробляється, і уникайте синхронних DNS-перевірок у SMTP-шляху, якщо ваш SLO для резолвера ненадійний.

5) Після «виправлення DNS» Postfix все ще відмовляє кілька годин

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

Корінна причина: Кеші. Негативне кешування. Локальний кешуючий резолвер тримає старі дані. Або ви виправили один авторитетний сервер, але не інші.

Виправлення: Перевірте TTL і SOA. Очистіть локальні кеші за потреби. Переконайтесь у консистентності авторитетних серверів. Не перезапускайте Postfix без потреби; це не ритуальна жертва, яка задовольнить богів резолвера.

6) «Host not found» після увімкнення суворих антиспам-правил

Симптом: Вхідні листи відхиляються через перевірки доменів/хостів під час DNS-коливань.

Корінна причина: Ви перенесли залежність від DNS у критичний шлях SMTP-рішень.

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

Жарт #2: Перезапуск Postfix не виправить DNS, але спалить калорії — здебільшого ваші.

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

Покроково: коли ви активно втрачаєте доставку пошти

1. Підтвердіть масштаб: Один домен чи багато? Використайте grep у логах пошти та приклади записів черги.
2. Запустіть прямі DNS-запити: dig MX для проблемних доменів проти кожного налаштованого резолвера.
3. Класифікуйте відмову: NXDOMAIN vs SERVFAIL vs timeout. Не ставте їх в один ряд.
4. Виправте шлях резолвера:
   • Якщо один резолвер поганий — видаліть його з конфігурації або виведіть з експлуатації.
   • Якщо мережа блокує — виправте фаєрвол/маршрутизацію.
   • Якщо проблема DNSSEC — виправте ланцюжок валідації; не відключайте DNSSEC на резолвері без чіткого рішення про ризики.
5. Стабілізуйте поведінку Postfix: Уникайте зміни конфігурації під час інциденту. Спочатку зробіть DNS здоровим.
6. Обережно очищуйте чергу: Коли DNS стабільний, розгляньте postqueue -f і стежте за обмеженнями на стороні отримувачів.
7. Зміцнення після інциденту: Додайте оповіщення по глибині черги, перевірки затримки DNS і відмов резолверів.

Чеклист для зміцнення: щоб «host not found» не став сюрпризом

• Запустіть локальний кешуючий резолвер на релях пошти (або використовуйте перевірену архітектуру stub-to-recursive) і моніторьте його.
• Використовуйте принаймні два upstream-резолвери, які незалежно здорові.
• Тестуйте DNS з того самого мережевого неймспейсу/контейнера, де працює Postfix.
• Оповіщуйте про:
  • розмір черги пошти і темп її росту
  • кількість рядків логів «Name service error»
  • затримку DNS-запитів і рівень SERVFAIL з поштових хостів
• Будьте обережні з SMTP-обмеженнями, що роблять синхронні DNS-запити в критичному шляху.
• Задокументуйте, як split-horizon DNS має працювати для поштових релеїв. Якщо «ніхто не знає», воно ламається о 3-й ранку.
• Перевіряйте вихідну доставлянність у CI/CD: хоча б один MX-запит і одне тестове SMTP-з’єднання до відомого домену.
• Тримайте IPv6 або повністю робочим, або переконливо спроектованим. Напівналаштований IPv6 — податковий збір у вигляді затримок.

Операційні точки прийняття рішень (про які люди сперечаються)

• Обхід корпоративного DNS? Для вихідних релеїв іноді так — якщо корпоративний DNS часто спричиняє інциденти. Робіть це управляємо, а не вночі в паніці.
• Відмовляти вхідну пошту під час проблем із DNS? Зазвичай ні. Віддавайте перевагу тимчасовим відкладанням, щоб відправники могли повторити спробу.
• Вимикати IPv6? Лише якщо ви усвідомлюєте наслідки. Краще: зробіть IPv6 коректним або гарантуйте, що резолвер і маршрути не гальмують через нього.

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

1) У чому різниця між NXDOMAIN і SERVFAIL у цьому контексті?

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

2) Чому Postfix каже «try again», якщо домен справді не існує?

Postfix часто трактує відмови DNS як тимчасові, бо DNS — розподілена система і відмови можуть бути транзієнтними. Крім того, «домена немає» може бути спричинено збоєм резолвера або split-horizon. Якщо ви хочете детермінованої поведінки bounce, потрібні політичні рішення на основі надійних DNS-сигналів.

3) Чи може один поганий резолвер справді спричинити інтермітентні проблеми з поштою?

Так. Якщо у системі два резолвери і бібліотека резолвера обертає або робить перехід нерівномірно, ви побачите спорадичні SERVFAIL/таймаути. Доставка пошти тоді виглядає «випадковою», бо залежить від того, який резолвер відповів на конкретний запит у конкретний момент.

4) Навіщо потрібні AAAA-запити, якщо ми доставляємо пошту лише по IPv4?

Навіть якщо доставка в підсумку йде по IPv4, резолвер може все одно робити AAAA-запит і чекати на таймаут або повтори. Це додає затримку і може спричинити «host not found», якщо шлях резолвера хворий. Ви не мусите любити IPv6, але мусите враховувати його вплив.

5) Як зрозуміти, чи це наш DNS чи DNS отримувача?

Тестуйте з вашого поштового хоста проти кількох резолверів. Якщо ваш налаштований резолвер відмовляє, а відомо хороший резолвер повертає коректні MX, проблема, ймовірно, у вас. Якщо кілька незалежних резолверів відмовляють однаково, швидше за все це DNS отримувача або його делегація/DNSSEC.

6) Чи допомагає перезапуск Postfix?

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

7) Чому «host not found» з’являється лише в години піку?

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

8) Які налаштування Postfix найчастіше підсилюють DNS-відмови?

SMTP-обмеження, що роблять DNS-запити під час обробки з’єднання (перевірки домену відправника, перевірки хосту клієнта) і активне використання RBL можуть перетворити повільність резолвера в повільність SMTP або відхилення. Це не завжди погано — це компроміс, який треба робити усвідомлено.

9) Як підтримати доставку пошти під час інциденту з резолвером?

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

10) Чи створюють «search» домени в resolv.conf реальні проблеми для Postfix?

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

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

Якщо зробите лише три речі, то ці:

1. Додайте моніторинг, що відображає реальність: оповіщення по глибині черги і по відмовах/затримках DNS з самих поштових хостів.
2. Зробіть шлях резолвера банально простим: два здорові upstream-резолвери, передбачувана поведінка і бажано локальний кешуючий резолвер на релях пошти.
3. Перестаньте перетворювати DNS-хащі в втрату пошти: будьте обережні з DNS-залежними відхиленнями SMTP, якщо у вас немає сильної надійності резолверів і чіткої бізнес-цілі.

Потім заплануйте коротке випробування: візьміть staging-реле, навмисно виведіть з ладу один IP резолвера і подивіться, що станеться. Якщо ваша система «мовчазно» падає — ви дізналися щось безцінне, і зробили це до того, як продакшн зайнявся вогнем.