DNS im Netzwerk

Dieser Artikel beschreibt die Nutzung von DNS in einem kleinen Netzwerk mit einer Domäne und Internetanbindung. Wenn Sie mehrere Domänen, redundante Internetanbindungen oder mehrere Subnetze nutzen, dann sind zusätzliche nicht beschriebene Einstellungen erforderlich.

Machen Sie sich mit dem Begriff "Split-DNS" bekannt. Die Konfiguration, bei der ihr interner Namensraum mit der offiziellen Domäne gleich ist, aber über getrennte Zonen bedient wird, ist mittlerweile angeraten. Nur so können URLs etc. sowohl intern als auch extern "gleich" bleiben aber mit passenden DNS-Einträgen auch entsprechend referenziert werden.

Achtung
Immer mehr offizielle Zertifizierungsstellen stellen keine Zertifikate mehr auf interne Namen aus !. Dies ist bei der Wahl der DNS-Namen für interne Server unbedingt zu berücksichtigen. Mein Ratschlag: SplitDNS oder Subdomäne aber nicht mehr ".local" oder ".intern"

Ein voll qualifizierter Hostname (FQDN) besteht aus einem Host-Teil und einem Domainteil. Der Host-Teil darf nicht länger als 64 Zeichen sein und sollte nur die Zeichen a-z, 0-9 und "-" enthalten. Alle anderen Zeichen können gehen, müssen aber nicht. So kann Lync keinen Pool mit einem "_" als Name nutzen, was Sie aber erst am Ende beim Zertifikatanfordern merken.

DNS, der Domain Name Service, ist eine wesentliche und oft unterschätzte Komponente in einem Netzwerk. DNS ist nicht nur dafür da, aus einem Rechnernamen eine IP-Adresse zu gewinnen, sondern hat viele Aufgaben, z.B.:

  • IP-Auflösung
    Um aus einem gegebenen Namen eine für den Rechner erreichbare IP-Adresse zu machen
  • Reverse Auflösung
    Um einer IP-Adresse einen sprechenden Namen zuzuordnen, z.B. bei Tracert oder bei der Rückwärtsauflösung von Mailservern (Spamschutz)
  • MX-Record
    Damit ein Mailserver seinen Kommunikationspartner für eine Domain finden kann
  • Active Directory SRV-Records
    Damit z.B. ein Exchange Server die globalen Kataloge findet (Mailrouting)
  • InstantMessaging Records
    Damit Office Communicator Clients ihren Server finden
  • Proxy Konfiguration
    In der Form eines WPad-Eintrags können Browser automatisch ihren Proxy Server finden.

Es ist daher wichtig, dass DNS in ihrem Netzwerk korrekt funktioniert. Sowohl Windows Clients, Server aber ins besondere auch Exchange benötigen DNS zur korrekten Funktion. Denn nur mittels DNS kann der Exchange Server korrekt den nächsten Globalen Katalog Server finden und Nachrichten routen.

Wahl des DNS-Namens

Wenn Sie das erste mal ein Active Directory installieren, dann werden Sie nach einen DNS-Namen gefragt. Hier haben Sie im wesentlichen vier Konzepte, von denen Sie sich für eines entscheiden müssen. Als Beispiel nutzen ich die MSXFAQ, welche den DNS-Namen "msxfaq.net" im Internet verwendet.

Name Beschreibung Bewertung

msxfaq.net

Offizielle Domain (SplitDNS)
Sie könnten ihr Active Directory genau so nennen wie ihre Internet Domäne, die Sie vermutlich schon haben. Allerdings sollten Sie dann nicht die gleichen DNS-Zone mit allen internen Servern und Diensten im Internet veröffentlichen. Das Mittel der Wahl ist hier dann ein "Split DNS"

msxfaq2.net

alternative offizielle Domain
Sie könnten eine zweite offizielle Domäne reservieren und nur intern nutzen, die sie besitzen aber nicht aktiv verwenden. Das machen einige Firmen, damit sie intern korrekte Namen verwenden. Wer weiß, wozu der Name später noch mal erforderlich ist. So tauchen die Namen ja auch im SMTP-Header auf und einige Spamfilter reagieren auf ungültige Namen.

ad.msxfaq.net

Sudomain der offiziellen Domain
Die ist eine Sonderform. Man nutzt einen offiziellen Namen und spart sich die Kosten einer zweiten Domain. Zudem erspart man sich per DNS-Forwarding den Aufwand der doppelpflege bei "SplitDNS".

msxfaq.local

"private" Domain
Sie könnten eine synthetische Domäne "firma.local" verwenden. Damit spart man das Geld für eine weitere Domain und bleibt sicher unerreicht. Aber ob das in Zeiten von VoIP, SIP etc. noch zweckmäßig ist ? Zudem werden sie Probleme bekommen, für interne Server ein offizielles Zertifikat von einer CA zu erhalten

msxfaq.

Single Label Domain
Sie könnten ganz auf eine Hierarchie verzichten und einfach den NT4 NetBIOS-Namen verwenden
BITTE MACHEN DIE DIES NICHT: ES NICHT SUPPORTET und nicht mit EXCHANGE 2007 kompatibel

Aus heutiger Sicht können kleine Firmen sicher den Ansatz nutzen, dass der interne DNS-Namen auch der externe Namen ist, da die offizielle Zone meist beim Provider gepflegt wird und damit die Trennung schon gegeben ist. Der Admin muss nur die externen Einträge manuell in der internen Zone pflegen (z.B. www.firma.tld), damit die eigene Webseite auch aus dem eigenen LAN erreichbar ist. Der Vorteil dabei ist zudem, dass sie Namen von Intern und Extern nicht ändern müssen (z.B. Outlook Web Access oder RPC/HTTP). Sie müssen aber immer alle externen Namen ihrer Domäne auch intern pflege, da der interne DNS-Server kein Forwarding zum Internet für ihre Domäne mehr macht

