Zum Inhalt springen

Leitlinien und Empfehlungen für die sichere Nutzung

Zuletzt aktualisiert am

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.

Die folgenden Konfigurationsempfehlungen dienen der Minimierung von Sicherheitsrisiken und der Sicherstellung der Verfügbarkeit.

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.

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.

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).

Das Domain Name System ist ein weltweit öffentliches Verzeichnis. Alle darin gespeicherten Informationen sind im Klartext abrufbar.

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.

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.

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).

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.

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).