Ermitteln der DNS-Anforderungen

Konfigurieren von Split-Brain-DNS mit Lync Server 2010

Wie bei der Netzwerkadressenübersetzung (Network Address Translation, NAT) gibt es auch für den Begriff "Split-Brain-DNS" unterschiedliche Definitionen. In diesem Dokument hat der Begriff "Split-Brain-DNS" folgende Bedeutung: die DNS-Zone für einen Namespace ist in der internen und in der externen DNS-Konfiguration identisch. Eine Vielzahl der DNS-SRV- und DNS-A-Einträge in der internen DNS-Konfiguration sind jedoch nicht in der externen DNS-Konfiguration enthalten und umgekehrt. Und in Fällen, in denen ein DNS-Eintrag sowohl in der internen als auch in der externen DNS-Konfiguration vorhanden ist (z. B. "www.contoso.com"), werden abhängig vom Ursprung der DNS-Abfrage unterschiedliche IP-Adressen zurückgegeben.

Wenn Sie Split-Brain-DNS konfigurieren, umfassen die folgenden internen und externen Zonen eine Übersicht über die Typen von DNS-Einträgen, die in jeder Zone erforderlich sind. Ausführliche Informationen finden Sie unter Referenzarchitektur.

Interne DNS-Konfiguration:

• Enthält eine DNS-Zone "contoso.com", für die die DNS-Konfiguration autoritativ ist

• Die interne Zone "contoso.com" umfasst Folgendes:

  • DNS-A- und DNS-SRV-Einträge für die automatische Microsoft Lync Server 2010-Clientkonfiguration (optional)

  • DNS-A- oder DNS-CNAME-Einträge für die automatische Ermittlung von Lync Server-Webdiensten

  • DNS-A- und DNS-SRV-Einträge für alle internen Server mit Lync Server 2010 im Unternehmensnetzwerk

  • DNS-A- und SRV-Einträge für die interne Edgeschnittstelle der einzelnen Lync Server 2010-Edgeserver im Umkreisnetzwerk

  • DNS-A-Einträge für die interne Schnittstelle der einzelnen Reverseproxyserver im Umkreisnetzwerk

  • Sämtliche Lync Server 2010-Edgeserver im Umkreisnetzwerk zeigen auf die internen DNS-Server, um die Abfragen an "contoso.com" aufzulösen

  • Sämtliche Server mit Lync Server 2010 und Clients mit Lync 2010 im Unternehmensnetzwerk zeigen auf die internen DNS-Server, um die Abfragen an "contoso.com" aufzulösen

Externe DNS-Konfiguration:

• Enthält eine DNS-Zone "contoso.com", für die die DNS-Konfiguration autoritativ ist

• Die externe Zone "contoso.com" umfasst Folgendes:

  • DNS-A- und DNS-SRV-Einträge für die automatische Lync Server 2010-Clientkonfiguration (optional)

  • DNS-A- oder DNS-CNAME-Einträge für die automatische Ermittlung von Lync Server-Webdiensten

  • DNS-A- und SRV-Einträge für die externe Edgeschnittstelle der einzelnen Lync Server 2010-Edgeserver oder virtuellen IP-Adressen der Hardwaregeräte zum Lastenausgleich im Umkreisnetzwerk

  • DNS-A-Einträge für die externe Schnittstelle der einzelnen Reverseproxyserver im Umkreisnetzwerk

Ermitteln von Diensten auf Clients, auf denen Microsoft Lync 2010 ausgeführt wird

Beim DNS-Lookup werden SRV-Einträge parallel abgefragt und in der folgenden Reihenfolge an den Client zurückgegeben (falls konfiguriert und verfügbar):

1. _sipinternaltls._tcp.<Domäne> – für interne TLS-Verbindungen

2. _sipinternal._tcp. <Domäne> – für interne TCP-Verbindungen (sofern TCP zulässig ist)

3. _sip._tls. <Domäne> – für externe TLS-Verbindungen

4. _sip._tcp. <Domäne> – für externe TCP-Verbindungen (sofern TCP zulässig ist)

