ArtsAutosBooksBusinessEducationEntertainmentFamilyFashionFoodGamesGenderHealthHolidaysHomeHubPagesPersonal FinancePetsPoliticsReligionSportsTechnologyTravel

Windows 2008 DNS Integration with Infoblox

Updated on October 20, 2010

Windows 2008 DNS and Infoblox NIOS Design

Very few organizations today use just Microsoft's implementation of DNS. Often the management, design, and overall responsibility for DNS is the day-to-day job of internal network engineers, not Windows administrators. This administrative model drives hybrid DNS implementations using both Windows and BIND based DNS servers (i.e. Infoblox NIOS), where more mature, sophisticated architectural models can meet enterprise needs.

Windows DNS and Infoblox NIOS Integration

Real world example

Executive Overview

The architecture and implementation of your Domain Name System (DNS) servers will define the following:

- The availability of DNS components to the organizations entities.

- The efficiency of name resolution in each portion of the enterprise.

- The accuracy of DNS records for clients in all locations at any given time.

- The security of DNS zones as they are presented to resolvers and network hosts and replicated to other DNS servers.

- The security of DNS records that are statically entered or dynamically updated directly or via proxy.

DNS in Windows Networks

DNS is the preferred name resolution standard in mainstream heterogeneous networks. For 10 years now clients and servers in Microsoft networks have used DNS by default for location services. To locate a domain controller on a Microsoft network, service resource records (SRV) records defined by RFC 2782 must be queried and resolved. At logon domain controllers are located by Windows client computers using LDAP over TCP :

_ldap._tcp.DnsDomainName

Other services are located and presented to Windows clients via SRV records and are site aware via TCP/IP subnets defined in Active Directory, providing highly available, efficient services to clients based on their proximity to resources:

_ldap._tcp.SiteName

Microsoft Windows DNS

Windows 2008 DNS server is based on standard DNS protocols and was built to facilitate close-knit integration with Active Directory. It is an RFC compliant DNS server that fully supports interoperability with other DNS server implementations (i.e. BIND-based solutions such as those offered by Infoblox).

DNS is absolutely necessary to support Active Directory. As an alternative to the standard master/slave relationship between primary and secondary DNS servers, Windows Server DNS can be Active Directory integrated, and replicated throughout the enterprise in a multi-master fashion.

Further, DNS zone data can be stored in domain or application directory partitions allowing an architect to define the desired set of domain controllers between which that zone's data will be replicated. For replication purposes, two application directory partitions storing zone data (DomainDnsZones and ForestDnsZones) exist in every domain and forest.

Windows 2008 DNS also supports GSS-TSIG based and standard dynamic update (RFC 2136), conditional forwarders, stub zones, incremental zone transfer, the new GlobalNames zone to finally supplant WINS , background zone loading, IP version 6 (IPv6), support for read-only domain controllers (RODCs), and a global query block list.

Infoblox NIOS

Infoblox NIOS runs on security hardened, proprietary Infoblox hardware appliances and virtually on VMware ESX , Cisco Integrated Services Router, and Riverbed Steelhead WAN optimization platforms to offer DNS, DHCP , NTP and IP address management (IPAM) services.

Perhaps as important as offering a standards-based, hardened, highly available DNS platform, Infoblox implements an administrative model based on granular access control. Additionally, IPAM WinConnect is available as an add-on to mirror this selfsame administrative model on Windows based servers.

Like Windows 2008 DNS server, Infoblox DNS supports the latest DNS improvements including GSS-TSIG and standard dynamic update, conditional forwarding, stub zones, DNS notify for incremental xfer, support for IPv6, and DNSSEC. Infoblox DNS also supports the ability to facilitate dynamic update even when directed to a standard secondary DNS server via a mechanism that updates the primary DNS instead.

Hybrid Architectures

While either solution can fully support Windows and Active Directory itself, hybrid architectures are implemented to leverage the best of each offering. This multi-platform design should consider:

- The type of administrative model that suits the organization

- The level of redundancy and quality of service required

- The end-to-end lookup path for resolvers in each area of the network

- The convergence of DNS zone data distributed in the enterprise

- The security of zone data as it relates to zone transfers

- The security of record level data especially as it relates to dynamic update

Windows DNS Infoblox DNS Hybrid Example

As an example, consider the following:

Infoblox DHCP serves up IP to client and:

- Uses GSS-TSIG to dynamically register clients RR/PTR in company.com (same for no-AD subdomains).

- Uses DHCID TXT to further secure client DDNS registrations (likely Check TXT Only implementation).

- Returns local Windows DNS server as primary, central DNS running server core as secondary.

-Windows DNS is authoritative for AD-specific subdomains (i.e. _msdcs, _tcp, _udp, and so on) and can resolve lookups locally instead of across the WAN resulting in an optimal lookup/resolver query path.

- Windows DNS is configured with forwarders or conditional forwarders to Infoblox as SOA for company.com and its non ad specific subdomains/other domains to perform recursive or iterative lookups based on policy.

- Infoblox is configured to receive GSS-TSIG DDNS updates for Windows 2008 domain controller A and PTR records in company.com and other non AD specific subdomains.

