Lync Server 2010 Mobility supports an internal and an external automatic discovery record. As described in this post, the mobile client signs-in by performing a DNS query for lyncdiscoverinternal.<your sip domain>. If this record is not present (does not resolve), the client attempts lyncdiscover.<your sip domain>. This design approach aligns to the Lync 2010 client software for Windows. First an attempt for the SRV record _sipinternaltls._tcp.<your sip domain>, followed by _sipinternal.tcp, followed by _sip._tls, then the A record fallbacks. This approach is great for Windows PCs, and allows Split-DNS configurations to bounce client systems to either the Internal Front-end Pool or the External Access Edge on the Internet. The Windows PCs are managed and Group Policy can add trusted root certificates to the computer certificate store.
But thinking about Mobile clients specifically, they do not have this Group Policy deployment luxury. I’m trying to determine the advantage of ever defining lyncdiscoverinternal.<your sip domain> in the internal DNS namespace. Typically, the Lync Web Services certificate assigned to the Front-end Pool is issued by an internal certificate authority. This Root Certificate Authority certificate is not present on Mobile devices, therefore will be untrusted. The Lync mobile client would not be able to sign-in, unless the internal root certificate was pre-installed on the device.
As you are unable to simply deploy the root certificates to your fleet of mobile devices, bouncing all the devices to lyncdiscover.<your sip domain> looks to be the most appropriate approach. This will typically require routing and access rules to allow internal traffic a connection to the Reverse Proxy server.