Wobei <Domäne> die von den internen Clients verwendete SIP-Domäne ist. Die letzten zwei Abfragen werden für Clients ausgeführt, die sich von außerhalb des internen Netzwerks verbinden. Beim Erstellen von SRV-Einträgen muss berücksichtigt werden, dass die Einträge auf einen DNS-A-Eintrag in derselben Domäne zeigen, in welcher der DNS-SRV-Eintrag erstellt wird. Wenn sich der SRV-Eintrag z. B. in der Domäne "contoso.com" befindet, kann sich der DNS-A-Eintrag, auf den er zeigt, nicht in der Domäne "fabrikam.com" befinden. Stattdessen muss sich dieser Eintrag ebenfalls in der Domäne "contoso.com" befinden.

Bei Ihrer erstmaligen Anmeldung versucht der Client, auf dem Lync ausgeführt wird, unter Verwendung jedes der drei SRV-Einträge in der entsprechenden Reihenfolge eine Verbindung mit einem Front-End-Pool herzustellen. Dabei spielt es keine Rolle, ob Sie sich von innerhalb oder außerhalb Ihres Netzwerks anmelden. Nachdem der Client, auf dem Lync ausgeführt wird, erfolgreich eine Verbindung herstellen konnte, speichert er den DNS-Eintrag im Zwischenspeicher und verwendet diesen Eintrag, bis keine Verbindung mehr hergestellt werden kann. Wenn der Client, auf dem Lync ausgeführt wird, den zwischengespeicherten Wert nicht verwenden kann, führt er eine neue DNS-Abfrage zum Ermitteln der SRV-Einträge aus und füllt den Zwischenspeicher erneut. Dieser Prozess findet beispielsweise statt, wenn Sie sich tagsüber beim internen Netzwerk angemeldet haben und sich abends über Ihr Laptop extern von zuhause aus anmelden.

Nachdem der SRV-Eintrag zurückgegeben wurde, wird der DNS-A-Eintrag (nach FQDN) des Servers oder Front-End-Pools abgefragt, der dem SRV-Eintrag zugeordnet ist. Wenn bei der DNS-SRV-Abfrage keine Einträge ermittelt werden, führt der Lync-Client eine explizite Suche nach "sipinternal.<Domäne>" aus. Falls auch die explizite Suche keine Ergebnisse bringt, sucht der Lync-Client nach "sip.<Domäne>".

Automatische Konfiguration ohne Split-Brain-DNS

Bei Verwendung von Split-Brain-DNS kann ein Lync Server 2010-Benutzer, der sich intern anmeldet, die automatische Konfiguration nutzen, wenn die interne DNS-Zone einen SRV-Eintrag "_sipinternaltls._tcp" für jede verwendete SIP-Domäne umfasst. Wenn Sie jedoch kein Split-Brain-DNS verwenden, ist die interne automatische Konfiguration von Clients, auf denen Lync ausgeführt wird, nur funktionsfähig, wenn Sie eine der weiter unten in diesem Abschnitt beschriebenen Problemumgehungen implementieren. Der Grund dafür ist, dass Lync Server 2010 den SIP-URI des Benutzers für den Abgleich der Domäne des Front-End-Pools benötigt, der für die automatische Konfiguration vorgesehen ist. Diese Anforderung muss auch in früheren Versionen von Communicator erfüllt werden.

Wenn Sie z. B. zwei SIP-Domänen verwenden, sind die zwei folgenden DNS-SRV-Einträge erforderlich:

• Wenn sich ein Benutzer als "lstest01@contoso.com" anmeldet, kann der folgende SRV-Eintrag für die automatische Konfiguration verwendet werden, da die SIP-Domäne des Benutzers (contoso.com) mit der Domäne des Front-End-Pools für die automatische Konfiguration übereinstimmt:

   _sipinternaltls._tcp.contoso.com. 86400 IN SRV 0 0 5061 pool01.contoso.com

• Wenn sich ein Benutzer als "lstest01@fabrikam.com" anmeldet, kann der folgende DNS-SRV-Eintrag für die automatische Konfiguration der zweiten SIP-Domäne verwendet werden.

   _sipinternaltls._tcp.fabrikam.com. 86400 IN SRV 0 0 5061 pool01.fabrikam.com

Zum Vergleich: wenn sich ein Benutzer als "lstest01@litwareinc.com" anmeldet, kann der folgende DNS-SRV-Eintrag nicht für die automatische Konfiguration verwendet werden, da die SIP-Domäne des Clients (litwareinc.com) nicht mit der Domäne des Pools (fabrikam.com) übereinstimmt:

 _sipinternaltls._tcp.litwareinc.com. 86400 IN SRV 0 0 5061 pool01.fabrikam.com

