DNS: Seltsames Verhalten des Telekom-Resolvers "ul-lb-a01.isp.t-ipnet.de" (217.237.150.188) bei bestimmten CNAME-Records
vor 4 Jahren
Liebes Telekom-Team,
ich nutze zu Hause einen Telekom-VDSL-Anschluss (250/40 Mbit/s) in Ulm, arbeite an der Universität Ulm und bemerke -wie einige Kolleginnen und Kollegen von mir- seit heute Mittag Probleme mit der DNS-Auflösung von Namensressourcen der Universität. Konkret scheint der Nameserver "ul-lb-a01.isp.t-ipnet.de" (217.237.150.188), der meinem Router als primärer DNS-Server zugewiesen wird, Schwierigkeiten beim Auflösen von einigen Hostnamen meines Arbeitgebers zu haben. Der zweite Nameserver "s-lb-a01.isp.t-ipnet.de." (217.237.151.142) ist sporadisch etwas träge, aber löst problemlos auf.
Konkret geht um die folgenden Hostnamen:
bbb.uni-ulm.de
scalelite.bbb.uni-ulm.de
und weitere Server unserer BigBlueButton-Cloud, die wir an der Universität Ulm betreiben.
Gebe ich zu Hause am Telekom-Anschluss ein:
steffen@blackbird:~$ nslookup bbb.uni-ulm.de 217.237.150.188
Server: 217.237.150.188
Address: 217.237.150.188#53
so erhalte ich:
** server can't find bbb.uni-ulm.de: SERVFAIL
Andere Hosts aus der selben DNS-Zone werden dagegen aufgelöst:
steffen@blackbird:~$ nslookup www.uni-ulm.de 217.237.150.188
Server: 217.237.150.188
Address: 217.237.150.188#53
Non-authoritative answer:
Name: www.uni-ulm.de
Address: 134.60.1.22
Name: www.uni-ulm.de
Address: 2001:7c0:3100::22
Bemerkenswert ist, dass alle von dem Problem betroffene Hosts in der Zone "uni-ulm.de" mit CNAME-Records eingetragen sind:
steffen@blackbird:~$ dig bbb.uni-ulm.de @217.237.150.188
; <<>> DiG 9.16.6 <<>> bbb.uni-ulm.de @217.237.150.188
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 54643
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;bbb.uni-ulm.de. IN A
;; ANSWER SECTION:
bbb.uni-ulm.de. 47051 IN CNAME 9137240d-b196-4115-b7cf-4dcd353e9280.ul.bw-cloud-instance.org.
;; Query time: 3111 msec
;; SERVER: 217.237.150.188#53(217.237.150.188)
;; WHEN: Mi Nov 11 20:10:58 CET 2020
;; MSG SIZE rcvd: 118
Es scheint also, als würde "217.237.150.188" insbesondere dann den SERVFAIL werfen, wenn ich nach einem Hostnamen frage, der einen CNAME-Record trägt. Dies, wie weitere Tests zeigen, allerdings nur, wenn dieser wiederum nach "bw-cloud-instance.org" verweist.
Andere mit CNAME-Records referenzierte Hostnamen verursachen wiederum keine Probleme. Fragt man aber direkt den CNAME an, geht es ohne Fehler:
steffen@blackbird:~$ dig A 9137240d-b196-4115-b7cf-4dcd353e9280.ul.bw-cloud-instance.org. @217.237.150.188
; <<>> DiG 9.16.6 <<>> A 9137240d-b196-4115-b7cf-4dcd353e9280.ul.bw-cloud-instance.org. @217.237.150.188
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14316
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;9137240d-b196-4115-b7cf-4dcd353e9280.ul.bw-cloud-instance.org. IN A
;; ANSWER SECTION:
9137240d-b196-4115-b7cf-4dcd353e9280.ul.bw-cloud-instance.org. 30 IN A 134.60.154.210
;; Query time: 7 msec
;; SERVER: 217.237.150.188#53(217.237.150.188)
;; WHEN: Mi Nov 11 20:16:28 CET 2020
;; MSG SIZE rcvd: 106
Allerdings kommt der Browser schon gar nicht so weit, dies zu tun, denn die Resolver-Bibliothek des Betriebssystems gibt nach dem ersten SERVFAIL offenbar auf. Dies führt zur Nicht-Erreichbarkeit unseres in der Online-Lehre eingesetzten Videokonferenz-Systems von vielen Heimarbeitsplätzen aus.
Dass dieses Verhalten jedoch nur bei "217.237.150.188" passiert, spricht dann aus meiner Sicht doch sehr dafür, dass es offenbar speziell bei diesem Resolver ein Problem gibt. Ein Test mit dem zweiten Nameserver, der meinem Router zugewiesen wird, zeigt dies deutlich:
steffen@blackbird:~$ dig bbb.uni-ulm.de @217.237.151.142
; <<>> DiG 9.16.6 <<>> bbb.uni-ulm.de @217.237.151.142
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1093
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;bbb.uni-ulm.de. IN A
;; ANSWER SECTION:
bbb.uni-ulm.de. 47570 IN CNAME 9137240d-b196-4115-b7cf-4dcd353e9280.ul.bw-cloud-instance.org.
9137240d-b196-4115-b7cf-4dcd353e9280.ul.bw-cloud-instance.org. 32 IN A 134.60.154.210
;; Query time: 7 msec
;; SERVER: 217.237.151.142#53(217.237.151.142)
;; WHEN: Mi Nov 11 20:09:30 CET 2020
;; MSG SIZE rcvd: 134
Hierüber funktioniert also alles perfekt! Ebenso funktioniert alles bestens, wenn ich mich in VPN des Arbeitgebers "einwähle" und die dort zugewiesenen Resolver nutze. Auch bei Kolleginnen und Kollegen, die bei anderen Providern sind, gibt es keine Probleme. Auch wenn ich direkt am Arbeitsplatz an der Universität sitze: Keine Schwierigkeiten.
Unter dem Problem leiden seit heute sehr viele Telekom-Kunden, die die BigBlueButton-Instanz der Universität Ulm derzeit für die Online-Lehre nutzen. Es wäre daher extrem hilfreich, wenn Sie das Problem an Ihre DNS-Experten weiterleiten könnten.
An der DNS-Konfiguration der Universität sind keine Fehler feststellbar und das Problem ist für mich nur beim Resolver "ul-lb-a01.isp.t-ipnet.de" (217.237.150.188) reproduzierbar.
Herzlichen Dank dafür im Voraus! Für Rückfragen stehe ich gerne zur Verfügung.
Freundliche Grüße
Steffen Moser
827
11
Das könnte Ihnen auch weiterhelfen
vor 11 Monaten
in
149
0
2
vor 5 Jahren
in
472
0
2
vor 4 Jahren
sieht so aus, als ob 217.237.150.188 keine Route zu ns1.ul.bw-cloud-instance.org hat.
8
Antwort
von
vor 4 Jahren
Ich habe den Netzwerkverkehr einmal mitgeschnitten, wenn ich "dig" nutze, um "bbb.uni-ulm.de" einmal von "217.237.150.188" und einmal von "217.237.151.142" auflösen zu lassen.
1) dig bbb.uni-ulm.de @217.237.150.188
Man erkennt, dass der DNS-Resolver der DTAG hier mit "Recursion available" antwortet, aber sie dann dennoch nicht ausführt und mit einem SERVFAIL quittiert. Ohne die RFCs nun im Detail durchdrungen zu haben, würde ich sagen, dass das Verhalten nicht in Ordnung ist. Wenn der Resolver keine Recursions anbieten will oder kann, dann ist das sein gutes Recht. Der Client muss sich dann per separater Query um den CNAME kümmern. Aber dann darf er nicht sagen, dass er Recursions kann und sie dann doch nicht liefern. Dies irrtiert zumindest die Resolver-Bibliothek meines Betriebssystems (OpenSUSE Tumbleweed) und der Browser (Firefox 82) lädt die Seite nicht. Dies geht seit gestern gegen Mittag vielen meinen Kollegen so, und da ich davon ausgehe, dass die Mehrzahl Windows und macOS nutzt, scheint es auch dort die lokalen Resolver-Bibliotheken durcheinanderzubringen...
Es fällt weiterhin auf, dass mein Rechner zwei Query-Datagramme versenden muss, um überhaupt vom DTAG -Server eine Antwort zu bekommen. Dies war bei Tests mehrfach der Fall. Nun kann es auf einer DSL immer mal Packet-Loss geben, aber der Anschluss hier läuft äußerst robust, DSL-Uptimes von mehreren Monaten (aktuell: letzter Sync vor 75 Tagen) sind die Regel, ich habe fast keine CRC-Fehler, vielleicht mal einen pro Tag. D.h. Packet-Loss auf Kundenseite schließe ich als Ursache aus.
Der Rechner, von dem aus ich getestet habe, hängt per Kabel am Router. Also gehe ich davon aus, dass der 217.237.150.188 entweder ein Lastproblem hat oder eines seiner Interfaces möglicherweise Pakete verliert. Möglicherweise sind sein seltsames Verhalten bzgl. der Beantwortung meiner Query und des Verlierens von Queries ja Symptome derselben Ursache?
2) dig bbb.uni-ulm.de @217.237.151.142
Hier sieht alles gut aus. Die Anfrage wird, wie vesprochen, rekursiv beantwortet. Es gibt aber auch bei diesem Server Hostnamen, die Probleme machen. So macht z.B. "scalelite.bbb.uni-ulm.de" auf beiden Servern Probleme, wie sich im Laufe des Abends herausgestellt hat.
Ich würde mich freuen, wenn sich dies einmal die Experten für die DNS-Resolver-Infrastrukturim Hause DTAG anschauen könnten. Das Problem ist nicht nur ein Problem von mir, der User-Helpdesk der Universität Ulm wurde gestern gegen Mittag mehr oder weniger zeitgleich vonsehr vielen Usern kontaktiert, die nun nicht mehr an Online-Vorlesungen teilnehmen oder diese gar halten konnten. Work-Arounds sind im Moment, VPN zu nutzen oder den Google-DNS 8.8.8.8 als DNS-Forwarder anzugeben.
Viele Grüße aus Ulm
Steffen
Uneingeloggter Nutzer
Antwort
von
vor 4 Jahren
ich hoffe, dass es sich wieder eingependelt hat.
Ansonsten melde dich gerne.
Liebe Grüße
Stella A.
1
Antwort
von
vor 4 Jahren
Hallo Stella,
Hallo @Steffen Moser, ich hoffe, dass es sich wieder eingependelt hat. Ansonsten melde dich gerne.
ich hoffe, dass es sich wieder eingependelt hat.
Ansonsten melde dich gerne.
Danke der Nachfrage! In der letzten Woche zeigten sich keine Auffälligkeiten. Meine Kollegen haben die CNAME-Records durch A- und AAAA-Records ersetzt, sodass wir unmittelbar nach Ablauf der TTLs wieder unsere Videokonferenz-Infrastruktur zur Verfügung hatten. Wir haben zusätzlich noch einen Record im DNS, der noch über einen CNAME in die bwCloud-Infrastruktur zeigt, um das Ganze zu beobachten - auch da sieht zur Zeit alles gut aus. Sollte das Problem wieder auftauchen, melde ich mich.
Viele Grüße
Steffen
Uneingeloggter Nutzer
Antwort
von
Uneingeloggter Nutzer
Antwort
von