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 :


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:


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 (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 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 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 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 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 zone and non AD specific subdomain zones (i.e.,, [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, 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, 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


      5 years ago


    • EricKCone profile imageAUTHOR


      8 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 -->

    • profile image


      8 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.


    This website uses cookies

    As a user in the EEA, your approval is needed on a few things. To provide a better website experience, uses cookies (and other similar technologies) and may collect, process, and share personal data. Please choose which areas of our service you consent to our doing so.

    For more information on managing or withdrawing consents and how we handle data, visit our Privacy Policy at:

    Show Details
    HubPages Device IDThis is used to identify particular browsers or devices when the access the service, and is used for security reasons.
    LoginThis is necessary to sign in to the HubPages Service.
    Google RecaptchaThis is used to prevent bots and spam. (Privacy Policy)
    AkismetThis is used to detect comment spam. (Privacy Policy)
    HubPages Google AnalyticsThis is used to provide data on traffic to our website, all personally identifyable data is anonymized. (Privacy Policy)
    HubPages Traffic PixelThis is used to collect data on traffic to articles and other pages on our site. Unless you are signed in to a HubPages account, all personally identifiable information is anonymized.
    Amazon Web ServicesThis is a cloud services platform that we used to host our service. (Privacy Policy)
    CloudflareThis is a cloud CDN service that we use to efficiently deliver files required for our service to operate such as javascript, cascading style sheets, images, and videos. (Privacy Policy)
    Google Hosted LibrariesJavascript software libraries such as jQuery are loaded at endpoints on the or domains, for performance and efficiency reasons. (Privacy Policy)
    Google Custom SearchThis is feature allows you to search the site. (Privacy Policy)
    Google MapsSome articles have Google Maps embedded in them. (Privacy Policy)
    Google ChartsThis is used to display charts and graphs on articles and the author center. (Privacy Policy)
    Google AdSense Host APIThis service allows you to sign up for or associate a Google AdSense account with HubPages, so that you can earn money from ads on your articles. No data is shared unless you engage with this feature. (Privacy Policy)
    Google YouTubeSome articles have YouTube videos embedded in them. (Privacy Policy)
    VimeoSome articles have Vimeo videos embedded in them. (Privacy Policy)
    PaypalThis is used for a registered author who enrolls in the HubPages Earnings program and requests to be paid via PayPal. No data is shared with Paypal unless you engage with this feature. (Privacy Policy)
    Facebook LoginYou can use this to streamline signing up for, or signing in to your Hubpages account. No data is shared with Facebook unless you engage with this feature. (Privacy Policy)
    MavenThis supports the Maven widget and search functionality. (Privacy Policy)
    Google AdSenseThis is an ad network. (Privacy Policy)
    Google DoubleClickGoogle provides ad serving technology and runs an ad network. (Privacy Policy)
    Index ExchangeThis is an ad network. (Privacy Policy)
    SovrnThis is an ad network. (Privacy Policy)
    Facebook AdsThis is an ad network. (Privacy Policy)
    Amazon Unified Ad MarketplaceThis is an ad network. (Privacy Policy)
    AppNexusThis is an ad network. (Privacy Policy)
    OpenxThis is an ad network. (Privacy Policy)
    Rubicon ProjectThis is an ad network. (Privacy Policy)
    TripleLiftThis is an ad network. (Privacy Policy)
    Say MediaWe partner with Say Media to deliver ad campaigns on our sites. (Privacy Policy)
    Remarketing PixelsWe may use remarketing pixels from advertising networks such as Google AdWords, Bing Ads, and Facebook in order to advertise the HubPages Service to people that have visited our sites.
    Conversion Tracking PixelsWe may use conversion tracking pixels from advertising networks such as Google AdWords, Bing Ads, and Facebook in order to identify when an advertisement has successfully resulted in the desired action, such as signing up for the HubPages Service or publishing an article on the HubPages Service.
    Author Google AnalyticsThis is used to provide traffic data and reports to the authors of articles on the HubPages Service. (Privacy Policy)
    ComscoreComScore is a media measurement and analytics company providing marketing data and analytics to enterprises, media and advertising agencies, and publishers. Non-consent will result in ComScore only processing obfuscated personal data. (Privacy Policy)
    Amazon Tracking PixelSome articles display amazon products as part of the Amazon Affiliate program, this pixel provides traffic statistics for those products (Privacy Policy)