Wenn für Clients, auf denen Lync ausgeführt wird, die automatische Konfiguration erforderlich ist, wählen Sie eine der folgenden Optionen aus:

• Gruppenrichtlinienobjekte   Verwenden Sie Gruppenrichtlinienobjekte zum Auffüllen der richtigen Serverwerte.

  Hinweis:
  Mit dieser Option wird die automatische Konfiguration nicht aktiviert, der Prozess der manuellen Konfiguration wird jedoch automatisiert. Daher werden die SRV-Einträge für die automatische Konfiguration bei Verwendung dieses Ansatzes nicht benötigt.

• Übereinstimmende interne Zone   Erstellen Sie eine interne DNS-Zone, die mit der externen DNS-Zone übereinstimmt (z. B. "contoso.com"), sowie DNS-A-Einträge für den Lync Server 2010-Pool, der für die automatische Konfiguration verwendet wird. Beispiel: wenn ein Benutzer in "pool01.contoso.net" verwaltet wird, sich jedoch als "lstest01@contoso.com" bei Lync anmeldet, erstellen Sie eine interne DNS-Zone "contoso.com" und in dieser Zone einen DNS-A-Eintrag für "pool01.contoso.com".

• Interne dedizierte Zone   Wenn die Erstellung einer vollständigen internen DNS-Zone nicht möglich ist, können Sie dedizierte Zonen erstellen, die den für die automatische Konfiguration erforderlichen SRV-Einträgen entsprechen. Anschließend füllen Sie diese Zonen mithilfe von "dnscmd.exe" auf. "Dnscmd.exe" wird benötigt, da die Benutzeroberfläche für DNS das Erstellen von dedizierten Zonen nicht unterstützt. Beispiel: wenn die SIP-Domäne "contoso.com" lautet und Sie über einen Front-End-Pool "pool01" mit zwei Front-End-Servern verfügen, benötigen Sie die folgenden dedizierten Zonen und DNS-A-Einträge in Ihrem internen DNS:

  dnscmd . /zoneadd _sipinternaltls._tcp.contoso.com. /dsprimary
  dnscmd . /recordadd _sipinternaltls._tcp.contoso.com. @ SRV 0 0 5061 pool01.contoso.com.
  dnscmd . /zoneadd pool01.contoso.com. /dsprimary
  dnscmd . /recordadd pool01.contoso.com. @ A 192.168.10.90
  dnscmd . /recordadd pool01.contoso.com. @ A 192.168.10.91
  

  Wenn Ihre Umgebung eine zweite SIP-Domäne (z. B. "fabrikam.com") umfasst, benötigen Sie die folgenden dedizierten Zonen und DNS-A-Einträge in Ihrem internen DNS:

  dnscmd . /zoneadd _sipinternaltls._tcp.fabrikam.com. /dsprimary
  dnscmd . /recordadd _sipinternaltls._tcp.fabrikam.com. @ SRV 0 0 5061 pool01.fabrikam.com.
  dnscmd . /zoneadd pool01.fabrikam.com. /dsprimary
  dnscmd . /recordadd pool01.fabrikam.com. @ A 192.168.10.90
  dnscmd . /recordadd pool01.fabrikam.com. @ A 192.168.10.91
  

Hinweis:

Der FQDN des Front-End-Pools wird zweimal aufgeführt, jedoch mit unterschiedlichen IP-Adressen. Der Grund dafür ist, dass ein DNS-Lastenausgleich verwendet wird. Bei Verwendung von Hardwarelastenausgleich wäre nur ein einzelner Front-End-Pool-Eintrag vorhanden. Zudem weisen die Beispiele "contoso.com" und "fabrikam.com" unterschiedliche FQDN-Werte des Front-End-Pools auf, die IP-Adressen sind jedoch gleich. Der Grund dafür ist, dass Benutzer, die sich über eine der SIP-Domänen anmelden, denselben Front-End-Pool für die automatische Konfiguration verwenden.

Ausführliche Informationen finden Sie im DMTF-Blog-Artikel "Communicator Automatic Configuration and Split-Brain DNS" unter https://go.microsoft.com/fwlink/?linkid=200707&clcid=0x407.

