Een mailserver die plots berichten begint vast te houden, met in de queue een foutmelding als deze:
Host or domain name not found. Name service error for
name=example.com type=MX: Host not found, try againDe queue groeit aan, de leeftijd van de oudste berichten loopt op naar uren, en het treft niet alle domeinen. Sommige bestemmingen werken gewoon nog. Er is niets gewijzigd aan de mailserver.
Ik heb hier een tijd op gezocht, en de oorzaak lag niet waar ik ze verwachtte. Ik schrijf het op omdat de foutmelding je op een verkeerd spoor zet, en omdat de meest logische oplossing precies de verkeerde is.
Wat er niet aan de hand was
De foutmelding suggereert een DNS-probleem bij de ontvangende partij, of een tijdelijke storing. Dat is ook wat je als eerste controleert. Maar de records waren correct, publieke resolvers gaven wel een antwoord, en het probleem bleef terugkomen voor een deel van de bestemmingen.
De echte oorzaak
Op de router was kort daarvoor een advertentieblokkering ingeschakeld. Dat soort functies, en ook contentfiltering of geforceerde DNS, doet meer dan alleen filteren. Ze onderscheppen al het uitgaande verkeer op poort 53 en antwoorden zelf als recursieve resolver. Voor gewone clients merk je daar niets van.
Mijn mailserver gebruikt echter een eigen recursieve resolver die het werk zelf doet. Die stelt zijn vragen rechtstreeks aan de rootservers en de servers van de topleveldomeinen, en verwacht daarop een verwijzing naar de volgende server in de keten. In plaats daarvan kreeg hij een volledig recursief antwoord terug van de onderschepper.
Zo’n antwoord past niet in het protocolverloop dat de resolver aan het afhandelen is. Hij verwerpt het, probeert opnieuw, verwerpt weer, tot hij zijn maximum aan pogingen bereikt en een SERVFAIL teruggeeft. Postfix ziet dan een tijdelijke DNS-fout en doet wat hij moet doen: het bericht in de queue houden en later opnieuw proberen.
Vandaar het onregelmatige patroon. Domeinen die nog in de cache zaten werkten gewoon, alles wat opnieuw opgezocht moest worden faalde.
De test die het uitwijst
Deze is beslissend. Stel een vraag zonder recursie rechtstreeks aan een rootserver:
dig +norecurse example.com MX @192.33.4.12 +time=5 +tries=1Een echte rootserver geeft een verwijzing terug. Geen antwoordsectie, en de vlaggen voor autoritatief en recursie staan niet aan. Zie je in de plaats daarvan een volledig antwoord, met die vlaggen wel aan, een responstijd van ongeveer één milliseconde en een DNS-cookie, dan praat je niet met een rootserver maar met iets op je eigen netwerk.
Een tweede controle, ter bevestiging:
dig +short id.server CH TXT @198.41.0.4Echte rootservers geven hier hun identiteit terug. Een onderschepper geeft een leeg antwoord.
Waarom je dit niet oplost met een publieke resolver
De reflex is begrijpelijk. Zet die eigen resolver af en verwijs de mailserver naar de router of naar een publieke resolver, en je queue loopt weer leeg. Het probleem is weg en je hebt een nieuw probleem gemaakt dat je niet ziet.
Spamfiltering leunt namelijk op DNS-blocklists, en die diensten weigeren vragen die via grote publieke resolvers binnenkomen. Ze zijn gratis voor eigen gebruik, niet voor het volume dat langs zo’n resolver passeert. Je krijgt dan geen foutmelding. Je krijgt eenvoudig geen treffers meer, waardoor je filtering stil uitvalt en je spam ziet toenemen zonder duidelijke oorzaak.
Een mailserver die zelf zijn DNS-vragen stelt, vanaf zijn eigen IP-adres, is dus geen luxe. Het is een voorwaarde om spamfiltering te laten werken.
De juiste oplossing
Sluit de mailserver uit van de advertentieblokkering en van elke vorm van DNS-omleiding of contentfiltering op zijn netwerk. Het doel is eenvoudig te formuleren: uitgaand verkeer op poort 53 vanaf die server moet het internet onaangeroerd bereiken. Laat de eigen resolver staan.
Inbraakdetectie en -preventie in beide richtingen mag gewoon aan blijven. Dat breekt de recursie niet.
Nadien controleren
Leeg de cache voor een paar domeinen die faalden, vraag ze opnieuw op, en test een adres uit een DNS-blocklist om te bevestigen dat ook dat pad werkt. Flush daarna de queue en kijk of berichten effectief de status verzonden krijgen. Een lege queue alleen is geen bewijs van aflevering, want een bericht kan ook verdwijnen omdat het teruggestuurd werd.
Wat je hieruit meeneemt
Een netwerkinstelling die niets met mail te maken heeft, kan je volledige mailverkeer platleggen. En de snelste oplossing is hier precies de oplossing die je spamfiltering stil onderuit haalt. Dat is het soort probleem dat je enkel vindt wanneer je de netwerklaag en de mailserver samen kan bekijken.
Loop je hier tegenaan en kom je er niet uit, stuur me gerust een bericht.