#neuland der klassischen Medien
Wir betreiben ja DNS-Server im Rahmen der ISP-Tätigkeit. Diese Server bedienen die Anfragen der Kunden und sollten deswegen zuverlässig und schnell antworten. Dazu schau ich mir ab und zu an, welche Anfragen bei welchen Server Probleme bereiten. Diesmal traf es die regionalen Zeitungen.
Trau, schau, wem
In regelmäßigen Abständen wird eine Stichprobe der unbearbeiteten Queries mitgeloggt, um die Problemfälle zu finden.
Also schauen wir mal in die Liste der Server, die länger als 10 Sekunden keine Antwort auf eine bestimmte Anfrage lieferten.
$ egrep '[0-9][0-9]\.[0-9]* iterator' /var/log/statistic.log |
awk '{print $9 " " $4 "/" $2 }' |
sort |
uniq
10.109.104.20 secureir.qa.ebaystatic.com./A
118.184.184.8 www.3322.org./A
134.91.235.100 veranstalterportal.ticketshop-thueringen.de./AAAA
134.91.235.100 www.mediengruppe-thueringen.de./AAAA
143.127.10.8 lib.norton.com./AAAA
192.166.198.86 47.250.215.85.in-addr.arpa./PTR
194.152.65.222 sme5100.d10.its.net./A
195.92.67.32 sme5100.d10.its.net./A
204.228.234.15 www.googlemail.de./A
204.236.217.229 api.prod.capptain.com./A
217.110.59.45 ads.newtention.net./A
54.221.107.196 api.prod.capptain.com./A
59.111.3.81 www.3322.org./A
62.96.140.187 ads.newtention.net./A
69.25.102.245 reports.hotbar.com./A
82.145.6.100 www.mediengruppe-thueringen.de./AAAA
82.145.6.100 www.zgt.de./AAAA
89.246.87.100 www.lesershop-thueringen.de./AAAA
89.246.87.100 www.mediengruppe-thueringen.de./AAAA
89.246.87.100 www.ticketshop-thueringen.de./AAAADer erste Fall ist klassisch: Ein Name eines gesicherten System hat einen nur intern erreichbaren Nameserver (10/8). Das ist kein Fehler, sondern entspricht dem empfohlenen Aufbau mit durchgehender Delegation bis nach intern.
Viel interessanter sind die vielen regionalen Medienangebote. Alle mit Anfragen nach IPv6 Adressen. Es ist immer der gleiche DNS-Server. Und die Wartezeiten bis zum finalen Timeout des DNS-Resolver können deutlich über 10min andauern.
Spurensuche
Die Häufung am Nameserver deutet auf eine Fehlkonfiguration hin.
Da es doch einen gewissen Bedarf nach den Inhalten gibt, und man im Zweifel auch mit einem Verantwortlichen das Problem klären könnte, qualifiziert sich dieses Phänomen zu einem interessanten Fall.
Zuerst einmal der Grundlagencheck:
$ host -t A www.mediengruppe-thueringen.de 82.145.6.100 www.mediengruppe-thueringen.de has address 82.145.6.159 $ host -t txt www.mediengruppe-thueringen.de 82.145.6.100 Host www.mediengruppe-thueringen.de not found: 5(REFUSED) $ host -t AAAA www.mediengruppe-thueringen.de 82.145.6.100 ;; connection timed out; no servers could be reached
Es hängt ganz offensichtlich vom angefragten Typ ab, wie der Server reagiert.
Dies deutet auf eine bewusste Konfiguration hin. Man möchte offenbar nur das zulassen, was man selbst für notwendig erachtet.
Wie schaut es dann dann mit DNSSEC aus? Schließlich habe ich auf den Resolvern DNSSEC Validierung an!
Dazu gibt es eine schöne Testseite: dnsviz.net. Diese liefert dieses Bild.
Oh, das schaut gar nicht gut aus!
Die vielen Warnschilder habe ich mal einzeln aufgelistet:
- www.zgt.de zone: The server(s) responded over TCP with a malformed response or with an invalid RCODE. (82.145.6.100, 89.246.87.100, 134.91.235.100)
- www.zgt.de/AAAA: No response was received from the server over UDP (tried 8 times). (82.145.6.100, 89.246.87.100, 134.91.235.100, UDP_0_NOEDNS)
- www.zgt.de/DNSKEY: The response had an invalid RCODE (REFUSED). (82.145.6.100, 89.246.87.100, 134.91.235.100, UDP_0_EDNS0_32768_4096, UDP_0_EDNS0_32768_512)
- www.zgt.de/MX: The response had an invalid RCODE (REFUSED). (82.145.6.100, 89.246.87.100, 134.91.235.100, UDP_0_EDNS0_32768_4096, UDP_0_EDNS0_32768_512)
- www.zgt.de/NS: The response had an invalid RCODE (REFUSED). (82.145.6.100, 89.246.87.100, 134.91.235.100, UDP_0_EDNS0_32768_4096)
- www.zgt.de/SOA: The response had an invalid RCODE (REFUSED). (82.145.6.100, 89.246.87.100, 134.91.235.100, TCP_0_EDNS0_32768_4096)
- www.zgt.de/SOA: The response had an invalid RCODE (REFUSED). (82.145.6.100, 89.246.87.100, 134.91.235.100, UDP_0_EDNS0_32768_4096)
- www.zgt.de/TXT: The response had an invalid RCODE (REFUSED). (82.145.6.100, 89.246.87.100, 134.91.235.100, UDP_0_EDNS0_32768_4096)
- zgt.de to www.zgt.de: No SOA RR was returned with the NODATA response. (74.208.254.254, 83.169.55.5, 195.34.161.195, 217.160.113.32, 2001:8d8:580:401:217:160:113:32, 2607:f1c0:849:fe00:74:208:254:254, 2a01:130:2000:118:195:34:161:195, 2a01:488:2000:c02:83:169:55:5, UDP_0_EDNS0_32768_4096)
- zgt.de to www.zgt.de: The Authoritative Answer (AA) flag was not set in the response. (74.208.254.254, 83.169.55.5, 195.34.161.195, 217.160.113.32, 2001:8d8:580:401:217:160:113:32, 2607:f1c0:849:fe00:74:208:254:254, 2a01:130:2000:118:195:34:161:195, 2a01:488:2000:c02:83:169:55:5, UDP_0_EDNS0_32768_4096)
- zgt.de/DNSKEY: No response was received from the server over UDP (tried 4 times). (2a01:130:2000:118:195:34:161:195, UDP_0_EDNS0_32768_512)
Kurz gesagt antwortet der Server nur auf eine Frage nach einer IPv4 Adresse korrekt. Der Rest wird entweder aktiv abgelehnt (REFUSED) oder die Anfrage komplett ignoriert (No response).
Selbst wenn eine inhaltlich korrekte Antwort zurück kommt, ist sie formal fehlerhaft.
Zum einen fehlt das (AA)-Bit, das ein zuständiger Server setzen sollte. Vermutlich ist einer der als authoritiv benannten Nameserver nur ein Recursor, der die Daten nicht in Kopie vorhält, sondern selbst auch immer an der Quelle fragen muss. Ein solcher Aufbau führt beim Ausfall der Quelle zum sofortigen Totalausfall der gesamten Zone. Sportlicher Ansatz!
Zum anderen ist die TCP-Implementierung fehlerhaft. Die Antworten entsprechen schlicht nicht der Norm. Da wäre jetzt langsam mal die eingesetzte Software von Interesse. Möglicherweise ist es sogar eine sackteure Appliance in ansprechender Gehäusefarbe mit schweren Hochglanz-Prospekten.
Auf der Suche
Der Ansprechpartner laut Whois ist telefonisch nicht erreichbar. Es tutet beliebig lange. Unglücklicherweise ist die benannte Person gleichzeitig administrativ, technisch und fürs DNS zuständig. Alle Einträge haben also die gleiche, nicht erreichbare, Telefonnummer.
Eine E-Mail werde ich nicht schreiben. Das Problem erfordert entweder ein längere schriftliche Erklärung (und da ist dieser Blogeintrag noch immer zu kurz) oder ein klärendes Gespräch, bei dem man sich auf das Gegenüber einlassen kann.
Also versuche ich über die Zentrale der FUNKE Corporate IT GmbH jemanden zu erreichen. Dort sagt man mir, dass man nicht zur IT durch stellen kann. Oh, das ist genial! Eine IT Firma, bei der die IT nur für gute Kunden erreicht werden kann.
Wesentlich hilfreicher ist dagegen die Telefonzentrale der Zeitungsgruppe Thüringen. Man reicht mich mehrfach hin und her, meist mit der Aussage Oh, da geht auch keiner dran.
Via Telefonkette gelange ich so zu Herrn H. aus der Netzwerkabteilung. Dieser hört sich das Problem an, wir kommen ins Gespräch und ich mache einen entscheidenden Fehler: Ich erkläre zu ausschweifend, welche Folgen diese Fehlkonfiguration hat.
Herr H. verbindet mich erleichtert sofort weiter zum Online Department. Schließlich hatte ich gerade gesagt, die Webseite würde deswegen mit 30 Sekunden Verzögerung …
Dort war man allerdings wesentlich schneller von Begriff und stellte mich wieder zu Herrn H. zurück. Offenbar hatten sie die besseren Worte gefunden, weil ich nun tatsächlich dazu kam, das Problem zu erklären.
Herr H. hat versprochen, sich zu informieren, wer und ob da was gemacht werden kann.
Warten auf Herrn H.