TL;DR - I want to add a DNS service record to a zone that our parent company manages in our local DNS server since parent company won't help but don't want to maintain an entire copy of their primary zone in order to do it.

Full story

I manage a small remote office (our company was just acquired by a large company) with 20 people and lots of local servers for engineering and testing purposes. I have a Windows Server 2008 machine setup with DNS running that resolves all of our local names and then forwards all other unknown names up to megacorp's internal DNS server via server-level forwarding. So far this works great.

However, we here at minicorp were recently switched to megacorp's Exchange server. When we configure our Outlook clients to connect to the Exchange server we can connect up, but we get the infamous "the name on the security certificate is invalid or does not match" warning. This is because the domain name in the certificate that megacorp uses doesn't match the domain name for use in Outlook auto discovery mechanism. For the most of megacorp's users this isn't an issue since they're on the active directory which pushes out the proper autodiscovery URL via SCP. Since we here in minicorp won't be joining the AD for a while we're stuck with this issue.

Microsoft describes some ways to fix it here: https://support.microsoft.com/en-us/kb/2772058

Megacorp's IT folks are overwhelmed with higher priority issues (nice way of saying they're of no help to minicorp for this problem) so I need to figure out a way to solve this without requiring them to make changes.

According to that Microsoft article, the 'proper' way to handle this is via SCP but since AD isn't an option we can't go that route. So Outlook falls down to the #3 option which tries the autodiscover.megacorp.com URL which works but results in the certificate warning. Also, in order to even make that work I've had to add a autodiscover.megacorp.com zone to my local DNS server since that name doesn't resolve in megacorp's DNS server for some reason.

The next option according to that article is to use a DNS service record to provide the proper autodiscover URL that matches the name in the SSL certificate. The problem is that I don't administer the primary zone for megacorp's domain which finally leads me to my question... Can I create a service DNS record for a zone that I don't manage? Similar to how I created a 'autodiscover.megacorp.com' zone which contains just the proper IP address for that name but all other name requests under megacorp.com domain get forwarded up to megacorp's DNS server, could I do something like that but with a service record? It's as though I want to 'subclass' megacorp's DNS so I can extend it to provide my own records.

Does such a thing exist or am I going in the wrong direction? Maybe there is a different way to solve this certificate error? I realize the proper way to handle this is for megacorp IT to implement this properly but... yeah...

Thanks for bearing with me through this question; it got a lot wordier than I intended.


Your idea will work. So long as you control the DNS servers used by the clients that you need to manipulate, there is nothing stopping you from intercepting the queries and replying however you like.

This answer comes with three caveats:

  1. Clearly, this is an option of last resort. Make sure you have a good idea of how the DNS admins of Megacorp are going to respond when they learn that you're intercepting DNS records that they manage.
  2. Don't Be A Dick. If Megacorp fixes the problem, you should make it a priority to stop doing this and relinquish control of their DNS data back to them.
  3. Interception should be as specific as possible. If you take control of blah.example.com, you are intercepting all queries to the left of blah, not just blah. You're taking control of an entire subdomain, not just a specific name + record type combination.

Lastly, there's a Windows specific caveat here: the DNS snap-in can't be used to create an apex SRV record. You can use it to create the zone, but the record itself will have to be populated using the commandline.

With that in mind:

  • Create a forward lookup zone with the exact name of the record you are intercepting. If you're trying to intercept a SRV record named _service._proto.example.com, you would create a zone named _service._proto.example.com. Following rule #3, avoid _proto.example.com and example.com. Doing so would end up intercepting much more than the traffic that you're trying to catch.
  • Define the SRV record at the top level of the zone using the commandline:

