blotter@c3d2.de blotter@c3d2.de (Di 14 Jun 2016 09:28:40 CEST):

┌─[ 834 Di Jun 14 09:19:09 ] └─[ user@sedna ~ ]---> cat /etc/resolv.conf # Generated by net-scripts for interface lo domain fritz.box nameserver 172.22.102.1

┌─[ 835 Di Jun 14 09:19:21 ] └─[ user@sedna ~ ]---> dig @172.22.102.1 luna2._domainkey.archlinux.org TXT ;; Truncated, retrying in TCP mode.

---------------------------^^^^^^^^^^ Leider kann man an Deiner Ausgabe nicht erkennen, ob Du schon kein EDNS mit Vereinbarung der Puffergröße verwendet hast, oder ob aber die Fritzbox das nicht mag und in der UDP-Antwort deshalb auf max 512 Byte geht, was zum Abschneiden der Antwort führt.

Man kann das sehen, wenn Du das +qr-Flag von Dig verwendest.

On 14.06.2016 10:43, Ronny Seffner wrote:

...

Hat irgendjemand eine Idee, warum dieser Record nicht über die Fritzbox abgefragt werden kann?

Negativcaching: die Fritz!Box schonmal aus gemacht, neu gestartet und den Record erneut abgefragt?

Nein.

Über/durch meine 7490 geht der Request zu beantworten.

Ich habe mittlerweile festgestellt, dass es nicht die Fritzbox ist sondern der DNS meines Providers. Es scheint viele DNS-Server zu geben, die nicht mehr als 512 Zeichen in einem Record akzeptieren. Deshalb haben die ganzen großen Mailanbieter auch nur 2048 Bit Schlüssel.

Uwe

Hallo Heiko,

On 15.06.2016 12:20, Heiko Schlittermann wrote:

Ich glaube, das ist so nicht richtig.

Das ist möglich, ich habe auch keine direkte Aussage dazu gefunden, nur Indizien.

Es gibt kaputte Routerfirmware und kaputte Firewalleinstellungen, die meinen, bei Port 53/UDP dürften es nicht mehr als 512B sein. Das stimmte früher, da was das tatsächlich die maximale Größe bei DNS.

Ich bin mir aber ziemlich sichere, dass es in diesem Fall nicht die Fritzbox ist, denn der Fehler tritt auch auf, wenn ich den von der Fritzbox benutzten Nameserver direkt frage und da es mit dem Google Nameserver auch klappt, sollte es eigentlich nichts in meinem Netzwerk sein.

Provider ist Kabeldeutschland/Vodafone und der (einer der) Nameserver ist: 83-169-185-161-isp.superkabel.de: 83.169.185.161

Heute wird Dein Client (dig) dem Server mitteilen, wie groß die UDP Pakete sein dürfen.

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:

Und was bedeutet es, wenn dieser Abschnitt in der Ausgabe von dig nicht vorhanden ist? Beim Google Nameserver und bei der Fritzbox ist dieser Abschnitt vorhanden, beim superkabel-ns nicht.

dig +qr …

Was macht '+qr'? Ich kann's in der Manpage nicht finden.

Was kommt da, wie sieht also die Query und wie sieht die komplette Antwort aus?

Mit direkter Abfrage des Nameservers:

dig +qr @83.169.185.161 luna2._domainkey.archlinux.org TXT

; <<>> DiG 9.10.3-P4 <<>> +qr @83.169.185.161 luna2._domainkey.archlinux.org TXT ; (1 server found) ;; global options: +cmd ;; Sending: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5992 ;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;luna2._domainkey.archlinux.org. IN TXT

;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 5992 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION: ;luna2._domainkey.archlinux.org. IN TXT

;; Query time: 37 msec ;; SERVER: 83.169.185.161#53(83.169.185.161) ;; WHEN: Wed Jun 15 18:25:14 CEST 2016 ;; MSG SIZE rcvd: 48

Uwe

Uwe Koloska ml@koloro.de (Mi 15 Jun 2016 18:29:48 CEST):

Ich bin mir aber ziemlich sichere, dass es in diesem Fall nicht die Fritzbox ist, denn der Fehler tritt auch auf, wenn ich den von der Fritzbox benutzten Nameserver direkt frage und da es mit dem Google Nameserver auch klappt, sollte es eigentlich nichts in meinem Netzwerk sein.

Ok, da ist was dran.

Provider ist Kabeldeutschland/Vodafone und der (einer der) Nameserver ist: 83-169-185-161-isp.superkabel.de: 83.169.185.161

Hm, die kann man leider von außerhalb KD nicht befragen. Da müsste also mal jemand, der auch an KD hängt, das Experiment wiederholen.

...

