DNSSEC

Änderungen im DNS-Verhalten

Änderungen an .com-/.net-/.edu-Namensservern im Zuge der Vorbereitung auf DNSSEC

Am 1. März 2010 hat Verisign zwei Änderungen vorgenommen, die sich auf das Verhalten der autoritativen Namensserver für die .com-, .net- und .edu-Zonen ([a-m].gtld-servers.net) auswirken. Die Änderungen sind eine Voraussetzung für die Anwendung von DNSSEC in diesen drei Zonen. Diese beiden Änderungen sind:
Neues Verhalten bei Weiterleitungen und Glue erhält keinen autoritativen Status mehr.

Neues Verhalten bei Weiterleitungen 

Wenn in der Vergangenheit ein vorhandener A- oder AAAA-Eintrag als „Glue“ (ein Adresseintrag an oder unter NS-Einträgen an einem Delegationspunkt) angefragt wurde, antworteten die autoritativen Namensserver für .com und .net mit dem Glue-Eintrag im Antwortbereich. Die Antwort war aber nicht als autoritativ gekennzeichnet, d.h., das AA-Bit war nicht gesetzt. Dieses Verhalten entsprach den DNS-Standards, neuere autoritative Server antworteten aber nicht in dieser Weise. Stattdessen antworteten neuere autoritative Server bei Abfrage eines Namens an oder unter einem Delegationspunkt mit einer Weiterleitung an die delegierte Zone. Dieses Verhalten wurde ebenfalls von den DNS-Standards unterstützt.

Die [a-m].gtld-servers.net-Server folgen nun bei Weiterleitungen der letzteren Verhaltensweise: Abfragen für Glue Records führen zu Weiterleitungen anstatt zu nicht-autoritativen Antworten.

Beachten Sie, dass diese Änderung sich auf die Auflösung bestimmter Domains unter .com und .net auswirkt, die voneinander abhängig sind. Die folgende Konfiguration voneinander abhängiger „example.com“- und „example.net“-Zonen hat beispielsweise in der Vergangenheit problemlos funktioniert:

example.com. NS ns1.example.net.
example.com. NS ns2.example.net.

example.net. NS ns1.example.com.
example.net. NS ns2.example.com.

Diese beiden Domains wurden in einem „Zyklus“ konfiguriert: Alle Server von example.com befinden sich in der example.net-Domain und alle Server von example.net befinden sich in der example.com-Domain. Eine solche zyklische Konfiguration wurde zur Auflösung verwendet, da [a-m].gtld-servers.net sowohl für die .com- als auch für die .net-Zonen autoritativ war und weil diese Server Abfragen für „Glue“ als nicht-autoritative Antworten ausgegeben haben, wie oben beschrieben.

Um präzise darzustellen, warum diese Konfiguration funktioniert hat, erwägen Sie die Schritte eines iterativen Resolvers (des Teils eines rekursiven Namensservers, der Abfragen sendet) für die Auflösung jeglicher Daten auf „www.example.com“.

  • Der iterative Resolver fragt einen autoritativen .com-Namensserver für „www.example.com“ ab und erhält eine Weiterleitung zu „example.com“, wobei nur Namensserver in „example.net“ angegeben werden.
  • Obwohl die Weiterleitung A-Einträge für „ns1.example.net“ und „vns2.example.net“ im Zusatzbereich der DNS-Nachricht enthält, ignorieren neuere iterative Resolver diese Einträge als Maßnahme gegen Cache Poisoning.
  • Nachdem die A-Einträge für „ns1.example.net“ und „ns2.example.net“ verworfen wurden, verfügt der iterative Resolver jetzt über die Namen, aber keine Adressen für die „example.com“-Namensserver. Er muss die Abfrage für „www.example.com“ vorübergehend aussetzen, um die Adresse eines der „example.com“-Namensserver zu suchen. Wir gehen davon aus, dass der Resolver sich für die Auflösung von „ns1.example.net“entscheidet.
  • Der iterative Resolver fragt schließlich einen autoritativen .net-Namensserver für die A-Einträge für „ns1.example.net“ ab. Beim derzeitigen Verhalten bei Weiterleitungen von [a-m].gtld-servers.net gibt der .net-Server eine nicht-autoritative Antwort für den A-Eintrag für „ns1.example.net“ aus. Der iterative Resolver verwendet diese Adresse, um diesen „example.com“-Namensserver zu kontaktieren und „www.example.com“ aufzulösen.