Die Nutzung einer eigenen offiziellen Domain für Intern ist für mittlere und große Firmen interessant, vor allem wenn viele Firmen unter einem Dach arbeiten. Die beiden letzten Optionen sind aus meiner Sicht nicht mehr sinnvoll anzuwenden.

Der Client im TCP/IP-Netz

Für den TCP/IP-Stack gibt es meist drei bzw. vier Dinge, die als IP-Adresse konfiguriert werden müssen und nicht über Namen eingetragen werden können

  • IP-Adresse mit Subnetz
  • Default Gateway
  • DNS und WINS-Server

Diese drei Parameter sind auf jedem PC statisch oder per DHCP zu pflegen. Das gibt genauso auch für einen Server, selbst wenn dieser selbst DNS-Server ist. Auch hier ist im einfachsten Fall dann eben 127.0.0.1 als DNS-Server einzutragen.

Das den meisten aber nicht so 100% klar ist, ist die genauer Funktion der Eintragungen im TCP/IP-Stack, da diese ja offensichtlich "pro Netzwerkkarte" eingetragen werden. Das bedeutet aber nicht, dass diese Eintragen "nur" für diese Netzwerkkarte gelten, sondern immer global sind.

Wenn Sie daher zwei Netzwerkkarten haben und in beiden unterschiedliche Default Gateways oder DNS-Server eintragen, dann bedeutet das für Windows, diese Werte alle zusammen zu fassen und immer abwechselnd die Adressen nutzt.

Windows nutzt den nächsten DNS-Server nicht, wenn der erste ein "Adresse nicht bekannt" liefert, sondern nur wenn der erste nicht antwortet. Es ist ein unterschied, ob ein Dienst nicht erreichbar ist (keine Antwort) oder mit einem "Nicht bekannt" antwortet

Daher ist es zwingend erforderlich, dass alle eingetragenen DNS-Server das gleiche wissen. Es ist demnach nicht sinnvoll, in den TCP/IP-Einstellungen den internen DNS-Server und den externen DNS-Server einzutragen.

Das gleiche gilt analog für den Eintrag des "Default Gateway". Da der Client nie wissen kann, hinter welchem Gateway das Ziel verborgen ist, sendet er abwechselnd die Daten zum einen und zum anderen Router. Nur wenn beide Router sich gegenseitig austauschen und ihre Leitwege können, können Sie dem Client dann per ICMP-Redirect das richtige Gateway nennen.

DNS und Redundanz

Wenn Sie daher den Ausfall ihres einzigen DNS-Servers absichern wollen, dann können Sie problemlos einen zweiten DNS-Server installieren. Wenn dies ebenfalls ein Windows 200x Server und Domänencontroller mit Active Directory integrierten Zonen ist, dann sind sogar die Zoneninformationen repliziert. Ansonsten müssen Sie manuell dafür sorgen, dass die Zonen repliziert werden. Achten Sie immer auf den Merksatz:

Alle von einem Client gefragten DNS Server müssen die gleichen Antworten zurück geben können.

Forwarder, Delegation und Root-DNS

Wenn ein Client nun einen DNS-Server befragt, dann liefert der DNS-Server die Antworten aus seiner lokalen Datenbank. Allerdings kann der DNS-Server natürlich nicht das gesamte Internet "kennen" und in seiner Datenbank vorhalten. Der DNS-Server kann daher nur die Informationen aus den Zonen liefern, die er selbst betreibt.

Fragt der Client jedoch Informationen nach, die der DNS-Server nicht hat, so hängt es nun von der Konfiguration des DNS-Servers ab, welche Antwort der Client bekommt. Drei Wege sind möglich:

  • Name existiert nicht
    Wenn der DNS-Server selbst keine Antwort liefern kann und auch nicht weiß, wie er an eine Antwort kommt, dann bekommt der Client eine "Name nicht auflösbar" und der Vorgang ist abgeschlossen
  • Verweis auf anderen DNS-Server
    Der DNS-Server kann den Client aber auch mitteilen, dass er selbst zwar keine Antwort weiß, aber der Client folgende andere DNS-Server fragen kann. Das bedeutet aber, dass der Client dann eine Verbindung zu den anderen DNS-Servern aufbauen muss.
  • Rekursive Antwort über Forwarder oder Root-Server
    Der weitaus häufigste Fall ist aber, dass der DNS-Server seinerseits andere DNS-Server fragt und die von dort erhaltene Antwort in den eigenen Cache übernimmt und an den Client zurück liefert. Dazu muss der DNS-Server entweder einen übergeordneten DNS-Server (Forwarder) fragen oder er befragt direkt die Root-Server.

Die Nutzung eines Forwarders ist dabei die häufigste und auch beste Konfiguration, da es nicht sinnvoll ist, gleich die Stammserver zu fragen, die den Server direkt wieder zu anderen DNS-Servern weiter leiten. In der Regel betreiben Provider entsprechende DNS-Server für ihre Kunden und diese haben sehr viele Antworten schon im Cache.

Hinweis:
Ein Windows DNS Server, der ROOT-Server ist, unterstützt keine "Conditional Forwarder". Bei BIND scheint so etwas möglich zu sein. Ein Root-Server nutzt stattdessen die Funktion der Delegierung von Zonen, um solche Anfragen auf andere DNS-Server zu verweisen anstatt selbst aufwändig weiter zu leiten.

DNS und Sicherheit

