Acorn Newsbot
Junior Member
- Joined
- Jan 28, 2006
- Posts
- 22,606
- Reaction score
- 126
The word ‘dangling’ always seems a bit comical to me. However, apply it to the world of the Domain Name System (DNS) and it becomes no laughing matter – but what does it mean? To understand what it is and the issues around dangling DNS, it’s important to first understand the basics of DNS.
The DNS is, fundamentally, a large distributed database used to store the mappings of name-to-address and address-to-name on the internet. This allows users to type in a recognisable domain name (e.g. nominet.uk) and get connected to the numerical IP address. In this database, the authority to update records is delegated down a tree structure. The name server (NS) records – which lists which servers are providing the DNS services for that domain name – are placed at the parent child cut, to delegate responsibility from above to below.
For example, I register brett.uk and provide the NS records of ns1.mydnsserver.com and ns2.mydnsserver.com to the registry. They place these in the .UK DNS zone, which allows me to enter records for my zone as I see fit on my DNS servers. Because no single entity controls the whole tree, anyone is at liberty to enter any records they want at their delegated level. Unfortunately, this also means they can manage their part of the tree badly and not give it the attention it may need: this is when dangling DNS issues may arise.
The term ‘dangling DNS’ doesn’t really refer to any specific problem; think of it as an over-arching term that encompasses all problems that are due to bad maintenance of DNS records. Most commonly, the problems relate to failing to remove records from the zone once they are no longer needed. These can occur in various scenarios; let’s look at a few different examples:
Example 1: IP Address re-use
My company decides to stand up a new service/application in the cloud and uses an elastic IP resource of 1.2.3.4. These IP addresses are loaned to me by the cloud provider for use in the cloud-based application, and I create the name to address mapping records in my DNS zone. In this case, I use my-new-app.brett.uk A 1.2.3.4 and my clients access my company’s service by using it.
One day, my company decides to turn off this service and return the loaned address to the cloud provider. Unfortunately, we forget to remove the DNS record from our zone, leaving it dangling. Cyber criminals might notice this dangling DNS by scanning the DNS zones, and could attempt to pick up the associated IP address from the cloud provider. If they do, they will be able to see the traffic that is still being sent to that old service, which could include sensitive information like authentication details.
Example 2: Hanging CNAME
My company develops a new application, but this time we use a CNAME (or alias) to map our advertised, easy-to-read application name to another less readable name we may have been given by a third party, such as:
my-new-app.brett.uk CNAME an-assigned-name.some-domain.com
As before, our clients use our services via the name we have assigned. Eventually, my company decides to turn off the service and release the name an-assigned-name.some-domain.com back to whoever assigned it. However, we forget to remove the my-new-app.brett.uk. Anybody can now register/control the previously assigned an-assigned-name.some-domain.com and they can then see any traffic still arriving at our decommissioned service; they can also use it in any way they wish.
Example 3: Cloud based DNS
It is becoming increasingly common for enterprises to use cloud-based DNS services such as Cloudflare or AWS route 53. During the sign-up for these services, the provider supplies NS records to your company for insertion into the parent zone for the delegation, and then provides a control panel where you can add/remove DNS records. In this situation, there are two ways in which problems can occur with dangling DNS:
In both these situations, NS records are present in the parent and point at the cloud provider but are not present in their system. Attackers regularly scan for domains in this state and then simply add them to the associated cloud provider. This allows them to add or remove records at will, including mail server (or MX) records that enable them to get mail delivered for the domain to their systems.
Take more care
Dangling DNS issues are usually the result of a lack of diligence in removing or updating entries in DNS, leaving attackers with an opportunity to hijack traffic to your services or – in extreme cases – take over a domain completely. This can easily be avoided by ensuring that whenever services are decommissioned, all associated records with that service are removed to ensure they can’t be re-used in unexpected and unwelcome ways.
It can be easy to forget to maintain DNS zones properly, so I would advise a regular audit and clean-up of your DNS to make sure you are always fully aware of its content and minimise any opportunities attackers have against your services. Think of it like cooking a fine dinner with all the trimmings: once you’ve eaten, you need to clean up the kitchen or else the scraps of food and detritus will attract vermin and bacteria, causing you unnecessary harm and headache. Make de-dangling it a habit and you will stay secure.
Find out more about Nominet’s cyber security services based on DNS analytics on our website.
The post Dangling DNS is no laughing matter appeared first on Nominet.
Continue reading...
The DNS is, fundamentally, a large distributed database used to store the mappings of name-to-address and address-to-name on the internet. This allows users to type in a recognisable domain name (e.g. nominet.uk) and get connected to the numerical IP address. In this database, the authority to update records is delegated down a tree structure. The name server (NS) records – which lists which servers are providing the DNS services for that domain name – are placed at the parent child cut, to delegate responsibility from above to below.
For example, I register brett.uk and provide the NS records of ns1.mydnsserver.com and ns2.mydnsserver.com to the registry. They place these in the .UK DNS zone, which allows me to enter records for my zone as I see fit on my DNS servers. Because no single entity controls the whole tree, anyone is at liberty to enter any records they want at their delegated level. Unfortunately, this also means they can manage their part of the tree badly and not give it the attention it may need: this is when dangling DNS issues may arise.
The term ‘dangling DNS’ doesn’t really refer to any specific problem; think of it as an over-arching term that encompasses all problems that are due to bad maintenance of DNS records. Most commonly, the problems relate to failing to remove records from the zone once they are no longer needed. These can occur in various scenarios; let’s look at a few different examples:
Example 1: IP Address re-use
My company decides to stand up a new service/application in the cloud and uses an elastic IP resource of 1.2.3.4. These IP addresses are loaned to me by the cloud provider for use in the cloud-based application, and I create the name to address mapping records in my DNS zone. In this case, I use my-new-app.brett.uk A 1.2.3.4 and my clients access my company’s service by using it.
One day, my company decides to turn off this service and return the loaned address to the cloud provider. Unfortunately, we forget to remove the DNS record from our zone, leaving it dangling. Cyber criminals might notice this dangling DNS by scanning the DNS zones, and could attempt to pick up the associated IP address from the cloud provider. If they do, they will be able to see the traffic that is still being sent to that old service, which could include sensitive information like authentication details.
Example 2: Hanging CNAME
My company develops a new application, but this time we use a CNAME (or alias) to map our advertised, easy-to-read application name to another less readable name we may have been given by a third party, such as:
my-new-app.brett.uk CNAME an-assigned-name.some-domain.com
As before, our clients use our services via the name we have assigned. Eventually, my company decides to turn off the service and release the name an-assigned-name.some-domain.com back to whoever assigned it. However, we forget to remove the my-new-app.brett.uk. Anybody can now register/control the previously assigned an-assigned-name.some-domain.com and they can then see any traffic still arriving at our decommissioned service; they can also use it in any way they wish.
Example 3: Cloud based DNS
It is becoming increasingly common for enterprises to use cloud-based DNS services such as Cloudflare or AWS route 53. During the sign-up for these services, the provider supplies NS records to your company for insertion into the parent zone for the delegation, and then provides a control panel where you can add/remove DNS records. In this situation, there are two ways in which problems can occur with dangling DNS:
- My company sets up cloud-based DNS and it all works fine. When we decide to decommission the service, we forget to remove the NS records for the cloud provider from the parent zone and so leave these records dangling.
- My company has set up multiple zones with my cloud provider and they always issue the same two NS records. For the new DNS zone we are setting up, we add the known NS records to the parent zone in advance of the set-up procedure with the cloud provider so all is ready to go. Then life happens, and my attention is taken elsewhere and I forget to complete the process and add the zone to the cloud provider. The NS records in the parent are left dangling.
In both these situations, NS records are present in the parent and point at the cloud provider but are not present in their system. Attackers regularly scan for domains in this state and then simply add them to the associated cloud provider. This allows them to add or remove records at will, including mail server (or MX) records that enable them to get mail delivered for the domain to their systems.
Take more care
Dangling DNS issues are usually the result of a lack of diligence in removing or updating entries in DNS, leaving attackers with an opportunity to hijack traffic to your services or – in extreme cases – take over a domain completely. This can easily be avoided by ensuring that whenever services are decommissioned, all associated records with that service are removed to ensure they can’t be re-used in unexpected and unwelcome ways.
It can be easy to forget to maintain DNS zones properly, so I would advise a regular audit and clean-up of your DNS to make sure you are always fully aware of its content and minimise any opportunities attackers have against your services. Think of it like cooking a fine dinner with all the trimmings: once you’ve eaten, you need to clean up the kitchen or else the scraps of food and detritus will attract vermin and bacteria, causing you unnecessary harm and headache. Make de-dangling it a habit and you will stay secure.
Find out more about Nominet’s cyber security services based on DNS analytics on our website.
The post Dangling DNS is no laughing matter appeared first on Nominet.
Continue reading...
