Zum Hauptinhalt springen

7. Rückwärtskompatibilität

Die Beschreibung der Rückwärtskompatibilität ist aufgrund des Mangels an Spezifika in der ursprünglichen Definition schwierig. In diesem Abschnitt werden einige Hinweise zum Aufbau von Rückwärtskompatibilität gegeben, die hauptsächlich aus den relevanten früheren Abschnitten wiederholt werden.

Rückwärtskompatibilität ist nicht notwendig, aber je größer der Umfang der Kompatibilität einer Implementierung ist, desto größer ist ihre Interoperabilität. Für Turnkey-Implementierungen ist dies normalerweise kein Problem. Für Allzweck-Implementierungen nimmt dies verschiedene Wichtigkeitsstufen an, je nach dem Wunsch des Implementierers, Interoperabilität aufrechtzuerhalten.

Es ist bedauerlich, dass die Notwendigkeit, auf älteres Verhalten zurückzugreifen, nicht entdeckt werden kann und daher in einer Konfigurationsdatei vermerkt werden muss. Eine Implementierung SOLLTE in ihrer Dokumentation Betreiber ermutigen, AXFR-Clients und -Server, über die sie wiederholt Notizen gemacht hat, regelmäßig zu überprüfen, da alte Software von Zeit zu Zeit aktualisiert wird.

7.1. Server​

Ein AXFR-Server hat den Luxus, auf die Fähigkeiten eines AXFR-Clients reagieren zu können, mit Ausnahme der Kenntnis darüber, ob der Client mehrere Ressourceneinträge pro AXFR-Antwortnachricht akzeptieren kann. Die Kenntnis, dass ein Client so eingeschränkt ist, kann nicht entdeckt werden; daher muss sie durch Konfiguration festgelegt werden.

Eine Implementierung eines AXFR-Servers KANN es erlauben, auf Basis einzelner AXFR-Clients zu konfigurieren, ob es notwendig ist, auf einen einzelnen Ressourceneintrag pro Nachricht zurückzukehren; in diesem Fall SOLLTE die Standardeinstellung sein, mehrere Einträge pro Nachricht zu verwenden.

Überlegungen für Legacy-Clients:

  1. Ein einzelner RR pro Nachricht: Einige sehr alte DNS-Implementierungen erwarten nur einen einzelnen Ressourceneintrag im Answer-Abschnitt jeder AXFR-Antwortnachricht. Moderne AXFR-Server SOLLTEN aus Effizienzgründen mehrere RRs pro Nachricht unterstützen, KÖNNEN jedoch eine Konfigurationsoption bereitstellen, um für spezifische Legacy-Clients zum Single-RR-Verhalten zurückzukehren.

  2. Nachrichtengröße: Ältere Clients können Einschränkungen bezüglich der maximalen Größe von DNS-Nachrichten haben, die sie verarbeiten können. AXFR-Server KÖNNEN Konfigurationsoptionen bereitstellen, um die Größe einzelner Antwortnachrichten bei der Interaktion mit solchen Clients zu begrenzen.

  3. EDNS(0), TSIG und SIG(0): Ältere Clients unterstützen möglicherweise EDNS(0), TSIG oder SIG(0) nicht. Ein AXFR-Server SOLLTE Abfragen von Clients, die diese Optionen nicht enthalten, angemessen handhaben und SOLLTE ihre Anwesenheit NICHT erfordern, es sei denn, dies ist aus Sicherheitsgründen speziell konfiguriert.

Empfehlungen für Server-Implementierungen:

  • Standardmäßig modernes, effizientes Verhalten (mehrere RRs pro Nachricht, Unterstützung für EDNS(0)/TSIG/SIG(0)).
  • Konfigurationsoptionen bereitstellen, um Legacy-Clients auf Client-Basis zu berücksichtigen.
  • Bekannte Kompatibilitätsprobleme und empfohlene Konfigurationseinstellungen für die Interoperation mit älterer Software dokumentieren.

7.2. Client​

Ein AXFR-Client hat die Möglichkeit, andere Funktionen (d.h. solche, die nicht in diesem Dokument definiert sind) beim Abfragen eines AXFR-Servers auszuprobieren.

Der Versuch, mehrere DNS-Abfragen über einen TCP-Transport für eine AXFR-Sitzung zu senden, SOLLTE abgebrochen werden, wenn er die ursprüngliche Anfrage unterbricht, und SOLLTE berücksichtigen, ob der AXFR-Server beabsichtigt, die Verbindung unmittelbar nach Abschluss des ursprünglichen (verbindungsverursachenden) Zonentransfers zu schließen.

Überlegungen für Legacy-Server:

  1. Mehrere RRs pro Nachricht: Moderne AXFR-Clients MÜSSEN darauf vorbereitet sein, mehrere Ressourceneinträge in einer einzelnen AXFR-Antwortnachricht zu empfangen. Dies ist Standardverhalten und wird seit vielen Jahren weit verbreitet eingesetzt.

  2. Verbindungsbehandlung: Ältere Server können die TCP-Verbindung unmittelbar nach dem Senden des finalen SOA-RR schließen, während andere die Verbindung für einen Zeitraum offen halten können. AXFR-Clients SOLLTEN auf beide Verhaltensweisen vorbereitet sein und SOLLTEN NICHT darauf vertrauen, dass die Verbindung nach Abschluss des Zonentransfers offen bleibt.

  3. Fehlerantworten: Einige ältere Server können nicht-standardmäßige Fehlerantworten zurückgeben oder dem DNS-Nachrichtenformat möglicherweise nicht strikt entsprechen. AXFR-Clients SOLLTEN eine robuste Fehlerbehandlung implementieren, um unerwartete Antworten angemessen zu behandeln.

Empfehlungen für Client-Implementierungen:

  • Alle in diesem Dokument definierten Standardfunktionen unterstützen.
  • Robuste Fehlerbehandlung implementieren, um geringfügige Abweichungen von der Spezifikation zu tolerieren.
  • Vermeiden, sich auf Verbindungspersistenz oder andere nicht-standardmäßige Verhaltensweisen zu verlassen.
  • Bereit sein, auf einfacheres Verhalten zurückzugreifen (z.B. EDNS(0) nicht zu verwenden), wenn ein Server es scheinbar nicht unterstützt.
Letztes Update am