Lync und DNS

Vor vielen Jahren mussten Windows Administratoren mit der Einführung eines Active Directory das erste mal sich ernsthaft mit DNS beschäftigen. Aber viel hat Windows schon selbst gemacht, zumindest wenn der DNS-Server auch auf Windows installiert wurde.

Mit Exchange 2007 und der Funktion "Autodiscover" war es für die Exchange Administratoren soweit, sich über DNS Gedanken zu machen. Damit hier "Plug and Play" korrekt aus dem Internet funktioniert, mussten diesmal manuell entsprechende DNS-Einträge, SSL-Zertifikate und Webveröffentlichungen angelegt werden.

Damit ein Client den OCS-Server möglichst automatisch findet, sollte man den SIP-Account an die Mailadresse oder den UPN anpassen. Viel wichtiger sind aber die Eintragungen im DNS, da der SIP-Client anhand der DNS-Domain im DNS nach den passenden Servern fragt. Dazu kommen Service Records zum Tragen, die der Client in der folgenden Reihenfolge abfragt. Hier am Beispiel meiner DemoUmgebung.

_sipinternal._tcp.ocsdemo.netatwork.de     SRV 10 10 5060 ocs.netatwork.de
_sipinternaltls._tcp.ocsdemo.netatwork.de  SRV 10 10 5061 ocs.netatwork.de
_sip._tls.ocsdemo.netatwork.de       SRV 10 10 433 ocs.netatwork.de
_sip._tcp.ocsdemo.netatwork.de       SRV 10 10 5060 ocs.netatwork.de
_sip._udp.ocsdemo.netatwork.de       SRV 10 10 5060 ocs.netatwork.de

Sobald ein Treffer vorhanden ist, wird dieser Eintrag genutzt, d.h. wenn Sie einen TLS-Eintrag haben, aber der LCS-Server kein SSL unterstützt, kann der Client keine Verbindung aufbauen.

Lync DNS Round-Robin
Für den Einsatz mit Lync und DNS-Round-Robin ist der Eintrag _SIP._TLS.<sipdomain> maßgeblich
Siehe auch Introducing DNS Load Balancing in Lync Server 2010 http://technet.microsoft.com/en-us/library/ff755052.aspx

Wenn Sie z.B. mal einfach den OCS Communicator starten und dann in einer CMD-Box mal ein "ipconfig /displaydns" ausführen, dann sehen Sie schon, welche Namen der DNS-Client versucht aufzulösen

PS C:\Documents and Settings\Administrator> ipconfig /displaydns

Windows IP Configuration

    _sipinternaltls._tcp.test2007.msxfaq.de
    ----------------------------------------
    Name does not exist.

    sipexternal.test2007.msxfaq.de
    ----------------------------------------
    Name does not exist.

    _sip._tcp.test2007.msxfaq.de
    ----------------------------------------
    Name does not exist.

    _sip._tls.test2007.msxfaq.de
    ----------------------------------------
    Name does not exist.

    _sipinternal._tcp.test2007.msxfaq.de
    ----------------------------------------
    Name does not exist.

    sip.test2007.msxfaq.de
    ----------------------------------------
    Name does not exist.

    sipinternal.test2007.msxfaq.de
    ----------------------------------------
    Name does not exist.

Sie benötigen natürlich nicht alle Einträge, sondern nur die, die in ihrer Umgebung sinnvoll sind. Auch ist es ein unterschied, welche Adressen extern veröffentlicht werden und welche Zertifikate zum Einsatz kommen. Der Name, auf den die Diensteinträge verweisen, sollte auch im Zertifikat entsprechend hinterlegt sein.

Weitere Einträge sind natürlich noch für Communicator Web Access erforderlich

as.owa.netatwork.de          CNAME    owa.netatwork.de
download.owa.netatwork.de    CNAME    owa.netatwork.de

