News .de-Domains nicht erreichbar: Probleme bei der DENIC legten deutsche Internetseiten lahm

[fdsonne]

Ja, das mit der Simulation ist auch meine erste Vermutung.

Simulation? Wer sprach von Simulation?

Aber 🤫 Ich will keine Probleme bekommen.
Danke, passt schon alles.

Naja, wenn Leute sich hinstellen und:
"Komisch, hier ging welt.de

Das war echt wieder ne merkwuerdige Stoerung."
sagen, dann kann man schon zweifeln... Ja, die Server hinter "welt.de" gingen und waren nicht in irgendeiner Form beeinträchtigt. Was aber eben nicht ging, war die Namensauflösung für alle .de Domains bei Gegenprüfung der Signaturen (DNSSEC).

Wie oben gesagt, wenn du keine Signaturprüfung nutzt oder an DNS Server deine Anfrage sendest, die das ihrerseits nicht tun, bemerkst du davon nix. Dann sieht es so aus als würde alles gehen. Aber es ging eben nicht alles.

Mit 1.1.1.1 hat bei mir gestern allerdings alles problemlos funktioniert.

Cloudflare hat gestern Abend die DNSSEC Validierung temporär für .de Domains abgestellt. Sprich dass die 1.1.1.1 ging ist je nach Zeitpunkt normal, weil sie eben keine Validierung mehr durchgeführt haben.

Na, vergiss mal nicht das manche Leute auch ihren DNS korrekt mit DoT verwenden. Es ist durchaus möglich, dass durch den Patch zwar das unverschlüsselte Processing abgeraucht ist, die DoT Schiene aber ganz normal weiter funktionierte. Ohne Einblicke in das innere Processing letztlich unmöglich zu beruteilen.

Und wie kommt die DNS Antwort IN den DoT oder DoH Host?
-> Das Kernproblem hier ist und war, dass die Signatur für .de Domains nicht valide war. Das heißt, wenn du ausschließlich DoT oder DoH nutzt, dann wird das Problem am Ende trotzdem nur eine Ebene weiter vor geschoben. Nämlich zwischen den DoT/DoH Anbieter und der DENIC, die ihrerseits für die .de TLD zuständig sind.

Auch in dem Fall gibt es nur die zwei validen Fälle, die zutreffen können. Wahrscheinlich nutzt jeder halbwegs seriöse DoH/DoT Anbieter DNSSEC seinerseits um die Daten zu validieren.

Der Unterschied dort ist nur, für den Weg vom Client zum DoT/DoH Server gibt es andere Regeln. Es gibt dort in der Form erstmal so keine TTL. Sprich der Kram könnte viel länger in Cache DBs der DoT/DoH Anbieter verweilen als die ursprüngliche TTL des DNS Eintrags mal vorgesehen hat.

Wie gesagt, bei mir hat mit DoT und 1.1.1.1 auch alles funktioniert. Und ich wüsste nicht, was bei DoT im Router oder Adapter cachen sollte, das ist vom Prinzip (Transportverschlüsselung) her ausgeschlossen.

Der Cache ist die Datenbank des DoT/DoH Anbeiters, der die Quelldaten aus dem DNS System holt und dann in eine lokale Cache Datenbank schreibt um schnell auf Anfragen reagieren zu können. Solange die Daten in diesen Caches stehen, gehen auch die Antworten. Das ändert aber nix an der Tatsache, dass das Problem trotzdem vorhanden ist. -> das ist praktisch die Option B) wie oben genannt.

 

[nipponpasi]

Wer sprach von Simulation?

Ich, aber muessen wir auch nicht weiter drueber sprechen.

dann kann man schon zweifeln...

fair enough ☝️😌

Wie oben gesagt, wenn du keine Signaturprüfung nutzt oder an DNS Server deine Anfrage sendest,...

Wirklich, ich hab keine Ahnung 🤷‍♂️

 

[Weyoun]

Wie kann ich mir die direkte ip´s speichern? Also zb von CB?

Das hängt davon ab, ob die wirklich dauerhaft statisch ist, oder ab und zu geändert wird. Kann man als Hosting-Kunde dauerhafte IP-Adressen erwerben (also auf Lebenszeit)? Spätestens bei einem möglichen Wechsel des Hosters dürfte das dann aber aber auch bei statischer IP wieder ein Thema werden.

 

[fdsonne]

Kann man als Hosting-Kunde dauerhafte IP-Adressen erwerben (also auf Lebenszeit)? Spätestens bei einem möglichen Wechsel des Hosters dürfte das dann aber aber auch bei statischer IP wieder ein Thema werden.

