Getting the Most from DTC
Infoblox Systems Engineers (SEs) Scott Friedman (TX), Ross Gibson (VA) and Sif Baksh (CO) offered the Infoblox technical community a very practical and interesting webcast on how to leverage application programming interface (API) calls to automate and optimize the Infoblox Global Server Load Balancer (GSLB), DNS Traffic Control (DTC).
They set the context with a basic API primer, provided a manual web UI configuration overview and then highlighted how a single API call could be used to save time and automate the configuration process. They wrapped-up the session with some very helpful and time-saving use cases that the audience could take with them. These included retrieving the next available IP address, next available network and an automatic update of DNS records. The recorded webinar was then posted as a resource to help teams see how the API works and how to increase productivity by doing a full DTC configuration through a single API call.
Unfortunately, many independent software vendors (ISVs) approach their APIs as a summer intern project or product checklist item rather than as a strategic part of their core solution. As a result, it’s clear that not all APIs are created equally. Many are not well designed, properly built and are a challenge to use, resulting in higher infrastructure maintenance costs, a drain on engineering, a limit to usability and more trouble than the value gained by their purchase price.
Not so here. During the session, it was quickly apparent about what differentiates the Infoblox DTC API. One was the power of visibility, where users could actually see backend data and the changes being made in the GUI. Second was how simple and easy the interface enabled the API call to automate the process. Third was the cost savings associated with how one API could be leveraged for similar tasks to ensure consistent, reliable configuration going forward. Fourth was the community resource itself for networking, idea-sharing, best practices and problem resolution. And most importantly, it showed Infoblox’s robust GSLB functionality in an open and interoperable solution that extends its capabilities to future users and applications.
The API Primer
Introduction: While the SE webcast provided a very brief API primer, the following gives a little more detail around the DTC API. There are two standard types of web service protocols for exchanging structured network data, the more popular RESTful (REpresentational State Transfer) web services interface (a.k.a., a RESTful web API), and SOAP (Simple Object Access Protocol). The Infoblox WAPI uses RESTful web services interface. HTTP methods are used for operations and support input and output in JSON (JSON-Pretty) and XML (XML-PrettY) formats. Infoblox can handle both. The -Pretty variants are the same except they can be formatted for readability which makes them very helpful for customers dealing with large datasets with specific layout requirements. Through available documentation, conventions clearly describe the syntax for WAPI methods and objects.
Transport/Authentication: WAPI uses HTTPS (HTTP over SSL/TLS) as the transport mechanism. The server certificate used for WAPI is the same certificate used by NIOS for the GUI. WAPI supports basic authentication (both username/password and certificate-based authentication) and can use the connection for multiple requests by supplying the cookie (ibapauth) that was returned after the initial authentication.
General Syntax and Options: All WAPI requests contain 3 parts: URL, Arguments and Data:
- URL: The first part of the URL identifies the WAPI request and specifies the expected WAPI version. The second part of the URL identifies the resource, such as a network, on which the request operates.
- Arguments: CGI query arguments can be used to specify general options, method specific options and data for the request. Infoblox provides the data format for returned values and methods including GET, PUT, DELETE and POST.
- Data (Body): Data formats are documented and dependent on the method.
Naming and Values: Field names include letters, digits and underscores. URL/CGI arguments are quoted based on where they are used. Data output is provided in JSON and XML.
Object Reference: WAPI returns Object References when an object is created, modified, deleted or read.
Function Calls: Functions are associated with particular objects and only the POST method allows function calls.
Extensible Attributes (EAs): EAs are customer-defined meta tags, essential sets of name value pairs in which the values can be lists (if the attribute allows for multiple values). It’s one of the unique features differentiates DTC. EAs can be searched using the GET method.
Use Flags: Use flags and use flag fields act like object fields, have special rules that guide them and can be written by PUT and POST requests.
Data Formats: Input data from the HTTP request comes from PUT and POST requests only defaulted to JSON but can be updated to the XML format. Output data is also defaulted to JSON but can also be changed to XML.
Error Handling: All errors return an HTTP status code of 400 and higher. 400-level errors are bad request errors initiated by an incorrect client request. 500-level errors include internal or server errors.
Methods: The Infoblox API includes four key methods noted below. These are enabled by method-specific syntax, options, arguments, search modifiers, schemas, return status, errors, and other attributes:
- GET: Used to read a single object designated with a reference or type, or search for objects that match specified rules.
- POST: Creates a new object.
- PUT: Used to update an existing object.
- DELETE: Removes an object (as might be expected).
Detailed documentation on the DTC API can be found in the API Docs.
Contrasting the Web UI vs. API Configuration
After laying the foundation of the API Primer, the SE team then showed how they configured DTC servers from existing DNS records using the Web UI. They began by adding DTC servers (e.g., a server IP, a load balancer virtual IP, etc.) and then configured pools to contain those server/virtual IPs. They then added a Load Balanced Domain Name (LBDN, i.e. the name DNS uses for querying) to tie it all together. In the process, they highlighted things like topology-based GSLB, along with internal use cases using the ExtensibleAttribute (user-defined meta-tag) data. In total, it would take a journeyman admin about 15 minutes to configure the Web UI manually, a process that would have to be repeated for each new application.
In contrast, the SEs then demonstrated how to perform an automatic update of DNS records to gather the inputs and automate the configuration all in one call. Once the API call is created, it can be leveraged with a few modifications for the next new application to get DTC configured and into production. The process showed how teams can use the API to lower DTC configuration from minutes to seconds while ensuring data quality. Sr. Systems Engineer Scott Friedman developed a short 10-minute video to highlight this process.
Time-Saving API Use Cases
As a bonus, the team shared a couple of practical use cases that webinar attendees could implement immediately. The first case addressed using an API call to obtain the next available IP:
API Call to Retrieve the Next Available IP
[
{
"method": "GET",
"object": "network",
"data": {
"network": "192.168.1.0/24"
},
"assign_state": {
"netw_ref": "_ref"
},
"discard": true
},
{
"method": "POST",
"object": "##STATE:netw_ref:##",
"args": {
"_function": "next_available_ip"
},
"enable_substitution": true
}
]
They then discussed how to add a new host based on the next available IP in the network, along with the hostname (the webinar example is named api.freedyhome.local).
API Call to Add a New Host to the Network
{
"name": "api.freedyhome.local",
"view": "default",
"ipv4addrs": [
{
"ipv4addr":"func:nextavailableip:192.168.1.0/24"
}
]
}
Using the DTC API to retrieve the next available IP, add a new host to the network and fully configure DTC for the next application are but a few of many different ways creative teams can get the most from Infoblox DTC.
Conclusion
With the DTC API, you can accomplish more with greater flexibility, time-savings, productivity and versatility, especially for similar and often replicated tasks, than by using the web UI. Thanks to its intentionally designed, open and interoperable architecture, the DTC API can enable companies to save time, handle repeated tasks, boost productivity and ensure that applications are visible, available, performing and optimized as part of a next level network solution.
About Infoblox DNS Traffic Control (DTC)
Infoblox DTC is a Global Server Load Balancer (GSLB) that offers next level reliability, automation and security over traditional Application Delivery Controllers (ADCs). It provides true DNS-based integration, not just a layer 2 and layer 3 bolt-on. It extends GSLB performance for Intranet and Internet, with topologies derived from user-defined extensible attributes (meta data), not just subnet and GeoIP data. It provides an intuitive single pane-of-glass for DNS and GSLB configuration and operations, giving the choice of visualizing server relationships through an easy-to-use GUI that requires no special programming skills, or a robust API for broader functional application. DTC drives visibility through fully-integrated reporting and analytics with query logging including over 100 pre-engineered, pre-built customizable dashboards and reports. It delivers rock-solid security via true cyber-intelligence including over 30 threat feeds with millions of indices—not just basic Response Policy Zone (RPZ) resolution. It supplies fast, efficient full-grid software updates, not manual, box-by-box upgrades. And finally, its license model deployment on existing machines is inexpensive, easy & fast (<30 minutes) without the need for added hardware. Infoblox DTC truly offers greater than 90% of the traditional ADC functionality at 20% of the cost.
