Postfix « host not found » : problèmes DNS qui tuent silencieusement le courrier

Ce que « host not found » signifie réellement dans Postfix

Postfix n’est pas poétique. « Host not found » signifie généralement qu’il a interrogé le résolveur et n’a pas obtenu de réponse exploitable. Cette réponse peut être « NXDOMAIN » (ça n’existe pas), ou « SERVFAIL » (le serveur DNS a abandonné), ou « timeout » (pas de réponse), ou « no data » (le domaine existe, mais pas le type d’enregistrement demandé).

Les endroits les plus courants où vous verrez cela :

• Envoi sortant vers des destinataires distants : Postfix tente de résoudre les enregistrements MX pour example.com, puis A/AAAA pour les noms d’hôte MX.
• Restrictions SMTP entrantes comme reject_unknown_client_hostname ou reject_unknown_sender_domain, où Postfix effectue des recherches pendant la conversation SMTP.
• Routage local lorsque vous utilisez des transport maps basées sur DNS ou des règles relayhost.

D’où vient la chaîne d’erreur

Postfix utilise les bibliothèques résolveur du système pour la plupart des recherches. Donc la formulation « name service error » n’est pas vraiment un caprice de Postfix ; elle remonte souvent du comportement du résolveur libc, influencé par :

• le contenu de /etc/resolv.conf et les domaines de recherche
• les résolveurs locaux en cache (systemd-resolved, unbound, dnsmasq)
• le chemin réseau vers les résolveurs en amont
• les échecs de validation DNSSEC (si activés sur votre chemin)
• le comportement IPv6 (les requêtes AAAA peuvent être étonnamment « bruyantes »)

La plupart du temps, le problème opérationnel immédiat est simple : le courrier est bloqué dans la file en état deferred. Le problème plus dangereux est que rien ne vous alerte à moins de surveiller la profondeur de file, les raisons de report ou les motifs dans les logs.

Idée paraphrasée (attribuée) : John Allspaw a longtemps promu l’état d’esprit opérationnel selon lequel la fiabilité vient du fait d’apprendre comment les systèmes échouent réellement, et non de supposer qu’ils n’échoueront pas.

Prenez cela au sérieux ici. Les pannes DNS sont normales. Votre système de messagerie doit les traiter comme des turbulences de routine, pas comme un impact de comète rare.

Playbook de diagnostic rapide (premier/deuxième/troisième)

Voici la séquence « arrêtez de deviner ». Faites-la dans l’ordre. Elle est conçue pour trouver rapidement le goulot d’étranglement : s’agit-il de la config Postfix, du résolveur local, du DNS en amont ou du domaine distant ?

Premier : confirmer l’erreur et isoler le domaine cible

1. Trouvez un message en échec dans la file et récupérez le domaine du destinataire et le texte d’erreur exact.
2. Vérifiez si c’est un seul domaine ou plusieurs. Un seul domaine pointe vers le DNS distant ; plusieurs domaines pointent vers votre chemin de résolveur.

Deuxième : tester le DNS depuis l’hôte Postfix (pas votre laptop)

1. dig MX et A/AAAA pour le domaine destinataire et pour les cibles MX.
2. Répétez contre votre résolveur configuré puis contre un résolveur public connu et sain (temporairement, pour le diagnostic). Les différences comptent.
3. Vérifiez les codes de réponse : NXDOMAIN vs SERVFAIL vs timeout sont des espèces différentes d’échec.

Troisième : vérifier la chaîne du résolveur local et les timeouts

1. Inspectez /etc/resolv.conf et les services de résolveur locaux.
2. Vérifiez les échecs DNSSEC, les désaccords split-horizon, et la connectivité IPv6 cassée.
3. Confirmez que Postfix n’est pas enfermé dans un namespace réseau/conteneur avec un DNS différent.

Si vous effectuez ces trois étapes, vous cesserez de vous disputer pour savoir si « le DNS est en panne » et commencerez à parler de quel chemin de résolveur vous ment.

