Server Man
Well-Known Member
- May 17, 2015
- Windows 10
- Edge 16.16299
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:
Thanks for reading!
Tim Beasley…out. (for now)
Continue reading...
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)
Continue reading...