Die gängigen zwei Gründe für einen NXDOMAIN bei einer DNS-Anfrage sind: Vertippt und vergessen. Bei vertippt ist es egal ob dies auf der Client Seite oder in der Zonendatei passiert ist: Vertippt bleibt vertippt. Und vergessen kennt jeder: Es hätte schon längst in der Zonendatei drin stehen sollen. Hätte. Nur was ist wenn man wie beim NXDOMAIN kein Ergebnis bekommt und stattdessen als Status FORMERR?
Ich hatte es bereits neulich schon einmal von einem DNS Problem: „lame server“ oder viel Spaß mit DNS. Hier verweigerte ein Server die Antwort obwohl er diese liefern müsste. Nur warum hat er dies getan? Was wäre wenn die Zonendatei und die Konfiguration korrekt wären? Was wäre wenn dieser eine Nameserver anstatt NXDOMAIN dann doch tatsächlich einen FORMERR zurück liefert? Und sogar bei Einträgen die es gibt der FORMERR kommt? Was wäre wenn das Dein DNS-Server wäre und Du jetzt nach der Ursache suchen müsstest?
Da kann man allerdings noch einen oben drauf setzen: Das ist kein generelles Problem, bei vielen funktioniert alles wunderbar. Und auch einschlägige Testtools welche man auf diversen Internetseiten findet liefern das korrekte Ergebnis zurück. Also gut, los geht es. Schauen wir uns das doch nochmals genauer an.
Was wissen wir bereits? Grundsätzlich funktioniert der DNS-Server. Der Fehler ist reproduzierbar und er ist selektiv. Das heißt bei den Personen wo dieses Problem auftritt, tritt es bei jeder DNS-Anfrage auf. Für alle anderen ist alles in bester Ordnung. Somit gibt es zwei Gruppen: Die wo es funktioniert und diejenigen wo es nicht funktioniert. Es gilt also den Unterschied zu suchen. Da für beide Gruppen der Server der gleiche ist muss die Ursache auf dem Client liegen. Irgendwas muss bei der vermeintlich gleichen Frage an den Server unterschiedlich sein. Also fangen wir mal an der Stelle an und betrachten die Frage an den Server genauer.
Zurück an die Konsole
Also gut, es geht darum zu finden was auf Client Seite passiert ist. Somit starte ich mein Werkzeug der Wahl: dig. Schauen wir uns doch mal an was hier zurück kommt:
steffen@gmn:~$ dig <domain>.com @ns1.<domain>.com
; <<>> DiG 9.16.1-Ubuntu <<>> <domain>.com @ns1.<domain>.com;; global options: +cmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 27153;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:; EDNS: version: 0, flags:; udp: 4096; COOKIE: 247f6f7828e8660c (echoed);; QUESTION SECTION:;<domain>.com. IN A
;; Query time: 204 msec;; SERVER: 1.2.3.4#53(1.2.3.4);; WHEN: Di Jun 16 21:36:49 CEST 2020;; MSG SIZE rcvd: 55
Grün markiert ist mein eingegebenes Kommando. Rot der FORMERR. Das wissen wir bereits. Aber halt, in der blau markierten Zeile mit Cookie: Da steht echoed in der Klammer, jedoch sollte hier good stehen. Also nochmals die gleiche Anfrage gestellt, dieses mal jedoch mit der zusätzlichen Option +noedns:
steffen@lka:~$ dig <domain>.com @ns1.<domain>.com +noedns
; <<>> DiG 9.16.1-Ubuntu <<>> <domain>.com @ns1.<domain>.com +noedns;; global options: +cmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23374;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0;; WARNING: recursion requested but not available
;; QUESTION SECTION:;<domain>.com. IN A
;; ANSWER SECTION:<domain>.com. 3600 IN CNAME sub.<domain>.com.
;; Query time: 204 msec;; SERVER: 1.2.3.4#53(1.2.3.4);; WHEN: Di Jun 16 21:36:57 CEST 2020;; MSG SIZE rcvd: 57
Und siehe an, das hat funktioniert. Dabei wäre es egal ob ich als Option +noedns wie gezeigt oder +nocookie verwendet hätte. Beide Optionen liefern wieder die gewohnten Ergebnisse zurück. Gesucht, gefunden: Der DNS-Server hat ein Problem mit EDNS.
Und nun?
Naja, was kann man tun? Bei mir hier im Netz läuft ein lokaler bind Server fürs DNS Caching. Gemäß Doku kann man hier sagen, dass immer dann wenn er den betroffenen Server kontaktiert werden soll EDNS abschaltet wird:
server <IP address or prefix> { edns no; };Der Link dazu: https://kb.isc.org/docs/aa-01219. Aber mal ehrlich: Will ich das tun? Nein, dass will ich nicht. Warum sollte ich die Probleme eines Dritten bei mir im DNS Resolver lösen? Hier liegt ja offensichtlich ein Fehler vor der klar wird wenn man z.B. ins RFC 6891, Absatz 6.1.2 schaut:
Any OPTION-CODE values not understood by a responder or requestor MUST be ignored.
Der Link zum RFC: https://tools.ietf.org/html/rfc6891#section-6.1.2. „Must be ignored“… Und was bekomme ich? FORMERR. Also alles andere als ignoriert. Soso…
Nein, dann soll doch lieber der DNS-Server Betreiber die passenden Updates einspielen damit EDNS bzw. die Cookies richtig funktionieren. Ich bin garantiert nicht der einzige mit dem Problem und ich werde es auch sicherlich nicht bleiben. EDNS ist nun mal wichtig für die kommenden DNS Erweiterungen.
Weitere Details zu den DNS Cookies sowie zu EDNS gefällig? Ein sehr guter Ausgangspunkt finde ich ist der DNS Flag Day von 2019: https://dnsflagday.net/2019/. Ebenso interessant dazu ist der ISC EDNS Compliance Test: https://ednscomp.isc.org/. Auch hier finden sich viele praktische Infos rund um das Thema EDNS. Und besonders Schick, deswegen heißt das Ding ja „Konformitätstest“: Hier kann man den betroffenen Server testen lassen und bekommt einen ausführlichen Bericht mit vielen weiteren Detailinformationen. Neben dem bereits genannten RFC ist auch dieses hier interessant welches die Cookies nochmals erklärt: https://tools.ietf.org/html/rfc7873#section-2.1.