Faits et histoire qui expliquent les bizarreries actuelles

DNS et e-mail ont grandi ensemble, ce qui explique pourquoi leurs modes d’échec sont profondément imbriqués. Quelques faits courts pour aider à comprendre le bazar :

1. Les enregistrements MX ont été introduits pour découpler le routage du courrier de l’adressage des hôtes. Avant MX, la livraison du courrier s’appuyait fortement sur les enregistrements A et des conventions implicites.
2. Les TTL DNS ont été conçus pour l’efficacité de cache, pas pour la clarté opérationnelle. Quand quelqu’un dit « on a corrigé le DNS », il faut encore demander « où, et quel TTL ? »
3. La mise en cache négative existe. Les réponses NXDOMAIN peuvent aussi être mises en cache, donc une faute de frappe transitoire peut perdurer comme une mauvaise odeur.
4. Les résolveurs réessayent souvent sur plusieurs serveurs. Un résolveur instable et un résolveur sain peuvent encore créer des échecs intermittents qui ressemblent à des « problèmes Postfix aléatoires ».
5. SMTP a été conçu pour la temporisation. Les échecs temporaires sont attendus ; les MTAs mettent en file et réessaient. C’est excellent — jusqu’à ce que cela masque votre incident.
6. L’adoption d’IPv6 a introduit des comportements « happy eyeballs » dans de nombreuses piles, mais pas toujours comme vous l’espériez. La latence des requêtes AAAA peut encore vous nuire même si votre routage IPv6 ne fonctionne pas.
7. DNSSEC peut transformer « ça marche sur mon résolveur » en « SERVFAIL partout ailleurs ». Les échecs de validation apparaissent comme SERVFAIL aux clients, ce qui ressemble à « le domaine est cassé » même quand les enregistrements existent.
8. Le split-horizon DNS est courant en entreprise. Le même domaine peut résoudre différemment à l’intérieur et à l’extérieur. Les serveurs de mail qui chevauchent ces frontières sont des victimes fréquentes.
9. Les gros fournisseurs publient des architectures DNS complexes. Plusieurs enregistrements MX, geo-DNS et TTL courts peuvent amplifier toute faiblesse dans votre chaîne de résolveur.

Le DNS n’est pas « juste un annuaire ». C’est une base de données distribuée avec mise en cache, timeouts, pannes partielles et politiques. Le courrier dépend du DNS plus que la plupart des applications, ce qui explique pourquoi vous pouvez perdre la délivrabilité du courrier alors que tout le reste semble correct.

Blague #1 : Le DNS est la seule base de données où « ça dépend » est une fonctionnalité, pas un bug.

Comment Postfix utilise le DNS (et où ça peut mal tourner)

Sortant : lookup MX, puis A/AAAA

Pour user@recipient.tld, Postfix effectue approximativement :

1. Recherche MX pour recipient.tld.
2. Si pas de MX, fallback sur A/AAAA pour recipient.tld (selon la politique et le comportement RFC).
3. Pour chaque nom d’hôte MX, recherche A/AAAA.
4. Tentative de livraison SMTP vers les adresses résolues, en respectant la priorité et la logique de retry.

« Host not found » peut se produire à plusieurs endroits : la recherche MX échoue, le MX existe mais pointe vers un nom d’hôte sans A/AAAA, ou votre résolveur renvoie de la mauvaise data.

Entrant : vérifications de politique qui déclenchent du DNS pendant SMTP

Les configurations Postfix modernes incluent souvent des restrictions qui appellent le DNS :

• reject_unknown_sender_domain provoque un contrôle A/AAAA (et parfois MX).
• reject_unknown_client_hostname effectue des PTR puis FCrDNS (vérification avant-arrière) .
• Les requêtes RBL sont aussi des requêtes DNS ; elles peuvent ralentir si vos résolveurs sont lents.

Ces vérifications sont utiles, mais elles introduisent aussi une dépendance. Vous avez intégré la disponibilité du DNS dans votre chemin de réponse SMTP. Si votre résolveur est lent, votre service SMTP devient lent. Si votre résolveur est cassé, votre SMTP devient « mystérieusement impoli ».

