Every IT organization on the planet wants to get by with the network infrastructure they have. Change is hard, and inherently risky. There has to be a pretty big reason to go in a different direction.
The Domain Name System (DNS) is no different. Most organizations start off with a simple, out of the box Microsoft DNS solution. For the number of DNS zones and DNS servers in most small networks, it probably works fine. It’s the default choice for Active Directory, so everything seems natural.
Yet there will inevitably come a time when the cost of free network infrastructure management is simply too high. As organizations scale, as strategic initiatives introduce more complexity, as workloads grow, all of the downsides of a Microsoft DNS infrastructure begin to show themselves.
Suddenly, the network seems fragile – errors and configuration issues in DNS entries often lead to downtime. Suddenly, the number of DNS queries grows dramatically and you have limited visibility into what’s happening on the network – either your external DNS or your internal DNS. Suddenly, even the “overlay” solutions you put in place start to fail. It’s at these times that all those Microsoft DNS issues start to cascade.
What are the symptoms of a system weighed down by Microsoft DNS? We put this handy chart together to demonstrate some of the operational challenges we see with customers of ours who are getting ready to migrate away from Microsoft DNS.
|DNS ISSUES||CAUSED BY||IMPACT|
|Hidden zones||Inconsistent query paths||Traveling users suffer loss of access to important services|
|Delayed DNS zone synchronization||Setting up secondaries but failing to enable notifications for those secondaries||Some internal locations or customers can see the modified/new record, and others are still receiving the wrong answer|
|Delegations reference missing glue records||Misconfiguration + stale data + decommissioned hardware||Service outages caused by failure to update all instances of a delegation target|
|Stale DDNS Host and PTR records||Misconfigured, broken or unused MS DNS scavenging and allowing company-wide DNS self-registration||Visual inspection becomes impossible because of huge, cluttered list of stale DNS records|
|DHCP ISSUES||CAUSED BY||IMPACT|
|DHCP reservations with invalid MAC addresses||Bad data entry||Inaccurate IP address data. Confusion as to why device has the wrong IP address or doesn’t exist anymore|
|Fake DHCP reservations||Manually misconfigured DHCP ranges (aka “Poor man’s IPAM solution)||Inaccurate IP address data. Inability to know if it’s safe to allocate the IP address|
|Unreachable gateway||Bad data entry||DHCP outages|
|Conflicting scopes between servers||DHCP services moved without cleanup or creation of backup server||IP address conflicts caused by dueling DHCP servers, DHCP reservations and DHCP option changes don’t take effect or stop working, DHCP pool exhaustion|
|IPAM ISSUES||CAUSED BY||IMPACT|
|Microsoft IPAM networks conflict with DHCP data||Bad data entry||Misconfiguration of routing tables, overlapping IP Address space inaccessible by DHCP clients due to netmask errors|
|DNS data references unknown private networks||No single source of truth – each group or BU tracks networks in a different way||Impossible to properly provision networks and wasted IP space, network equipment, and under-utilized servers|
|Static and DHCP-reserved IP addresses within active DHCP scopes||Bad practice from MS requirement in early versions of their DHCP service||Unintentional reduction in DHCP pool size, increased risk of surprise DHCP pool exhaustion, risk of DHCP conflicts|
|Stale IPAM data and lack of input restrictions||Legacy networks from sold-off divisions or old work sites||Unnecessary purchase of additional network hardware, vulnerable services present on the production network|