Hinweis:
Die Inhalte der Blogs und die zugehörige URL können ohne vorherige Ankündigung geändert werden.

Ermitteln von Diensten auf Clients mobiler Geräte, auf denen Lync 2010 ausgeführt wird

Clients mobiler Geräte, auf denen Lync 2010 ausgeführt wird, verwenden DNS-A- oder DNS-CNAME-Einträge, um Mobilitätsdienste zu ermitteln. Bei der DNS-Suche wird zuerst versucht, eine Verbindung mit dem vollqualifizierten Domänennamen (FQDN) herzustellen, der dem internen DNS-Eintrag (d. h. "lyncdiscoverinternal. <sipDomäne>") zugeordnet ist. Wenn mit der internen URL keine Verbindung hergestellt werden kann, wird versucht, eine Verbindung mit dem FQDN herzustellen, der dem externen DNS-Eintrag (d. h. "lyncdiscover. <sipDomäne>") zugeordnet ist. Priorität hat immer die interne URL. Wenn die Verbindung mit der interner URL erfolgreich ist, verwendet der Client das WLAN-Netzwerk des Unternehmens. Wenn eine Verbindung mit der internen URL scheitert, aber eine Verbindung mit der externen URL erfolgreich ist, wird die Clientanforderung über den Reverseproxy an den Front-End-Server oder Director weitergeleitet.

Ist eine Verbindung erfolgreich, gibt der AutoErmittlungsdienst alle Webdienste-URLs für den Home-Pool des Benutzers zurück, einschließlich der Mobilitätsdienst-URLs. Jedoch ist sowohl die interne Mobilitätsdienst-URL als auch die externe Mobilitätsdienst-URL mit dem externen Webdienste-FQDN verbunden. Daher stellt das mobile Gerät (egal, ob es sich innerhalb oder außerhalb des Netzwerks befindet) immer extern über den Reverseproxy eine Verbindung mit dem Mobilitätsdienst her.

Tipp:

Obwohl die Standardkonfiguration ermöglicht, dass der Datenverkehr des mobilen Clients über die externe Website erfolgt, können Sie die Einstellungen ändern, damit nur die interne URL zurückgegeben wird. Bei dieser Konfiguration können Benutzer auf ihren mobilen Geräten mobile Lync-Anwendungen nur verwenden, wenn sie sich im Firmennetzwerk befinden. Zur Unterstützung dieser Konfiguration müssen Sie das Set-CsMcxConfiguration-Cmdlet ausführen. Sie müssen auch die internen Webdienste-VIPs auf den Hardwaregeräten zum Lastenausgleich auf dem Front-End-Server und Director konfigurieren, um cookiegestützte Persistenz zu erzielen. Ausführliche Informationen zu den Anforderungen an Hardwaregeräte zum Lastenausgleich finden Sie im Abschnitt "Anforderungen bei Verwendung eines Hardwaregeräts zum Lastenausgleich für den Reverseproxy" unter Hardwaregeräte zum Lastenausgleich. Ausführliche Informationen zum Verwenden von Set-CsMcxConfiguration, um den Datenverkehr des mobilen Clients auf das interne Netzwerk zu beschränken, finden Sie unter Installieren des Mobilitäts- und AutoErmittlungsdiensts.

Hinweis:
Obwohl mobile Anwendungen auch eine Verbindung mit anderen Lync Server 2010-Diensten wie dem Adressbuchdienst herstellen können, werden interne Webanforderungen mobiler Anwendungen nur an den externen Web-FQDN für den Mobilitätsdienst geleitet. Für andere Dienstanforderungen, beispielsweise Adressbuchanforderungen, ist diese Konfiguration nicht erforderlich.

Lync 2010 für mobile Geräte unterstützen auch die manuelle Ermittlung von Diensten. In diesem Fall muss jeder Benutzer in den Einstellungen des mobilen Geräts wie folgt die vollständigen internen und externen AutoErmittlungsdienst-URIs konfigurieren, einschließlich Protokoll und Pfad:

• https://<ExtPoolFQDN>/Autodiscover/autodiscoverservice.svc/Stamm für externen Zugriff

• https://<IntPoolFQDN>/AutoDiscover/AutoDiscover.svc/Stamm für internen Zugriff