DNS ist sicher, wenn es die Server sind. Leider ist das erst in letzter Zeit besser umgesetzt worden, so dass bei falscher Konfiguration z.B.: folgende Dinge passieren können.

  • Cache Poisoning
    Wenn ein DNS-Server im Internet weiter Informationen erfragt, so gibt es bei einigen Servern das Problem, dass der angefragte Server nicht nur die gewünschte Antwort, sondern auch zusätzliche Antworten zurück liefern kann. Nicht alle DNS-Server verwerfen diese unerwünschten Pakete. So kann ein Angreifer falsche Informationen in den Cache einschleusen.
  • DNS als VPN-Tunnel
    Eine DNS-Anfrage erfragt einen Namen und bekommt eine IP-Adresse zurück. Es gibt Code, der sich genau diesen "Transport" zu nutze macht, um Informationen zu übertragen. Dazu ist ein einsprechend präparierter DNS-Servive im Internet erforderlich, der als Gegenstelle die Anfragen übernimmt. Der angefragte "Name" ist dabei die Nutzinformation. für einen Administrator fällt dies dann auf, wenn ein Client exzessiv viele DNS-Anfragen stellt. Programme wie NTOP können bei der Suche helfen.
  • DNS-Denial of Service
    Ein DNS-Server ist ein Dienst, der natürlich auch durch eine Vielzahl an Paketen überfordert werden kann. Einen echten Schutz dagegen gibt es leider nicht.
  • Falsche Dynamische Updates
    Systeme können sich auch selbst im DNS eintragen. diese dynamischen Updates funktionieren mit Windows 200x über eine sichere Authentifizierung (Computerkonto). Allerdings gibt es auch DNS-Server, die jedem System ein dynamisches Update erlauben. Das ist oft bei gemischten Umgebungen ein Problem.
    Die DNS-Server, welche Zonen für die Anfragen aus dem Internet halten, sollten keine anonymen dynamischen Updates erlauben.

So gibt es generell die Verfechter des Standpunkts, dass Client gar nicht direkt die Adressen im Internet auflösen müssen, sondern der Zugriff nur über Proxies und Relays zu erfolgen hat. Dann müssen nur diese Systeme die Adressen im Internet während die Clients nur interne Adressen auflösen können. Allerdings gibt es auch Dienste,  die über reines Web Surfen und Mail hinaus gehen und faktisch nur per NAT durchgelassen werden können. Dann ist wieder eine Auflösung durch den Client erforderlich.

Solange ein Client dann nicht direkt weniger vertrauenswürdige System im Internet befragen kann, sondern zwingend über die DNS-Server der mittels Forwarding gehen müssen, ist das Risiko reduziert.

Beispiele

Hier ein paar Beispiele für die möglichen Implementierungen von DNS-Auflösungen in verschiedenen Umgebungen. Auf eine Anbindung per ISDN und Wählleitung haben ich verzichtet, da hierbei viele DNS-Abfragen sehr schnell sehr teuer werden können und daher eine transparente Namensauflösung für alle Clients nach außen nicht sinnvoll ist. Hier ist dann besser mit einem Smarthost für den Mailversand und einem Proxyserver für Surfen zu arbeiten.

Szenario Beschreibung

Small Business mit NAT-Router

Die Clients fragen beide den einzigen DNS-Server im internen LAN.  Dieser DNS-Server beantwortet Anfragen an die  lokale Zone direkt und alle anderen Anfragen werden als Forwarder an den Router gestellt.  Der Router bekommt durch die Einwahl per DSL die IP-Adressen des Provider-DNS und agiert als DNS-Proxy.

Sollte der Router kein DNS-Proxy unterstützen, sollten Sie bei den internen DNS-Servern die Provider-DNS-Server eintragen und im Router den Zugriff auf dieses System per NAT erlauben. Wenn allerdings der Provider dann die IP-Adressen seiner DNS-Server einmal ändert, müssen Sie die Eintragungen in ihrem DNS-Server ebenfalls aktualisieren, damit die Auflösung wieder funktioniert.

Beachten Sie, dass der DNS-Server keinen Zugriff auf die Rootserver durchführt. Auch die Clients und andere internen Server sollten immer nur die internen DNS-Server fragen, damit sie auf jeden Fall Informationen bezüglich des Active Directory zuverlässig auflösen können.

Zwei Domaincontroller mit NAT-Router

Die Clients fragen beide internen DNS-Server im Wechsel. Die DNS-Server beantworten Anfragen an die  lokale Zone direkt und alle anderen Anfragen werden als Forwarder an den Router gestellt.  Der Router bekommt durch die Einwahl per DSL die IP-Adressen des Provider-DNS und agiert als DNS-Proxy.

Sollte der Router kein DNS-Proxy unterstützen, sollten Sie bei den internen DNS-Servern die Provider-DNS-Server eintragen und im Router den Zugriff auf dieses System per NAT erlauben. Wenn allerdings der Provider dann die IP-Adressen seiner DNS-Server einmal ändert, müssen Sie die Eintragungen in ihrem DNS-Server ebenfalls aktualisieren, damit die Auflösung wieder funktioniert.

Der gründe Pfeil bedeutet, dass beide internen DNS Server sich replizieren. Bei Active Directory integrierten Zonen ist dies durch das Active Directory gegeben. Ansonsten müssen Sie einen DNS-Server als "Primary" für die Zone bestimmen, in dem Sie die Zone pflegen und die Zone beim den zweiten Server als sekundäre Zone eintragen.

Beachten Sie, dass sich die DNS-Server nicht gegenseitig als Forwarder nutzen und keinen Zugriff auf die Rootserver durchführen. Auch die Clients und andere internen Server sollten immer nur die internen DNS-Server fragen, damit sie auf jeden Fall Informationen bezüglich des Active Directory zuverlässig auflösen können.

Standleitung mit eigenem offiziellen DNS-Server und Relay in einer DMZ

Solch eine Konfiguration erlaubt eine höhere Sicherheit, da der interne DNS-Server nicht mehr direkt Kontakt zu externen Servern steht, sondern ein DNS-Forwarder in einer DMZ dazwischen geschaltet ist.