Seit dem 1. März 2010 gibt der .net-Server allerdings den A-Eintrag für „ns1.example.net“ nicht aus, sondern leitet stattdessen an „example.net“ weiter. Denken Sie aber daran, dass alle „example.net“-Namensserver sich in der „example.com“-Domain befinden. Der einzige Grund für den iterativen Resolver, „ns1.example.net“ aufzulösen, besteht in der Auflösung der ersten Abfrage, „www.example.com“, offensichtlich ebenfalls in der „example.com“-Domain. Da alle Domains voneinander abhängig sind, kann die Auflösung nicht mehr erfolgreich sein.

Verisign hat zwei Listen von .com- und .net-Domains erstellt, die von dieser Änderung betroffen sein können:

Liste 1: An Zyklen beteiligte Domains

Die Domains in dieser Liste sind voneinander abhängig, wie oben beschrieben. Im oben beschriebenen Szenario würden beispielsweise sowohl „example.com“ als auch „example.net“ in der ersten Liste auftauchen.

Liste 2: Domains, die ausschließlich von Domains in Zyklen abhängig sind

Die Domains in dieser Liste sind nicht aktiv Teil eines Zyklus wie die Domains in der ersten Liste. Stattdessen verwenden alle Domains in Liste 2 ausschließlich Namensserver aus Domains, die Teil eines Zyklus sind. In anderen Worten bezieht eine Domain in Liste 2 alle ihre Namensserver von einer oder mehreren Domains in Liste 1. Um das obige Beispiel fortzuführen: Wenn die Domain „foo.com“ die Namensserver „ns1.example.com“ und „ns2.example.com“ hätte, würde „foo.com“ in Liste 2 aufgeführt.

Wenn eine Domain in einer der beiden Listen angezeigt wird, erfordert die Änderung vom 1. März, dass mindestens einer ihrer Namensserver dahingehend geändert wird, dass er entweder den Zyklus unterbricht (für Domains in Liste 1) oder die Abhängigkeit einer Domain von einem Zyklus aufhebt (für Domains in Liste 2).

Glue erhält keinen autoritativen Status mehr 

Im .com-/.net-Registry-System kann eine Domain in eine administrative Warteschlange versetzt werden. Eine Domain in der Warteschlange wird nicht veröffentlicht: Die NS-Einträge, die die Domain delegieren, werden aus der .com- oder .net-Zone entfernt. Registrare versetzen eine Domain zum Beispiel in die Warteschlange, wenn sie abläuft, der Registrant aber nicht auf die Verlängerungsaufforderungen reagiert hat, oder wenn sie für bösartige Aktivitäten verwendet wird.

Vor dieser Änderung wurden beim Versetzen einer Domain in die Warteschlange NS-Einträge aus der Zone entfernt, aber keiner der A- und AAAA-Einträge von Namensservern in dieser Domain. Erwägen Sie zum Beispiel eine Situation, in der „example.com“ in der Registry zusammen mit dem Namensserver „ns.example.com“ vorhanden ist. (Wichtiger Hinweis: Ob die „example.com“-Zone selbst „ns.example.com“ als einen ihrer autoritativen Namensserver verwendet, ist für das hier beschriebene Verhalten nicht von Bedeutung. Wichtig ist, dass „ns.example.com“ sich in der „example.com“-Domain befindet, d.h. unter ihr im DNS-Namensraum.)

In der Vergangenheit wurden die NS-Einträge, die eine „example.com“-Domain delegierten, aus der .com-Zone gelöscht, wenn diese Domain in die Warteschlange versetzt wurde. Die A- und AAAA-Einträge für „ns.example.com“ blieben in der Zone. Da diese Einträge sich nicht mehr unter einem Delegationspunkt befanden, wurden sie zu autoritativen Daten.

Ab dem 1. März 2010 werden die NS-Einträge, die eine Domain delegieren, aus der Zone entfernt, wenn diese Domain in die Warteschlange versetzt wird, und die A- und AAAA-Einträge für Namensserver unter der Domain erhalten keinen autoritativen Status mehr. Diese A- und AAAA-Einträge werden nicht wirklich entfernt: Sie werden zwar nicht ausgegeben, wenn sie direkt angefragt werden, aber sie werden im Zusatzbereich von Weiterleitungen, die sich auf sie beziehen, angezeigt.

Wenn im obigen Beispiel „example.com“ in die Warteschlange versetzt würde, würden die NS-Einträge aus der Zone entfernt. Wenn aber die „example.net“-Domain „ns.example.com“ als Namensserver verwendet, beinhaltet eine Weiterleitung an „example.net“ die A- und AAAA-Einträge für „ns.example.com“ im Zusatzbereich.

Wenn Sie Fragen zu diesen Änderungen haben, kontaktieren Sie Verisigns Kundenservice für Registrys.

Zum Seitenanfang