In part 4 of Turbocharge your Infoblox RESTful API calls series, we discuss what asynchronous programming is, and how it can be implemented to dramatically improve the speed of automation scripts.
In this fourth and final article of the Turbocharge your Infoblox RESTful API calls series, we explain what async programming is, its pros and cons, as well as demonstrate how how it can be leveraged to vastly improve the performance of scripts which make use of the Infoblox WAPI. In this article we will again take our original WAPI script which inserts 1,024 IPv4 network objects...
In part 3 of Turbocharge your Infoblox RESTful API calls series, we discuss how to batch WAPI requests using the request body to speed up our automation scripts.
In this third article of the Turbocharge your Infoblox RESTful API calls series, we discuss synchronous programming and its drawbacks. In addition, we show how to leverage the Infoblox WAPI request object to effectively batch a large number of "requests" into a single WAPI call to improve performance. First, we should discuss what synchronous programming is, why it's good, and what are its weaknesses.
The code u...
In part 2 of Turbocharge your Infoblox RESTful API calls series, we discuss concurrency, its pros and cons, how it can be implemented to speed up automation scripts.
In this second article of the Turbocharge your Infoblox RESTful API calls series, we'll take our synchronous Infoblox WAPI automation script and demonstrate how we can improve it by using concurrency to make it run faster. In this article we discuss what concurrency is, the pros and cons for using it in development, and how to implement it in our automation scripts. Recall that at a high level, scripts can be...
In this multi-part series we provide four ways to vastly improve the performance and efficiency of your calls to the Infoblox REST API.
I've spent the last several weeks exploring ways to improve the performance of scripts that leverage the Infoblox NIOS WAPI to make customer DDI automation execute faster. In this multi-part series, we'll detail four ways to turbocharge your scripts when making calls to the Infoblox WAPI. Our goals are to provide the following:
- Increase performance - i.e., reduce the time to execute scripts
- Achieve greater efficiency
- Improve business...
In this second part, I offer another solution for collecting DNS client query statistics on the fly using commercial off-the-shelf tools that will provide a bit more flexibility.
In this blog article, I explore a different way of gathering and reporting DNS Client Resolver statistics. In this post, I use a combination of Open Source Software and commercial off-the-shelf software in rolling a solution to build a list of DNS Top Talkers. In this second part, we continue to rely on DNS query logging, but instead of harvesting log data by downloading and parsing through Infobl...
A common task for decommissioning or moving a name server is figuring out which clients are querying our particular name server. In this article, I discuss how you can parse syslog messages and build a DNS Top Talkers list.
I recently worked with a customer on a project to help them decommission an Infoblox DNS appliance from their Grid. They needed the device to be removed from "play" immediately and there was very little time to accomplish the task. Our first task was to determine the following:
- What IP addresses were querying the DNS?
- What was the volume of DNS quer...
The ISC has issued an Operation Notification for BIND 9.16.0 - An error in handling TCP client quota limits can exhaust TCP connections.
In the previous blog article announcing BIND 9.16.0, it was discussed that significant work was done to modernize BIND's networking framework to use libuv, a multi-platform C library that provides async I/O on event loops. Unfortunately, as a result of that work, there was an issue introduced in the code that enforces TCP client quota limits. The issue in the code is that there are situations where the TCP client count is not properly...
DNS Response Policy Zones (DNS RPZ) is a method that allows a name server to be configured with information on top of the global DNS to provide alternate responses to queries.
One of the original purposes for DNS RPZ was to provide "DNS Firewall" capabilities. DNS RPZ was originally created to protect internet users from an ever-expanding list of threats, exploits, and attacks. While DNS RPZ excels at providing users protection, it also provides ancillary benefits and can be used to serve a wide variety of other use cases. Here are a few:
- Static NAT
- Split Horizon DNS en...