The Cable Guy März 2004

Transkript

1 The Cable Guy März 2004 Local Server-Less DNS-Namensauflösung für IPv6 von The Cable Guy Alle auf Deutsch verfügbaren Cable Guy-Kolumnen finden Sie unter &formate=&suche=the+cable+guy.

2 Inhalt Inhalt...2 Local Server-Less Domain Name System (LSLDNS)...3 Funktionsweise von LSLDNS...4 Zusätzliche Informationen...5

3 Local Server-Less Domain Name System (LSLDNS) Local Server-Less Domain Name System (LSLDNS), auch Multicast-DNS genannt, ist eine neue Fähigkeit des IPv6-Protokolls. Sie steht mit Microsoft Windows CE ab Version 4.1 zur Verfügung. LSLDNS wird im Internet-Draft Local Server-less DNS (LSLDNS) query resolution beschrieben (draftietf-dnsext-mdns-07.txt). Anmerkung: In neueren Versionen des Internet-Drafts zu Multicast-DNS wurden der Name des Protokolls (jetzt Link-Local Multicast Name Resolution - LLMNR) und viele Implementierungsdetails geändert. LLMNR wird in diesem Dokument jedoch nicht besprochen. LSLDNS stellt eine Namensauflösung für ein Ad-Hoc-Netzwerk und Netzwerke mit einem einzelnen Subnetz bereit, die nicht über einen DNS-Server verfügen. Mit IPv4 wird dieses Problem unter Windows-TCP/IP durch NetBIOS über TCP/IP (NetBT) gelöst daher ist NetBT standardmäßig aktiviert. Mit NetBT sendet ein anfragender Knoten eine NetBIOS-Namensauflösungsanfrage als Broadcast an die Broadcastadresse des lokalen Subnetzes. Der Knoten, der den angefragten Namen verwendet, schickt eine Unicast-NetBIOS-Namensanforderungsantwort an den anfragenden Knoten zurück somit ist der Name aufgelöst. Aus den folgenden Gründen funktioniert dieses Verfahren unter IPv6 nicht: NetBIOS kann über IPv6 nicht verwendet werden. Es gibt keine Broadcastadressen unter IPv6. LSLDNS ist ein einfacher Anfrage-Antwort-Mechanismus, der es IPv6-Knoten in Ad-Hoc-Netzwerken und in Netzwerken mit einem einzelnen Subnetz erlaubt, auch ohne DNS-Server die Namen der anderen Knoten im Subnetz aufzulösen. In Netzwerken mit mehreren Subnetzen wird davon ausgegangen, dass es einen Router und einen DNS-Server gibt. Da unter IPv6 keine Broadcasts verfügbar sind, werden stattdessen Multicast-Nachrichten verwendet. In den folgenden Punkten entspricht LSLDNS dem Standard-DNS: Es verwendet FQDNs (Fully Qualified Domain Names vollqualifizierte Domänennamen). Es verwendet die gleichen Nachrichten und Nachrichtenstrukturen wie DNS (wie in RFC 1035 definiert). In den folgenden Punkten unterscheidet sich LSLDNS vom Standard-DNS: LSLDNS-Nachrichten werden an die TCP- und UDP-Ports 5353 statt an die TCP- und UDP- Ports 53 geschickt. LSLDNS-Abfragen werden an eine Multicast-Adresse statt an die Unicast-Adresse eines DNS-Servers geschickt. Der LSLDNS-Cache ist vom DNS-Cache getrennt. LSLDNS wird in folgenden Situationen verwendet: Wenn kein DNS-Server konfiguriert ist. Wenn der DNS-Server nicht auf eine Anfrage antwortet. Wenn der DNS-Server mit dem Rückgabewert (RCODE) 0 antwortet aber keine Antworteinträge im Paket vorhanden sind. Wenn DNS-Server mit dem Rückgabewert 3 antworten (Domäne nicht vorhanden). Die für die DNS-Namensauflösungsanforderungen verwendete Multicast-Adresse wird Solicited-Name Multicast-Adresse genannt. Sie setzt sich folgendermaßen zusammen:

4 Prefix: FF02::2:0:0/96 Die höchsten 32 Bits im MD5-Wert (Message Digest 5) des Hostteils eines FQDNs oder eines unqualifizierten Namens. Der Hostteil des FQDNs officecomputer.example.com ist zum Beispiel officecomputer. Der Host mit dem entsprechenden Hostnamen überwacht die Solicited-Name-Multicast-Adresse und der Host, der eine Namensauflösung für einen FQDN versucht, der mit diesem Hostteil anfängt, verwendet als Zieladresse für die Auflösungsanfrage diese Solicited-Name-Multicast-Adresse. Funktionsweise von LSLDNS Ein Knoten, der LSLDNS unterstützt, berechnet während des Startvorgangs seine eigene Solicited- Name-Multicast-Adresse und weist IPv6 an, auf Pakete an diese Adresse zu reagieren. Wenn eine Anwendung den Windows-Sockets-Funktionsaufruf getaddrinfo() verwendet, um einen FQDN oder einen nicht qualifizierten Namen in eine Adresse aufzulösen, dann extrahiert der LSLDNS- Knoten den Hostnamen, berechnet den MD5-Hash des Hostnamens und hängt dessen höchste 32 Bits an das Prefix FF02::2:0:0/96 an. Dies ist dann die Solicited-Name-Multicast-Adresse. Der abfragende Knoten erstellt und sendet dann eine DNS-Namensauflösungsanfrage an diese Adresse. Sie hat den folgenden Inhalt: IPv6-Header Das Feld Quelladresse ist auf die Link-Local-Adresse des abfragenden Knotens gesetzt. Das Feld Zieladresse ist auf die Solicited-Name-Multicast-Adresse gesetzt. Das Feld Hop Limit ist auf den Wert 255 gesetzt. UDP-Header Das Feld Quellport ist auf den Wert 5353 gesetzt. Das Feld Zielport ist auf den Wert 5353 gesetzt. DNS-Header Das Flag Recursion Desired (RD) ist auf den Wert 0 gesetzt. Der Question-Abschnitt des Pakets enthält außerdem den vollständigen Namen der Anwendung und die Record-Typ-Anfrage aus dem getaddrinfo()-funktionsaufruf. Das Hop-Limit im IPv6-Header ist auf 255 gesetzt. Jeder Empfänger überprüft vor einer Verarbeitung der Nachricht, ob das Hop-Limit den Wert 255 hat. Diese Prüfung entspricht einer Neighbour- Discovery-Nachricht, mit der der Empfänger prüft, ob die Nachricht von einem Knoten im lokalen Subnetz kam. Wenn das nicht der Fall ist, dann wäre das Hop-Limit auf einen anderen Wert als 255 gesetzt. Wichtig ist auch das RD-Flag mit dem Wert 0 im DNS-Header. Dieses zeigt an, dass der Empfänger keine rekursive Auflösung für den Absender durchführen soll. Die DNS-Namensauflösungsanfrage per Multicast wird von den Knoten empfangen, die die entsprechende Solicited-Name-Multicast-Adresse überwachen. Sie prüfen erst, ob das Hop-Limit auf 255 gesetzt ist. Wenn dies nicht der Fall ist, dann wird die Nachricht kommentarlos verworfen. Der empfangende Host prüft dann, ob er für den Namen in der Anfrage zuständig ist. Im Gegensatz zum normalen DNS sind LSLDNS-Knoten selbst für die Auflösung ihrer Namen zuständig nicht der DNS-Server. In der DNS-Terminologie würde das heißen "LSLDNS-Knoten sind der SOA für eine Zone (diese besteht jedoch nur aus ihrem eigenen Namen)". Wenn ein Knoten für den Namen in einer Anfrage zuständig ist (wenn es sich also um seinen eigenen Namen handelt), dann verschickt er eine DNS-Namensauflösungsantwort mit den folgenden Inhalten: IPv6-Header Das Feld Quelladresse ist auf die Link-Local-Adresse des anfordernden Knotens gesetzt. Das Feld Zieladresse ist auf die Quelladresse aus der erhaltenen DNS-

