IPAM

I've never liked the term "enablement." It's one of those superfluous terms like "incentivize" and "irregardless" likely coined by corporate sycophants either to render the otherwise mundane more alluring or in ignorance of the existence of shorter formed synonyms. So instead of discussing "automating cloud network enablement," we'll cover"enabling cloud network automation." Moving beyond my introductory digression, i.e., back to the mundane, that is the concept of the cloud which promises several benefits to IT organizations. The cloud offers the ability to leverage infrastructure, platforms and applications to use when needed, for as long as needed, and to pay only for what they used and for how long. This ability to grow and shrink computing, application or infrastructure capacity on demand provides the elasticity enterprises need to support demand surges, new developments, business continuity and much more. Elasticit

The Internet Corporation for Assigned Names and Numbers (ICANN) just published their review of the recent domain name system (DNS) root zone key rollover. The rollover occurred on October 11, 2018. Please read my prior post for background on DNSSEC and role of the root zone key. ICANN's summary report concludes that the rollover was indeed an "overwhelming success" given the very small number of disruptions detected during the rollover process. The report provides a logical and thorough timeline of the planning leading up to and encompassing the rollover. The report also highlighted several observations of the rollover process, summarized following: The vast diversity of resolver software implementations and configurations on the global Internet renders impossible the ability to predict general resolver behavior leading up to and during a rollover. And the lack of measurement capability prevents assured readiness assessment for major DNS changes. So ICANN and the DN

They were only trying to do the right thing. When a recursive DNS server issues a query using DNS Extensions (EDNS) to another DNS server and the answer indicates a format error or there is no answer at all, developers of various recursive DNS server implementations created workarounds such as reissuing the query without extensions or querying another server authoritative for the same zone. This philosophy centered on coding the recursive server to fetch an answer even if it meant trying to ask in many different forms. While a noble pursuit in "doing what it takes" to obtain an answer, these and similar workarounds introduce additional queries of various formats and additional processing requirements on the recursive server. These inefficiencies, while intended to satisfy the requirement of answering the query, are needlessly reducing performance and scalability of the Internet. And as more extension features are introduced, complexity of recursive server software will incr