dnscmd /recordadd _autodiscover._tcp.example.com @ SRV 0 0 443 mail.example.com.

  • I need to create a SRV record at the top level (megacorp.com). According to the Microsoft article it should be _autodiscover._tcp.megacorp.com. I wouldn't create a zone with that name because then a SRV record created within it would look like _autodiscover._tcp._autodiscover._tcp.megacorp.com. Instead I think I need to create a megacorp.com top level zone and create the SRV record there. However, when I do that I intercept ALL requests for megacorp which is not what I want... – minicorpit Apr 15 '16 at 18:42
  • You're confused, I think. The zone would in fact be called _autodiscover._tcp.example.com. If you use Other New Records in the DNS snap-in to add the record in this domain, the SRV record dialog will already be populated with _autodiscover._tcp.example.com at this point. If you're ever worried about whether or not a name you're entering will be treated as fully qualified, just append a . to the end. In this particular case, it's not necessary. I'd make sure that the trailing dot is present in the Host offering this service field, though. – Andrew B Apr 15 '16 at 18:48
  • OK, I've created the _autodiscover._tcp.megacorp.com zone. I then add a New Resource Record to this zone (using the DNS snap-in). The domain field is filled in with _autodiscover._tcp.megacorp.com, but the other fields are blank. I tried leaving everything but the Host offering this service field blank but it wouldn't let me. So I fill in the fields as described by the Microsoft article but leave me in a situation I described in my previous email. I think I'm still missing something. Sorry for being slow... – minicorpit Apr 15 '16 at 19:30
  • Hmm. Might be a limitation imposed by the snap-in. Unfortunately, I only have read-only access to our Windows environment and can't lab this out for you. I can say that this is completely legal from a DNS standpoint, so I suggest trying to do this using the command line. (link updated, the last one had some bad syntax) – Andrew B Apr 15 '16 at 19:35
  • 1
    Ah hah! That was it. The command line allowed me to specify @ as the node name which created the service record at the root of the zone which is where I want. Thanks for all your help. – minicorpit Apr 15 '16 at 19:50

I think if this were possible it would be a massive security vulnerability with DNS - you could put some static entries on host files if it's a small office or suppress the warning.


Method 4: Configure Outlook to allow the connection to the mismatched domain name

ImportantThis section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base: 322756 How to back up and restore the registry in Windows To configure Outlook to ignore the name mismatch and connect to a specific HTTP endpoint, you can set or deploy a registry value. To do this, follow these steps: Close Outlook. Start Registry Editor. To do this, use one of the following procedures, as appropriate for your version of Windows. Windows 10 and Windows 8: Press Windows Key + R to open a Run dialog box. Type regedit.exe and then press OK. Windows 7: Click Start, type regedit.exe in the search box, and then press Enter. Locate and then click to select the following registry subkey: HKEY_CURRENT_USER\Software\Microsoft\Office\xx.0\Outlook\AutoDiscover\RedirectServers Note You can also use the following registry subkey: HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\xx.0\Outlook\AutoDiscover\RedirectServers Where xx is 12.0 for Outlook 2007, 14.0 for Outlook 2010, 15.0 for Outlook 2013, and 16.0 for Outlook 2016 Click the Edit menu, point to New, and then click String Value. Type the name of the HTTPS server to which AutoDiscover can be connect without warning for the user, and then press ENTER. For example, to allow a connection to https://contoso.com, the first String Value (REG_SZ) name would be as follows:

contoso.com You do not have to add text to the Value data box. The Data column should remain empty for the string values that you create. To add more HTTPS servers to which AutoDiscover can connect without displaying a warning, repeat steps 4 and 5 for each server. On the File menu, click Exit to exit Registry Editor.

  • DNS is a massive security vulnerability unless something like DNSSEC is in play. :) It's very possible. – Andrew B Apr 15 '16 at 16:26
  • yes but in the context it would be man in the middle against your own domain – Sum1sAdmin Apr 15 '16 at 16:30
  • Out of curiosity, I actually tried that method previously and it doesn't actually work. I think the AutoDiscover\RedirectServers registry key is actually to suppress the warning about using the autodiscover URL to begin with (I also received that prompt but I checked don't ask me again). This doesn't effect the certificate name mismatch like the KB article title suggests. This is probably for the best given the security implications. – minicorpit Apr 15 '16 at 18:29
  • what are the security implications? – Sum1sAdmin Apr 15 '16 at 19:03
  • The MITM attack you mentioned. Someone could redirect the traffic from your Outlook client attempting to connect to the autodiscover URL and the Outlook client wouldn't warn the user of this. The MITM could do all sorts of bad stuff like this. Regardless, Microsoft should probably update that KB article since it isn't accurate. – minicorpit Apr 15 '16 at 19:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.