Do Lync 2010 clients dream of lyncdiscover records?

Lync client discovery should be well-known subject for being widely documented. Most will know that Lync 2010 client is (or was?) SRV record-oriented, that is, its preferred discovery methods were based on the two following records:

_sipinternaltls._tcp.sipdomain.com for internal  Lync pool
_sip._tls.sipdomain.com for external Lync edge pool

whereas Lync 2013 family clients (with some differences on the Lync store app) are A record-oriented, that is, its preferred discovery methods are based on the two following records:

lyncdiscoverinternal.sipdomain.com for internal Lync pool
lyncdiscover.sipdomain.com for external Lync edge pool

It seems to be common knowledge that more recent Lync 2010 clients introduced the same behaviour as Lync 2013 clients, supposedly having the feature to now query the lyncdiscoverinternal and lyncdiscover added through an unspecified CU (or, I was unable to find specific information).

This seems to be confirmed by the following Technet article and several other sources. Specifically:

"(...) Microsoft Lync 2010, Lync 2013, and Lync Mobile are similar in how the client finds and accesses services in Lync Server 2013 (...)" "(...) For all clients except for the Lync Windows Store app During DNS lookup, SRV records are queried and returned to the client in the following order:

1. lyncdiscoverinternal.<domain>   A (host) record for the Autodiscover service on the internal Web services

1. lyncdiscover.<domain>   A (host) record for the Autodiscover service on the external Web services

1. _sipinternaltls._tcp.<domain>   SRV (service locator) record for internal TLS connections

1. _sipinternal._tcp.<domain>   SRV (service locator) record for internal TCP connections (performed only if TCP is allowed)

1. _sip._tls.<domain>   SRV (service locator) record for external TLS connections

 " (...) Cumulative updates to the desktop clients change the DNS location process from Lync Server 2010 (...)"

On a customer's site, with Lync 2013 server, and an unusual proliferation of both Lync 2010 and 2013 desktop clients, however, a different behaviour was noted. The scenario was:

- Lyncdiscover and lyncdiscoverinternal records were deployed
- _sipinternaltls.tcp and _sip.tls records were NOT deployed

Lync 2010 clients were still able to perform server discovery and sign in both internally and externally, but it was determined Lync 2010 discovery happened through sip.domain.com A record (existing on both sides of split DNS) and not through Lyncdiscover and lyncdiscoverinternal. This was randomly discovered as sip.domain.com records were briefly removed due to a sip domain migration and caused Lync 2010 client sign in to start failing.

A test seemed to further confirm this:
This is a Wireshark trace of a Lync 2013 client sign-in process, and it shows the expected and documented behaviour:

This is a trace of a Lync 2010 client (January 2014 update - 4.0.7577.4419) - there is no trace of client trying to query lyncdiscoverinternal and lyncdiscover; SRV records are queried first, then failing back to sip.domain.com A record.

My takeaway was: ensure _sipinternaltls.tcp and _sip.tls records are deployed whenever Lync 2010 clients are or may be part of the game :)