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!
Greetings everyone! Tim Beasley (Platforms PFE) coming back at ya from the infamous Nixa, Missouri! It’s infamous since it’s the home of Jason Bourne (Bourne Identity movies).
Anyways, I wanted to reach out to you all and quickly discuss the behavior changes of Windows Server 2016 when it comes to reverse DNS records. Don’t worry, it’s a good thing! We’ve written the code to follow RFC standards. But if you’re not aware of them, you might run into some wacky results in your environment.
During some discussions with one of my DSE customers, they had a rather large app that ultimately broke when they introduced WS2016 domain controller/DNS servers to their environment. What they saw was some unexpected behavior as the app references hostnames via reverse DNS records (PTRs). Now you might be wondering why this became an issue…
Turns out the app they use expects reverse DNS records in ALL LOWERCASE FORMAT. Basically, their application vendor did something silly, like take data from a case insensitive source and used it in a case sensitive lookup.
Before you all possibly go into panic mode, most applications are written well; they don’t care about this and work just fine. It’s the apps that were written for this specific behavior (and quite frankly don’t follow RFC standards) that could experience problems. Speaking of RFC Standards, you can read all about case insensitivity requirements per RFC 4343 here.
Let me give you an example of what it is I’m talking about here. In the below screenshot, you will see “2016-PAMSVR” as a pointer (PTR) record. This was taken from my lab environment running WS2016 1607 with all the latest patches (at this time April 2018 updates). Viewing the DNS records in the MMC, reflects uppercase and lowercase. In contrast, prior to 2016 (so 2012 R2 and lower) the behavior was different in that ALL PTRs registered show up in LOWERCASE only.
***Note, the client OS levels doing the PTR registrations does not matter. This behavior will be reflected no matter what version of Windows or other OS you use.***
Here’s another example from an nslookup perspective:
To reiterate, when dynamically registering a PTR record against a DNS Server running Windows Server 2012 R2 or older, the DNS Server will downcase the entry.
Test machine name: WiNdOwS-1709.Contoso.com
When registering it against a DNS Server running Windows Server 2016,
we keep the machine name case.
Please keep this behavior in the back of your mind when you’re introducing WS2016 Domain Controllers / DNS servers to your environments for the first time. Chances are you won’t run into any problems whatsoever. But if the stars aligned improperly and this does turn out to be an issue for you, then here are some suggestions on how to remediate it:
- Involve your App Vendor(s) and have them update their code the correct way, following RFC standards.
- What #1 says.
- Again, do what #1 says.
- If the app vendor pushes back and you absolutely have no other choice…you could update all the hostnames in your environment via PowerShell to reflect lowercase. You’d then have to clear out all reverse records and have the devices re-register once their hostnames are down-cased. An example of this can be found here. Just be careful doing this and make sure you test the PowerShell script first before deploying to a production environment!!!
Thanks for reading!
Tim Beasley…out. (for now)