Chemin du résolveur local : votre vraie dépendance

Postfix s’appuie typiquement sur ce que l’hôte utilise pour la résolution de noms. Cela signifie que votre « conception DNS » inclut :

• Stub resolver (127.0.0.53 avec systemd-resolved, ou unbound local, etc.)
• Résolveurs en amont (DNS d’entreprise, DNS de VPC, ISP, publics)
• Règles de pare-feu et routage (surtout UDP/53, TCP/53, et fragments UDP)
• EDNS0 et comportement DNSSEC

Si vous voulez moins de pannes mail, traitez le DNS comme une dépendance de niveau 0. Surveillez-le. Provisionnez-le en redondance. Gardez-le ennuyeux.

Tâches pratiques : commandes, sorties et décisions (12+)

Voici les tâches que j’exécute réellement quand « host not found » apparaît. Chaque tâche inclut : commande, ce que vous pourriez voir, ce que ça signifie, et la décision à prendre.

Task 1: Identify the exact deferral reason in the queue

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

Ce que ça signifie : Vous voyez différentes classes d’échec. Seul le dernier est l’échec de résolution DNS. Ne les confondez pas.

Décision : Choisissez un message représentatif avec l’erreur DNS et concentrez-vous sur ce domaine et ce type de recherche.

Task 2: Pull a single queue file for full context

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

Ce que ça signifie : L’appel au résolveur a échoué sur une requête MX pour le domaine lui-même, pas pour les hôtes cibles MX.

Décision : Testez la résolution MX pour recipient.tld depuis cet hôte, en utilisant le même chemin de résolveur.

Task 3: Read mail logs for patterns and scope

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)

Ce que ça signifie : Plusieurs domaines échouent. C’est un fort indice que votre chaîne de résolveur est malade, pas seulement le DNS d’un domaine distant.

Décision : Passez de « debug recipient.tld » à « debug notre chemin client DNS ».

Task 4: Confirm what resolvers the host will use

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

Ce que ça signifie : Vous utilisez le stub systemd-resolved. Postfix interrogera 127.0.0.53, qui relaie vers ce que systemd-resolved considère comme correct.

Décision : Inspectez l’état de systemd-resolved et les serveurs en amont ensuite. Méfiez-vous aussi des domaines search qui provoquent des requêtes surprises.

Task 5: Inspect systemd-resolved’s upstream DNS and per-link config

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

Ce que ça signifie : Les résolveurs en amont sont 10.20.0.10 et 10.20.0.11. Si ceux-ci sont inaccessibles ou mal configurés, Postfix échouera aux recherches.

Décision : Testez les requêtes directement contre chaque serveur en amont pour détecter une situation de split-brain ou un serveur en échec.

Task 6: Query MX directly against the configured resolvers

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

Ce que ça signifie : Pas NXDOMAIN. SERVFAIL implique que le résolveur n’a pas pu compléter la recherche (échec DNSSEC, problème en amont, délégation incorrecte, récursion cassée).

Décision : Interrogez le second résolveur ; si l’un répond et l’autre SERVFAIL, vous avez des échecs intermittents selon le résolveur utilisé.

Task 7: Compare with the second resolver

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)

Ce que ça signifie : Un résolveur est cassé. Votre hôte utilisera parfois celui-ci, selon la sélection et les timeouts du résolveur.

Décision : Supprimez ou corrigez 10.20.0.10. Ne « attendez pas que ça se rétablisse ». Les serveurs DNS qui renvoient parfois SERVFAIL sont la route vers des files hantées.

Task 8: Validate the MX targets resolve to addresses

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

Ce que ça signifie : Il existe une adresse IPv4 pour l’hôte MX. Faites la même chose pour AAAA même si vous « n’utilisez pas IPv6 ».

Décision : Si A existe mais que la recherche AAAA bloque à cause d’un chemin IPv6 cassé, il faudra corriger IPv6 ou ajuster le comportement du résolveur ; voir Task 12.

