What is a dangling DNS record?
A dangling DNS record refers to a record that is pointing to a resource such as a server, IP or endpoint that either no longer exists or is inaccessible. In this context, dangling refers to a record being left in a hanging state or pointing to nowhere. This issue is typically the result of poor DNS hygiene, decommissioning or update practices. In the era of public cloud computing, dangling DNS records pose an added security risk.
Why do they matter?
Prior to the widespread adoption of public cloud computing services, dangling DNS records made the life of network engineers difficult – but posed less of a risk to the security of an organisation. Typically, organisations owned or rented relatively static infrastructure and IP address blocks from Internet Service Providers (ISPs).
Fast-forward to the era of AWS, Azure and GCP – you can now spin up virtual servers and rent public IP addresses in seconds. When you’re finished you can release those servers and IP addresses back to the cloud providers pool for another customer to use. This introduces a problem.
Consider the following example
I decide on AWS to host my blogging website dcremin.com, opting for an EC2 instance with a public IPv4 address assigned to it of 3.25.107.136. I have also chosen to use AWS’ native DNS service (Route53) to add a corresponding DNS A record that points to blog.dcremin.com to 3.25.107.136 – the public IP of my EC2 instance.
At a later date, I decide to move my website from an EC2 instance to an S3 bucket as it largely static and this option is more cost effective – registering a CNAME record for blog2.dcremin.com in Route53. Additionally, I release the public IPv4 address back to AWS’ pool and decommission the EC2 instance.
However, as part of this process I forget to disassociate blog.dcremin.com with the 3.25.107.136 IP address in the Route53 service. Later, a malicious actor happens to be allocated the same IP address by AWS and decides to host a malicious phishing website with it. My Route53 record will now resolve blog.dcremin.com to the website hosted by the malicious actor.
CNAME record considerations
The example presented above considers a DNS A Record. However, this issue also impacts CNAME Records and can often be easier to exploit by malicious actors due to the custom nature of services such as S3 and Elastic Beanstalk in AWS for example. Thus, if you use CNAME records as part of S3 bucket hosting – you should consider record hygiene as part of your decommissioning process.
Manually identifying offending records
The quickest way to identify dangling DNS records at scale is via the extensive APIs made available by cloud service providers (CSPs). I will discuss AWS in a little more detail below, but the steps are largely the same for all CSPs:
- Query the DNS service for a list of your A and CNAME records.
- Query the compute service for a list of all your elastic and public IP addresses.
- If necessary, query additional services such as S3 for CNAME relationships.
- Cross reference the results to identify where a record exists, but an IP or service does not.
- Perform the relevant clean up of your DNS records.
- Update deployment and decommissioning procedures to include a DNS cleanup step.
Automated method for identifying records
The following is a project I developed to identify dangling DNS A Records in AWS accounts and alert the relevant team for remediation via Slack message. Currently the scope of this project is for A Records only, I aim to add CNAME Record identification at a later date.
The Dangling DNS Scanner is deployed to Lambda in your AWS account via Terraform. The function can be scheduled to run periodically and retrieve all A Records across Route53 Hosted Zones for a given account. The IP addresses associated with these records are then cross-referenced against the Elastic and Public IP addresses in the account. If a potential dangling record is identified, a Slack message is sent to a dedicated channel to alert the relevant team to investigate and remediate if necessary.
Sample Slack message for a dangling record
Project details & caveats
A few additional details and caveats you should know about:
:: As mentioned, at present the Lambda only checks for A Records – CNAME records are not part of the queries.
:: The project is intended to be a best effort and may of course, contain bugs (I am not a Software Engineer). If you do encounter a bug, please open a pull request on GitHub. Additionally, if you see an opportunity for improvement – please let me know.
:: Finally, you should never clone something directly from the internet and run it in a production environment. All testing has been done in a test/development environment. Please test rigorously before considering a production scan.
Future work
- Extend the script to check for CNAME dangling records connected to other AWS services such as S3 and Elastic Beanstalk.
- Add optional remediation functionality that would automatically update records to remove offending IPs or CNAMEs.
- Improve the processing time and account for large numbers of Route53 records in a hosted zone(s).
Fin.
Thanks for taking the time to read this post. I hope it has been useful in understanding the need for routine audits of your cloud DNS configuration to identify dangling records. If you have any feedback/corrections please feel free to reach out to me via the email below or on LinkedIn. I’d love to hear from you!
-Dan