DNSSEC is increasingly adopted by organizations to protect DNS data and prevent DNS attacks like DNS spoofing and DNS cache poisoning. At the same time, more DNS deployments are using proprietary DNS features like geo-routing or load balancing, which require special configuration to support using DNSSEC. When these requirements intersect with multiple DNS providers, the system breaks down.
Privacy problems are an area of wide concern for individual users of the Internet -- but what about network operators? Geoff Huston wrote an article earlier this year concerning privacy in DNS and the various attempts to make DNS private on the part of the IETF -- the result can be summarized with this long, but entertaining, quote.
The ICANN Security and Stability Advisory Committee (SSAC) has recently published SAC105, a report on the interplay between the DNS and the Internet of Things (IoT). Unlike typical SSAC publications, SAC105 does not provide particular recommendations to the ICANN Board, but instead is informative in nature and intends to trigger and facilitate dialogue in the broader ICANN community.
In June, I participated in a workshop, organized by the Internet Architecture Board, on the topic of protocol design and effect, looking at the differences between initial design expectations and deployment realities. These are my impressions of the discussions that took place at this workshop. ... In this first part of my report, I'll report on the case studies of two protocol efforts and their expectations and deployment experience.
DNS Operations, Analysis, and Research Center (DNS-OARC) held its 30th meeting in Bangkok on the 12th and 13th May. Here's what attracted my interest from two full days of DNS presentations and conversations, together with a summary of the other material that was presented at this workshop. Some Bad News for DANE (and DNSSEC): For many years the Domain Name X509 certification system, or WebPKI, has been the weak point of Internet security...
I've been incredibly lucky in my time at Neustar to lead both the exceptional Registry and Security teams. While these divisions handle their own unique product and service offerings, it's clear that they have some obvious crossovers in their risks, opportunities and challenges. Having been closely involved in the strategy of both these teams, it strikes me that there is more we as Registry Operators and service providers can and should be doing to align the world of cybersecurity with that of domain names.
March 22, 2019, saw the completion of the final important step in the Key Signing Key (KSK) rollover - a process which began about a year and half ago. What may be less well known is that post rollover, and until just a couple days ago, Verisign was receiving a dramatically increasing number of root DNSKEY queries, to the tune of 75 times higher than previously observed, and accounting for ~7 percent of all transactions at the root servers we operate.
Because the speed of DNS is so important to the performance of any connection on the 'net, a lot of thought goes into making DNS servers fast, including optimized software that can respond to queries in milliseconds, and connecting DNS servers to the 'net through high bandwidth links. To set the stage for massive DDoS attacks based in the DNS system, add a third point: DNS responses tend to be much larger than DNS queries.
With the latest "DNSpionage" attack, ICANN astutely prompted domain name holders to fully deploy DNSSEC on their names. Afilias absolutely supports this and encourages the same. In this post, I remind you of why DNSSEC is important and our continued role. Afilias has a long history in the development and advocacy of DNSSEC. In 2007, we partnered with Public Interest Registry to help found dnssec-deployment.org.
Recently, the DNS has come under an extensive attack. The so-called "DNSpionage" campaigns have brought to light the myriad methods used to infiltrate networks. These attacks employed phishing, system hopping via key exfiltration, and software zero day exploits, illustrating that many secure networks may not be fully protected.