Task 9: Check for NXDOMAIN vs NODATA precisely

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

Ce que ça signifie : NXDOMAIN est définitif : le nom de domaine n’existe pas dans le DNS. C’est en principe une défaillance permanente, mais Postfix peut tout de même la considérer comme temporaire selon le contexte.

Décision : Pour l’envoi sortant : générer un bounce si c’est vraiment invalide ; pour les vérifications entrantes : réfléchissez avant de rejeter le courrier sur la seule existence du domaine (cela peut causer des faux positifs pendant des incidents DNS).

Task 10: Confirm whether queries time out (network/firewall/path MTU)

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

Ce que ça signifie : Pas SERVFAIL—c’est un souci de connectivité. Cela peut venir du pare-feu, du routage, du service DNS down, ou des fragments UDP rejetés.

Décision : Testez TCP/53, et vérifiez la reachabilité basique vers le résolveur.

Task 11: Test DNS over TCP (catches “UDP works until it doesn’t”)

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

Ce que ça signifie : Si UDP et TCP timeout, le résolveur est injoignable ou bloqué. Si UDP échoue mais TCP fonctionne, vous pouvez avoir un problème de fragmentation UDP/EDNS0.

Décision : Corrigez les règles de pare-feu et le MTU/fragmentation. En atténuation rapide, certains environnements réduisent la taille UDP EDNS0 sur les résolveurs, mais c’est un pansement à suivre et retirer ensuite.

Task 12: Detect broken IPv6 that slows resolution

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

Ce que ça signifie : « NOERROR with 0 answers » (NODATA) est acceptable. Le mauvais signe est la latence de deux secondes. C’est typiquement un délai du résolveur (timeout en amont, problème de chemin v6, ou réessais DNSSEC).

Décision : Si les requêtes AAAA coûtent constamment des secondes, vous ajoutez de la latence à chaque tentative de livraison. Corrigez le chemin du résolveur ; ne « désactivez IPv6 » que si vous maîtrisez pleinement les conséquences.

Task 13: Confirm Postfix isn’t using a different DNS view (containers/namespaces)

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

Ce que ça signifie : Postfix effectue les recherches DNS normalement. Si le déploiement est conteneurisé, il peut néanmoins utiliser le resolv.conf du conteneur.

Décision : Si Postfix tourne dans un container, exécutez les mêmes commandes dig depuis l’intérieur du container. Si il tourne sur l’hôte, continuez le debug sur l’hôte.

Task 14: Check for resolver library timeouts and rotate behavior

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

Ce que ça signifie : Vous ne contrôlez pas explicitement timeout et attempts ici. Les valeurs par défaut varient. Certains environnements activent aussi rotate, ce qui peut répartir la douleur équitablement entre les résolveurs.

Décision : Si un résolveur en amont est malade, retirez-le ou réparez-le. Ajuster les paramètres de retry du résolveur n’est pas un substitut à un DNS sain.

Task 15: Validate that your own hostname and HELO name resolve

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

Ce que ça signifie : Si votre propre nom d’hôte ne résout pas dans la vue DNS que vous utilisez, vous pouvez déclencher des rejets distants étranges et parfois des échecs de politique locaux.

Décision : Assurez-vous que l’identité que Postfix présente (myhostname, smtpd_banner, noms TLS) est résoluble et cohérente dans les vues qui comptent.

Task 16: If deferrals are piling up, confirm queue growth and retry behavior

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

Ce que ça signifie : Vous avez un retard. Postfix réessaiera, mais il faut gérer l’impact opérationnel : usage disque, bouffées de bounces, et workflows métier retardés.

Décision : Réparez le DNS d’abord. Ensuite envisagez un vidage contrôlé de la file (postqueue -f) pendant une fenêtre calme, et surveillez les limites de débit distantes.