Dieser DNS-Server können nun auch gleich als DNS-Server für eine Split-DNS-Konfiguration dienen, d.h. Sie könnten ihre eigenen offizielle Zone auf diesem DNS-Server pflegen und auf den internen Server die gleiche Zone für den internen Gebrauch betreiben.

Anbindung an eine Muttergesellschaf

Eine weitere Konstellation stellt den Betrieb als eigenständige untereinheit in einem Verbund da. Solche Umgebungen finden Sie nicht nur in multinationalen Konzernen sondern z.B.: auch in Universitäten, in denen Fachbereiche oder Institute eigenständige Strukturen aufbauen, aber DNS-Technisch unter dem Namensraum der Universität hängen.

  • Verfügbarkeit
    Auch hier sollte der Fachbereich natürlich die Verfügbarkeit seiner eigenen DNS-Server durch Redundanz sicherstellen.
  • Interne Auflösung zuerst
    Weiterhin sollten alle Systeme des Bereichs NUR die eigenen DNS-Server fragen. Ein häufiger Fehler ist das Eintragen von DNS-Servern der Mutter auf den Clients. Diese Server wissen meist nichts über den Fachbereich, was zu sporadischen Fehlern kommt.
  • Externe Auflösung durch Weiterleitung
    Die eigenen DNS-Server sollten nun Namen, die nicht lokal vorhanden sind, über eine Weiterleitung auflösen.
  • Replikation
    Man kann nun überlegen, ob am die Zonen anderer Fachbereiche oder der Mutter als sekundär auf die eigenen Server repliziert (Zustimmung ´der anderen Seite vorausgesetzt). Man könnte auch überlegen, die eigene DNS-Zone zu den DNS-Servern der Mutter replizieren zu lassen. Damit  würden "falsch" konfigurierte Clients, die zentral fragen, doch noch den Weg zu den eigenen Servern finden, auch wenn die Delegierung nicht korrekt erfolgt ist.

Einbindung eines Partners

Wird nun aber eine andere Domäne eines Partners oder Zulieferers eingebunden, so ist es meist notwendig, dass die internen Informationen Server und IP-Adressen über eine dedizierte Router oder VPN-Verbindung aufgelöst werden müssen. Hierzu gibt es mehrere mögliche Optionen:

  • Selektives Forwarding
    Ab Windows 2003 können Sie den DNS-Server derart konfigurieren, dass er für bestimmte Zonen einen bestimmten Forwarder nutzt und für alle anderen Adressen weiterhin ihren Internet Provider fragt.
  • Zonentransfer
    Alternativ könnten Sie ihren DNS-Server als sekundären Server für die Zone des Partnern einrichten. Der Partner muss den Transfer natürlich erlauben. Dann betrachtet ihr DNS-Server auch diese Zone als "lokal" und beantwortet Anfragen selbst und fragt nicht im Internet weiter nach.
  • Delegierung
    Als dritte Option könnten Sie die Zone des Partners bei sich eintragen und auf den DNS-Server des Partners verweisen lassen. Dann würden jedoch die Clients selbst auf den Partner-DNS-Server zugreifen. Diese Variante ist auch etwas aufwändiger einzurichten.
  • Aliaseinträge und Hosteinträge
    Sie könnten natürlich auch die ausgewählten fraglichen Server des Partners direkt in ihrem DNS als Eintrag führen und den Zugriff über ihren eigenen Namensraum erlauben.

Aber allein eine funktionierende Namensauflösung ist noch der Anfang für eine Zusammenarbeit.

Diese vier Beispiele sind natürlich nur eine Auswahl an möglichen Konfigurationsoptionen und sollen zur Erläuterung dienen. Missverstehen Sie diese Beispiele daher nicht als Empfehlungen für ihre Konfiguration. Wenn Sie sich unsicher sind, wie ihre DNS Auflösung ideal zu konfigurieren ist, sollten Sie sich entsprechende Unterstützung besorgen.

Fehlersuche mit NSLOOKUP und NETDIAG

Der erste Hilfsmittel zur Fehlersuche ist das Programm NSLOOKUP. Im Gegensatz zu PING und einigen anderen Programmen nutzt NSLOOKUP ausschließlich die konfigurierten oder vorgegebenen DNS-Server und ignoriert alle anderen Methoden der Namensauflösung, die Windows anbietet. Insbesondere WINS, Broadcasts und lokale LMHOSTS und HOSTS-Dateien können bei PING zu Erfolgsmeldungen führen, die mit NSLOOKUP aber entsprechend als Fehler erkannt werden. Wenn ihr DNS-Server korrekt konfiguriert ist, dann sollten folgende Aufrufe in einer DOS-Box auf jedem Client zu einem Ergebnis führen:

NSLOOKUP -querytype=MX msxfaq.de

NSLOOKUP www.msxfaq.de

Rufen Sie die Befehle ruhig mehrfach auf, denn wenn Sie mehrere DNS-Server haben, sollten alle Server Server eine Antwort liefern. Es kann aber sein, dass bei einer hohen Belastung der Leistung die ersten Anfragen noch nicht funktionieren.

Ein weiteres Hilfsmittel ist das Programm NETDIAG aus den Support Tools. Durch folgenden Aufruf erhalten Sie ehr genaue Informationen über die DNS-Konfiguration:

NETDIAG /TEST:DNS /DEBUG

Die Ausgabe (gekürzt) enthält dann sehr weit reichende Informationen zum DNS-Status ihres Servers oder ihrer Arbeitsstation.

C:\>NETDIAG /TEST:DNS /DEBUG

Gathering IPX configuration information.
Opening \Device\NwlnkIpx failed
Querying status of the Netcard drivers... Failed
Testing Domain membership... Passed
Gathering NetBT configuration information.
Testing DNS
PASS - All the DNS entries für DC are registered on DNS server '10.1.1.10'.

Tests complete.


