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

Ich habe nichts davon mitbekommen. :D

Ich war seit gestern morgen ab 07:00 Uhr bis gerade eben nicht im www unterwegs. ;):)
 
  • Gefällt mir
Reaktionen: the_IT_Guy und nipponpasi
Vexz schrieb:
OPNsense ist eine sehr gute Wahl, keine Sorge.
Ich habe schon viel durch, von Fritz Box über pfsense und diverse Unifi Gateways. Mal schauen wie es jetzt mit opnsense klappt. Bis jetzt bin ich allerdings sehr positiv gestimmt. Alles schnell, niedriger ping, gute Auswertungen. Mal sehen. Ausschlaggebend für mich war am Ende das die eine gute API anbieten. So kann ich claude drauf schicken und alles prüfen lassen. Muss gestehen das ich ohne die KI-Hilfe zuviel schiss hätte irgendwas grob fahrlässig falsch zu konfigurieren oder etwas essentielles liegen zu lassen. Aber mir fehlt einfach die Zeit um mich auch noch in opnsense einzugraben.
 
  • Gefällt mir
Reaktionen: Vexz
Sun_set_1 schrieb:
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?
Aber so funktioniert DNS doch nicht?

Ob verschlüsselt oder nicht, ist dem DNS Paket doch total egal. Faktisch funktioniert die Kette so, dass ein Client über DNS (idR. udp53 oder eben von mir aus auch DoH - tcp443 oder DoT - tcp853) einen Resolver DNS Server fragt und der Resolver DNS Server rennt rekursiv durch den DNS Baum und geht die zuständigen Nameserver der angefragten Zone durch um letztlich am Ende dann den passenden Wert zur angefragten Ressource zu bekommen und an den Client zurück zu liefern.
DNSSEC kommt dort oben drauf oder eben auch nicht, wenn nicht validiert. DNSSEC ist nicht! DoH und/oder DoT. Das sind zwei völlig verschiedene paar Schuhe. DoH/DoT ist eine Art Transport Verschlüsslung. Bzw. noch genauer, es ist ein gängiges Mittel in der Praxis, die sogenannte "last mile" abzusichern. Also vom Client zum DNS Resolver. Was vor dem DNS Resolver passiert, also woher der DNS Resolver seine Daten bekommt und ob er validiert ob diese stimmen (DNSSEC), ist völlig losgelöst davon.

Es gibt seit 2024 sogenanntes ADoT, was für Authoritative DNS over TLS steht und exakt das absichern soll, was DoT oder DoH nicht absichern. Nämlich die "first mile". Allerdings ist das auch in 2026 noch kein 100% gelebtes und vollständig implementiertes Thema. Gängige DNS Resolver im Netz aka Google, Cloudflare, ... prüfen initial und proaktiv auf Port tcp853 ob der Nameserver ADoT spricht, fallen aber auf normale unverschlüsselte udp53 Pakete zurück, wenn nicht. Es gibt keinen Zwang ADoT zu sprechen. Das ist für das DNS Thema generell kein Muss.


Was ich aber nicht verstehe in deiner Aussage - das spielt am Ende alles gar keine Rolle, weil DNSSEC davon komplett losgelöst ist. Egal wer in der Kette, es reicht ein einziges System was DNSSEC validiert -> dann geht ohne gültige Signatur die Auflösung nicht. Und wenn trotzdem Daten zurück kommen, dann liegt es an gecachten Einträgen.

Stell dir das bildlich einfach so vor. Früher bist du zum Geldautomaten deiner Bank gegangen um Bargeld abzuholen. Heute kannst du auch im Supermarkt Bargeld abheben. Ob du zur Bank oder den Supermarkt gehst, es spielt keine Rolle. Du brauchst Kohle auf dem Konto, sonst kommt da nix raus.
Exakt das ist hier das Thema, die DNSSEC Validierung der .de TLD schlug fehl. Quasi wie kein Geld auf dem Konto. Egal von du versucht hast. Dass das manchmal trotzdem noch ging lag einfach daran, dass teilweise dem Geldgeber nicht bekannt war, dass du blank bist. Weil der noch im Hinterkopf hatte, da ist schon noch Polster aufm Konto. Er hat es nur nicht nochmal verifiziert.
Sun_set_1 schrieb:
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,
Ich glaube du hast da irgendwie einen Denkfehler. Was du meinst ist nicht das, was üblicherweise DoH oder DoT ist. Es ist nicht notwendig da irgendwas aufzubrechen und rein zu sehen. Es interessiert auch die TLD nicht. Weil DoH/DoT nur von Client zu Resolver DNS gesprochen wird.