Auch die weiteren Edge-Rollen benötigen entsprechende Eintragungen und auch Zertifikate

Einträge im DNS vornehmen

Hinweis:
Der "Time to Live" (TTL) ist nicht frei konfigurierbar. Lync akzeptiert nur Werte zwischen 5 Minuten und 24 Stunden. Sollten Sie daher DNS-Einträge außerhalb dieser Zeitspanne eintragen, dann wird der nächst gültige Wert angenommen. Dies gilt für A-Records wie für SRV-Records.

Die erforderlichen Einträge müssen Sie als Administrator manuell anlegen, da weder das Setup noch der Server ihnen die Arbeit abnimmt. Damit die "Autokonfiguration" des Communicators also funktioniert, müssen Sie in der Zone der DNS-Domäne den ein oder anderen Eintrag ergänzen, z.B. über den Windows DNS Manager.

Die Eintragungen sind immer in der Domäne durchzuführen, wie auch die SIP-Domäne der Anwender lautet.  In folgender Reihenfolge sucht der Client, was besonders für die Trennung zwischen internen und externen Zugriffen relevant ist.

Eintrag Type Bedeutung

_sipinternaltls._tcp.<domain>

SRV

Für interne TLS Verbindungen

_sipinternal._tcp.<domain>

SRV

Für interne TCP Verbindungen ohne Verschlüsselung, wenn dies erlaubt ist.

_sip._tls.<domain>

SRV

Für externe TLS Verbindungen z.B.: über die Edge Rolle

_sip._tcp.<domain>

SRV

Für externe TCP Verbindungen z.B.: über die Edge Rolle. Diesen Eintrag würde ich aber nicht anbieten wollen und auch dem OCS-Server die Verbindung ohne TLS untersagen.

sipinternal.<domain>
sipexternal.<domain>
sip.<domain>

A
A
A

Fallback, wenn SRV-Records nicht verfügbar sind.

_sipfederationtls._tcp.<domain>

SRV

Erforderlich für die automatisch Konfiguration zwischen "federated partner". Der OCS findet den Access Edge Server über den SRV-Record.

Es handelt sich jeweils um SRV-Records mit Priorität, Port und Serverangabe. Der Name des Servers muss bei TLS dem Namen des Zertifikats entsprechen. 

DNS Einträge für OCS

Der "Underscore" am Anfang ist korrekt und kein Tippfehler.

_sipinternaltls._tcp.<domain> SRV service location:
priority = 0
weight = 100
port = 5061
svr hostname = sip.msxfaq.de

Beachten Sie, dass der Hostname des SRV-Records in der gleichen DNS-Domäne liegen muss, wie die SIP-Domäne selbst. Der Hostname selbst sollte ein A-Record sein.
Dies gilt nicht bei manueller Konfiguration der Servernamen.

Folgendes funktioniert:

_sipinternaltls._tcp.firma.tld  SRV  0 100 5061 sip.firma.de
sip.firma.de                   A    xxx.xxx.xxx.xxx

Dieses Beispiel funktioniert nicht:

_sipinternaltls._tcp.firma.tld  SRV  0 100 5061 sip.hoster.de
sip.hoster.de                   A    xxx.xxx.xxx.xxx

Wenn Sie beim Office Communicator das Logging ins Eventlog aktivieren, sehen Sie folgende Meldung im Eventlog:

Protokollname: Application
Quelle:        Communicator
Datum:         05.03.2009 16:21:50
Ereignis-ID:   2
Aufgabenkategorie:Keine
Ebene:         Fehler
Schlüsselwörter:Klassisch
Benutzer:      Nicht zutreffend
Computer:      FC-MOBIL.netatwork,de
Beschreibung:
Communicator konnte den Anmeldeserver nicht finden. Der DNS SRV-Eintrag für Domäne 
netatwork.test verweist auf den ungültigen Server sip.netatwork.de, der für die Unterstützung der Domäne nicht vertrauenswürdig ist, da es für die Domäne des 
Servers keine Übereinstimmung gibt.
 