Trois mini-récits d’entreprise (anonymisés, plausibles, techniquement exacts)

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Ils ont migré une paire de relais mail dans un nouveau VPC. Tout le reste était déjà présent : serveurs applicatifs, bases de données, caches, le zoo cloud habituel. L’équipe a supposé que le DNS « fonctionnerait simplement », parce que le DNS avait fonctionné pour tout le reste.

En moins d’une heure, la file mail a commencé à gonfler. Aucune alarme, parce que le service SMTP était up. Le CPU allait bien. Les disques allaient bien. De l’extérieur, c’était un mardi tranquille. De l’intérieur, le courrier sortant s’empilait avec des erreurs host not found sur plusieurs domaines destinataires.

L’hypothèse qui les a piégés : « Si curl peut résoudre des noms, Postfix le peut aussi. » Sauf que Postfix vivait dans une image de container durcie avec son propre /etc/resolv.conf pointant vers une ancienne IP de résolveur interne qui n’existait pas dans le nouveau VPC. Le DNS de l’hôte fonctionnait ; celui du container non.

La correction fut embarrassante de simplicité : reconstruire le container pour utiliser le DNS de la plateforme, et ajouter un test qui exécute une vraie recherche MX pendant le déploiement. Ce qui a fait mal, c’est le temps passé à déboguer « Postfix » alors que le plancher de faille était le DNS.

Ils ont aussi ajouté une alerte sur la profondeur de file. Pas parce que c’est sophistiqué, mais parce que ça dit la vérité même quand tout le reste ment.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une équipe sécurité a déployé des restrictions SMTP agressives pour réduire le spam et l’usurpation. Bons objectifs. Ils ont activé reject_unknown_sender_domain et quelques contrôles supplémentaires sur le nom client. Les logs mail semblaient plus propres. Moins d’expéditeurs poubelle. Tout le monde se sentait accompli.

Puis une fenêtre de maintenance routinière a frappé les résolveurs DNS d’entreprise. Pas une panne totale — juste une défaillance partielle où un résolveur renvoyait intermittently des SERVFAIL pendant que l’autre fonctionnait. Le trafic web ne l’a pas remarqué parce que les navigateurs et les stacks applicatifs réessayaient, mettaient en cache et masquaient le souci. SMTP, en revanche, prend des décisions de politique en temps réel par connexion. Les relais mail ont commencé à rejeter du vrai courrier de manière sporadique pendant la vacillation DNS.

L’« optimisation » a été coûteuse opérationnellement : ils ont déplacé l’échec de « reporté en sortie » (récupérable) à « rejeté en entrée » (potentiellement perdu, selon le comportement de l’expéditeur). Certains expéditeurs ont réessayé ; d’autres non. Ce n’est pas un échec moral de l’expéditeur. C’est juste la façon dont l’écosystème se comporte.

Ils ont conservé les contrôles, mais ont changé de philosophie : les rejets dépendants du DNS s’appliquent uniquement quand ils ont une forte confiance et un faible risque de perte, et ils ont intégré la santé des résolveurs dans la supervision de la couche mail. Surtout, ils ont décidé que lorsque le DNS est dégradé, le MTA doit se dégrader gracieusement — plus de reports, moins de rejets définitifs.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une autre société avait une règle ennuyeuse : chaque relais mail de production exécutait un résolveur cache local (unbound) sur localhost, avec deux résolveurs en amont et des timeouts stricts. Ils avaient aussi une vérification synthétique minuscule : chaque minute, résoudre MX pour trois domaines externes bien connus et un domaine interne, depuis l’hôte mail lui-même. La vérif n’était pas intelligente. Elle était juste persistante.

Un matin, les DNS en amont ont commencé à perdre des fragments UDP à cause d’un changement de pare-feu. Certaines requêtes fonctionnaient encore — les petites. D’autres timeoutaient — réponses plus grosses, réponses lourdes en DNSSEC, certains ensembles MX. Les vérifs synthétiques l’ont détecté immédiatement parce que les réponses MX ont tendance à être « plus volumineuses » que des A simples.

