Namensauflösung im LAN und Internet
Siehe dazu auch:
Die Frage
Immer wieder gern gesuchte Information, die sich durch folgende Fragestellungen ausdrückt:
- Mein Outlook braucht lange um zu starten
- Mein Outlook findet den Server nicht
- Der Name kann nicht aufgelöst werden
- Mails im Internet Mail Dienst werden nicht gesendet
- Connectoren funktionieren nicht
- Im LAN geht alles, aber über RAS komme ich nicht an den Server
Und viele andere ähnliche Fragestellungen zielen eigentlich ganz genau darauf hinaus, dass die Namensauflösung im LAN nicht funktioniert.
Was in einem lokalen LAN vielleicht mit "Broadcasts" überbrückt werden kann, funktioniert spätestens in Netzwerken mit mehreren Segmenten, Routern oder Wählzugängen oder VPN nicht mehr. Hier muss der Client als auch der Server die notwendigen Dienste schnell und zuverlässig finden.
Bitte haben Sie Verständnis, dass ich hier nicht die Namensauflösung über DNS bis ins kleinste Detail beantworte. White Papers dazu gibt es bei Microsoft und bei den Anleitungen zu BIND und anderen DNS-Servern. Auch die Online Hilfe von Windows 2000 ist im Hinblick auf DNS und deren Konzepte aufschlussreich. Empfehlenswert ist das Microsoft White Paper zu DNS. Die Installation für Windows NT 4.0 ist im DNS Installation Whitepaper von Microsoft gut beschrieben. Grundfunktionen von DNS für den Mailversand finden sie bei "Internet Mail - Wir geht das ?"
Die Folge
Wenn dies nicht funktioniert, passiert es eben, dass
- Outlook bis zu 2 Minuten beim Start braucht
- Outlook Replikation langsam ist.
- Löschen von einzelnen Mails lange dauert (hier kann aber auch der Start der Leistungsoptimierung schon Wunder wirken, speziell nach Installation von Exchange 5.5. SP3)
- Mails an das Internet gehen nicht raus
- Benutzer können sich nicht anmelden, weil der Exchange Server keinen Domain Controller findet
- OWA findet keinen Server oder User
- In der NetzwerkUmgebung verschwinden teilweise Rechner
- Laufwerke und Drucker können nicht zugewiesen werden
- ...
Die möglichen Fehlerbilder sind vielfältig. Eine saubere Namensauflösung im LAN ist ein wichtiges Fundament für eine zuverlässige Funktion. Also korrigieren Sie das. Glück für Sie, wenn diese unvollständige Konfiguration erst beim Einsatz von Outlook und Exchange auffällt.
Und wie funktioniert das alles nun?
Ein Netzwerk dient der Kommunikation zwischen Rechnern. Vergleichbar zum Telefon hilft aber das schnellste Kommunikationsnetz niemandem, wenn man nicht weiß, wer wo zu erreichen ist. So wie das Telefonbuch bei Rufnummern hilft, muss auch im Netzwerk eine Auflösung der Namen möglich sein.
Solange Microsoft Netzwerke ohne "24h-Server" als Workgroup Netzwerk genutzt wurden, konnte keine Maschine als Namensdienst genutzt werden. Diese kleinen Netzwerke nutzten daher Broadcasts (Rundsprüche an alle Rechner), um einen Partner zu finden. Dies ist in größeren Netzwerke und bei WAN-Verbindungen ungünstig, da Broadcasts von allen Systemen empfangen und verarbeitet werden müssen und auch von einer Bridge oder den heute gerne eingesetzten Switches nicht blockiert werden können. Bei WAN-Verbindungen mit Routern, können Broadcasts blockiert werden und verursachen dadurch meist keine Kosten, aber natürlich ist dann keine Namensauflösung zwischen den Standorten möglich und damit nur eine erschwerte Kommunikation. Windows-Netzwerke können neben der Namensauflösung per Broadcast auch die Nutzung von Dateien (LMHOSTS) und des Netzwerkdienstes WINS. DNS für NetBIOS wird nur genutzt, wenn dies in der Netzwerksystemsteuerung auch aktiviert ist.
Die Reihenfolge von WINS, und Broadcasts kann über den "Wins-Knotentyp" im DHCP-Server eingestellt werden da gibt es:
- H-Knoten (Hybrid) erst Wins dann Broadcast
- B-Noten (Broadcast) nur Broadcast
- M-Knoten (Multi) erste Broadcast dann WINS
- P-Knoten (Point2Point) nur WINS
Es sollte völlig klar sein, dass "H-Knoten" und der Einsatz eines WINS-Servers optimal in einer Windows NT4 Umgebung sind. Leider sind WINS-Server nicht in einer Standardinstallation von Windows NT oder Windows 2000 dabei. Da muss der Administrator schon selbst installieren und konfigurieren und ein Client ist auch erst mal ein B-Knoten.
Will ein Windows-System einen Rechnernamen über TCP/IP auflösen, so durchläuft es folgende Schritte:
Eine Besonderheit ist der DNS-Server von Windows NT, welche rekursiv einen WINS-Server befragen kann. Damit kann ein Netzwerk mit eigener ZONE auch anderen Rechnern außerhalb per DNS aufgelöst werden, obwohl intern nur der WINS-Server genutzt wird. WINS eignet sich primär zur Auflösung der Namen innerhalb der eigenen NT-Domäne und des eigenen IP-Netzwerks. Replikationen sind anderen WINS-Servern sind möglich aber sollten wohl überlegt sein
Unabhängig hiervon sind WINSOCK-Aufrufe (Telnet, FTP etc.) welche nativ TCP/IP nutzen und daher direkt bei DNS einsteigen. Die Schritte 1 bis 3 werden von den Windows Netzwerkdiensten genutzt (Drucken, Dateifreigabe, DDE, alle NetBIOS Dienste, RPC).
Outlook nutzt problemlos DNS direkt, muss aber auch den "flachen" Namen des Server (d.h. ohne Domainendung) auflösen können.
Suche bei der Namensauflösung
Selbst wenn Sie nun glauben, alles "richtig" eingestellt zu haben, kann es sein, dass es nicht funktioniert. Dann kann es immer noch an verschiedenen Stellen klemmen. Oft hilft ein Neustart aber letztlich beseitigt man damit keine Probleme, sondern löscht primär den Cache eines Clientsystems und oftmals ist das schon eine Lösung. Aber es geht auch ohne Neustart und mit den richtigen Diagnosetools kann man der Sache auf den Grund kommen.
- NSLOOOKUP auf dem Client
Mit dem Programm NSLOOKUP können die sehr genau DNS Diagnose betreiben. Leider ist NSLOOKUP nicht grade einfach aber nach etwas eingewöhnlich kann man damit alles auslesen. Durch den Start alleine erfährt man schon, welchen DNS Server der Client nutzt und ob dieser antwortet. - Abfrage des MX-Record mit NSLOOKUP
Durch folgende Eingabe auf der Kommandozeile sollten Sie den MX-Eintrag für msxfaq.de erhalten:
nslookup -querytype=MX msxfaq.de
Ausgabe: Server: www-proxy.H1.srv.t-online.de Address: 217.237.149.161 Nicht autorisierte Antwort: msxfaq.de MX preference = 10, mail exchanger = mx01.kundenserver.de msxfaq.de MX preference = 10, mail exchanger = mx00.kundenserver.de
- NSLOOKUP zum Test eines Zonentransfers
Wenn Sie intern mehrere DNS-Server einsetzen und ein sekundärer Server keine Kopie der Zone ziehen kann, dann können Sie dies auch mit NSLOOKUP testen. Sie müssen sich natürlich mit einem Server verbinden, der diese Zone auch betreibt.
nslookup -q=AXFR msxfaq.de
- IPCONFIG auf dem Client
Mit dem Aufruf von "IPCONFIG /displaydns" kann man sehr genau ermitteln, welche DNS-Namen im Cache des Clients wie aufgelöst wurden.
Mit "ipconfig /Flushdns" kann man den Cache auch ohne Neustart löschen - DNS-Manager auf dem Server
Wer mit NSLOOKUP keine Domäne anzeigen will, kann das auch mit dem DNS-Manager auf dem Server. Letztlich sind diese Informationen die gleichen, die man mit NSLOOKUP lesen und kontrollieren kann. Allerdings eben ohne Einbeziehung des Clients und dortiger Konfigurationsfehler - HOSTS auf dem Client
Kontrollieren sie, ob in %windir%\system32\drivers\etc. eine "HOSTS"-Datei liegt. in einem "normalen Netzwerk" ist diese Datei überflüssig. Nur wenige Sonderfälle benötigen eine HOSTS Datei. Im Zweifel brauchen Sie keine, sondern sollten solche Einträge im DNS statisch pflegen. - NBTSTAT auf dem Client
Für die Auflösung per WINS auf dem Client kann mit NBTSTAT einen Fehler verfolgt werden.
Mit "NBTSTAT -C" kann der lokale WINS Cache angezeigt werden
Mit NBTSTAT -R kann auch dieser Cache geleert werden - NBLOOKUP auf dem Client
Analog zu NSLOOKUP für DNS gibt es Microsoft mitterlweile auch ein NBLOOKUP für WINS:
830578 NBLookup.exe command-line tool - WINS-Manager auf dem Server
Auf dem WINS-Server kann mit dem Manager die Datenbank angezeigt werden und eventuell falsche Einträge auch gelöscht werden. Sobald sie mehrere replizierte WINS-Server haben, sollte sie aber keine Einträge löschen, sondern veralten. Ansonsten laufen die Datenbanken der WINS-Server nicht mehr synchron. Diese Fehler sind sehr aufwändig zu erkennen und zu beheben. - LMHOSTS
Analog zu HOSTS bei DNS kann mit WINS eine LMHOSTS genutzt werden. Aber hier gilt: Im Zweifel nicht notwendig.
Besser sind WINS-Server mit statischen oder replizierten Einträgen
Weitere Links
- DNS
- WINS
- Reverse DNS
- SMTP und MX
- Namensauflösung im LAN und Internet
- Exchange und dynamischem DNS
- 300684 Information about configuring Windows für domains with
single-label DNS names
Not Supported with Exchange 2007. Kein SP1 möglich - 254680 DNS namespace planning
- 837391 Exchange Server 2003 and Exchange 2000 Server require NetBIOS name resolution für full functionality
- Q120642 TCP/IP & NBT Configuration Parameters für Windows NT
- Q136516 XCLN: Improving Windows Client Startup Times
- Q137966 Changing NetBIOS Name Resolution Ordner in Windows für Workgroups
- Q142309 NetBIOS Name Resolution using DNS and the HOSTS File
- Q163409 NetBIOS Suffixes (16th Character of the NetBIOS Name)
- Q163576 XGEN: Changing the RPC Binding Ordner
- Q173676 Client Cannot Resolve MX Record via Microsoft DNS Server
- Q225130 Verifying Name Records in WINS in Windows 2000
- 275278 DNS Server becomes an island when a domain controller points to itself für the _msdcs.ForestDnsName domain
- Q831609 How to Change the Method That Outlook 2003 uses to Resolve Server Names (FQDN oder NetBIOS)
- 837391 Exchange Server 2003 and Exchange 2000 Server require NetBIOS name resolution für full functionalityy
- Microsoft
White Paper zu DNS
ftp://ftp.Microsoft.com/bussys/winnt/winnt-docs/papers/dnswp.exe - Microsoft
DNS Installation Whitepaper
ftp://ftp.Microsoft.com/bussys/winnt/winnt-docs/papers/dnsinstall.exe - 153001 XFOR: DNS MX Records and CNAMEs
- Verwenden von NSLOOKUP
http://www.Microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/nslookup.mspx - So funktioniert DNS
http://www.linuxfibel.de/dns_srv.htm - DNS Step by Step
http://www.Microsoft.com/downloads/details.aspx?familyid=15D276A5-4BF6-4ADD-9F67-56B38CCB576B&displaylang=en - Wie sollte WINS konfiguriert werden?
http://www.faq-o-matic.net/content/view/102/44 - Exchange Extension 80004005 Error on Child Domain
http://untangible.com/2008/04/exchange-extension-80004005-error-on.html
Ein Grund mehr wieder WINS einzuführen.