Was ich allerdings sagte ist, dass der DNS Resolver das was du hier beschreibst, ja trotzdem machen muss. Eben auch in 2026 noch häufig unverschlüsselt über udp53 - eben weil ADoT zwar existiert, aber bei weitem kein Muss noch überhaupt ansatzweise flächendeckend implementiert ist.
Sun_set_1 schrieb:
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.
Das ist aber halt leider technisch nicht machbar. Weil der DNS1 überhaupt keine Handhabe hat ob DNS2 ADoT spricht oder nicht. Faktisch prüfen größere DNS Resolver Hosts heutzutage durchaus, ob ADoT geht - aber wenn nicht, dann geht es halt nicht.

Am Ende aber wie gesagt auch gar nicht der Punkt. Auch mit ADoT wird man normalerweise DNSSEC validieren. Und da die Signaturen für die .de Zone nicht valide waren, ist es auch in dem Fall egal ob die DNS Anfrage Transportverschlüsselt wurde oder nicht. DNSSEC validiert die Richtigkeit von Record und Value über eine Signatur. Wenn die nicht passt, ist die Aufgabe von DNSSEC, genau genommen exakt das auch mitzuteilen. Nämlich dass das nicht stimmt. Technisch spielt es keine Rolle ob das über (A)DoT erfolgt oder nicht.


Btw. weil ich es gerade sehe, in der Pressemitteilung von der DENIC steht das übrigens auch nochmal erklärt: https://blog.denic.de/technische-storung-bei-de-domains-behoben/
"Sofern bei der Namensauflösung ein validierender DNS-Resolver zum Einsatz kam, wurden die DNS Antworten für sämtliche de.-Domains als fehlerhaft verworfen. Manche Resolverbetreiber haben als Überbrückungsmaßnahme die DNSSEC- Validierung für .de-Domains ausgesetzt."
 
Zuletzt bearbeitet:
incurable schrieb:
Herzlichen Glückwunsch,
Dankeschön. 🎉🏆🫶
Wenn Du mir nun erklärst weshalb, denn der Rest deines Posts erschließt sich mir nicht. :D
 
  • Gefällt mir
Reaktionen: nipponpasi
@knoxxi

Ich halte es für extrem problematisch, dieses Bild außerhalb seines historischen Kontexts zu verwenden.

Es als Meme-Aufhänger für einen saloppen Spruch herzunehmen, wie Du es hier hast, ist für mich schlicht widerlich.
 
incurable schrieb:
Ich halte es für extrem problematisch
Ist ok für mich, wenn Du das so siehst. Sei dir unbenommen.

Wenn Du es für problematisch hältst, ist es dein gutes Recht es seitens der Moderation überprüfen zu lassen.

Ich denke viele können es im Kontext einordnen wie es gemeint ist und was damit ausgedrückt werden soll.

Nichts liegt mir ferner als 9/11 zu verunglimpfen.
 
  • Gefällt mir
Reaktionen: the_IT_Guy und nipponpasi
Weyoun schrieb:
Kann man als Hosting-Kunde dauerhafte IP-Adressen erwerben (also auf Lebenszeit)?
Was meinst Du mit „auf Lebenszeit“ genau? Wenn ich bei einem üblichen Hoster z.B. einen vServer miete, dann bekomme ich in der Regel eine fest zugeordnete IPv4 aus dem Adressraum des Hosters für die Dauer meines Vertrages.

Bei Hyperscalern wie Amazon gibt es kostenlos in der Regel nur dynamische Adressen, eine feste kostet eine monatliche Gebühr. Das hängt damit zusammen, dass man dort VMs in der Regel nur in ein nicht öffentliches VNET stellt, und den ggf. notwendigen öffentlichen Zugriff über eigene Dienste (Revers Proxy, etc.) löst.

Um „eigene“ IPv4 und IPv6 Blöcke zu erwerben und zu nutzen, braucht man ein eigenes Autonomes System und muss sich selber darum kümmern, wie dieses ins Internet gerouted wird. Übliche Hoster bieten nicht die Möglichkeit, dass der Kunde sein eigenes AS mitbringt und über ihre Infrastruktur routet.

Sowas muss man entweder im eigenen Rechenzentrum betreiben oder sich irgendwo per Colocation einmieten. Es gibt sicher auch irgendwelche „managed RZ“ Angebote, mit denen man den gesamten Betrieb einer solchen Infrastruktur outsourcen kann. Aber nur zum Zweck einer „lebenslangen“ IP Adresse wird das niemand machen.
 
Sun_set_1 schrieb:
Router kann ich ausschließen da wie gesagt DoT aktiviert war, da kann der nichts cachen.
wieso sollte er nichts cachn wenn der DoT nutzt natürlich wird weiterhin gecacht.

ich nutze ein Glinet Brume 3 bei mir mit Adguard und dort sind 4 dns upstreams hinterlegt mit tls, keiner ging gestern hatte mir schon die haare ausgerupft woran es liegen könnte.
 
Zurück
Oben