- All Windows 2008 domain controllers use AD integrated zone data for AD specific subdomains and are configured to point to dedicated AD integrated DNS servers running Server Core.

- All Window 2008 domain controllers are configured with forwarders or conditional forwarders (easier to manage via AD replication / not per server) to Infoblox HA for company.com and all non AD specific subdomains.

- Infoblox is configured for delegated subdomains for all AD specific subdomains listing Server Core 1 and Server Core 2 as NS for AD specific subdomains.

Proximity of Service

To accommodate location based name resolution services, each NS for company.com and other non AD specific subdomains deployed in a decentralized fashion can further be configured with the NS records of AD DNS servers closest to client computers.

Zone Authority

Infoblox is authoritative for company.com zone and non AD specific subdomain zones (i.e. amer.company.com, emea.company.com, asia.company.com [examples only]). Windows is authoritative only for delegated subdomains specific to support Active Directory.

Dynamic Update and GSS-TSIG

A NIOS appliance can use GSS-TSIG authentication for dynamic DNS updates for either one of the following:

- A NIOS appliance serving DHCP can send GSS-TSIG authenticated DDNS updates to an AD domain controller running Microsoft Windows 2003/8.

- A NIOS appliance serving DNS can receive GSS-TSIG authenticated DDNS updates from DHCP clients and servers.

DHCID (TXT) records

- DHCP DDNS registration on behalf of clients uses hash of MAC for added layer of protection (Infoblox supports [Internet Security Consortium draft]).

Depending on your expected usage, you must carefully consider the various options for update verification. The following section illustrates recommendations for each verification option:

- Standard ISC: This method is the most stringent option for verification of updates. This is the default.

- ISC Transitional: This method is useful during migrations from systems that do not support the TXT record to systems that are ISC-based.

- Check TXT only: This method is useful for the roaming laptop scenario (dual NIC's/dual MAC's/one RR). The NIOS appliance checks that a TXT record exists, but does not check the value of the TXT record.

- No TXT record: This method should be used with caution because anyone can send DNS update and overwrite records. This method is useful when both ISC and non-ISC-based DHCP servers and clients are updating the same zone.

Migration Scenarios

To achieve the desired end-state architecture for DNS, any changes that must be made need be controlled and reversible, without presenting the potential risk for any interruption in service. As a brief high-level example without any detail these changes might include:

1. Install two Windows AD integrated DNS servers alternatively running server core to function as centralized DNS pair, forwarding to Infoblox for company.com, its non AD specific subdomains, acting authoritative for AD specific subdomains only.

2. Define and implement regionalized AD integrated DNS servers to service requests without traversing the WAN.

3. Configure all windows AD servers to use centralized DNS as primary, decentralized as secondary.

4. Verify the creation of all SRV records / Note a dual set of SRV records exists presently on Infoblox (client still glued there).

5. Manually configure several test client computers to use centralized DNS pair / regionalized DNS.

6. Rollout DNS changes to client computers via Infoblox DHCP.

7. Remove AD specific subdomains from Infoblox, delegate subdomains in Infoblox UI to centralized DNS pair. Configure any decentralized Infoblox (doubt this exists…) NS to use regionalized NS.

8. Implement GSS-TSIG for DHCP on behalf of client computers.

9. Implement GSS-TSIG for Dynamic Update on Domain Controller RR and PTRs in company.com, non AD specific subdomains etc.

10. Implement DHCID to further secure dynamic updates.

11. Swing all Microsoft server (i.e. Exchange, Share Point, and so on) DNS client configurations from Infoblox to Windows DNS.

Action Plan

The success of this implementation will hinge on team and organization-level project participation. Most importantly we must facilitate open communication of technical, operational, and managerial requirements to drive a multi-platform DNS design plan. Windows architects and those owning Infoblox and network services must work side-by-side at least in defining requirements and objectives.

Today's successful projects are defined well first, planned carefully, mocked up in lab environments, built to specification, tested thoroughly, refined, deployed in pilot, and finally, deployed in stages or at once depending on scope.

Eric K. Cone

President, Principal Consultant

Share your experience in this area here.

Reader Feedback

    0 of 8192 characters used
    Post Comment

    • profile image

      anonymous 4 years ago

      Thanks!

    • EricKCone profile image
      Author

      EricKCone 6 years ago

      @anonymous: This is really high level. I should put together something more comprehensive as you suggest. I implemented Infoblox as a pure replacement for Windows DNS in a data center consolidation project. Perhaps that would be a nice example.

      This paper focused on integration, rather than replacement. Essentially the IPAM driven requirements of your networking group will sometimes dictate the implementation of hybrid designs. Infoblox offers a component that ties the two platforms together nicely. It's called Infoblox NIOS for Microsoft Management. Check it out here --> http://www.infoblox.com/en/products/nios-for-micro...

    • profile image

      anonymous 6 years ago

      Interesting paper, but it's not a very clear and concise take on Infoblox working within an AD environment. I would have liked to see written HOW you implement within a Windows environment more clearly and the migration path to Infoblox from an AD integrated DNS implementation.