Common concerns in a Microsoft DNS migration
Most organizations start off managing their Domain Name System (DNS) 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. Organizations scale, strategic initiatives introduce more complexity, and workloads grow. And then all of the downsides of a Microsoft DNS server infrastructure begin to show themselves.
Here are some indicators that you’ve outgrown Microsoft DNS:
High stakes IPAM spreadsheets
Juggling spreadsheets for IP address management is unwieldy and inefficient.
“Fat finger” changes to DNS records regularly bring down the network.
Overwhelming DNS workload
Your team is falling behind on important initiatives because they’re stuck dealing with service tickets.
Put your DNS in order with a centralized, automated solution
BlueCat’s Adaptive DNS solutions for DNS, DHCP, and IPAM (DDI) create a solid foundation for your network infrastructure. Adaptive DNS eliminates the heavy workload and systemic risk that comes with using Microsoft DNS on complex global networks.
Single source of truth
Put all your DDI data into a single repository to eliminate errors and increase agility.
Restrict access based on threat feeds and response policy zone (RPZ) rules.
Increase efficiency by automating standard management tasks.
Put DNS and DHCP wherever you need them. Do so with appliances, virtual instances (VMware, KVM, HyperV), and public cloud (AWS, Azure, Google Cloud Platform).
Reporting and auditing
Capture information on users, DNS servers, deployments, and RPZ activity for easy audits.
Seamless DNS migration
Cleanse your data, ensuring nothing gets left behind.
Granular DNS traffic logs
Agent-less visibility into any device. Track originating IP, DNS queries and DNS response data, authoritative nameserver, query type, and protocol information. Do so for both internal and external DNS client queries.
Integrate your existing systems using REST APIs.
Beat SLAs with Adaptive Apps & Plugins
A service-level agreement (SLA) sets expectations for what a customer prospects they’ll be receiving from a service provider. In this 30 second feature, explore three add-ons that you can tailor for Adaptive DNS to exceed these expectations. Improve visibility and IT ticket fulfilment across your enterprise using plugins, Cloud resources, or the BlueCat ServiceNow integration to provide fully automated updates.
Common concerns in a Microsoft DNS migration
We get it. Migrating your core infrastructure is inherently risky, and a big change to the DNS management system you’re probably used to. Here are some topics we regularly address with customers considering a switch from Microsoft DNS to BlueCat.
What about Active Directory?
BlueCat integrates seamlessly with any Active Directory infrastructure. Contrary to popular perception, Active Directory can use any DNS service, including BlueCat—it does not require Microsoft DNS.
Can we get by with an overlay?
So-called “overlay” solutions can help with visibility during the migration process. But they cannot address the architectural challenges inherent in Microsoft DNS. Only an enterprise approach to DNS can solve these problems definitively.
How do we minimize migration risk?
Any infrastructure change comes with inherent risk. BlueCat’s proven migration process cleanses and rationalizes your DNS data, ensuring a smooth transition.
How will this work in the cloud?
There are many ways to implement DNS in the cloud. BlueCat offers a wide variety of supported platforms and architectures.
Symptoms of a system weighed down by Microsoft DNS
What are the symptoms of a system weighed down by Microsoft DNS issues? These charts detail some of the issues customers see when they might be ready to migrate away from Microsoft DNS.
Issues for DNS:
|DNS Issue||Caused By||Impact|
|Hidden zones||Inconsistent query paths||Traveling users suffer a 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, and 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 a huge, cluttered list of stale DNS records|
Issues for DHCP:
|DHCP Issue||Caused By||Impact|
|DHCP reservations with invalid MAC addresses||Bad data entry||Inaccurate IP address data; confusion as to why the device has the wrong IP address or it no longer exists|
|Fake DHCP reservations||Manually misconfigured DHCP ranges||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|
Issues for IP address management (IPAM):
|IPAM Issue||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 Microsoft 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|