What in the World Happened to my DNAME Resolution!!??

___________________________________________________________________________________________________________________________

IMPORTANT ANNOUNCEMENT FOR OUR READERS!

AskPFEPlat is in the process of a transformation to the new Core Infrastructure and Security TechCommunity, and will be moving by the end of March 2019 to our new home at https://aka.ms/CISTechComm (hosted at https://techcommunity.microsoft.com). Please bear with us while we are still under construction!

We will continue bringing you the same great content, from the same great contributors, on our new platform. Until then, you can access our new content on either https://aka.ms/askpfeplat as you do today, or at our new site https://aka.ms/CISTechComm. Please feel free to update your bookmarks accordingly!

Why are we doing this? Simple really; we are looking to expand our team internally in order to provide you even more great content, as well as take on a more proactive role in the future with our readers (more to come on that later)! Since our team encompasses many more roles than Premier Field Engineers these days, we felt it was also time we reflected that initial expansion.

If you have never visited the TechCommunity site, it can be found at https://techcommunity.microsoft.com. On the TechCommunity site, you will find numerous technical communities across many topics, which include discussion areas, along with blog content.

NOTE: In addition to the AskPFEPlat-to-Core Infrastructure and Security transformation, Premier Field Engineers from all technology areas will be working together to expand the TechCommunity site even further, joining together in the technology agnostic Premier Field Engineering TechCommunity (along with Core Infrastructure and Security), which can be found at https://aka.ms/PFETechComm!

As always, thank you for continuing to read the Core Infrastructure and Security (AskPFEPlat) blog, and we look forward to providing you more great content well into the future!

__________________________________________________________________________________________________________________________

Hello world; Brandon Wilson here, with a special thanks to Tony Gaston in our support wing, here to talk to you briefly about changes in DNAME resolution for Windows Server 2012 R2 that were introduced in KB3133954. More specifically, if you look at the “Known issue” section of KB3133954, you will find that it states:

“After you install this update, the DNAME resolution by Microsoft DNS Servers will be changed.

Previously, you could query for the domain (type=ANY or type=A) example.com, and get back the host (A) record for the DNAME. After you install this update, that query fails.

This change was made for compliancy with RFC 6672.”

So, let’s dive into this a little bit more shall we?? Per the RFC, the DNAME applies only to objects within the domain, and not to the domain itself. The bottom of page 4, along with pages 5 and 6 in the RFC talk about this behavior more in detail, so I’ll try not to get too wordy on that. First, let’s look at the high-level RFC defined behavior, where if you query the DNAME directly, you get the DNAME response back (this is from RFC 6672):

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Here are some more specific examples to chew on; hopefully they help you see the new behavior:

Now that we have all of that covered, we may as well talk a bit about KB3133954 itself… The actual KB title is “DNSSEC validation fails when incorrect response to DNSKEY query is sent on Windows Server 2012 R2-based DNS server”. The high-level overview is that this is to correct an issue where if a DNSKEY query is targeted for a name that has a DNAME, then it will respond back with the DNSKEY rather than the “correct”/expected target name. So, in correcting 1 issue, you are actually correcting both that issue, as well as refining your DNS servers to be RFC compliant. In the context of the behavior change however, DNSSEC is a separate topic altogether, and the KB is only an introduction point to the changes made for DNAME resolution.

And in a nutshell, that’s pretty much it. I just wanted to let everyone know about the changes and provide a bit of an example to maybe, just maybe, eliminate some head scratching! Hey, we can all dream right…?

References:

DNSSEC validation fails when incorrect response to DNSKEY query is sent on Windows Server 2012 R2-based DNS server

https://support.microsoft.com/en-us/help/3133954/dnssec-validation-fails-when-incorrect-response-to-dnskey-query-is-sent-on-windows-server-2012-r2-based-dns-server

RFC 6672: DNAME Redirection in the DNS

https://tools.ietf.org/html/rfc6672

Thanks for reading everyone!

Brandon Wilson, Sr. Premier Field Engineer, Platforms and Active Directory