Monday Morning In German Practices And Pharmacies
Since Monday 12 October, many doctors' practices, pharmacies and clinics in Germany have had trouble reaching the Telematikinfrastruktur, the national health network, and Gematik reports disruption for providers whose connectors come from Secunet or RISE. The services that fail or work only in part are the insured-person data check (VSDM), secure messaging (KIM), e-prescriptions, the electronic patient record and electronic sick notes.
Connectors from CGM are not affected, Gematik says, because CGM does not use the feature in question. The cause is the scheduled change of the DNS root key.
Gematik expects every Secunet and RISE connector in the field to be affected during the week unless it gets a fix, and sites without their own connector can be hit if they connect through a data-centre connector. Gematik cannot yet say how many connectors are affected.
A Calendar That Was Public For 21 Months
The key change sat on the public calendar for 21 months, and the first working day after it still brought an outage.
| Date | Event |
|---|---|
| 11 January 2025 | New root key KSK-2024 (key tag 38696) is published in the root DNSKEY set |
| 11 August 2026 | ICANN publishes guidance on what to expect during the rollover |
| 6 October 2026 | Cloudflare warns that validating resolvers must trust the new key |
| 11 October 2026 | KSK-2024 starts signing the root DNSKEY set and KSK-2017 (key tag 20326) stops |
| 12 October 2026 | Gematik reports disruption for Secunet and RISE connectors |
| 13 October 2026 | heise updates its report with Gematik's responses |
ICANN's guidance asked operators of DNSSEC-validating resolvers, DNS software vendors and anyone with manually configured trust anchors to confirm their systems were ready before 11 October. Cloudflare added that a validating resolver which does not trust the new key can make healthy websites unreachable, and that the root had changed its key-signing key only once before.
Why Existing Tunnels Survived And New Ones Fail
The affected connectors apparently lack the new internet root trust anchor, so they cannot resolve the addresses of the VPN access services run by Arvato and T-Systems and cannot build a new tunnel to the health network.
Tunnels that are already up need no new name lookups, so they keep working. The root DNSKEY records also stay in caches for 48 hours, which hides the fault until a restart or reconnect finds an empty or expired cache. That is why heise reports that affected operators should not restart their connectors.
Gematik describes a workaround that the on-site service provider must apply by hand, and its guide for Secunet connectors recommends adding the new trust anchor even to connectors that still work. For RISE there is no separate guide yet, and RISE announced firmware 6.2.3 with what it called an important correction from 8 October, though it is unknown whether that fixes this fault. Why the connectors did not take over the new key is still unclear: the specification requires automatic RFC 5011 updates for the health network's own anchor, but it is not clear that the internet anchor gets them.
The May 2020 Precedent
In late May 2020 about 80,000 of roughly 130,000 connected practices and clinics could not reach some health network services, and the affected connectors came from T-Systems, RISE and Secunet.
Gematik first blamed a faulty entry in its trust service status list. The magazine c't later linked the outage to a new DNSSEC root trust anchor set in May 2020 combined with an administration error. In mid-June 2020 the master-data sync was still disrupted at more than 40,000 practices, and recovery needed on-site updates by service providers because remote maintenance was often not approved.
What To Ask Your Vendors Before The Next Root Change
Start with every device that builds VPN tunnels or validates DNS on its own, such as gateways, medical connectors and embedded appliances. Ask each vendor to confirm in writing how its trust anchor updates, by RFC 5011 or by hand, and whether it already holds KSK-2024.
Test a restart or reconnect in a maintenance window only after that confirmation, and keep the vendor's manual workaround ready. Cloudflare offers a readiness test based on RFC 8509 for the resolver your browser uses, and it says most website operators need no action.
Put root key changes and certificate expiries on the same change calendar as software releases. This outage had a date, a public key and a published guide, and the fault only showed once the date had passed.
Read next: Yandex Cloud Advised Customers to Host Elsewhere | Three Windows Support Deadlines Land Within 30 Days