Es wird dringend empfohlen, die automatische Ermittlung anstelle der manuellen Ermittlung zu verwenden. Bei der Behandlung von Konnektivitätsproblemen mobiler Geräte sind manuelle Einstellungen jedoch nützlich. Ausführliche Informationen zu den für den AutoErmittlungsdienst verwendeten DNS-Einträgen finden Sie unter Technische Anforderungen für die Mobilität. Ausführliche Informationen zum Planen der Mobilität finden Sie unter Planung der Mobilität.

DNS-Lastenausgleich

Der DNS-Lastenausgleich wird typischerweise auf Anwendungsebene implementiert. Die Anwendung (z. B. ein Client, auf dem Lync 2010 ausgeführt wird) versucht, eine Verbindung mit einem Poolserver herzustellen. Hierzu wird eine der IP-Adressen verwendet, die über die DNS-A-Abfrage für den FQDN des Pools ermittelt wurden.

Wenn z. B. drei Front-End-Server im Pool "pool01.contoso.com" vorhanden sind, werden folgende Schritte ausgeführt:

• Der Client, auf dem Lync 2010 ausgeführt wird, sendet eine DNS-Abfrage für "pool01.contoso.com", erhält als Antwort drei IP-Adressen und speichert diese wie folgt im Zwischenspeicher (nicht unbedingt in dieser Reihenfolge):

  pool01.contoso.com      192.168.10.90

  pool01.contoso.com      192.168.10.91

  pool01.contoso.com      192.168.10.92

• Anschließend versucht der Client, eine TCP-Verbindung (Transmission Control Protocol) mit einer der IP-Adressen herzustellen. Ist dies nicht möglich, versucht der Client, eine Verbindung mit der nächsten IP-Adresse im Zwischenspeicher herzustellen.

• Bei erfolgreicher TCP-Verbindung handelt der Client die Verwendung von TLS zur Verbindungsherstellung mit dem Front-End-Server aus.

• Wenn keine Verbindung hergestellt werden kann, wird der Benutzer darüber informiert, dass gegenwärtig keine Server mit Lync Server 2010 verfügbar sind.

Hinweis:

Der DNS-basierte Lastenausgleich unterscheidet sich von DNS-Roundrobin (DNS RR). Dieser letztgenannte Mechanismus bezieht sich typischerweise auf einen Lastenausgleich, bei dem DNS zur Bereitstellung einer anderen Reihenfolge von IP-Adressen für die Server in einem Pool eingesetzt wird. Mit DNS RR ist typischerweise nur ein Lastenausgleich, jedoch kein Failover möglich. Wenn die Verbindung mit der IP-Adresse, die über die DNS-A-Abfrage zurückgegeben wurde, nicht hergestellt werden kann, tritt für die Verbindungsherstellung ein Fehler auf. Daher ist DNS-Roundrobin allein weniger zuverlässig als der DNS-basierte Lastenausgleich. Sie können DNS-Roundrobin gemeinsam mit dem DNS-Lastenausgleich verwenden.

DNS-Lastenausgleich wird für folgende Szenarien eingesetzt:

• Lastenausgleich für SIP- und HTTP-Datenverkehr zwischen Servern

• Lastenausgleich für Anwendungen der Unified Communications-Anwendungsdienste, z. B. automatische Konferenzzentrale, Reaktionsgruppen und die Anwendung zum Parken von Anrufen

• Verhindern neuer Verbindungen mit Anwendungen der Unified Communications-Anwendungsdienste (auch als "Serverausgleich" bezeichnet)

• Lastenausgleich für den gesamten Datenverkehr zwischen Clients und Edgeservern

DNS-Lastenausgleich kann für folgende Szenarien nicht eingesetzt werden:

• Webdatenverkehr von Clients zu Servern

DNS-Lastenausgleich und Datenverkehr im Partnerverbund:

• Wenn eine DNS-SRV-Abfrage mehrere DNS-Einträge zurückgibt, wählt der Zugriffs-Edgedienst immer den DNS-SRV-Eintrag aus, dessen Priorität durch die kleinste Zahl und dessen Gewichtung durch die größte Zahl gekennzeichnet ist. Wenn als Ergebnis mehrere DNS-SRV-Einträge mit gleicher Priorität und Gewichtung zurückgegeben werden, wählt der Zugriffs-Edgedienst den SRV-Eintrag aus, der vom ersten DNS-Server zurückgegeben wurde.