u/lordgurke

Moin,

ich sitze in der Technik eines kleineren Telefonieanbieters für Glasfaser/Festnetz.

Wenn Kunden über uns die 112 wählen, übermitteln wir natürlich die Standortdaten des Anschlusses (Straße, Hausnummer, PLZ ...) zusammen mit dem Anruf.

Das funktioniert seit Jahren problemlos, bzw. gingen wir davon aus, weil bei Tests immer alles gepasst hat.

Gestern hatte ich eine Unterhaltung mit einer Feuerwehrleitstelle in Niedersachsen die ein Problem damit hatte, wie wir den Straßennamen übermitteln — in sehr bestimmten Konstellationen nämlich mit transliterierten Umlauten, also "ae" statt "ä".

Das ist laut technischer Spezifikation explizit so erlaubt, aber diese Leitstelle stand jetzt vor dem Problem, dass deren System zwar eine "Bärenstr.", aber keine "Baerenstr." kannte und der Anrufer so nicht automatisch einem Kartenpunkt zugeordnet werden konnte.

Das Problem mit den transliterierten Umlauten wird bei uns absehbar verschwinden (obwohl es, ich wiederhole mich, laut Spezifikation kein Fehler ist), aber ich frage mich jetzt, ob das ein generelles, weit verbreitetes Problem ist, welches einfach nur bisher nicht an uns herangetragen wurde.

Bei dem alten Standort-Kram über ISDN-Technik gab es auch keine Umlaute, deshalb wundert es mich dass die Software der Leitstelle jetzt plötzlich daran zerschellt.

Ist das für euch in der Leitstelle tatsächlich problematisch, wenn die Umlaute in Straßennamen ersetzt sind oder ist das eher ein isoliertes Problem dieser einen Leitstelle in Niedersachsen?

Update 06.05., 01:43 Uhr CEST – Entstörungsmeldung

Es kommt gerade eine offizielle Entstörungs-Meldung der DENIC über die Mailingliste:

> DENIC informiert über die Behebung der DNSSEC Störung für .de-Domains > > Frankfurt am Main, 6. Mai 2026 – Die DENIC eG hatte eine Störung im DNS für .de-Domains. > > Infolgedessen kam es zeitweise zu Einschränkungen bei der > Erreichbarkeit insbesondere von DNSSEC-signierten .de-Domains. Die Störung ist inzwischen behoben und alle Systeme laufen wieder stabil. > Die genaue Ursache wird derzeit noch analysiert. Sobald belastbare Erkenntnisse vorliegen, wird DENIC diese transparent zur Verfügung stellen. > > DENIC dankt allen Betroffenen für ihr Verständnis. > > Für Rückfragen steht die DENIC über die bekannten Kontaktwege zur Verfügung.

---

Update 06.05., 00:20 Uhr CEST

Ich sehe auf unseren DNS-Recursorn, dass einige .de-Nameserver mittlerweile gültige/valide Antworten liefern. Einige antworten aber noch mit defekten Signaturen, so dass aktuell die Auflösbarkeit ein wenig Glückssache ist.

---

Update 05.05., 23:24 Uhr CEST

Die DENIC teilt über ihre Tech-Mailingliste mit:

> Frankfurt am Main, 5.5.2026 – Die DENIC eG verzeichnet derzeit eine Störung im DNS-Service für .de-Domains. > Infolge dessen kommt es zu einer Störung bei der Erreichbarkeit aller DNSSEC-signerter .de-Domains. > Die Ursache der Störung ist derzeit noch nicht abschließend geklärt. > Die technischen Teams der DENIC arbeiten mit Hochdruck an der Analyse und an der schnellen Wiederherstellung eines stabilen Betriebs. > Nach aktuellem Stand können Nutzer und Betreiber von .de-Domains von Beeinträchtigungen bei der Domainauflösung betroffen sein. > Weitere Informationen werden bereitgestellt, sobald belastbare Erkenntnisse zur Ursache und Wiederherstellung vorliegen. > Die DENIC bittet alle Betroffenen um Verständnis. > Für Rückfragen steht die DENIC über die bekannten Kontaktwege zur Verfügung.

---

Originaler Post vom 05.05., 21:59 Uhr CEST:

Aktuell löst die gesamte .de-Zone und damit alle Domains unterhalb von .de nicht mehr auf.

Ursache ist augenscheinlich irgendein DNSSEC-"Fuckup" bei der DENIC – die liefern aktuell ungültige bzw. nicht standardkonforme DNSSEC-Signaturen aus, was dann zu Validierungs-Fehlern und dies letztlich zu Problemen bei der DNS-Auflösung führt.

Beispiel:

$ dig @8.8.8.8 "de."

; <<>> DiG 9.20.22 <<>> @8.8.8.8 de.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 20681
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
; EDE: 6 (DNSSEC Bogus): (RRSIG with malformed signature found for de/soa (keytag=33834))
;; QUESTION SECTION:
;de.                            IN      A

;; Query time: 8 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Tue May 05 21:56:19 CEST 2026
;; MSG SIZE  rcvd: 99

Bzw. ausführlicher:

$ delv +ns de.
[gekürzte Ausgabe]

;; received packet from 195.243.137.26#53
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:  12434
;; flags: qr aa; QUESTION: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1452
;; QUESTION SECTION:
;de.                            IN      A

;; AUTHORITY SECTION:
;de.                    7200    IN      SOA     f.nic.de. dns-operations.denic.de. (
;                                               1778011046 ; serial
;                                               7200       ; refresh (2 hours)
;                                               7200       ; retry (2 hours)
;                                               3600000    ; expire (5 weeks 6 days 16 hours)
;                                               7200       ; minimum (2 hours)
;                                               )
;de.                    7200    IN      RRSIG   SOA 8 1 86400 (
;                                               20260519195728 20260505182728 33834 de.
;                                               fZeJzo+L0goapprXUMpvN4DAlYPm
;                                               i7+4w66M2GQQs6om004MuW6h8xx4
;                                               lX552MGeAUpM8kqBkFD0EZxCJpoG
;                                               4KTAvn7RI+YWwQl1hOWp/H9UYC/7
;                                               M5JC0obqKBrHnHQEpLlBwvWWiSGd
;                                               Ox1phRVM4lVuyx5jquh0BfqSsTQn
;                                               k/8= )
;a0d5d1p51kijsevll74k523htmq406bk.de. 7200 IN NSEC3 1 1 0 - (
;                                               A0D5F6VETKD4HE1UG3NJGF20U4QMCIAQ
;                                               NS SOA RRSIG DNSKEY NSEC3PARAM )
;a0d5d1p51kijsevll74k523htmq406bk.de. 7200 IN RRSIG NSEC3 8 2 7200 (
;                                               20260519191938 20260505174938 33834 de.
;                                               DZhBfHZt+n/IFEdUgogT4Npxzdkz
;                                               LjUMslehShbTAbH6n4qaRnMH9zGu
;                                               gRutdlxWrtEywgA6XEpU+vsE2wBk
;                                               S3BWXA1D1BWoLqmxETwqZSmXnJ30
;                                               IM16mtRwp9nxbWOMWAr/KfTiyoa+
;                                               xPivpFl6Rg8jSzX3HIGGlLHAFVgZ
;                                               KaY= )


;; insecurity proof failed resolving 'de/A/IN': 195.243.137.26#53
;; response code: SERVFAIL

Ich habe gerade eine Mail bekommen, dass mein S/MIME-Zertifikat am 08. Mai (Freitag) widerrufen wird – sehr wahrscheinlich aus den selben Gründen, wie bei der vorherigen Aktion.

Text von der D-Trust-Webseite:

>WICHTIGE INFORMATION zu S/MIME-Zertifikaten (Personenzertifikate)

>Das Wichtigste vorab: die bestehenden Zertifikate waren und sind zu keiner Zeit in ihrer Sicherheit oder Integrität beeinträchtigt. 

>In Folge des TLS-Austauschs Mitte April haben wir in einem strukturierten Prozess auch die Prozesse zum Ausstellungsverfahren unserer S/MIME Zertifikate überprüft. Hierbei ist festgestellt worden, dass gemäß Baseline Requirements in einzelnen CAs der Linting-Prozess nicht ausreichend implementiert worden war. 

>Die Anpassung erfolgt am Montag, den 4. Mai 2026. Vor diesem Hintergrund tauschen wir die folgenden S/MIME Zertifikate aus: „Advanced Personal eID“, „Advanced Enterprise (inkl. SIG/ENC) ID“ sowie die „Advanced Team ID“. Diese Zertifikatstypen können entsprechend nicht mehr bezogen werden. 

>Wichtig für Sie: Da die oben genannten S/MIME Zertifikate ab Freitag, den 08. Mai 2026, 15:00 Uhr, ihre Gültigkeit verlieren, bitten wir Sie, rechtzeitig ein neues Zertifikat zu beantragen. Der Austausch des neuen S/MIME-Zertifikates erfolgt kostenfrei. Wir empfehlen Ihnen, die betroffenen Zertifikate auch nach dem Tausch aufzubewahren. So stellen Sie sicher, dass bereits auch zuvor empfangene E-Mails weiterhin entschlüsselt werden können.