Posts

Showing posts from September, 2018

Why would anyone want to attack DNS?

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

The problem with predictions

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

Why you probably need two DNSSEC keys per zone

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

ICANN Schedules DNSSEC Root Key Rollover

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