Leitlinien und Empfehlungen für die sichere Nutzung
Zuletzt aktualisiert am
1. Einleitung
Abschnitt betitelt „1. Einleitung“Diese Dokumentation unterstützt Cloud-Kunden bei der sicheren Konfiguration und Nutzung des STACKIT DNS-Dienstes. STACKIT DNS ist ein Managed Service für das Hosting von öffentlichen DNS-Zonen. Während STACKIT die Sicherheit der Infrastruktur und der Nameserver gewährleistet, liegt die inhaltliche Verantwortung für die Zonen, Records und die Zugriffskontrolle im Verantwortungsbereich des Kunden.
2. Sichere Konfiguration von DNS-Zonen
Abschnitt betitelt „2. Sichere Konfiguration von DNS-Zonen“Die folgenden Konfigurationsempfehlungen dienen der Minimierung von Sicherheitsrisiken und der Sicherstellung der Verfügbarkeit.
Keine internen IP-Adressen im öffentlichen DNS
Abschnitt betitelt „Keine internen IP-Adressen im öffentlichen DNS“Empfehlung: Veröffentlichen Sie keine privaten IP-Adressen (z. B. 10.0.0.0/8, 192.168.0.0/16) in Ihren STACKIT DNS-Zonen.
Hintergrund: STACKIT DNS-Zonen sind öffentlich auflösbar. Interne IPs im öffentlichen DNS offenbaren Details über Ihre interne Netzwerktopologie (“Information Disclosure”). Dies erleichtert Angreifern die Orientierung, falls sie anderweitig Zugang zu Ihrem Netzwerk erlangen. Nutzen Sie für interne Auflösungen separate, interne DNS-Resolver.
Begrenzung von Round-Robin-Einträgen
Abschnitt betitelt „Begrenzung von Round-Robin-Einträgen“Empfehlung: Hinterlegen Sie für einen einzelnen Domainnamen (A/AAAA-Records) eine limitierte Anzahl an IP-Adressen (Richtwert: max. 8-10).
Hintergrund: Zu viele IP-Adressen in einer Antwort erhöhen die Größe des DNS-Pakets. Überschreitet die Antwort die Standard-UDP-Paketgröße, kann dies zu Fragmentierung oder einem Fallback auf TCP führen, was die Latenz erhöht (Performance) und bei strikten Firewalls zu Auflösungsproblemen führen kann.
Wahl der TTL (Time to Live)
Abschnitt betitelt „Wahl der TTL (Time to Live)“Empfehlung: Wählen Sie die TTL passend zur Änderungshäufigkeit (Standardempfehlung: 3600 Sekunden / 1 Stunde).
Hintergrund: Extrem kurze TTLs erhöhen die Last und das Risiko von Auflösungsfehlern bei kurzen Netzstörungen. Sehr lange TTLs behindern schnelle Reaktionen auf Vorfälle (z. B. IP-Schwenk bei Ausfall).
3. Datensicherheit und Umgang mit Informationen
Abschnitt betitelt „3. Datensicherheit und Umgang mit Informationen“Das Domain Name System ist ein weltweit öffentliches Verzeichnis. Alle darin gespeicherten Informationen sind im Klartext abrufbar.
Keine personenbezogenen Daten
Abschnitt betitelt „Keine personenbezogenen Daten“Empfehlung: Speichern Sie keine personenbezogenen Daten in DNS-Records (z. B. Klarnamen oder persönliche E-Mail-Adressen in TXT-, SOA- oder SPF-Records).
Hintergrund: DNS-Daten sind öffentlich und können nicht zugriffsgeschützt werden. Die Speicherung personenbezogener Daten stellt daher ein Risiko für die Einhaltung der DSGVO dar.
Keine Geheimnisse (Secrets) im Klartext
Abschnitt betitelt „Keine Geheimnisse (Secrets) im Klartext“Empfehlung: Hinterlegen Sie keine sensitiven Passwörter, API-Keys oder Credentials im Klartext in TXT-Records.
Hintergrund: TXT-Records werden häufig zur Domain-Validierung (z. B. für Zertifikate oder SaaS-Dienste) genutzt. Achten Sie darauf, dass hierbei nur die dafür vorgesehenen Challenge-Tokens publiziert werden und keine produktiven Geheimnisse.
4. Identitäts- und Rechtemanagement (IAM)
Abschnitt betitelt „4. Identitäts- und Rechtemanagement (IAM)“Der Zugriff auf die Verwaltung der DNS-Zonen erfolgt über die STACKIT Plattform und sollte restriktiv gehandhabt werden.
Rollenkonzept: Nutzen Sie das STACKIT Projekt-Rollenkonzept (RBAC). Vergeben Sie schreibende Rollen (z. B. Project Owner oder Project Member) nur an Personen oder Service-Accounts, die diese zwingend benötigen (“Principle of Least Privilege”). Nur-lesende Zugriffe sollten über entsprechende Rollen (z. B. Project Viewer) abgebildet werden.
Authentisierung: Schützen Sie Benutzerkonten mit Zugriff auf das STACKIT Portal oder die API durch starke Passwörter und, wo verfügbar, durch Multi-Faktor-Authentifizierung (MFA).
5. Administration und Automatisierung
Abschnitt betitelt „5. Administration und Automatisierung“Infrastructure as Code (IaC): Es wird empfohlen, DNS-Zonen bevorzugt über Automatisierungstools zu verwalten (z. B. via STACKIT Terraform Provider oder STACKIT CLI). Dies ermöglicht Versionierung, Peer-Reviews (4-Augen-Prinzip im Code) und schnelle Wiederherstellung (Disaster Recovery).
Vermeidung von “Dangling DNS”: Überprüfen Sie regelmäßig, ob CNAME-Einträge auf Ressourcen zeigen, die nicht mehr existieren (z. B. gelöschte Load Balancer oder Storage Buckets). Verwaiste Einträge können für Subdomain-Takeover-Angriffe missbraucht werden.
6. Schwachstellen und Updates
Abschnitt betitelt „6. Schwachstellen und Updates“Verantwortung Provider: STACKIT verantwortet das Patch-Management und die Absicherung der zugrundeliegenden DNS-Server-Infrastruktur sowie die Bereitstellung von Sicherheitsfunktionen (z. B. DDoS-Schutz der Anycast-Plattform).
Verantwortung Kunde: Der Kunde ist verantwortlich für die sichere logische Konfiguration der Zonen (wie in Abschnitt 2 und 3 beschrieben).