By Bob Rose, Ross Gibson & Paul Adair
Hybrid Cloud Answers Needed
More and more companies are leveraging public cloud infrastructure in conjunction with their on-premise infrastructure, commonly referred to as a hybrid cloud deployment. Deploying applications in a hybrid cloud model can sometimes benefit from Domain Name System (DNS) answers that are specific to a client based on its location. The Infoblox DNS Traffic Control (DTC) functionality can be leveraged to provide site-specific answers that may be required.
This blog presents an interesting use case where a customer utilizes DNS resolution to provide traffic segregation of Microsoft Active Directory (AD) authentication for non-site-aware clients. DTC can be used as a solution by providing site specific Service Record (SRV) responses based on device location, whether on-premises or in the public cloud as described below.
It All Begins with DNS
At the heart of this solution lies DNS. DNS serves as the “phone book” of the internet by associating “easy to recall” hostnames with IP addresses required for communication by network equipment. DNS also stores and associates various information with domain names like email servers authorized to process email for a given domain. More importantly, DNS enables names to be assigned to organizations and referenced without regard to the physical routing hierarchy of numerical IP addresses. DNS distributes the assignment of domain names mapped to IP addresses with an authoritative server which tracks its own changes to avoid syncing updates with a central registrar.
SRV
SRV also plays a key part in this solution. SRV is a data category within DNS that specifies information on available services (e.g., voice, video and messaging applications in IP networks). AD clients use SRV records to identify which domain controllers are available to provide authentication (e.g., record of _gc._tcp). SRV record support was added to DTC in NIOS 8.3. To use an SRV record in DTC, the DTC server object must be created and saved first, and then the SRV record can be added within the DTC object using the DTC web GUI.
In DTC, the GUI displays the following format:
- Display Input As: RFC 2782 format (_service._protocol.domain) or free format
- Service: Name of the designated service
- Protocol: Service protocol (typically TCP or UDP)
- Domain: Domain name valid for the record
- Preview: Visualization of the data
- Priority: Priority of the target host (lowest value is the most preferred)
- Weight: Weighing of records with the same priority
- Port: TCP or UDP port on which the service is located
- Target: Hostname of the machine providing the service
- DNS Target: DNS target field
- Comment: User comments relative to this SRV
- Disable: Control for turning off the record
What About Site-Awareness?
Some non-Windows clients that authenticate against AD are not site-aware. This means that they could potentially attempt authentication against less-than-optimal servers. In a typical AD environment, once a client talks to an AD controller, it determines its site affiliation and then queries for site-specific service listings. In some cases, Admins may wish to provide site-specific answers to clients that are otherwise not site-aware. With DTC, Admins can use the client source to return specific SRV records to the client, thereby, controlling the behavior of site-unaware clients.
Ross Gibson and Scott Friedman, Infoblox Sr. Systems Engineers, recently prepared a short Infoblox YouTube video to demonstrate a sample of this implementation. This video shows how using DTC’s new SRV-record support capability can provide site-specific responses to queries for the _gc._tcp record for a domain.
DNS Behavior Without DTC
Typically, clients get a list of SRV records when querying for _gc._tcp. The client will usually use the SRV record with the lowest-numbered priority value. The client then only relies on using other records if the host connection fails. Services with multiple SRV records having the same priority value use the weight field to determine which host to use. Weight values are considered against other weights for the service presuming that they have the same priority. For the following use case, a DNS SRV record query is sent to _gc._tcp.company.com, and the DNS server returns all possible answers for the record, leaving it to the client to decide which Domain Controller to use as shown below:
DNS Behavior with DTC
In contrast, when DTC is used, the DNS responses can be specific to each client based on its location. By providing only a single response when queried for the _gc._tcp record, the client must use the Domain Controller that the DNS server provides as shown below: In addition, since DTC can perform health checks against the target domain controllers, a solution like this can be configured to provide a different answer to the client if a Domain Controller becomes unavailable.
In addition, since DTC can perform health checks against the target domain controllers, a solution like this can be configured to provide a different answer to the client if a Domain Controller becomes unavailable.
Summary
This is just one creative example of how the new DTC SRV-record support can be used to provide answers based on the client’s location. Infoblox’s DTC functionality allows the DNS Admin the ability to create IPAM-integrated, topology-based, high-availability solutions for many types of applications and functions.
