Firewalls richtig konfigurieren: Port 53 TCP und EDNS

Moin,

weil ich gerade diesen bescheuerten Fehler aus der Ferne debuggen durfte:

Liebe Menschen, die ihr Firewalls bei Kunden konfiguriert: DNS benutzt Port 53 auf UDP und TCP.
TCP ist nicht optional sondern wird in freier Wildbahn wirklich genutzt! Und ist auch standardisiert: RFC 1035, 4.2.2

Aber da dieser Fehler alleine noch genug Raum für funktionierendes DNS ließe:
Wenn eure Firewall noch der lange überholten Meinung ist, dass DNS-Antworten per UDP niemals einen Payload > 512 Bytes haben dürfen, sollte euer Resolver oder Forwarder, der hinter dieser Firewall steht, das auch wissen, damit dieser nicht per EDNS arglos größeren Payload anbietet.
Das starre 512 Bytes-Limit ist spätestens mit verbreiteter Einführung von EDNS überholt, denn jetzt können beide Seiten diese Payload-Größe aushandeln.


Also, kurz zusammengefasst:

• DNS-Anfragen mit UDP und TCP erlauben
• Wenn die UDP-Payloadgröße durch die Firewall begrenzt wird, muss der DNS-Resolver oder Forwarder diesen Wert kennen, damit er nichts falsches via EDNS advertised. Allerdings tut man sich schon aus Performance-Gründen einen Gefallen, wenn man UDP-Payload bis wenigstens 786 Bytes durchlässt - das reicht im Falle von DKIM und DNSSEC in vielen Fällen schon aus und verhindert die latenzbehafteteren Nachfragen per TCP.

Wer jetzt sagt: "Ach, was betrifft mich das, so riesengroße DNS-Antworten sind hochgradig exotisch und sowas haben wir hier nicht!":
Ausgang meiner Recherche war, dass der (aus meiner Sicht auch, aber anderweitig kaputte) Spamfilter beim Empfänger versuchte, die DKIM-Signaturen eingehender Mails gegen die DKIM-Einträge im DNS zu validieren, bei manchen Mails dann dabei wegen oben beschriebener Fehler aber keine Antworten bzw. "SERVFAIL" bekam und deshalb dann die E-Mail nicht haben wollte.
Ursache dafür war, dass der DNS-Server beim Empfänger per EDNS advertisete, dass er 1680 Bytes UDP-Payload empfangen kann. Und meine DNS-Server ihm daher wie geheißen die 517 Bytes großen Antworten per UDP schickten.
Die Firewall fraß diese Pakete auf, weil sie mehr als 512 Bytes Payload trugen. Eine Nachfrage des Empfänger-DNS-Servers via TCP scheiterte, weil die Firewall keine DNS-Anfragen per TCP heraus ließ. Also: Timeout auf allen Kanälen und damit keine Antwort.

Das Debugging wurde dadurch erschwert, dass dies nur bei einer Absenderdomain passierte. Mails anderer Domains auf dem selben Server mit dem exakt selben DKIM-Schlüssel im DNS liefen problemlos durch. Die problematische Domain war einfach insgesamt relativ lang (29 Zeichen mit Subdomain), die anderen, deutlich kürzeren Domains haben den Payload in der Antwort nicht über 512 Bytes aufgebläht.


Nachtrag:
Ich wollte doch noch ein paar nicht-repräsentative Grafiken über die Anfrage- und Antwortstatistiken meiner Nameserver mitgeben!

Das hier ist die Response-Size:


Ja, das Problem mit der Response-Size betrifft für reguläre positive Antworten (Rcode 0) zwar nur 1-2% der Queries (zumindest bei den Domains auf meinen Nameservern), aber das reicht ja wie man sieht schon aus, um ernsthafte Probleme zu verursachen.

Die Antworten mit Rcode 3 sind Antworten auf Fragen nach nichtexistenten Namen (NXDOMAIN), wo man mit DNSSEC relativ große Antworten mitliefert, weil man durch NSEC3-Hashes ja beweisen muss, dass da nichts ist. Die würden auf jeden Fall kleben bleiben, da merkt man es aber kaum, weil der Name ja eh nicht auflösbar wäre.


Ein Blick auf die gewählten Transporte: Etwa 10% aller Anfragen kommen mit TCP, also nicht ganz unsignifikant.


Das korreliert von der Menge her interessanterweise mit dem Anteil EDNS-Fähiger Resolver, die eine Buffersize von <= 1023 Bytes advertisen und deshalb für manche Antworten zwingend auf TCP umschalten müssen. Nicht-EDNS-Fähige Resolver scheinen kaum noch unterwegs zu sein.