Heute wird Dein Client (dig) dem Server mitteilen, wie groß die UDP Pakete sein dürfen.

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:

Und was bedeutet es, wenn dieser Abschnitt in der Ausgabe von dig nicht vorhanden ist? Beim Google Nameserver und bei der Fritzbox ist dieser Abschnitt vorhanden, beim superkabel-ns nicht.

Dann wird EDNS vom angefragten Server nicht unterstützt. Meine Deutung. Im Übrigen passiert genau das hier bei mir zu Hause (T-Online, Speedport W 724V).

Wenn ich den DNS-Proxy auf dem Speedport frage, gibt es eine „truncated“ UDP-Antwort und anschließend eine richtige Antwort über TCP. Wenn ich den DNS-Server frage, den der Speedport auch nutzt, dann das selbe Symptom, also truncated und dann TCP.

Aber es funktionert dann erwartungsgemäß, halt ohne EDNS. (Also in der Query ist das EDNS noch drin, in der Response vom Server nicht mehr.)

;luna2._domainkey.archlinux.org. IN TXT

Ich würde nun mal mutmaßen, dass der Server, den Dein Router verwendet, entweder am EDNS scheitert (was ich aber für unwahrscheinlich halte, denn dann würde er es bei anderen Anfragen vermutlich auch tun), oder aber, dass der am Problem der großen Antwort scheitert.

Wenn ich einen DNS-Forwarder verwende, dessen TCP-Verbindungen nach außen ich blocke (hier: @localhost), dann bekomme ich SERVFAIL, wenn ich gleichzeitig noch max-udp-size und edns-udp-size auf 512 setze.

http://web.mit.edu/ops/services/hesiod/src/bind-9.5.0-P1/doc/arm/Bv9ARM.ch06...

Es wäre jetzt weiter zu erforschen, welcher Parameter hier der entscheidende ist.

Meine Vermutung ist immer noch eine broken Firewall, vielleicht bei KD. Tritt dieser Effekt bei allen Antworten auf, die >512 sind?

Uwe Koloska ml@koloro.de (Do 16 Jun 2016 10:42:22 CEST):

On 16.06.2016 08:44, Heiko Schlittermann wrote:

...

Uwe Koloska ml@koloro.de (Mi 15 Jun 2016 18:29:48 CEST):

...

Provider ist Kabeldeutschland/Vodafone und der (einer der) Nameserver ist: 83-169-185-161-isp.superkabel.de: 83.169.185.161

Hm, die kann man leider von außerhalb KD nicht befragen. Da müsste also mal jemand, der auch an KD hängt, das Experiment wiederholen.

Ich hab's von zwei verschiedenen Anschlüssen (allerdings beide in Dresden) versucht und das gleiche Ergebnis erhalten.

...

Dann wird EDNS vom angefragten Server nicht unterstützt. Meine Deutung. Im Übrigen passiert genau das hier bei mir zu Hause (T-Online, Speedport W 724V).

Wenn ich den DNS-Proxy auf dem Speedport frage, gibt es eine „truncated“ UDP-Antwort

Würde ich die mit der folgenden Anfrage sehen? dig +qr ...

Mit +qr? Nee, das macht nur, dass die ausgehende Query angezeigt wird. Mehr Antwort bekommst Du da sicher auch nicht.

...

und anschließend eine richtige Antwort über TCP.

Ist das vielleicht der Konfigurationsfehler bei KD, dass TCP ausgeschaltet oder geblockt ist? EDNS muss ja nicht unterstützt werden.

Ja, so in der Richtung würde ich das vermuten. EDNS brauchen die nicht, dann wird halt TCP verwendet, aber wenn das nicht geht, ist es halt doof und wird zunehmend dööfer, weil die Antworten länger werden (Kontext DNSSEC).

...

Meine Vermutung ist immer noch eine broken Firewall, vielleicht bei KD.

Das würde zumindest zu den vielen Klagen über mistkonfiguriertes DNS bei KD passen ...

Du bist ja auch nicht gezwungen, die zu verwenden.

...

Tritt dieser Effekt bei allen Antworten auf, die >512 sind?

Mir sind bisher keine anderen Anfragen bzw. Zielrecords dieser Größe über den Weg gelaufen.

size-really-matters.schlittermann.de TXT Das letzte Zeichen im Ergebnis-Datensatz muss ein Z sein.

Gibt es eigentlich eine Möglichkeit mit dnsmasq bestimmte Anfragen (also z.B. *._domainkey.* oder konkret luna2._domainkey.archlinux.org) anders zu bearbeiten (an einen anderen Nameserver weiterleiten, etc.)?

server = /luna2._…/8.8.4.4/

Oder so ählich. Müsste in der Manpage zu dnsmasq stehen.