Monthly Archives: September 2013

DNS Limitations in Windows Runtime

Lately I’ve been looking at line-of-business applications for Windows 8.x and how you would go about deploying such applications in the real world. When you build a line-of-business application in-house you can often get away with doing things like hard coding service URLs, but if you are building software that is going to redistributed to multiple customers or even on the Windows Store you need to figure out how your application is going to “discover” where the services are located.

The simple and obvious approach is for the application, upon starting to ask the user for a server name to connect to, but in enterprise environments this information is often opaque to the end-user. Further, once this information “gets out” it can be notoriously hard to retrain users to enter some other value if the network topology changes.

DNS Support in Windows Runtime

Discovering service endpoints is a common challenge. For example, when you set-up e-mail in many mobile devices an automated discovery process is undertaken which involves querying DNS for addresses such as “” when you tell the mail client that your e-mail is “”.

The Domain Name System actually has a mechanism to support discovery of services associated with a domain name via the use of SRV records. An SRV record is a DNS record which combines a service name, protocol, domain and target address to tell a program (via a DNS resolver) which endpoint it should connect to. Many technologies and/or products such as Active Directory and Lync rely on this mechanism.

Getting back to Windows 8.x, I was investigating the best way to enable an service address discovery mechanism which followed this basic process:

  1. On initial start-up of application, ask user for their e-mail address.
  2. Use the domain part of the e-mail address to initiate an SRV record lookup (DNS)
  3. Use the target address from the SRV to connect to service address.

Unfortunately, Windows Runtime doesn’t expose a good mechanism to do this, and the .NET API subset exposed to Windows Runtime doesn’t contain the classes that you might have used to do this in a traditional desktop application. There is some suggestion that you can use the DatagramSocket class to do SRV record lookups for UDP endpoints, but my scenario is for TCP connections.


Without the ability to execute sophisticated DNS queries from modern applications in Windows 8.x the only thing that you can do from a discovery point of view is abandon using SRV records and use an “autodiscover” mechanism similar to the way that Microsoft Outlook uses to find the mail server based on the e-mail address.

This process would look something like the following:

  1. On initial start-up of application, ask user for their e-mail address.
  2. Use the domain part of the e-mail address and prefix with a unique string (e..g
  3. Send a request to this endpoint to download configuration data which can be used to locate service endpoints.
  4. If this fails fallback to ask for detailed configuration information.

As it happens I believe that Microsoft has already encountered this problem. If you’ve used Lync, you’ll know that there are two different Lync clients for Windows. The standard desktop Lync client, and the modern version of the Lync client. The modern Lync client relies on a mechanism similar to the above (, whereas the desktop client can make use of the SRV records to discover the location of the server.

The “autodiscover” or “lyncdiscover” approach for Exchange or Lync respectively rely on a CNAME record being present in the DNS and a server available at that address to respond to the discovery requests. This would be largely unnecessary if the platform supported querying SRV records.

You might be tempted to look at implementing your own DNS client using the sockets API in Windows Runtime. Of course this would take some time to implement correctly, but more than that, you need to be able to discover the address of your assigned DNS server, which from what I can tell is not exposed to modern applications via Windows Runtime.