Technisch gesehen kannst du das. Zumindest wenn du die jährlichen Gebühren für die IP Blöcke zu zahlen bereit bist. Es gibt PA (Provider Aggregatable) und PI (Provider Independent) Adressen. Das Hauptproblem ist wahrscheinlich aktuell, zumindest im IPv4 Umfeld, dass es fast keine dieser Adressblöcke mehr zu kaufen gibt. Die Hoster selbst haben ihrerseits IP Blöcke gekauft und nutzen diese an ihren Standorten. Aufgrund der Knappheit rücken diese solche IPs aber eben nicht für extern raus. Sprich du kannst nicht deine IP dort einfach "abkaufen" und mitnehmen.

Wahrscheinlich ist da aber auch Niemand "böse" drüber, wenn du selbst mit deiner IP Range ums Eck kommst und bei Provider Wechsel eben dann "mitnimmst".

Meist gibt es aber Beschränkungen und Vorgaben, vor allem durch die RIPE, wie groß die Blöcke sind die im Internet dann geroutet werden sollen. Denn jeder Split der Netzbereiche sorgt für Einträge in der Routing Tabelle. Aktuell sind das grob über den Daumen 1.000.000 Einträge im BGP. Einzel IPs werden da definitiv nicht geroutet. Ich meine mich zu erinnern dass du mindestens ein /29 brauchst. Das kann aber auch falsch im Hinterkopf sein. Also bitte nicht drauf festnageln...

 

[Sun_set_1]

-> Das Kernproblem hier ist und war, dass die Signatur für .de Domains nicht valide war. Das heißt, wenn du ausschließlich DoT oder DoH nutzt, dann wird das Problem am Ende trotzdem nur eine Ebene weiter vor geschoben. Nämlich zwischen den DoT/DoH Anbieter und der DENIC, die ihrerseits für die .de TLD zuständig sind

Ja na klar. Aber darum gehts (mir) gar nicht. Du kannst doch trotzdem einen Bug haben, der die Annahme von ursprgl unverschlüsselten Paketen verhindert, die von ab der Quelle verschlüsselten aber zulässt.
Jetzt hört mein Verständnis an der Stelle auf aber ich weiß gar nicht genau wie das beim Abgangs-DNS mit DoT läuft. Entpackt der Server die Anfrage, schaut auf die TLD und schnürt sie dann wieder unverändert wie ursprünglich zu?

Oder decrypted der Server, schaut sich die TLD an, schreibt was aka "i was here" in den Header und verschlüsselt dann mit eigenem Secret neu? Oder geht das plain in https?

Alleine schon hier gibts zwei fehleranfällige Aspekte,

1. Die Verschlüsselung selbst. Wird wieder orginal verpackt oder wird mit eigenem Secret neu verschlüsselt zwischen Abgang und Empfang-DNS? Hat alles sauber funktioniert?
2. Wird bei dem Vorgang was in den Header geschrieben? Ggf. ein Wert den der Empfangs-DNS benötigt um sauber antworten zu können? Aka Message IID? Ging ggf hier was schief?

Der Unterschied dort ist nur, für den Weg vom Client zum DoT/DoH Server gibt es andere Regeln. Es gibt dort in der Form erstmal so keine TTL.

Vermute weil die erstmal rein https nutzen? Wie sieht es bei aktivem DoT aus, hier muss das Paket ja dann quasi im HTTPS nochmals als DoT-Paket verschlüsselt vorliegen? Oder entschlüsselt der Abgangs-DNS, packt es in HTTPS und wird dann wieder am Empfangs-DNS quasi plain text verarbeitet? Ich hatte DoT / DoH immer als E2E encrypt verstanden? In meinem Kopf hat der erste DNS immer nur auf die TLD zwecks Ermittlung -ZielDNS geschaut und dann das verschlüsselte Paket weitergeleitet?

Alleine das wären doch schon wieder zwei neue Fehlerquellen. Idk find das sehr schwierig zu beurteilen, wenn man nicht selbst dort arbeitet. Es gibt so vieles, außerhalb vom Standard-DNS Protokoll, das schief laufen kann, da find ich die Aussage "es gibt nur zwei Möglichkeiten" einfach schwierig.


Edit:

Habs aus Interesse nachgeschaut. Wir haben beide nen Punkt. Ganz generell technisch ist es egal wie die Ursprungsanfrage läuft. DNS1-> DNS2 entscheiden erstmal autark ob sie auch https / tls basiert kommunizieren oder nicht.