La file mail a commencé à croître, mais ils avaient déjà des alertes sur la longueur de file et la latence de résolution DNS. La réponse à l’incident a été ennuyeuse aussi : rollback de la politique pare-feu, vidage du cache du résolveur, surveillance de la décrue de la file, et ne pas toucher aux boutons non liés.

Ils n’ont pas reçu de prix. Ils ont livré le courrier. En exploitation, c’est le prix.

Erreurs courantes : symptôme → cause racine → correctif

1) « Host not found » pour de nombreux domaines à la fois

Symptôme : Plusieurs domaines non liés échouent avec des erreurs de recherche MX.

Cause racine : Votre chemin de résolveur est cassé (un résolveur en amont down, systemd-resolved confus, pare-feu bloquant le DNS, ou échecs de validation DNSSEC).

Correctif : Identifiez quel résolveur renvoie SERVFAIL/timeout, retirez-le de la rotation, restaurez la connectivité réseau, et vérifiez avec des tests dig @resolver MX domain.

2) « Host not found » seulement pour un domaine destinataire

Symptôme : Un domaine échoue systématiquement ; les autres sont livrés.

Cause racine : DNS du domaine distant mal configuré (MX manquant et pas de fallback A, délégation cassée, enregistrement DS obsolète provoquant un échec DNSSEC).

Correctif : Vérifiez depuis plusieurs résolveurs. S’il échoue partout, c’est chez eux ; filez et réessayez. S’il échoue seulement depuis votre résolveur d’entreprise, corrigez votre résolveur ou contournez-le pour l’envoi sortant via un résolveur récursif stable.

3) Échecs intermittents : ça marche la moitié du temps

Symptôme : Le même domaine alterne entre fonctionnel et « host not found ».

Cause racine : Plusieurs résolveurs avec comportements incohérents ; la sélection/timeout du résolveur produit de la roulette. Parfois c’est aussi le split-horizon selon le chemin réseau.

Correctif : Interrogez chaque résolveur directement. Retirez le mauvais. Si le split-horizon est voulu, assurez-vous que le relais mail est dans la vue DNS correcte de façon cohérente.

4) Livraison lente du courrier, pas d’échec total

Symptôme : Le courrier arrive finalement mais met des minutes ; les sessions SMTP sont lentes.

Cause racine : Les recherches DNS font des timeouts avant de réussir (commun avec des routes IPv6 cassées, des résolveurs surchargés, ou des timeouts RBL).

Correctif : Mesurez le temps des requêtes avec dig +stats. Corrigez la performance du résolveur, assurez-vous que l’IPv6 fonctionne bout en bout ou qu’il est traité correctement, et évitez les vérifications DNS synchrones dans le chemin SMTP quand votre SLO résolveur n’est pas solide.

5) Après une « correction DNS », Postfix échoue encore pendant des heures

Symptôme : Vous avez corrigé des enregistrements mais Postfix voit encore NXDOMAIN ou de mauvaises réponses.

Cause racine : Caches. Mise en cache négative. Résolveur local qui conserve d’anciennes données. Ou vous avez corrigé un serveur faisant autorité mais pas les autres.

Correctif : Vérifiez les TTL et le SOA. Videz les caches locaux si approprié. Vérifiez la cohérence des serveurs faisant autorité. Ne redémarrez pas Postfix à la va-vite ; ce n’est pas un sacrifice rituel qui apaise les dieux du résolveur.

6) « Host not found » après activation de règles anti-spam strictes

Symptôme : Le courrier entrant est rejeté lors de contrôles domaine/nom d’hôte pendant des oscillations DNS.

Cause racine : Vous avez déplacé la dépendance DNS dans le chemin de décision SMTP en production.

Correctif : Réévaluez les restrictions. Préférez les reports temporaires aux rejets définitifs quand le DNS est peu fiable. Surveillez la santé des résolveurs et envisagez un cache local avec un comportement prévisible.

Blague #2 : Redémarrer Postfix ne réparera pas le DNS, mais ça brûle des calories — surtout les vôtres.