Computer Name: SRV01
DNS Host Name: srv01.msxfaq.local
DNS Domain Name: msxfaq.local
System info : Microsoft Windows Server 2003 (Build 3790)
Processor : x86 Family 15 Model 2 Stepping 7, GenuineIntel
Hotfixes :
Installed? Name
Yes KB831464
Yes KB893803v2
Yes Q147222


Netcard queries test . . . . . . . : Failed

Information of Netcard drivers:

---------------------------------------------------------------------------
Description: Parallelanschluss (direkt)
Device: \DEVICE\{F1840E93-DDF0-4B8B-9B19-F9095C949A49}
GetStats failed für 'Parallelanschluss (direkt)'. [ERROR_NOT_SUPPORTED]
---------------------------------------------------------------------------
Description: WAN-Miniport (PPTP)
Device: \DEVICE\{97EFE0B2-D333-43ED-AD19-BA394C192D30}
GetStats failed für 'WAN-Miniport (PPTP)'. [ERROR_INVALID_FUNCTION]
---------------------------------------------------------------------------
Description: WAN-Miniport (PPPOE)
Device: \DEVICE\{9FE07AA5-1FC4-444B-9EA8-7A8FD68670B6}
GetStats failed für 'WAN-Miniport (PPPOE)'. [ERROR_INVALID_FUNCTION]
---------------------------------------------------------------------------
Description: WAN-Miniport (IP)
Device: \DEVICE\NDISWANIP
GetStats failed für 'WAN-Miniport (IP)'. [ERROR_INVALID_FUNCTION]
---------------------------------------------------------------------------
Description: WAN-Miniport (Netzwerkmonitor)
Device: \DEVICE\NDISWANBH
GetStats failed für 'WAN-Miniport (Netzwerkmonitor)'. [ERROR_INVALID_FUNCTION]
---------------------------------------------------------------------------
Description: WAN-Miniport (L2TP)
Device: \DEVICE\{C59852EA-E890-49F3-8894-7A3A392BDB54}
GetStats failed für 'WAN-Miniport (L2TP)'. [ERROR_NOT_SUPPORTED]
---------------------------------------------------------------------------
Description: Intel 21140-basierter PCI-Fast Ethernet-Adapter (Standard)
Device: \DEVICE\{153A76FE-C305-4BD3-9C4E-6B62DEFBE7A1}
GetStats failed für 'Intel 21140-basierter PCI-Fast Ethernet-Adapter (Standard)'. [ERROR_INVALID_FUNCTION]
---------------------------------------------------------------------------
[FATAL] - None of the netcard drivers provided satisfactory results.

Per interface results:
Adapter : LAN 10.1.1.10
Adapter ID . . . . . . . . : {153A76FE-C305-4BD3-9C4E-6B62DEFBE7A1}

Netcard queries test . . . : Failed
NetCard Status: uNKNOWN

Global results:

Domain membership test . . . . : Passed
Machine is a . . . . . . . . . : primäry Domain Controller Emulator
NetBIOS Domain name. . . . . . : MSXFAQ
Dns domain name. . . . . . . . : msxfaq.local
Dns forest name. . . . . . . . : msxfaq.local
Domain Guid. . . . . . . . . . : {71614A43-EA64-48BF-9722-73BD9DB4AA67}
Domain Sid . . . . . . . . . . : S-1-5-21-3830009233-4121518305-2830858423
Logon User . . . . . . . . . . : Administrator
Logon Domain . . . . . . . . . : MSXFAQ


NetBT transports test. . . . . . . : Passed
List of NetBt transports currently configured:
NetBT_Tcpip_{153A76FE-C305-4BD3-9C4E-6B62DEFBE7A1}
1 NetBt transport currently configured.

DNS test . . . . . . . . . . . . . : Passed
Interface {153A76FE-C305-4BD3-9C4E-6B62DEFBE7A1}
DNS Domain:
DNS Servers: 10.1.1.10
IP Address: Expected registration with PDN (primary DNS domain n
ame):
Hostname: srv01.msxfaq.local.
Authoritative zone: msxfaq.local.
Primary DNS server: srv01.msxfaq.local 10.1.1.10
Authoritative NS:10.1.1.10
Check the DNS registration für DCs entries on DNS server '10.1.1.10'

********** * ********** * ********** * ********** * ********** *
* CHECK NAME _ldap._tcp.msxfaq.local. on DNS server 10.1.1.10
********** * ********** * ********** * ********** * ********** *

The Record is correct on DNS server '10.1.1.10'.

********** * ********** * ********** * ********** * ********** *
* CHECK NAME _ldap._tcp.Standardname-des-ersten-Standorts._sites.msxfaq.local. o
n DNS server 10.1.1.10
********** * ********** * ********** * ********** * ********** *

The Record is correct on DNS server '10.1.1.10'.

********** * ********** * ********** * ********** * ********** *
* CHECK NAME _ldap._tcp.pdc._msdcs.msxfaq.local. on DNS server 10.1.1.10
********** * ********** * ********** * ********** * ********** *

The Record is correct on DNS server '10.1.1.10'.

********** * ********** * ********** * ********** * ********** *
* CHECK NAME _ldap._tcp.gc._msdcs.msxfaq.local. on DNS server 10.1.1.10
********** * ********** * ********** * ********** * ********** *

The Record is correct on DNS server '10.1.1.10'.

********** * ********** * ********** * ********** * ********** *
* CHECK NAME _ldap._tcp.Standardname-des-ersten-Standorts._sites.gc._msdcs.msxfa
q.local. on DNS server 10.1.1.10
********** * ********** * ********** * ********** * ********** *

The Record is correct on DNS server '10.1.1.10'.

********** * ********** * ********** * ********** * ********** *
* CHECK NAME _ldap._tcp.71614a43-ea64-48bf-9722-73bd9db4aa67.domains._msdcs.msxf
aq.local. on DNS server 10.1.1.10
********** * ********** * ********** * ********** * ********** *

