The DNS records required for Lync mobility can be a little confusing due to the fact that mobile clients will always connect to the external web services FQDN. In Lync 2010 the URL's returned by the Lync Discover service for internal and external are the same external web services URL. In Lync 2013 the client is hard coded to look for a a single purpose built URL which is also the external web services URL.
Here is how I would recommend that DNS is configured:
Internal DNS
The internal DNS records cause the most confusion, and are often the reason internally connected mobile devices fail to connect.
lyncdiscoverinternal.sipdomain.com
A record or CNAME pointing to the Front End pool.
This requires that devices have installed the internal CA certificate, or a public certificate has been used that is already trusted by the device. In Lync 2010 you can actually get away with not including this record, instead just including the following record which would normally only be included in external DNS. By doing this you get around the need to install the internal CA certificate. In Lync 2013 all clients now use the Lync Discover service, so it is not advisable to use this workaround. The reason being that you don't want all Lync clients on your internal network connecting to the external Lync Discover service.
lyncdiscover.sipdomain.com
A record pointing to the external web services IP address.
This will normally be the external ISA server interface. This configuration requires that traffic can hairpin out the firewall and back in again, which is also a requirement of the following required DNS record. One trick that can be applied to both these records, is rather than pointing them to the external ISA interface, you point them to the internal interface, and enable the "local host" interface on the web listener associated to the Lync external web services rule. This enables ISA to receive the inbound request and process it locally, applying the rule and sending it back via the internal interface.
![]()
External DNS
External DNS is much more clear cut and doesn't require a heck of a lot of explaining.
lyncdiscover.sipdomain.com
A record pointing to external the external web services IP address.
This will normally be the external ISA server interface.
Here is how I would recommend that DNS is configured:
Internal DNS
The internal DNS records cause the most confusion, and are often the reason internally connected mobile devices fail to connect.
lyncdiscoverinternal.sipdomain.com
A record or CNAME pointing to the Front End pool.
This requires that devices have installed the internal CA certificate, or a public certificate has been used that is already trusted by the device. In Lync 2010 you can actually get away with not including this record, instead just including the following record which would normally only be included in external DNS. By doing this you get around the need to install the internal CA certificate. In Lync 2013 all clients now use the Lync Discover service, so it is not advisable to use this workaround. The reason being that you don't want all Lync clients on your internal network connecting to the external Lync Discover service.
lyncdiscover.sipdomain.com
A record pointing to the external web services IP address.
This will normally be the external ISA server interface. This configuration requires that traffic can hairpin out the firewall and back in again, which is also a requirement of the following required DNS record. One trick that can be applied to both these records, is rather than pointing them to the external ISA interface, you point them to the internal interface, and enable the "local host" interface on the web listener associated to the Lync external web services rule. This enables ISA to receive the inbound request and process it locally, applying the rule and sending it back via the internal interface.
lync-web-external.domain.com
A record pointing to the external web services IP address.
This one confuses a lot of people because it doesn't normally make sense to point an internal record, to a services external IP address, when that service is local. Regardless of whether you have used lyncdiscoverinternal or lyncdisover, the fact remains that this service will still always return the external web services URL, and it is for this reason we need to include the external IP address in internal DNS. If you don't, because your internal DNS is authoritative for your domain, it will not return an IP address to internally connected mobile devices. I still don't really understand Microsoft's logic here but this is the recommended configuration.
External DNS is much more clear cut and doesn't require a heck of a lot of explaining.
lyncdiscover.sipdomain.com
A record pointing to external the external web services IP address.
This will normally be the external ISA server interface.
lync-web-external.domain.com
A record pointing to the external web services IP address.
This will normally be the external ISA server interface.