Aber,
Viele Anbieter verfolgen die Philosophie, wenn wir DoT anbieten, verschlüsseln wir komplett -> In dem Fall greift oft die Logik: Wenn ursprünglich verschlüsselt wurde, wird auch für den Rest Verschlüsselung genutzt.
Kommt die erste Anfrage plaintext rein, kann sie auch zB aus Loadbalancing Gründen plaintext an DNS2 weitergeben werden. Kommt die Anfrage per DoT rein, ist dies keine Option mehr.

In dem Sinne kann die Nutzung durchaus einen Unterschied im Antwortverhalten begründen.

 

[Dinonator]

damit gehts:

Da sind DNS-Server von Cloudflare und Google.

Cloudlare und Google sind Krankheiten!
Jetzt werde ich noch meine DNS Anfragen (z.B. Surfverhalten), an DIESE Kammeraden schicken,
wobei ich den Dreck ebend vermeiden will.

Ging übrigens nach einer Weile, gestern Nacht ~01:xx auch nicht mehr!

Ergänzung (Heute um 12:08)

Wow CB heute mal wirklich schnell!

Hab auch gerade Probleme festgestellt und mich gefragt, ob es nur an mir und Telekom liegt.

Blöd weil ich nun meine 2FA nicht abschließen kann, weil ich nicht ins Email Konto komme xD

Tipp:
Willste eine Nation lahmlegen, drücke jedem Affen ein Smartphone in die Hand,
mit dem ALLES gemacht werden kann, auf einem EINZIGEN Gerät (Tolle Sache).
Ein Hoch auf die "Apps"! PS: Das Bargeld MUSS auch weg!

Ergänzung (Heute um 12:14)

Wenn du Internet sehr effektiv lahmlegen willst, kill einfach DNS. So viel zum Thema Resilienz…

Das Internet selber (IP-Protokoll + TCP), juckt "dein DNS" aber so was von gar nicht!
Die abhängigen WWW's Fritzen, und wer ist das nicht (inkl. mir, aber versuche es immer mehr zu vermeiden),
erwischt es halt voll.

Ich habe sogar von Kreaturen gehört, die ihre Firewalls per 2FA (DNS,WWW basierend Quellen/Ziele) "absichern". Dann kannste nicht mal mehr checken, an was es liegt, weilst nicht mehr rankommst.

Tipp (nochmal):
Willste eine Nation lahmlegen, drücke jedem Affen ein Smartphone in die Hand,
mit dem ALLES gemacht werden kann, auf einem EINZIGEN Gerät (Tolle Sache).
Ein Hoch auf die "Apps"! PS: Das Bargeld MUSS auch weg!

 

[valizz]

und ich dachte mein internet spinnt wieder

 

[frames p. joule]

Spekulationen und wage* Feindbilder über Privatpersonen

Hier waren wohl die Anführer der Länder Russland, Nordkorea, China und Palästina gemeint.

Zeitlicher Zusammenhang - die DENIC hatte gestern Abend eine Party in Berlin.
Es ist Humor.

Ja, hab ich auch als Versuch von Humor aufgefasst, aber trotzdem verstehe ich es nicht.

 

[Dinonator]

Und ich dachte mir mein Provider hat mich gesperrt, wegen exzessivem XXX kucken!
Weiter dachte ich, ich habe meinen russischen MP3 Lieferanten zu oft angesurft.

Dann dachte ich: AHA nun ist die EU-Alterskontrolle AKTIV!

PS: Bloß weil ich paranoid bin, heisst das nicht, dass sie nicht hinter mir her sind!

 

[nipponpasi]

Nordkorea, China

War ja klar, gleich wieder auf Weonsunim Kim Jong Un oder den Chinesen rumhacken. 😒

Vielleicht ist auch einfach irgendwas kaputt gegangen?

 

[Sun_set_1]

Ja, hab ich auch als Versuch von Humor aufgefasst, aber trotzdem verstehe ich es nicht.

Ich glaube du gehst da mit zu viel Hirnschmalz ran. Er wollte ganz einfach andeuten das jemand besoffen auf den falschen Knopf gedrückt hat.

Auch der Aspekt, dass du ein System hast das prinzipiell 99,9999% Verfügbarkeit bietet aber genau dann an dem einen Tag im Jahr abraucht, an dem sie ne Firmenfeier veranstalten. Das hat schon ne gewisse Ironie in sich.

 

[nipponpasi]

Das hat schon ne gewisse Ironie in sich.

Das ist spaeter was fuer die Lore am Lagerfeuer.

 

[frames p. joule]

rumhacken

Ja, ich habe nur gesagt, der Kommentar war nicht rassistisch, sondern legitim. Die Frage habe ich selber nicht gestellt.

 

[nipponpasi]

war nicht rassistisch