The Record is correct on DNS server '10.1.1.10'.

********** * ********** * ********** * ********** * ********** *
* CHECK NAME 3eca2305-16ac-49bf-9ecd-65c8afeb56f0._msdcs.msxfaq.local. on DNS se
rver 10.1.1.10
********** * ********** * ********** * ********** * ********** *

The Record is correct on DNS server '10.1.1.10'.

********** * ********** * ********** * ********** * ********** *
* CHECK NAME _kerberos._tcp.dc._msdcs.msxfaq.local. on DNS server 10.1.1.10
********** * ********** * ********** * ********** * ********** *

The Record is correct on DNS server '10.1.1.10'.

********* * ********** * ********** * ********** * ********** *
** CHECK NAME _kerberos._tcp.Standardname-des-ersten-Standorts._sites.dc._msdcs.m
sxfaq.local. on DNS server 10.1.1.10
********** * ********** * ********** * ********** * ********** *

The Record is correct on DNS server '10.1.1.10'.

********** * ********** * ********** * ********** * ********** *
* CHECK NAME _ldap._tcp.dc._msdcs.msxfaq.local. on DNS server 10.1.1.10
********** * ********** * ********** * ********** * ********** *

The Record is correct on DNS server '10.1.1.10'.

********** * ********** * ********** * ********** * ********** *
* CHECK NAME _ldap._tcp.Standardname-des-ersten-Standorts._sites.dc._msdcs.msxfa
q.local. on DNS server 10.1.1.10
********** * ********** * ********** * ********** * ********** *

The Record is correct on DNS server '10.1.1.10'.

********** * ********** * ********** * ********** * ********** *
* CHECK NAME _kerberos._tcp.msxfaq.local. on DNS server 10.1.1.10
********** * ********** * ********** * ********** * ********** *

The Record is correct on DNS server '10.1.1.10'.

********** * ********** * ********** * ********** * ********** *
* CHECK NAME _kerberos._tcp.Standardname-des-ersten-Standorts._sites.msxfaq.loca
l. on DNS server 10.1.1.10
********** * ********** * ********** * ********** * ********** *

The Record is correct on DNS server '10.1.1.10'.

********** * ********** * ********** * ********** * ********** *
* CHECK NAME _gc._tcp.msxfaq.local. on DNS server 10.1.1.10
********** * ********** * ********** * ********** * ********** *

The Record is correct on DNS server '10.1.1.10'.


********** * ********** * ********** * ********** * ********** *
* CHECK NAME _gc._tcp.Standardname-des-ersten-Standorts._sites.msxfaq.local. on
DNS server 10.1.1.10
********** * ********** * ********** * ********** * ********** *

The Record is correct on DNS server '10.1.1.10'.


********** * ********** * ********** * ********** * ********** *
* CHECK NAME _kerberos._udp.msxfaq.local. on DNS server 10.1.1.10
********** * ********** * ********** * ********** * ********** *

The Record is correct on DNS server '10.1.1.10'.

********** * ********** * ********** * ********** * ********** *
* CHECK NAME _kpasswd._tcp.msxfaq.local. on DNS server 10.1.1.10
********** * ********** * ********** * ********** * ********** *

The Record is correct on DNS server '10.1.1.10'.

********** * ********** * ********** * ********** * ********** *
* CHECK NAME _kpasswd._udp.msxfaq.local. on DNS server 10.1.1.10
********** * ********** * ********** * ********** * ********** *

The Record is correct on DNS server '10.1.1.10'.

********** * ********** * ********** * ********** * ********** *
* CHECK NAME _ldap._tcp.DomainDnsZones.msxfaq.local. on DNS server 10.1.1.10
********** * ********** * ********** * ********** * ********** *

The Record is correct on DNS server '10.1.1.10'.

********** * ********** * ********** * ********** * ********** *
* CHECK NAME _ldap._tcp.Standardname-des-ersten-Standorts._sites.DomainDnsZones.
msxfaq.local. on DNS server 10.1.1.10
********** * ********** * ********** * ********** * ********** *

The Record is correct on DNS server '10.1.1.10'.

********** * ********** * ********** * ********** * ********** *
* CHECK NAME _ldap._tcp.ForestDnsZones.msxfaq.local. on DNS server 10.1.1.10
********** * ********** * ********** * ********** * ********** *

The Record is correct on DNS server '10.1.1.10'.

********** * ********** * ********** * ********** * ********** *
* CHECK NAME _ldap._tcp.Standardname-des-ersten-Standorts._sites.ForestDnsZones.
msxfaq.local. on DNS server 10.1.1.10
********** * ********** * ********** * ********** * ********** *

The Record is correct on DNS server '10.1.1.10'.

********** * ********** * ********** * ********** * ********** *
* CHECK NAME msxfaq.local. on DNS server 10.1.1.10
********** * ********** * ********** * ********** * ********** *

The Record is correct on DNS server '10.1.1.10'.

********** * ********** * ********** * ********** * ********** *
* CHECK NAME gc._msdcs.msxfaq.local. on DNS server 10.1.1.10
********** * ********** * ********** * ********** * ********** *

The Record is correct on DNS server '10.1.1.10'.

********** * ********** * ********** * ********** * ********** *
* CHECK NAME DomainDnsZones.msxfaq.local. on DNS server 10.1.1.10
********** * ********** * ********** * ********** * ********** *

The Record is correct on DNS server '10.1.1.10'.

********** * ********** * ********** * ********** * ********** *
* CHECK NAME ForestDnsZones.msxfaq.local. on DNS server 10.1.1.10
********** * ********** * ********** * ********** * ********** *

The Record is correct on DNS server '10.1.1.10'.

** ** Check DC DNS NAME FINAL RESULT ** **
PASS - All the DNS entries für DC are registered on DNS server '10.1.1.10'.

The command completed successfully