Checklists / plan étape par étape

Étape par étape : quand vous perdez activement la livraison de courrier

1. Confirmer l’étendue : Un domaine ou plusieurs ? Utilisez grep sur les logs mail et des échantillons d’entrées de la file.
2. Exécuter des requêtes DNS directes : dig MX pour les domaines en échec contre chaque résolveur configuré.
3. Classifier l’échec : NXDOMAIN vs SERVFAIL vs timeout. Ne les traitez pas de la même façon.
4. Réparer le chemin des résolveurs :
   • Si un résolveur est mauvais, retirez-le de la config ou mettez-le hors service.
   • Si le réseau bloque, corrigez le pare-feu/routage.
   • Si DNSSEC est en cause, réparez la chaîne de validation ; ne désactivez pas aveuglément DNSSEC sur le résolveur sans décision claire sur le risque.
5. Stabiliser le comportement de Postfix : Évitez les changements de configuration pendant l’incident. Rétablissez le DNS d’abord.
6. Vider la file avec précaution : Une fois le DNS stable, envisagez postqueue -f et surveillez le throttling distant.
7. Renforcement post-incident : Ajoutez des alertes sur la profondeur de file, des contrôles de latence DNS, et de la redondance des résolveurs.

Checklist de durcissement : empêcher que « host not found » soit une surprise

• Exécutez un résolveur cache local sur les relais mail (ou utilisez un design stub-to-recursive éprouvé) et surveillez-le.
• Utilisez au moins deux résolveurs en amont indépendants et sains.
• Testez le DNS depuis le même namespace réseau/container qui exécute Postfix.
• Alertes sur :
  • taille et taux de croissance de la file mail
  • taux de lignes de log « Name service error »
  • latence de requête DNS et taux de SERVFAIL depuis les hôtes mail
• Soyez prudent avec les restrictions SMTP qui font des requêtes DNS synchrones dans le chemin critique.
• Documentez comment le split-horizon DNS doit fonctionner pour les relais mail. Si c’est « personne ne sait », ça faillira à 3 h du matin.
• Validez la délivrabilité sortante dans CI/CD : au moins une recherche MX et une connexion SMTP test vers un domaine connu.
• Gardez IPv6 soit complètement fonctionnel, soit explicitement pris en compte. Un IPv6 à moitié configuré est une taxe de latence.

Points décisionnels opérationnels (ceux dont on discute)

• Doit-on contourner le DNS d’entreprise ? Pour les relais mail sortants, parfois oui — si le DNS d’entreprise est source fréquente d’incidents. Faites-en une décision gérée, pas un hack de minuit.
• Doit-on rejeter le mail entrant quand le DNS est instable ? Généralement non. Préférez les échecs temporaires pour que les expéditeurs puissent réessayer.
• Doit-on désactiver l’IPv6 ? Seulement si vous assumez les conséquences. Mieux : corrigez IPv6, ou assurez-vous que le résolveur et le routage ne ralentissent pas les requêtes.

FAQ

1) Quelle est la différence entre NXDOMAIN et SERVFAIL dans ce contexte ?

NXDOMAIN signifie que le nom de domaine n’existe pas dans le DNS. SERVFAIL signifie que le résolveur n’a pas pu compléter la requête (échec en amont, DNSSEC, récursion désactivée, délégation lame). NXDOMAIN est une réponse « pas de tel domaine » ; SERVFAIL est « j’ai essayé et quelque chose a cassé ».

2) Pourquoi Postfix dit « try again » si le domaine n’existe vraiment pas ?

Postfix traite souvent les échecs DNS comme transitoires parce que le DNS est un système distribué et les pannes peuvent être temporaires. De plus, « le domaine n’existe pas » peut être causé par des glitches du résolveur ou des vues split-horizon. Si vous voulez un comportement de bounce déterministe, vous avez besoin de décisions de politique informées par des signaux DNS fiables.

3) Un seul mauvais résolveur peut-il vraiment causer des échecs intermittents de mail ?

