So, all looks good thus far…
…and yet we cannot sign-in. Let’s see – the Lync server is accessible, all services up and running, _sipinternaltls._tcp.drago.local DNS record is present… way a second! Our SIP domain is drago.ws and the SIP-URI we decided to use is @drago.ws. In this case, the users will sign-in as user@drago.ws and Lync client will look for _sipinternaltls._tcp.drago.ws DNS SRV record. But… we don’t have drago.ws zone in our DNS…
Here comes the Split DNS mystery.
Our domain is drago.local and by default, we have Active Directory Integrated Zone for .local domain. Shall internal users make a DNS query for, let say, www.drago.ws, the request would be forwarded to the Public internet where the zone drago.ws will be discovered and an answer will be returned. With this in mind, we could, indeed, create _sipinternaltls._tcp.drago.ws SRV record pointing to fe.drago.local, but publishing internal resources on Public DNS is absolutely un-acceptable.
The solution is to create a zone for drago.ws domain in our internal DNS. Then, the queries for .ws domain will be served locally. In this scenario we have “Split-brain DNS”. Split, because internal DNS queries will be served internally, while public internet users will be served from the Public DNS (in our case hosted by GoDaddy.)
Maintaining two zones is a “Double the fun” indeed and must be carefully planned and cared for. Many times we could end up chasing ghosts if the zone was misconfigured. Also, in some cases we could send traffic (internal requests) to public server interfaces thus creating bottleneck.
For example, in our college, the “home page” is the college web site. Had we had split-brain DNS and mishandled the A record entries, all 1,500 internal computers would hit the Public IP interface in addition to the thousand hits from outside. Instead, we have “internal” and “external” website, essentially “splitting” traffic because internal resources gets the website bind to an interface with Local IP address (internal DNS returns LAN IP), while external requests go to the NIC with Public IP.
Another example that apply to our lab: Let’s assume that we have web server with two NIC. We run two web sites – one public – http://www.drago.ws and another – http://resources.drago.ws where we publish internal reports and sensitive information. “resources” web site is bind to internal IP address only thus not accessible from Internet. In this case we would create one A record in the Public DNS (for www.drago.ws with the public IP address) but two A records in the internal DNS – one for www and one for resources.
Having said all that, let’s create the additional zone in our .local DNS.
Now we have to create our Lync SRV records in the new zone.
…and try to sign-in again.
Finally, if we look Lync Configuration Information, our Server SIP URI is listed correctly (fe.drago.local)
1 comment:
thanks
Post a Comment