C:\>

Wichtig ist das "PASS" am Ende der Analyse. Hier habe ich die Funktion auf einem DC ausgeführt, der natürlich eine entsprechende Anzahl von DNS-Einträgen zu prüfen hat.

DNS Alterung (Scavening)

In der Standardeinstellung erlaubt ein Windows 200x DNS-Server sichere dynamische Updates, d.h. ein Client kann sich selbst nach einer Authentifizierung eintragen und auch wieder löschen. Nur kommt er oft nicht zum Löschen, wenn z.B. die Netzwerkverbindung abreißt oder der PC einfach abgeschaltet wird. Also sammeln sich im DNS-Server nach und nach alte Einträge. In Verbindung mit DHCP kann es sogar sein, dass der PC später eine neue IP-Adresse bekommt und ein andere PC die alte Adresse nutzt. Eine Verbindung zu einem PC kann daher auf einem anderen PC landen. Das stört besonders bei der Fernwartung durch den Helpdesk. Also steht Aufräumen an. Entsprechende Hinweise von Microsoft helfen bei der Konfiguration.

Man muss vor allem auf dem Server die Funktion aktivieren und dann pro Zone auch noch mal die individuellen Einstellungen pflegen.

DNS Scaveing pro Zone Einstellungen auf dem Server

Beachten Sie:

Scavening löscht Server
Die Aufräumfunktion basiert nicht auf dem Alter des DNS-Eintrags, sondern dem Alter des Timestamps und je nach Konfiguration der Clients und DHCP-Einstellungen kann eine Fehlkonfiguration dazu führen, dass aktive Einträge entfernt werden!

Daher sind zwei Werte unter "Veraltete Ressourceneinträge aufräumen" wichtig, die in der Onlinehilfe und Doku aus meiner Sicht nicht deutlich genug das Thema beschreiben:

  • Intervall für Nichtaktualisierung (Standard: 7 Tage)
    Client können ihre eigenen DNS-Einträge natürlich auch "öfter" aktualisieren. Allerdings kann ich über diesen Wert steuern, welche Mindestzeit vergehen muss, bis ein Client den Timestamp neu schreiben darf. Da so eine Update des Timestamp bei AD-integrierten Zonen auch eine AD-Replikation auslöst, kann ich als Admin damit übereifrige Clients Ausbremsen. Das bedeutet aber auch, dass ein Timestamp selbst eines aktiven Clients immer bis zu dieser Zeit alt sein.
  • Aktualisierungsintervall (Standard: 7 Tage)
    Dies ist die Zeit, nach der der DNS-Server einen Eintrag dann letztlich löscht. Auch hier ist wieder der Timestamp maßgeblich. Wer hier eine kürzere Zeit als beim ersten Wert einträgt, darf sich nicht wundern, wenn aktive Server plötzlich im DNS nicht mehr erscheinen.

Ehe Sie nun die beiden Werte auf 30min und 31 min setzen, sollten Sie wissen, wie oft ein Client überhaupt eine DNS-Aktualisierung versucht. Die Werte sind die Defaults für die unterschiedlichen Teilbereiche:

Dienst Beschreibung Intervall

Netlogon

Der Windows Anmeldedienst registriert damit speziell auf Domain Controllern die Einträge zu LDAP, GC, Kerberos

24 Stunden

Cluster

Auch der Windows Cluster Dienst aktualisiert die Einträge der virtuellen Server

24 Stunden

DHCP-Client

Auf jedem System gibt es den DHCP-Client-Dienst, welcher auf Systemen mit vorgegebener IP-Adresse aktiv ist und für die Registrierung der DNS-Namen sorgt.
Bei dynamisch vergebener IP-Adresse wird das Intervall der DHCP-Lease-Zeit angepasst

24 Stunden oder halbe DHCP-Leasedauer

DHCP-Server

Alte Clients, die sich nicht selbst im DNS eintragen können, werden stellvertretend durch den DHCP-Server auf dem DNS-Server eingetragen. Auch hier richtet sich die Zeit nach dem DHCP-Lease

halbe DHCP-Leasedauer

Sie sehen also, dass die beiden Zeiten auf keinen Fall kleiner 24h sein dürfen. Ein sauber beendeter Client trägt sich natürlich aus dem DNS-Server aus. Nur Systeme, die beim Shutdown keine Verbindung mehr zum DNS-Server hatten, bleiben damit als Leichen zurück.

Sie können in den Zonen aber gerne die beiden Zeiten pflegen. Aktiv werden diese erst über einen Kommandozeile oder die Aktivierung auf dem Server.

dnscmd ServerName /StartScavenging

Manuelle Aktionen

Wem das alles zu viel Arbeit oder zu viel "Unsicherheit" ist, dem kann mit dem VBScript DNSAge geholfen werden. Dieses Skript nutzt WMI, um das Alter der verschiedenen Einträge zu ermitteln und anzuzeigen. Wer mag, kann diese damit dann auch gleich löschen lassen.

Aber auch ohne den Löschbefehl können Sie so alte Systeme recht einfach identifizieren. Sie nutzen die Zeit aus dem Parameter "Intervall für Nichtaktualisierung " und addieren z.B. 24h oder die halbe DHCP-Lease-Dauer von Clients mit dynamischen Adressen hinzu und filtern dann auf alle Einträge die älter als diese zeit sind.

DNS im AD

Wenn Sie DNS-Zonen im Active Directory ablegen, dann haben Sie bei der Konfiguration die Wahl, ob die Zonen im Forst oder in der Domäne liegen. Diese Wahl steuert nicht nur, welche Active Directory Partition die Daten vorhält, sondern damit auch wie weit die Daten repliziert werden und welche DCs die Zoneninformation vorliegen haben. Eine Ablage in der Domäne macht eine Zone auch nur für DCs in dieser Domäne direkt erreichbar und veränderbar. Wenn Sie also mehrere Domänen und Zonen betreiben müssen Sie über die DNS Hierarchie, Delegation, Forwarder und Secondary Server sicherstellen, dass alle Server alle Namen auflösen können.

