Dismissing the Myth that Active Directory Requires Microsoft DNS

Whether it’s the internet at large or
your directory services-based network, DNS is the glue that holds it all
together. A simple DNS failure can
translate into total network failure, and because your network is your
business, that translates into a business failure as well. The dependency of this critical network
service combined with the wealth of network information hosted on a typical DNS
opens your network up to vulnerability from external attacks. DNS is now tied with HTTP as the top targeted
service of application attacks such as DNS DDOS, NXDOMAIN and DNS hijacking.

It is for these reasons that your
organization more than likely utilizes a solution besides Microsoft for your
external DNS service. If so, you aren’t
alone. The majority of organizations
today don’t utilize Microsoft for their external DNS services. This is because:

• There isn’t an inherent need to utilize
  Microsoft DNS.
• IT admins want enhanced security features and
  value-added services when considering a DNS placement that is publicly
  vulnerable to attacks.

To put it simply,
organizations demand the best solution for their external DNS that lie exposed
to internet attacks. Third-party DNS
solutions are available on the market which are designed and built from the
ground up with security in mind. The
truth is, though, that an organization’s internal DNS structure is equally open
to malicious threats that can originate from downloaded malware, phishing and
backdoors. In addition, the need for
added intelligent services such as integrated DNS-based traffic control,
network load balancing and service monitoring add great value to an
organization. Unfortunately, many
organizations select their internal DNS solution with a lot less scrutiny. (For more on AD’s biggest problems, see The Top Five Active Directory Management Pain Points.)

The Microsoft Myth

In the case of your typical Windows domain network, many IT
managers are conditioned to only consider Microsoft DNS services as an internal
solution. Many times this is because:

• It’s convenient to use the in-box solution.
• The myth that Active Directory requires
  Microsoft DNS to function properly.

However, this myth simply isn’t
true. In fact, Microsoft even published
a KB article addressing this misinformative concept years ago. You can read the
full KB article here.

Active Directory must be supported by
DNS in order to function properly, but the implementation of Active Directory
Services does
not require the installation of Microsoft DNS. A BIND DNS or other third-party DNS will
fully support a Windows domain. In fact,
even if you are creating an AD forest for the first time, the DC Promo wizard
does not require you to select DNS. Notice how the wizard will allow you to continue with the DC promotion
process despite not choosing to install the DNS server component as is shown in
the screenshot below.

Active Directory-Integrated DNS

There are some advantages of utilizing
Active Directory-Integrated DNS for your DNS zone besides the mere convenience
of the in-box wizard. The primary benefits
are:

• AD replication will
  take care of DNS zone replication automatically.
• All DNS servers are writable.

This reduces the necessity to configure and allot for
separate DNS zone transfer traffic. Other benefits include secure updates and DHCP integration, but these
features are available in third-party solutions as well.

The fact is that
AD-Integrated DNS is an option, but not required. In fact, even if you are currently utilizing
AD-Integrated DNS, Microsoft gives you the option to either add a secondary DNS
or change the structure to one of the traditional DNS zone types as is shown in
the screenshot below:

This built-in feature is so that
Windows DNS can integrate with an alternative DNS server such as BIND. In truth, you can configure:

• All of your DNS servers configured with
  AD-Integrated zones
• All of your DNS servers configured with a
  traditional primary/secondary zones
• A hybrid of both AD-Integrated zones and
  secondary zones

As mentioned, AD-Integrated DNS
integrates DNS replication into the existing AD replication infrastructure,
eliminating the need to manually configure replication partners. This task is easily performed, however, by inputting
any secondary DNS servers as is shown below. Notice you can assign zone partners according to IP address or
simply limit it to all state name servers.

DNS supports a variety of records besides simply HOST, CNAME, MX and NS records. It also supports an assortment of SRV records. A Windows domain relies on select SRV records in order to accommodate AD functions such as net logon and domain join. Microsoft Exchange also depends on some of the same records as well, such as the global catalog record. The list of required SRV records is shown below.

Which look like this on a Microsoft DNS server:

As is shown in the screenshot
above, these SRV records reside in the following required zones:

• _udp.DNSDomainName
• _tcp.DNSDomainName
• _sites.DNSDomainName
• _msdcs.DNSDomainName

These required records are
automatically registered by a domain controller within a Windows DNS, although
there are third-party DNS solutions that support dynamic registration as
well. Even when not supported, however,
these records are rarely ever modified so they need only be manually configured
one time. (To learn about different types of DNS records, see 12 DNS Records Explained.)

Easy Migration

Even if one is uncomfortable
creating these records and zones manually or they already have an existing
Windows AD-Integrated DNS infrastructure, one can follow the following steps to
easily migrate to a third-party DNS solution:

1. If
   creating a new Windows forest or domain, select the Microsoft DNS capability so
   that all required SRV records are created automatically.
2. Add
   a third-party DNS to the network and allow zone transfers to take place with
   it.
3. If
   necessary, convert your AD-Integrated DNS structure to a standard zone
   structure.
4. Designate
   the newly integrated third-party DNS as the primary.
5. Uninstall
   DNS services from all domain controllers or Windows member servers.

As we have
clearly shown, Active Directory does not require Microsoft DNS. So what is the incentive to not utilize the
convenience of exclusively utilizing Microsoft DNS servers? Below is a list of some of the value-added features offered by
third-party DNS solutions available today:

• Proactive automated adaptive behavior protection
  from DNS attacks, malware and data exfiltration
  through customized DNS firewall security
• Utilize DNS and DHCP
  features that are unavailable from Microsoft in-box solutions such as Identity
  Mapping (linking IP addresses to users)
• Intelligently resolve
  queries and direct traffic according to geographic location
• Increased logging to help
  determine where issues and attacks are originating
• Utilizing a single
  solution for external and internal DNS (aka “Single View”)
• Operating-system-agnostic
  way to manage DNS
• Increased security by
  reducing admin privilege usage

Anyone who has managed a Windows
domain is aware of the stark limitations of in-box logging and auditing. Trying to discern which DC a device logged
onto, not to mention its assigned IP address, is problematic and cumbersome at
best. The level of auditing and logging
available in third-party products is exemplary. Imagine being able to access the details of a device that was leased a
DHCP address over a year ago!

Microsoft has always conceded
that any compliant DNS solution will work alongside Active Directory. In short,
there is no imperative to use Microsoft DNS with Active Directory other than
convenience and the fact that it’s just always been done that way before, which
is never a good reason to do anything.