IPAM

Your domain name represents your identity on the Internet. Customers, prospects, associates, and generally anyone on the Internet can navigate to your website simply by knowing your domain name. The domain name system (DNS) facilitates this naming process by enabling the resolution of your site's name to Internet Protocol addresses that devices use to connect to your website over the Internet. While DNS simplifies navigation to your Internet presence thanks to your domain name, it also introduces an exposure to visual misrepresentations of your domain name in the DNS and therefore on the Internet. Such misrepresentations may be totally innocent, such as when would-be visitors "fat finger" or mistype your web address in their browsers leading them to another website, or downright malicious where a miscreant creates a website reachable by a visually similar or slight variation in your domain name. Such a malicious website could be designed to visually appear similar to

Need a quick summary of essential DNS security measures on a single page? I've published a DNS Security Battlecard just for you. My intention is to "net out" the key measures you should consider to better secure your DNS and thereby better secure your overall network. The battlecard summarizes, for each DNS server role, various controls you can implement related to deployment, routing controls, server controls and DNS application/protocol controls. Beyond the network and server level controls highlighted in the battlecard, please do not forget the human element of security that pervades all DNS server roles. This includes developing and enforcing an organizational security policy, incorporating security functions and requirements into staff job descriptions, staffing of personnel with appropriate job-specific skill sets, regular training of security policies and controls, and periodic auditing of staff activities. Other enterprise-wide security considerations include

The Domain Name System (DNS) makes the Internet usable for humans. It is fundamental to the proper operation of virtually all Internet Protocol (IP) network applications, from web browsing to email, from messaging to multi-media applications and more. By its very nature, the global Internet DNS system serves as a distributed data repository containing domain names (e.g., web addresses) and corresponding IP address information. DNS has proven extremely effective and scalable in practice and most people take DNS for granted given its proven reliability. However, its essential function and decentralized architecture serve to attract attackers seeking to exploit its distributed structure and rich data store for sinister activities. Every time you enter a web address or send an email, you use DNS. DNS translates human-preferred "www" names into computer-preferred binary addresses. This translation service is more commonly referred to as a name resolution process, whereby a web a

Two basic tenants of information technology (IT) network security practices entail partitioning DNS server deployments and corresponding functions based on trust zones and in employing a multi-layered defense in depth style approach. I’ll use the term “trust sectors” instead of “trust zones” given the ambiguity of the word “zone” in a DNS context. Establishing an effective defense is critical as is preparation, monitoring, event detection to rapidly identify attacks in progress and enact recovery plans to perform mitigation actions to minimize or nullify their impacts. Event post-mortems are also critical to feeding back to the security plan to apply lessons learned to improve detection and recovery times. Generally, DNS deployment designs should account for high availability, performance, scalability, human intervention and of course, security. Using a trust sector approach to DNS server deployment allows you to segment namespace and resolution responsibility which provides a solid

The National Institute of Standards and Technologies (NIST) Cybersecurity Framework (CSF) is a de facto security implementation standard not only for the U.S. government, but for organizations worldwide. This framework defines a common lexicon to facilitate documentation and communication of security requirements and level of implementation. In addition, the framework enables an organization to identify risks and to prioritize the mitigation of risks with respect to business priorities and available resources. NIST’s CSF seeks to facilitate communications within an  organization as well as to external parties when conveying security goals, maturity status, improvement plans and risks. The framework is comprised of three major components: The framework core defines security activities and desired outcomes for the lifecycle of an organization’s management of cybersecurity risk. The core includes detailed references to existing standards to enable common cross-standard categorization

The Domain Name System (DNS) makes the Internet usable for humans. It is fundamental to the proper operation of virtually all Internet Protocol (IP) network applications, from web browsing to email, from messaging to multi-media applications and more. By its very nature, the global Internet DNS system serves as a distributed data repository containing domain names (e.g., web addresses) and corresponding IP address information. DNS has proven extremely effective and scalable in practice and most people take DNS for granted given its proven reliability. However, its essential function and decentralized architecture serve to attract attackers seeking to exploit its distributed structure and rich data store for sinister activities. Every time you enter a web address or send an email, you use DNS. DNS translates human-readable "www" names into computer-readable binary addresses. This translation service is more commonly referred to as a name resolution process, whereby a web ad

About fifteen months ago, I boldly predicted that half of all Internet communications would consist of IPv6 traffic by the second half of 2020. My post also posited that IPv6 penetration could hit 25% by the end of 2017; a mark it seems we're only just now about to hit according to google's IPv6 statistics . Alas, my irrational exuberance has been tempered by the reality of a seeming asymptotic plateauing at 25%. Based on these latest measurements and quadratic curve-fitting, it seems that we would be pressed to get to 40% of Internet users using IPv6 by the end of 2020. While many in the Internet community had eagerly desired to turn the corner on IPv4 and proclaim IPv6 "the" Internet protocol, it seems the Internet will remain dual protocol for quite some time. While most had accepted this reality, albeit grudgingly, the common belief held that the proportion of IPv4 users would vastly diminish throughout this decade, into the next, and eventually fade into obscu

If you've endeavored to or are considering digitally signing your DNS information, congratulations! You are helping to make the Internet safer. And you're doing yourself a favor in authenticating your own domain namespace. This will make it nearly impossible for an attacker, using DNS alone at least, to steer would-be web visitors to an impostor site which could damage your reputation, customer satisfaction and your brand. Of course, this defense only applies to visitors using DNS resolvers or recursive servers that perform DNSSEC validation, which hopefully will encompass most if not all Internet users in a matter of time (don't worry, unlike my proclivity for predicting full IPv6 deployment, albeit inaccurately, I don't plan to predict full DNSSEC deployment, but it's pretty easy so let's get on with it people!). Most vendor implementations including ISC's BIND, PowerDNS, Microsoft and KnotDNS automate DNSSEC signing to varying degrees. Some IPAM vendors

The Internet Corporation for Assigned Names and Numbers (ICANN) has announced that the DNS root zone DNSSEC key will be rolled over on October 11, 2018 at 4pm UTC (12 noon EDT). The original plan to roll the root zone key one year ago was postponed due to a concern about the lack of resolver readiness at the time for the new root key. Validating resolvers must possess the current root zone key as a trust anchor in order to validate DNSSEC signatures. There are two different types of DNSSEC keys. Zone signing keys, ZSKs, sign resource record sets (RRSets) within a given zone and may generally be modified at will by a zone administrator, i.e., without affecting validation of other Internet DNS zones. Key signing keys, KSKs, on the other hand, sign the zone keys themselves, the DNSKEY RRSet, and changes in KSKs can impact Internet DNS resolution if performed without coordination. This is due to the fact that the DNSSEC trust model mirrors the DNS domain tree. Just as the very process