Eine Ablage als Forest-Zone bedeutet, dass alle DNS-Server auf DCs diese Zone lesen und schreiben können und dass diese natürlich als Bestandteil der "Confioguration"-Partition auch auf alle DCs repliziert wird. Die Objekte sind per ADSIEDIT sehr einfach zu finden.

Fokus DN ADSIEdit

Windows 2000 Domain Zone
Die DNS-Zone ist Teil der Domain Zone

DC=<zonenname>,CN=MicrosoftDNS,CN=System,dc=<domain>

Windows 2003 und höher Domain
Die DNS-Zonen ist eine eigene AD Partition

DC=<zonenname>,CN=MicrosoftDNS,DC=DomainDnsZones,dc=<domain>

Windows Forestzone
Die DNS-Zonen liegen in der Forest Partition

DC=<zonenname>,CN=MicrosoftDNS, DC=ForestDnsZone,dc=<rootdomain>

In dem jeweiligen Container liegen dann die Elemente vom Typ "DnsNode"

Die "Nutzdaten" liegen dann aber in einem binäre codierten Feld "dnsRecord"

Die Daten im DNSRecord-Feld sind leider nicht komplett offen gelegt. Eine Teilbeschreibung finden sie in

[MS-DNSP] Domain Name Service (DNS) Server Management Protocol Specification
http://download.microsoft.com/download/9/5/E/95EF66AF-9026-4BB0-A41D-A4F81802D92C/[MS-DNSP].pdf
Kapitel 2.3.2.2 DNSRecord

Damit nun ein DNS-Server nicht für jede DNS-Abfrage direkt eine AD-Abfrage starten muss, hält jeder DNS-Server einen Cache vor, in dem er sich die Antworten zwischenpuffert. Das führt natürlich dazu, dass Änderungen an den AD-Einträgen nicht sofort auch durch den DNS-Server gesehen werden. Hier hilft es dann den DNS-Service neu zu starten oder zumindest die Zone neu zu laden:

Ein weiterer Aspekt ist natürlich das Thema "löschen", wie ich auch schon unter DNS Alterung beschrieben habe. Wenn ein Computer sich neu registriert, wird bei einer AD-Integrierten Zone ein neues Objekt im AD angelegt. Meldet sich der Computer ordnungsgemäß ab, wird der DNS-Eintrag wieder gelöscht. Dies kann sogar mehrfach pro Tag (Reboots etc.) erfolgen. Im Hinblick auf "Deleted Objects" im Active Directory ist dies natürlich nicht empfehlenswert. Daher werden DNS-Objekte nicht sofort im AD gelöscht, sondern neben der normalen Verfallszeit erst einmal als DNSTombstoned markiert und ein weiterer Prozess löscht Die Elemente später auch aus dem Active Directory, womit sie aber immer noch "wiederherstellbar" sind. Hier die Kette der Stati

Zwischen "Aktiv" und "DNSTombstone" ist ein Wechsel über den DNS-Server möglich. Beachten Sie aber, dass nicht nur das Attribut "dnsTombStone" gesetzt und gelöscht wird, sondern auch den "dnsRecord". Auch wenn daher ein wirklich gelöschtes Objekt aus dem Windows 2008R2 Dumpster oder sogar aus DeletedObjects wieder geholt werden kann und Sie das Feld "DNSTombstoned" wieder auf False setzen, hilft ihnen das nicht weiter, weil das Feld "dnsRecord" weiterhin falsche Daten enthält und der DNS-Server diesen Eintrag ignoriert. Sie erhalten also maximal den Namen des DNS-Eintrags,der nicht mehr vorhanden sind. Wenn Sie früher vielleicht einen Export der DNS-Einträge gemacht haben (LDIFDE/CSVDE und Taskplaner helfen), dann können Sie das vorhandene Elemente mit dem Wert "DNSTombstoned=TRUE" löschen und das komplette funktionierende Objekt von früher wieder herstellen. Bedenken Sie aber auch dann wieder AD-Replikation, DNS Zonencache und DNS Clientcache. Die Änderungen werden also nicht sofort aktiv.

Häufige Fehler

Um die Funktion von DNS deutlich zu machen,

  • Verschiedene DNS-Server im Client
    Es ist nicht erlaubt, auf dem Client sowohl den internen DNS-Server als auch einen externen DNS-Server einzutragen. Der Client würde wechselseitig fragen und eine Auflösung würde mal gehen und mal nicht gehen, da der externe Server keine Informationen über das interne Active Directory haben sollte und umgekehrt.
  • Forwarder auf "fremden" DNS-Server
    Wer nicht die ROOT-Server fragen will, sollte nicht irgendwelche anderen DNS-Server in der Welt fragen, die in verschiedenen Newsgroups oder Webseiten genannt werden. Zum einen sind diese nicht immer vertrauenswürdig und könnten ihre Anfragen auf eine ganz falsche IP-Adressen lenken. Zum anderen sind diese netztechnisch oft ebenso schlecht zu erreichen
    Die einzigen Forwarder, die sie eintragen sollten, sind die DNS-Server ihres Providers, die ihnen dieser sicher gerne nenne. Schließlich spart auch der Provider Datenverkehr zu den Rootservern, wenn er ihre Frage aus seinem Cache beantworten kann. Und schneller ist es allemal.
  • Verkreuzte Forwarder
    DNS ist eine Baumstruktur und so sollten Sie auch die Forwarder eintragen. Der Forwarder sollte immer mehr und alles auflösen können als ihr eigener DNS-Server. Es ist nicht nützlich, wenn Sie zwei DNS-Server haben, die sich gegenseitig als Forwarder befragen.

Weitere Links