Sicherheit im DNS stirbt selten am grossen theoretischen Bruch. Sie stirbt an kleinen Bequemlichkeiten. Ein offener Primary. Ein Zonentransfer im Klartext. Eine TSIG-Konfiguration, die Integrität liefert, aber Vertraulichkeit nicht einmal verspricht. Ein Zertifikat, das abläuft, weil das Monitoring versagt. Wer autoritative Nameserver betreibt und sich mit der üblichen Minimalhärtung zufriedengibt, bewegt sich nicht in einem Katastrophenszenario. Er bewegt sich bloss in einem Raum stillschweigender Annahmen. Genau dort habe ich meine Centurion-Nameserverinfrastruktur noch einmal konsequent nachgeschärft.
Der Ausgangspunkt war bereits alles andere als fahrlässig. Die Zonen liegen bei mir seit über einer Dekade nicht auf öffentlich schreibbaren Primaries, sondern auf meinem eigenen Hidden Master. Die Antworten kommen über vier Slaves aus zwei autonomen Systemen, über zwei TLD-Räume und über mehrere geographisch getrennte Standorte. Der Zugriff auf die Managementebene läuft nur über Jump-Server. SSH ist gehärtet. Die Hosts sind allgemein sauber verriegelt. DNSSEC ist gesetzt. Zonentransfers und NOTIFY waren per ACL und TSIG abgesichert. Wer so baut, hat die gröbsten Fehler der Branche bereits hinter sich gelassen. Wer so baut, hat aber noch nicht das Ende der Fahnenstange erreicht.
Der nächste Schritt war bei mir schon seit einiger Zeit umgesetzt, ohne dass er nach aussen gross sichtbar wurde. AXFR und IXFR liefen nicht mehr im klassischen Klartext, sondern bereits über TLS. Der Transport war also geschützt, der Hidden Master wurde serverseitig geprüft, und TSIG blieb für die DNS-seitige Authentisierung daneben bestehen. BIND selbst ordnet genau diese Kombination als praktikabel ein: Strict TLS mit TSIG und optionalen IP-basierten ACLs ist laut Dokumentation für viele reale Umgebungen völlig akzeptabel, während mTLS als eigenständige Lösung gilt und den Vorteil hat, die Abhängigkeit von geteilten symmetrischen Secrets zu verringern.1
Genau an dieser Stelle begann für mich die interessante Frage. Nicht ob one way TLS stark ist. Das ist es. Sondern ob der Schritt zu mTLS in meinem Threatmodell noch rational ist oder bloss kryptographischer Zierrat. Die Antwort ist nicht allgemein, sondern abhängig vom Schutzobjekt, vom Netzmodell und davon, wie ernst man die eigenen Annahmen nimmt.
Zunächst zur Begriffsklärung, weil in DNS-Diskussionen erstaunlich oft Schlagworte herumgereicht werden, als wären sie selbsterklärend. TSIG ist die transaktionsbezogene Authentisierung von DNS-Nachrichten mittels gemeinsamer Geheimnisse und Hashverfahren. Der Standard ist heute RFC 8945. TSIG authentisiert einzelne DNS-Transaktionen, etwa NOTIFY, Dynamic Updates oder Zonentransfers. TSIG liefert Integrität und Authentizität auf Nachrichtenebene. TSIG liefert ausdrücklich keine Vertraulichkeit.2 DNSSEC ist etwas anderes. DNSSEC signiert Zonendaten, nicht Transportkanäle. Es geht um Datenursprungsauthentisierung, Integrität und gesicherte Nicht-Existenz, also um RRSIG, DNSKEY, DS, NSEC und verwandte Mechanismen. Die Grunddokumente bleiben RFC 4033, 4034 und 4035.3 4 5 NOTIFY ist nochmals etwas anderes. RFC 1996 definiert es als Anstoss des Primary an den Secondary, die SOA erneut zu prüfen und nötigenfalls einen Transfer zu ziehen. NOTIFY transportiert also nicht die Zone, sondern den Hinweis auf einen möglichen neuen Stand.6 IXFR ist der inkrementelle Zonentransfer nach RFC 1995, AXFR der vollständige Zonentransfer nach RFC 5936.7 8 Und XFR over TLS, also XoT, ist seit RFC 9103 standardisiert. Der Grund für dieses RFC ist simpel: Zonentransfers laufen klassisch im Klartext, und TSIG verhindert zwar unbefugte Transfers, beseitigt aber nicht das passive Mitschneiden des Zoneninhalts auf dem Transportweg.9
Genau dort verläuft die erste echte Trennlinie zwischen mehreren Bedrohungsbildern. Wer nur verhindern will, dass irgendein beliebiger Host einen AXFR abruft, erreicht mit ACLs und TSIG bereits sehr viel. Wer verhindern will, dass jemand den Inhalt des Transfers auf der Leitung mitliest, braucht Transportverschlüsselung. Wer verhindern will, dass die Gegenseite auf TLS-Ebene bloss wegen Erreichbarkeit und irgendeines Zertifikats als vertrauenswürdig gilt, landet bei Strict TLS. Wer zusätzlich sicherstellen will, dass nicht nur der Hidden Master, sondern auch jeder Secondary gegenüber dem Hidden Master selbst eine durch die eigene PKI gebundene Identität vorweisen muss, landet bei mTLS. Die Schutzstufen bauen also nicht auf derselben Achse auf. Sie adressieren unterschiedliche Fehlerklassen.
In meiner Infrastruktur ist der Hidden Master auf Netzwerkebene ohnehin eng eingeschlossen. Die Verbindungen zwischen Hidden Master und Slaves laufen über definierte ACLs. Der Hidden Master selbst ist nicht frei aus dem Internet ansprechbar. Das ist ein massiv unterschätzter Punkt, weil er die Angriffsfläche der Schreibseite des autoritativen DNS sofort verkleinert. Ein öffentlich sichtbarer Primary mag bequem sein. Er erhöht aber den Druck auf den sensibelsten Knoten. Ein Hidden Master verschiebt die Autorität an eine Stelle, die nicht delegiert und nicht öffentlich abgefragt wird. Hetzner dokumentiert für Secondary-DNS ausdrücklich auch ein solches Hidden Primary-Modell. Das ist nicht exotisch, sondern solides Betriebshandwerk.10
Mit diesem Modell im Rücken war die frühere Ausbaustufe meines Setups bereits schlüssig: Hidden Master, vier Slaves, DNSSEC, TSIG, ACLs, Hardening, one way TLS für AXFR und IXFR. BIND war hier eindeutig. TLS-Verbindungen zu Primaries sind nur dann wirklich authentisiert, wenn remote-hostname und oder ca-file im verwendeten tls-Block gesetzt sind. Ohne diese Angaben bleibt man bei opportunistischem TLS. Das schützt vor passiven Beobachtern, aber nicht vor einem aktiven On-Path-Angriff.11 RFC 9103 sagt exakt dasselbe auf Protokollebene. Wer also XFR über TLS fährt, aber die Gegenseite nicht sauber prüft, hat zwar Vertraulichkeit gegen das einfache Mitlesen gewonnen, aber die Vertrauensfrage nicht wirklich beendet.
Der Schritt von one way TLS zu mTLS adressiert nun ein schärferes Modell. mTLS ist nicht die Antwort auf alles. mTLS beantwortet die Frage, ob ich dem Secondary als Client gegenüber dem Hidden Master eine eigene, an meine CA gebundene Identität abverlange, statt mich nur auf ein Shared Secret und eine IP-Freigabe zu verlassen. Der praktische Zugewinn liegt also dort, wo ich das Risiko symmetrischer Secrets reduzieren, Rollen sauberen Zertifikatsidentitäten zuordnen und den Zugriff an eine eigene PKI binden will. BIND formuliert den Vorteil von mTLS genau in dieser Richtung: Mutual TLS kann als eigenständige Lösung für XFR-Authentisierung gelten und vermeidet die Sicherheitsnachteile geteilter Secrets. Ich habe TSIG trotzdem nicht entfernt. Nicht, weil mTLS zu schwach wäre, sondern weil in einer realen Migrationsphase zusätzliche Authentisierung auf DNS-Nachrichtenebene kein Nachteil ist, solange man die Komplexität noch im Griff hat.
Das klingt abstrakt, bis man es operativ erlebt. Bei mir war der eigentliche Stolperer am Ende nicht Kryptographie, sondern Zertifikats-Lifecycle. Ein abgelaufenes Hidden-Master-Zertifikat genügte, um die Slave-Zonen stillzulegen. BIND meldete auf dem Secondary sauber: TLS peer certificate verification failed. Genau das war der Punkt, an dem aus Theorie wieder Betrieb wurde. Der Fall war lehrreich, weil er einen alten Unterschied sichtbar macht. TSIG-Fehler und TLS-Fehler sind nicht dasselbe. TSIG kann vollständig korrekt sein, und die Transfers scheitern trotzdem, weil die Gegenstellenprüfung auf TLS-Ebene greift. Das ist kein Mangel des Systems. Es ist das System. Wer XoT mit echter Gegenstellenprüfung fährt, muss Zertifikate wie Produktionskomponenten behandeln, nicht wie Beilagen.
Damit kommt man fast zwangsläufig zu einer zweiten Einsicht, die viele noch verdrängen. Die öffentliche WebPKI zieht sich aus clientAuth zurück. Let’s Encrypt hat die Client-Authentication-EKU 2026 aus dem Standardprofil entfernt und das Übergangsprofil tlsclient nur noch befristet für bestehende Nutzer offengelassen. DigiCert beschreibt denselben Trend für öffentliche TLS-Zertifikate mit einem gestreckten Zeitplan bis 2027.12 13 Wer mTLS zwischen autoritativen Nameservern ernsthaft und dauerhaft betreiben will, landet also vernünftigerweise bei einer internen PKI. Alles andere ist Provisorium. Genau das habe ich im Thread testweise nachvollzogen. Für einen Ad-hoc-Test lässt sich die Sache mit öffentlichen Zertifikaten noch biegen. Für ein stabiles Architekturziel taugt das nicht. Die Konsequenz ist einfach: Für serverAuth und clientAuth auf der Autoritätsstrecke gehört die Zertifikatslogik in eine eigene, interne CA.
Ein Missverständnis habe ich im Zuge dessen ebenfalls gezielt ausgeräumt. Wer NOTIFY over TLS denkt, landet gedanklich sehr schnell bei einem Zertifikatspaar pro Rolle und Host und sieht plötzlich ein Monsterprojekt. Das ist unnötig. Ein Host, der sowohl als TLS-Server als auch als TLS-Client auftritt, kann mit einem einzigen Dual-Use-Zertifikat betrieben werden, solange die EKUs und die eigene CA-Policy dazu passen. BINDs tls-Blöcke erzwingen keine getrennten Server- und Client-Zertifikate pro Host. Getrennte Schlüssel sind ein legitimer Härtungsschritt. Zwingend sind sie nicht.14 Die wichtigere Frage ist ohnehin, ob NOTIFY over TLS im gegebenen Threatmodell überhaupt einen nennenswerten Mehrwert bietet.
Meine Antwort darauf fällt reserviert aus. NOTIFY nach RFC 1996 ist der Hinweis zur SOA-Prüfung, nicht der eigentliche Transport des Zoneninhalts.15 Der Geheimnisträger ist der Zonentransfer. Dort liegt also auch der Gewinn von TLS. Wer NOTIFY klassisch auf Port 53 belässt, es per TSIG signiert und XFR dann ausschliesslich über TLS abwickelt, trifft für viele hochgehärtete Eigenumgebungen eine vernünftige Entscheidung. Ich habe mich genau dafür entschieden. Das spart Zertifikatsrollen, spart Fehlermodi und verschwendet die Komplexität nicht an einen Mechanismus, dessen Sicherheitshebel viel kleiner ist als beim XFR selbst. Diese Entscheidung ist keine Kapitulation vor der Reinheitslehre, sondern eine nüchterne Priorisierung.
Daraus ergibt sich für mein Setup 2026 eine Abfolge, die ich für belastbar halte. Der Hidden Master bleibt Hidden Master. Die Slaves bleiben auf vier autoritative Knoten in zwei autonomen Systemen und zwei TLD-Räumen verteilt. Die Netzwerkpfade zwischen Hidden Master und Slaves bleiben zusätzlich per ACL limitiert. NOTIFY bleibt klassisch auf Port 53 und wird mit TSIG signiert. AXFR und IXFR laufen ausschliesslich über TLS. Für den XFR-Pfad verlange ich vom Hidden Master per ca-file auf dem TLS-Listener gültige Client-Zertifikate der Slaves, also mTLS. TSIG bleibt daneben bestehen. Der Effekt ist klar verteilt: Die DNS-Nachricht ist weiter symmetrisch signiert, der Transport ist verschlüsselt, der Hidden Master bindet die Gegenstelle zusätzlich an eine eigene Zertifikatsidentität.
Wer wissen will, wo so ein Aufbau im Jahr 2026 im Verhältnis zu bekannten Providern steht, muss zwischen öffentlicher Dokumentation und möglicher interner Praxis unterscheiden. Cloudflare dokumentiert Secondary DNS und Zone Transfers weiterhin im klassischen Vokabular: AXFR und IXFR, Peer Server, Port 53, ACLs, NOTIFY, TSIG optional, aber ausdrücklich empfohlen.16 17 Das ist ordentlich, aber es ist öffentlich dokumentiert nicht dasselbe wie ein mTLS-zentriertes XFR-Modell. Hetzner dokumentiert Secondary-Zonen für selbstverwaltete Nameserver ebenfalls entlang von NOTIFY sowie AXFR und IXFR, inklusive Hidden Primary-Beispiel, und bleibt in den öffentlich sichtbaren Howtos ebenfalls beim klassischen Modell, nicht bei XFR over TLS oder mTLS.18 Netcup dokumentiert für Domains vor allem Delegation auf eigene Nameserver, Redundanz, Glue und optionale DNSSEC-Aktivierung. Eine öffentlich dokumentierte Managed-Secondary- oder XFR-over-TLS-Praxis in derselben Tiefe wie bei Cloudflare oder Hetzner ist dort nach meinem Stand nicht sichtbar.19
Man sollte aus dieser Gegenüberstellung weder Überheblichkeit noch falsche Bescheidenheit ableiten. Ich betreibe kein globales Anycast-Netz wie Cloudflare. Ich betreibe auch keinen Managed-DNS-Service mit der Reichweite eines Hyperscalers. Die Vergleichsfrage läuft also nicht auf Fläche, DDoS-Kapazität oder Kundenprodukt hinaus. Sie läuft auf die Autoritätsstrecke und die Trust-Boundaries hinaus. In genau diesem engeren Sinn steht die Centurion-Infrastruktur über dem, was die grossen Anbieter in ihrer öffentlichen Dokumentation als Standardmodell beschreiben. Hidden Master, keine öffentliche Schreibseite, eigene Pfad-ACLs, DNSSEC, TSIG, Hardening und nun mTLS auf der XFR-Strecke sind keine Standardkost mehr. Sie sind ein bewusstes Härtungskonzept.
Best Practice 2026 ist damit kein monolithischer Satz, sondern ein abgestuftes Urteil. Wer Managed DNS konsumiert und den Betrieb nicht selbst kontrolliert, wird mit klassischem Secondary DNS, TSIG und sauber gepflegten ACLs oft gut leben. Wer eine eigene autoritative Infrastruktur mit hohem Anspruch an Isolierung und Vertraulichkeit betreibt, sollte Hidden Master, DNSSEC, TSIG und XFR over TLS als Baseline sehen. Wer die Vertrauensfrage auf der Clientseite des Transfers ebenfalls an die eigene PKI binden will, landet folgerichtig bei mTLS für XFR. Ich würde das heute nicht als exotische Spielerei abtun. Ich würde es auch nicht als zwingende Pflicht für jeden ausrufen. Es ist die logische nächste Stufe, sobald man die Autoritätsstrecke als eigene Hochsicherheitsdomäne versteht.
Der interessante Punkt liegt an anderer Stelle. Die Szene redet gern über DNSSEC, als sei mit Signaturen schon alles Wesentliche getan. Das ist zu kurz. DNSSEC schützt die publizierten Daten gegen Fälschung auf dem Weg zum Resolver. DNSSEC verschlüsselt keinen Zonentransfer. DNSSEC authentisiert keinen Secondary gegenüber dem Primary. DNSSEC ersetzt auch keinen sauberen Hidden-Master-Entwurf. Wer das verwechselt, baut aneinander vorbei. Die drei Ebenen sind verschieden. DNSSEC schützt Datensätze. TSIG schützt DNS-Transaktionen. TLS schützt den Transport. mTLS bindet die Transportendpunkte zusätzlich an Zertifikatsidentitäten. Gute Architektur besteht darin, diese Ebenen nicht zu vermengen und auch nicht künstlich gegeneinander auszuspielen.
Ein zweiter Denkfehler sitzt in der Gewöhnung an Klartext. Klassischer AXFR oder IXFR mit TSIG ist vielen Administratoren lange genug vertraut, dass die fehlende Vertraulichkeit fast unsichtbar geworden ist. RFC 9103 hat gerade dieses blinde Feld adressiert. Der Zoneninhalt ist auf der Leitung ein lohnendes Objekt. Wer an der richtigen Stelle mitliest, bekommt den vollständigen Zustand der Zone, samt Struktur, interner Namen, Subdomains, Mailtopologie und allem, was organisatorisch und sicherheitlich über Jahre zusammengesammelt wurde. Ich habe dieses Problem nicht deshalb ernst genommen, weil es modern klingt, sondern weil autoritatives DNS in der Realität einen hervorragenden Lageplan der eigenen Infrastruktur darstellt.
An genau diesem Punkt schliesst sich auch der Bogen zu meinen älteren Überlegungen über Systemhärtung. Ich habe nie viel davon gehalten, Sicherheit als Produkt einzelner heroischer Features zu begreifen. Sicherheit entsteht an den Kanten. An den Übergängen zwischen öffentlicher und nicht öffentlicher Autorität. Zwischen Datenintegrität und Transportschutz. Zwischen Hostidentität und geteiltem Secret. Zwischen sauberem Betrieb und blosser Konfigurationsästhetik. Mein Nameserver-Stack war schon vorher sicher. Der Schritt zu mTLS auf der XFR-Strecke ändert nicht die Welt. Er schliesst aber einen Pfad, der bislang noch auf weniger harten Annahmen stand als der Rest der Umgebung.
Die nüchterne Quintessenz lautet also so: Wer 2026 eigene autoritative DNS-Infrastruktur auf ernstem Niveau betreibt, sollte Hidden Master, DNSSEC, TSIG und Transportverschlüsselung nicht mehr als voneinander unabhängige Optionen betrachten. Sie gehören auf unterschiedliche Ebenen derselben Verteidigungslinie. Wer dann noch den Secondary selbst an eine interne PKI binden will, wählt mTLS für XFR. Wer dabei auf klassisches, TSIG-signiertes NOTIFY auf Port 53 setzt, handelt nicht rückständig, sondern vernünftig. Der Sicherheitshebel sitzt beim Zonentransfer, nicht beim Signal zur SOA-Prüfung. Komplexität ist nur dort gerechtfertigt, wo sie einen klar benennbaren Angriffspfad schliesst.
Die anonymisierten Konfigurationsbeispiele unten orientieren sich an BIND 9.20, wie es in Debian 13 mit bind9 1:9.20.18-1~deb13u1 ausgerollt wurde. Die verwendeten Konstrukte, also listen-on ... tls, allow-transfer ... transport tls, tls-Blöcke mit ca-file, remote-hostname, cert-file und key-file, sind in der BIND-Referenz dokumentiert.
Bind9-Snippets
Der Hidden Master braucht für das hier beschriebene Modell einen TLS-Listener auf dem XFR-Port, der sein Serverzertifikat präsentiert und über ca-file die Client-Zertifikate der Slaves prüft. allow-transfer wird auf Port und Transport eingegrenzt. NOTIFY bleibt klassisch auf Port 53 und wird über TSIG signiert.
tls "xfr-in-mtls" {
cert-file "/etc/bind/pki/primary/fullchain.pem";
key-file "/etc/bind/pki/primary/privkey.pem";
ca-file "/etc/bind/pki/ca/xfr-clients-ca.pem";
protocols { TLSv1.3; };
session-tickets no;
};
options {
listen-on { 127.0.0.1; 10.0.0.10; };
listen-on-v6 { ::1; 2001:db8:100::10; };
listen-on port 8853 tls "xfr-in-mtls" { 10.0.0.10; };
listen-on-v6 port 8853 tls "xfr-in-mtls" { 2001:db8:100::10; };
notify explicit;
allow-transfer port 8853 transport tls {
key "secondary-a";
key "secondary-b";
key "secondary-c";
key "secondary-d";
};
also-notify {
198.51.100.11 key "secondary-a";
198.51.100.12 key "secondary-b";
203.0.113.21 key "secondary-c";
203.0.113.22 key "secondary-d";
};
};
key "secondary-a" {
algorithm hmac-sha512;
secret "BASE64_SECRET";
};
server 198.51.100.11 {
keys { "secondary-a"; };
}
...Auf dem Secondary genügt für genau dieses Design ein ausgehender TLS-Client-Block zum Hidden Master. Ein eigener TLS-Listener ist nicht nötig, solange NOTIFY klassisch bleibt und der Secondary den Zonentransfer selbst zum Hidden Master zieht.
tls "to-primary" {
remote-hostname "primary.example.net";
ca-file "/etc/bind/pki/ca/xfr-servers-ca.pem";
cert-file "/etc/bind/pki/ns01/fullchain.pem";
key-file "/etc/bind/pki/ns01/privkey.pem";
protocols { TLSv1.3; };
session-tickets no;
};
key "primary-peer" {
algorithm hmac-sha512;
secret "BASE64_SECRET";
};
server 10.0.0.10 {
keys { "primary-peer"; };
};
zone "example.net" IN {
type secondary;
file "/var/cache/bind/slaves/example.net";
primaries {
10.0.0.10 port 8853 tls "to-primary" key "primary-peer";
};
allow-notify { 10.0.0.10; };
allow-transfer { none; };
};Wer one way TLS statt mTLS für XFR fahren will, entfernt auf dem Hidden Master im eingehenden TLS-Listener schlicht das ca-file. Genau dort sitzt in BIND die Client-Zertifikatsprüfung. Der Rest der Logik, also remote-hostname und ca-file auf dem Secondary für die Prüfung des Hidden Masters, bleibt bestehen.
Sicherheit in DNS endet nie in einem eleganten Schlusspunkt. Sie endet in der Bereitschaft, an jeder Grenze die richtige Frage zu stellen. Welches Objekt schütze ich hier eigentlich. Die Daten. Den Transport. Die Gegenstelle. Mein Nameserver-Stack ist heute nicht unverwundbar. Er ist bloss deutlich schlechter angreifbar als gestern. Für Infrastruktur genügt das als Fortschritt vollkommen.
Quellen
- ISC, „BIND 9 Configuration Reference“, BIND 9.20.x und aktuelle Referenzdokumentation, Abschnitte zu
tls,allow-transfer,also-notify, Strict TLS und Mutual TLS. https://bind9.readthedocs.io/en/v9.20.6/reference.html ↩︎ - H. Gudmundsson, P. Wouters, S. Kumar, M. StJohns, O. Sury, D. Eastlake 3rd, A. Gudmundsson, „RFC 8945: Secret Key Transaction Authentication for DNS (TSIG)“, IETF, November 2020, STD 93. https://www.rfc-editor.org/rfc/rfc8945.html ↩︎
- R. Arends et al., „RFC 4033: DNS Security Introduction and Requirements“, IETF, März 2005. https://datatracker.ietf.org/doc/html/rfc4033 ↩︎
- R. Arends et al., „RFC 4034: Resource Records for the DNS Security Extensions“, IETF, März 2005. https://datatracker.ietf.org/doc/html/rfc4034 ↩︎
- R. Arends et al., „RFC 4035: Protocol Modifications for the DNS Security Extensions“, IETF, März 2005. https://datatracker.ietf.org/doc/html/rfc4035 ↩︎
- P. Vixie, „RFC 1996: A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)“, IETF, August 1996. https://datatracker.ietf.org/doc/html/rfc1996 ↩︎
- M. Ohta, „RFC 1995: Incremental Zone Transfer in DNS“, IETF, August 1996. https://datatracker.ietf.org/doc/html/rfc1995 ↩︎
- E. Lewis, A. Hoenes, „RFC 5936: DNS Zone Transfer Protocol (AXFR)“, IETF, Juni 2010. https://datatracker.ietf.org/doc/html/rfc5936 ↩︎
- V. Toorop et al., „RFC 9103: DNS Zone Transfer over TLS“, IETF, August 2021. https://www.rfc-editor.org/rfc/rfc9103.html ↩︎
- Hetzner, „Configuring secondary zones for DNS software“, Dokumentation, Stand 6. Oktober 2025, einschliesslich Hidden Primary-Beispiel sowie NOTIFY- und AXFR/IXFR-Konfiguration für selbstverwaltete Nameserver. https://docs.hetzner.com/networking/dns/howto-secondary-zones/dns-software/ ↩︎
- Siehe Fn. 1. ↩︎
- Let’s Encrypt, „Profiles“ sowie „Upcoming Features“, Stand 2026, zur Ausphasung der
TLS Client Authentication-EKU und zum befristetentlsclient-Profil bis Juli 2026. https://letsencrypt.org/docs/profiles/ ↩︎ - DigiCert, „Removing the client authentication EKU from public TLS certificates“, Knowledge Base, 3. März 2026, zum Auslaufen von
clientAuthin öffentlichen TLS-Zertifikaten bis März 2027. https://knowledge.digicert.com/alerts/sunsetting-client-authentication-eku-from-digicert-public-tls-certificates ↩︎ - Siehe Fn. 1. ↩︎
- Siehe Fn. 6. ↩︎
- Cloudflare, „Set up incoming zone transfers (Cloudflare as Secondary)“, Entwicklerdokumentation, Stand 30. Oktober 2025, mit ACL-Hinweisen, AXFR/IXFR, TSIG optional aber empfohlen und NOTIFY-Empfehlung. https://developers.cloudflare.com/dns/zone-setups/zone-transfers/cloudflare-as-secondary/setup/ ↩︎
- Cloudflare, „Set up outgoing zone transfers (Cloudflare as Primary)“, Entwicklerdokumentation, Stand 23. Oktober 2025, mit Peer-Servern, Port 53, optionalem TSIG und NOTIFY für Secondary-Provider. https://developers.cloudflare.com/dns/zone-setups/zone-transfers/cloudflare-as-primary/setup/ ↩︎
- Hetzner, „Configuring secondary zones for DNS software“, Dokumentation, Stand 6. Oktober 2025, einschliesslich Hidden Primary-Beispiel sowie NOTIFY- und AXFR/IXFR-Konfiguration für selbstverwaltete Nameserver. https://docs.hetzner.com/networking/dns/howto-secondary-zones/dns-software/ ↩︎
- netcup, „Configuring DNS (Existing Domains)“ und „Setting Up Your Own Nameservers (Existing Domains)“, Dokumentation, Stand 3. März 2026, mit Fokus auf Delegation eigener Nameserver, Redundanz, Glue und DNSSEC, ohne öffentlich ausgeführtes Managed-Secondary-/XFR-over-TLS-Modell. https://www.netcup.com/en/helpcenter/documentation/domain/dns-settings ↩︎