Ja, so hab ich das auch nicht aufgefasst! 🤝

 

[Avenger84]

ich habe hier mehrfach den Tipp gelesen man solle sich von seinen Favoriten Seiten die IP Adressen verlinken für den Störfall, wie gestern Abend.
Das ist natürlich Unsinn.

Vermutlich haben die Tippgeben nicht mal kurz probiert, ob es überhaupt klappen könnte, z.B. CB:

Die Website ist nicht erreichbar
Die Webseite unter https://212.83.33.137/ ist eventuell vorübergehend nicht verfügbar oder wurde dauerhaft an eine neue Webadresse verschoben.

Selbst wenn man den Zertifikatsfehler weg klickt, kommt man dennoch nicht zum Ziel.

Warum?

a) Seiten teilen sich einen Server (IP-Adresse) mit (zig) anderen Seiten. Der Name (Domain) wird im Host-Header mitgesendet – fehlt dieser -> Error.

b) meinen Webserver Zuhause habe ich, z.B. gegen falsche URL oder IP-Adresseingabe geschützt, das tun vermutlich auch die "großen" so oder so ähnlich:

catchall:

server {
    server_name _;
    listen 443 ssl default_server;
    listen [::]:443 ssl default_server;
    http2 on;
    listen 443 quic default_server;
    listen [::]:443 quic default_server;
    ssl_certificate /etc/letsencrypt/live/xxx.de/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/xxx.de/privkey.pem;
    return 444;
}

die anderen config Blöcke hören entsprechend nur auf ihren Namen:

server {
    server_name meinedomain.de www.meinedomain.de;
    root /var/www/html;
    index index.html;
    ...

Weitere Hindernisse:
Selbst wenn man die Startseite per IP erreichen würde, alle Bilder, Skripte und Unterseiten sind im Quelltext meistens mit der Domain verlinkt. Sobald man also irgendwo hin klickst oder die Seite Ressourcen nachladen will, fragt der Browser wieder den (gestörten) DNS ab – und die Seite bricht zusammen.

Große Seiten nutzen Content Delivery Networks (wie Cloudflare). Die IP-Adresse von heute, kann sich morgen schon ändern oder gehört nur zu einem Lastverteiler, der ohne den korrekten Domainnamen den Zugriff verweigert. Zudem sind diese IPs oft dynamisch.

 

[nipponpasi]

@Avenger84 danke fuer die Nachhilfe. 👨‍🎓

 

[Kampfbiene]

Ich fand es ganz "interessant". DNSSEC funktioniert offensichtlich, es ist ja durchaus Absicht, dass die Seiten dann nicht mehr erreichbar sind. Zumindest bis DNS Anbieter dann eigenmächtig entscheiden der Fehler sei schon nicht so schlimm und die Validierung einfach deaktivieren 🤦‍♂️

 

[aid0nex]

Mit 1.1.1.1 hat bei mir gestern allerdings auch alles problemlos funktioniert.

Ich habe ebenfalls 1.1.1.1 und als Backup 1.0.0.1 (und auch bei IPv6 das entsprechende Äquivalent) konfiguriert und habe die Probleme gehabt. Du hast ggf. Glück gehabt weil deine Anfragen noch auf deinem Router gecached waren.

Hab das btw damals wegen den Urheberrechtssperren des Telekom DNS gemacht.

 

[Vexz]

Habe seit ein paar Tagen Opnsense laufen und als dann gestern Abend im LAN Domains nicht mehr aufgelöst haben, stink sauer. KI hat mir dann geraten DNSSEC abzuschalten, danach ging wieder alles. Habe das Problem aber tatsächlich nicht extern gesucht sondern in meiner Opnsense-Config vermutet. Hatte schon an meiner Wahl gezweifelt, daher gut zu wissen das hier das Problem woanders lag.

OPNsense ist eine sehr gute Wahl, keine Sorge. DNSSEC macht meiner Erfahrung nach mehr Probleme, als dass es sie löst, weshalb ich es nicht mehr nutze.

 

[Sun_set_1]

Ich habe ebenfalls 1.1.1.1 und als Backup 1.0.0.1 (und auch bei IPv6 das entsprechende Äquivalent) konfiguriert und habe die Probleme gehabt. Du hast ggf. Glück gehabt weil deine Anfragen noch auf deinem Router gecached waren.

Hab das btw damals wegen den Urheberrechtssperren des Telekom DNS gemacht.

Router kann ich ausschließen da wie gesagt DoT aktiviert war, da kann der nichts cachen.
DNS Empfangsserver sieht natürlich anders aus, kA. Hast Du auch DoT aktiviert?