Background A very common request I get from business units (and end users, even) is to be granted read access to internal Microsoft DNS servers. I completely understand the motivation: it could be very convenient to be able to review both the existence and resolution data of DNS records. I mean, you can grant read-only access to a file share and a database, so you should be able to do the same for DNS, right? Unfortunately, it's not that simple, and for one main reason: Microsoft DNS security sucks. I'm not going to go into all the technical details here (may do a full post with all that later), but because of the way Microsoft has set up their default permissions, the security principal Authenticated Users can create and modify all records in any zone hosted by a Windows DNS server. This is to allow and enforce secure dynamic updates. However, the major takeaway for today's post is that anyone who is granted the ability to connect to a Windows DNS server via MMC can cr...

Summary Several things suck about Microsoft's DNS implentation, but the top two for me have to be security and backups. I don't know how many times I've had to explain to a team that I was not going to give them access to the DNS MMC snap-in because it would mean dozens or hundreds of Deny ACLs on zones in that environment. But that's another post. This post is about DNS backups. After experiencing the kind of event that causes one to review one's DNS backup plan, I found there wasn't a tidy way to back up AD-integrated zones like the options for AD, DHCP, and other infrastructure services. I started with a 36-line .bat file that required modification and an individual scheduled task for each zone that needed to be backed up. With the advent of the basic DNS cmdlets in Server 2008 R2, I moved on to an unholy combination of a PowerShell script that gathered zone info and called my old script in a loop. Not efficient, but it only needed one scheduled task. ...