5. Autorisierung

Zonentransfers können sensible Informationen über die Struktur und den Inhalt einer Zone preisgeben, was Angreifern potenziell bei Aufklärungsaktivitäten hilft. Aus diesem Grund verwenden AXFR-Server typischerweise Autorisierungsmechanismen, um Zonentransfers nur auf vertrauenswürdige Clients zu beschränken.

Dieser Abschnitt beschreibt gängige Autorisierungstechniken, die in AXFR-Implementierungen verwendet werden. Beachten Sie, dass dieses Dokument keine spezifische Autorisierungsmethode vorschreibt; Implementierer und Betreiber sind frei, den Ansatz zu wählen, der ihren Sicherheitsanforderungen am besten entspricht.

Gängige Autorisierungstechniken

1. Zugriffskontrolllisten (ACLs): Ein AXFR-Server KANN IP-adressbasierte ACLs verwenden, um zu beschränken, welche Clients Zonentransfers anfordern dürfen. Der Server prüft die Quell-IP-Adresse der eingehenden TCP-Verbindung gegen eine konfigurierte Liste erlaubter Adressen oder Netzwerke.

   • Vorteile: Einfach zu implementieren und zu konfigurieren.
   • Einschränkungen: Anfällig für IP-Adress-Spoofing (obwohl der TCP-Drei-Wege-Handshake einigen Schutz bietet). Nicht geeignet für Clients mit dynamischen IP-Adressen.

2. TSIG (Transaction Signature): TSIG [RFC2845] bietet kryptografische Authentifizierung von DNS-Nachrichten unter Verwendung gemeinsamer geheimer Schlüssel. Ein AXFR-Server KANN TSIG-Authentifizierung für Zonentransfer-Anfragen verlangen.

   • Vorteile: Bietet starke Authentifizierung und Nachrichtenintegrität. Nicht abhängig von IP-Adressen.
   • Einschränkungen: Erfordert, dass vorverteilte Schlüssel sowohl auf dem Client als auch auf dem Server konfiguriert werden. Schlüsselverwaltung kann in großen Bereitstellungen herausfordernd sein.

3. SIG(0) (Signature): SIG(0) [RFC2931] bietet auf öffentlichen Schlüsseln basierende Authentifizierung von DNS-Nachrichten. Ein AXFR-Server KANN SIG(0) verwenden, um AXFR-Abfragen zu authentifizieren.

   • Vorteile: Verwendet Public-Key-Kryptographie und vermeidet die Notwendigkeit vorverteilter Geheimnisse. Geeignet für Szenarien, in denen TSIG-Schlüsselverwaltung unpraktisch ist.
   • Einschränkungen: Komplexer zu implementieren und zu konfigurieren als TSIG. Erfordert Public-Key-Infrastruktur.

4. TLS/SSL: Obwohl in diesem Dokument nicht spezifiziert, KANN ein AXFR-Server TLS oder SSL verwenden, um TCP-Verbindungen zu verschlüsseln und zu authentifizieren, die für Zonentransfers verwendet werden. Dieser Ansatz ist für DNS-Zonentransfers nicht standardisiert, kann aber in privaten oder kontrollierten Umgebungen verwendet werden.

5. VPN oder private Netzwerke: In einigen Bereitstellungen werden Zonentransfers über private Netzwerke (z.B. VPNs [RFC2764]) durchgeführt, die nicht öffentlich über das Internet zugänglich sind. Dieser Ansatz verlässt sich auf Sicherheit auf Netzwerkebene statt auf Authentifizierung auf Anwendungsebene.

Autorisierungsrichtlinie

Ein AXFR-Server SOLLTE eine konfigurierbare Autorisierungsrichtlinie implementieren, die bestimmt, welche Clients Zonentransfers anfordern dürfen. Die Richtlinie SOLLTE mindestens eine der oben aufgeführten Autorisierungstechniken unterstützen.

Ein AXFR-Server MUSS auf nicht autorisierte AXFR-Abfragen mit einer DNS-Antwortnachricht antworten, die RCODE REFUSED (5) enthält. Dies informiert den Client, dass der Zonentransfer aufgrund von Richtlinienbeschränkungen verweigert wurde.

Standardverhalten

Das Standardverhalten eines AXFR-Servers bezüglich Autorisierung wird von diesem Dokument nicht spezifiziert. Implementierer SOLLTEN ein sicheres Standardverhalten wählen, wie zum Beispiel:

• Standardmäßiges Verweigern aller Zonentransfer-Anfragen, wobei eine explizite Konfiguration erforderlich ist, um spezifische Clients zu erlauben, oder
• Erlauben von Zonentransfers nur von spezifischen IP-Adressen, die als sekundäre Server konfiguriert sind.

Ein AXFR-Server DARF standardmäßig KEINE uneingeschränkten Zonentransfers an beliebige Clients erlauben, da dies ein erhebliches Sicherheitsrisiko darstellt.

Mehrere Autorisierungsmethoden

Ein AXFR-Server KANN mehrere Autorisierungsmethoden gleichzeitig unterstützen. Beispielsweise könnte ein Server sowohl IP-adressbasierte ACL-Übereinstimmung als auch TSIG-Authentifizierung verlangen, damit ein Zonentransfer erlaubt wird. Die Einzelheiten der Kombination mehrerer Autorisierungsmethoden sind implementierungsabhängig.

Autorisierungsfehler

Wenn eine AXFR-Abfrage die Autorisierungsprüfungen nicht besteht, SOLLTE der AXFR-Server mit RCODE REFUSED antworten. Der Server KANN den fehlgeschlagenen Autorisierungsversuch für Audit-Zwecke protokollieren.

Ein AXFR-Server DARF KEINE Details darüber preisgeben, warum die Autorisierung fehlgeschlagen ist (z.B. durch Zurückgeben verschiedener Fehlercodes für verschiedene Fehlerursachen), da dies potenziellen Angreifern nützliche Informationen liefern könnte.