Oui. Si votre système a deux résolveurs et que la bibliothèque résolveur tourne ou bascule imparfaitement, vous verrez des SERVFAIL/timeouts sporadiques. La livraison mail semblera alors « aléatoire », car elle dépendra du résolveur qui a répondu à cette requête précise au moment donné.

4) Pourquoi les recherches AAAA comptent si nous n’utilisons que l’IPv4 pour livrer le mail ?

Même si la livraison finale se fait en IPv4, le résolveur peut toujours interroger AAAA et attendre des timeouts ou des réessais. Cela ajoute de la latence et peut déclencher « host not found » si le chemin du résolveur est malade. Vous n’êtes pas obligé d’aimer IPv6, mais il faut en tenir compte.

5) Comment savoir si c’est notre DNS ou le DNS du destinataire ?

Testez depuis votre hôte mail contre plusieurs résolveurs. Si votre résolveur configuré échoue mais qu’un résolveur connu renvoie les MX corrects, c’est probablement votre chemin résolveur. Si plusieurs résolveurs indépendants échouent de la même façon, c’est probablement le DNS du domaine destinataire ou sa délégation/DNSSEC.

6) Redémarrer Postfix aide-t-il ?

Rarement. Postfix ne met généralement pas en cache le DNS de manière que le redémarrage corrige. Les redémarrages peuvent ajouter du churn et du délai pendant que la file continue de grossir. Réparez le DNS, puis videz la file quand tout est stable.

7) Pourquoi voyons-nous « host not found » seulement aux heures de pointe ?

Vos résolveurs peuvent être surchargés, perdre des paquets, ou être limités en débit en amont. Les problèmes d’heure de pointe sont souvent des problèmes de capacité ou de perte de paquets déguisés en « mystères DNS ». Mesurez la latence et les taux de timeout pendant les pics, pas à 14h quand tout est calme.

8) Quels paramètres Postfix amplifient le plus souvent les échecs DNS ?

Les restrictions SMTP qui effectuent des recherches DNS pendant le traitement de la connexion (vérifications de domaine expéditeur, vérifications de nom client) et l’usage intensif des RBL peuvent transformer la lenteur des résolveurs en lenteur ou rejet SMTP. Ce n’est pas intrinsèquement mauvais — c’est un compromis à faire volontairement.

9) Comment maintenir le flux de mail pendant un incident de résolveur ?

À court terme : retirez le résolveur défaillant de votre configuration, ou pointez les relais mail vers un résolveur récursif stable destiné à la production. À moyen terme : exécutez un résolveur cache local sur les hôtes mail pour lisser les pannes en amont et réduire la latence.

10) Les domaines search dans resolv.conf posent-ils un vrai problème pour Postfix ?

Ils peuvent. Un point manquant ou un nom partiel peut déclencher des requêtes supplémentaires quand le résolveur ajoute les domaines de recherche. Cela perd du temps et peut créer des modèles de trafic surprenants. Pour l’infrastructure mail, soyez conservateur avec les domaines search et préférez les noms pleinement qualifiés dans les configs.

Conclusion : prochaines étapes réalisables cette semaine

Si vous ne faites que trois choses, faites celles-ci :

1. Ajoutez de la supervision qui reflète la réalité : alertez sur la profondeur de file et sur les échecs/latences de résolution DNS depuis les hôtes mail eux-mêmes.
2. Rendez votre chemin de résolveur ennuyeux : deux résolveurs en amont sains, comportement prévisible, et idéalement un résolveur cache local sur les relais mail.
3. Arrêtez de transformer les incidents DNS en perte de courrier : soyez prudent avec les rejets SMTP dépendants du DNS sauf si vous avez une fiabilité de résolveur forte et une intention métier claire.

Puis planifiez un court exercice : prenez un relais de staging, cassez volontairement une IP de résolveur, et observez ce qui se passe. Si votre système échoue « silencieusement », vous aurez appris quelque chose inestimable — et vous l’aurez appris sans mettre la production en feu.