As the world becomes more dependent on technology, the underlying architecture becomes even more important. A key, often hidden (or simply overlooked) technology is Domain Name Service. DNS is the service that gets you there. Or to put it in technical terms… the service that resolves a URL into an IP address to enable network routing of your request to the relevant web page or resource.
Security concerns around the confidentiality of DNS messaging are valid given there is no inherent specification. But DNSSEC does not resolve confidentiality issues. Other products (e.g., Cloudflare or OpenDNS) are designed to meet those needs.
DNS is susceptible to various types of attacks. DNS shadowing is a threat where the attacker gets access to the domain registrant’s account and creates subdomains from the parent domain of the victim to draw unsuspecting visitors to bogus sites that are hosted under the newly created subdomains. These attacks are mitigated by adequate authentication protection managing DNS (such as multifactor and dual-control authentication) and continuous monitoring of DNS properties.
DNS has also been used in large-scale attacks (terabytes of data) concerning amplification (return large amounts of data from small requests) and reflection (spoofing the response to an unsuspecting victim). Botnets comprised of insecure IoT devices can be used to generate DNS resolver requests like the argument ‘ANY,’ which will return a great deal of data for a small initiating request but will have the spoofed address of the victim that gets the response. One mitigation may be that the ISP may blackhole (have the response sent to a non-resolvable address) all traffic to the targeted victim’s IP address, protecting itself and taking the target’s site offline.
RFC5011 references a DNS Security (DNSSEC) specification that automates the trust anchor process of validating thousands of possible DNS systems that may exist in a resolver’s DNS hierarchy. The purpose of DNSSEC is to validate the zone transfers with a digital signature and to thwart attackers that falsify responses to DNS queries, giving them the ability to redirect end users to bogus internet sites. On 27th September 2017, the Internet Corporation for Assigned Names (ICANN) announced that in the first quarter of 2018, it planned to roll out a new key signing key (KSK) to support global DNSSEC. The rollout of KSK-2017 was successfully completed on 11th October 2018. This represented the first change to the KSK since 2010.
Because of increased reports of confirmed DNS hijacking and manipulation of resolve requests, ICANN published the following checklist in February 2019:
- Ensure your email domain has a Domain-based Message Authentication, Reporting and Conformance (DMARC) policy with Sender Policy Framework (SPF) and/or Domain Keys Identified Mail (DKIM) and that you enforce such policies by other domains on your email system.
- Ensure that your DNS zone records are DNSSEC signed, and your DNS resolvers are performing DNSSEC validation.
- Ensure all system security patches have been reviewed and applied.
- Review log files for unauthorized access to systems, especially administrator access.
- Review internal controls over administrator (‘root’) access.
- Verify integrity of every DNS record, and the change history of those records.
It is therefore vital that DNS is considered within the scope of any technical assessment of a cloud-facing service. For too long this crucial infrastructure service has been overlooked, but as technology advances and ubiquitous access to cloud services becomes the ‘norm,’ DNS should now only be ignored at your peril.
For more information on securing DNS, consider registering for NCSC’s Protective DNS Service, available here:
MIC Solutions 