Lösung:
 Der Netzwerkadministrator muss die DNS SRV-Eintragskonfiguration überprüfen, um 
sicherzustellen, dass der SRV-Eintrag für die Domäne auf einen Server zeigt, 
dessen Name den DNS-Namenskonventionen im Serverbereitstellungshandbuch entspricht.

Die Lösung besteht darin, in der SIP-Domäne einen A-Record auf die IP-Adresse des OCS-Servers anzulegen, auch wenn dieser in einer anderen DNS- und Active Directory Domain installiert ist.

_sipinternaltls._tcp.firma.tld  SRV  0 100 5061 sip.firma.tld
sip.firma.tld                   A    hostip,.hostip.hostip.hostip

Allerdings bedeutet dies dann, dass der Hoster natürlich für den Namen "sip.firma.tld" ein Zertifikat bereitstellen muss bzw. ein SAN-Zertifikat für alle SIP-Domains genutzt wird, sonst sehen sie auf dem Client wieder nur eine Meldung:

Da DNS Einträge an für sich nichts geheimes sind, können Sie den Eintrag von jeder Firma abfragen. Ein einfacher NSLOOKUP von einem DSL-Anschluss liefert die Daten:

Wenn Sie mit OCS Enterprise Server und Pools arbeiten, dann darf der Eintrag nur auf einen Pool verweisen. Der Pool nimmt die Anfrage an und verteilt schon die Anmeldung auf den richtigen Server. Die SIP-Domain muss nicht identisch mit der AD-Domäne sein. Analog zu Autodiscover muss der Eintrag in der Domain sein, die der user als SIP-Eintrag im Active Directory hat.

Wenn man die DNS-Einträge nicht vornehmen kann, dann kann man auch hier lokal per Registry Werte vorgeben (Siehe Siehe Microsoft Office Communicator 2005 Planning and Deployment Guide und http://regardingthetoys.spaces.live.com/blog/cns!F4AD31CB7032290E!164.entry

DNS-Einträge prüfen

Es ist nicht immer einfach, alle DNS-Einträge per NSLOOKUP fehlerfrei zu prüfen. Daher habe ich ein kleines VBScript geschrieben, welches die Funktion für sie ausführt.

Das Skript nutzt das Programm NSLOOKUP.EXE dazu und parst die Ausgabe. Ich kann also nicht sicherstellen, dass es mit jeder Version und Sprache von Windows korrekt funktioniert.

ocsdns.vbs.txt

Hier ein  Beispiel von Microsoft:

Bei einem Aufruf von intern sollten sie natürlich ihre eigene SIP-Domäne verwenden und das Ergebnis sollte die internen Server auflösen:

Communicator und DNS

Auch der Communicator nutzt gerne DNS, um die Lync-Server aber auch Exchange Web Services zu finden. Dabei werden auch Service-Records genutzt. Allerdings prüft der Communicator die Hostnamen sehr genau und wenn Sie hier nicht gut aufpassen, dann bekommen die Clients eine Zertifikatwarnung zu sehen. Das passiert immer dann, wenn Sie z.B. per SRV-Rrecord auf einen Host in einer anderen DNS-Domain verweisen.

_sip._tls.sipdomain.tld  SRV 0 0 05061 lync.provider.com

Auch ist die Autodiscover-Auflösung für den Lync Communicator erforderlich, um z.B. einen Zugriff auf den Kalender und andere Exchange Informationen zu erhalten. Hier nutzt der Communicator allerdings die SMTP-Domain und nicht die SIP-Adresse des Benutzers.

In allen Fällen muss natürlich sicher gestellt sein, dass die Zertifikate des Server den angesprochenen Namen im Antragsteller (CN) oder als Subject Alternate Name (SAN-Zertifikate) enthalten.

Weitere Links