5 Namensauflösungsnachricht gesetzt (die Link-Local-Addresse des anfragenden Knotens). Das Feld Hop-Limit ist auf den Wert 255 gesetzt UDP-Header Das Feld Quellport ist auf den Wert 5353 gesetzt. Das Feld Zielport ist auf den Wert 5353 gesetzt. DNS-Header Das Flag Authoritative Answer (AA) ist auf 1 gesetzt. Das Flag Recursion Available (RA) ist auf 0 gesetzt. Das Feld RCODE ist auf 0 gesetzt. Der Question-Abschnitt enthält die Question-Section-Felder und Inhalte aus der DNS- Namensauflösungsanfrage. Der Answer-Abschnitt enthält die entsprechenden Einträge für die Namen, die in der DNS- Namensauflösungsanfrage abgefragt wurden. Wenn die gesamte DNS-Namensauflösungsantwort länger als 512 Byte ist, dann setzt der antwortende Knoten das Flag Truncation (TC) auf 1. Der anfordernde Knoten kann dann entweder die Anfrage über eine Unicast-Nachricht oder eine TCP-basierte DNS-Namensauflösungsanfrage wiederholen, oder er kann eine neue UDP-basierte Abfrage über EDNS0 versuchen (wie in RFC 2671 definiert). Wenn der anfragende Knoten keine Antwort erhält, dann kann er die DNS-Namensauflösungsanfrage bis zu dreimal wiederholen. Wenn er auf alle Anfragen keine Antwort erhält, dann kann er davon ausgehen, dass der abgefragte Name im Netzwerk nicht verwendet wird. In diesem Fall gibt er eine Fehlermeldung an die Anwendung zurück, die die Funktion getaddrinfo() aufgerufen hat. In einem Ad-Hoc-Netzwerk oder einem Netzwerk mit einem einzelnen Subnetz, ist es möglich, dass mehrere Knoten denselben Hostnamen verwenden. Einem Computer wird zum Beispiel der FQDN officecomputer.example.com zugewiesen und einem anderen der FQDN officecomputer.upstairs.example.com. Die Solicited-Name-Multicast-Adresse ist für beide Computer gleich. Eine Abfrage für officecomputer.example.com, die an die Solicited-Name-Multicast-Adresse für den Hostnamen officecomputer gesendet wird, wird von beiden Computern verarbeitet. Da jedoch nur ein Computer den FQDN officecomputer.example.com verwendet, wird auch nur ein Computer antworten. Es ist außerdem möglich, dass mehrere Knoten den gleichen FQDN verwenden. Auch hier ist natürlich für beide die Solicited-Name-Multicast-Adresse gleich eine Anfrage an diese Adresse wird somit auch von beiden Computern verarbeitet, und in diesem Fall senden auch beide Computer eine Antwort. Der anfragende Host behandelt die mehrfachen Antworten in diesem Fall so, als hätte er eine einzelne Antwort mit mehreren DNS-Einträgen erhalten. Zusätzliche Informationen Internet Protocol Version 6 Technology Center (englischsprachig). IETF DNS Extensions Working Group (englischsprachig). Internet Protocol Version 6 (IPv6) Support in Windows CE 4.1 and later (englischsprachig). Alle in deutscher Sprache verfügbaren Cable Guy-Kolumnen finden Sie unter J&prod=&formate=&suche=The+Cable+Guy. Die englischsprachige Cable Guy-Kolumne finden Sie unter