We did another partial scan of a Tranco top 100,000 popular websites domains to look for more dangling DNS problems. As expected we found many more — around 345 candidates. You can see some of our past research via https://dnsinstitute.com/research/dangling-dns/. This article briefly introduces the various types of Dangling DNS with examples.
DNS Institute has have been analyzing and reporting about DNS mistakes for years, including defining multiple novel techniques for detecting dangling DNS problems. Our DNS Institute DNS Analyzer detects near 200 anomalies as defined by RFC requirements, government mandates, and registry best practices.
In simplest terms, Dangling DNS is where a resource doesn't point to where it was intended. This could be due to a typo or misspelling, or losing track of names and IP addresses which may have changed or expired. In many cases, the problems are not noticable, but sometimes may be exploited to take advantage of mistaken identity. This may be done by registering the mistake domains or getting old IP addresses newly assigned for non-authenticated communications.
The DNS resource record types involved include any that have a target or assignment which potentially can be taken over, such as SPF includes and allowed IP ranges, HTTPS/SVCB targets, NS nameservers and delegations, SRV targets, MX mail servers, DNAME aliases, CNAME aliases, IP address records, etc. The following are brief descriptions of the various types of Dangling DNS.
Targets of various Dangling DNS domains may be expired or unregistered and may be registered again, such as via an ICANN-designated registrar. Here are a few examples (of hundreds we have found):
guardian.ng. 300 IN MX 5 email.guadian.ng.
todtv.com.tr. 300 IN MX 15 as1.digituk.com.tr.
Often organizations still own the target parent domain — maybe referenced from the same domain — but due to name changes or typo, it refers to a name that does not exist under the domain they control. Note if the DNS is managed by a third-party, then they already have control of the situation so this shouldn't introduce new problems (unless they are trying to hide exploits). We have found hundreds of thousands of examples of this. The following example shows the missing target MX for a domain is under its own domain:
genealogy.net. 300 IN MX 10 134.102.123.245.genealogy.net.
(Maybe that was caused by simple mistake: listing an IP address for a mail server which is a domain without a trailing period so became part of the parent zone.)Another example of different domains, but (appears) to be the same company:
sony.jp sony.jp. 300 IN MX 100 mail.enet.sony.co.jp.
The domain referenced may be controlled by a third-party who is currently unlikely to abuse or take advantage of a mistake. Examples are typo for MX mail servers such as atl1.aspmx.l.google.com. and us-smtp-inbounb-1.mimecast.com. The target organization already has a relationship to offer the mail service so makes no sense to repurpose or use malice for mistakes like this. Examples of third-party control domains which may be utilized to take over a target include the following Squatted/Reseller domains and Sub-domain providers.
Another scenario is when a third-party provider no longer provides the intended service for the assigned domain and others who are unrelated can register with the service provider and take over a previously assigned domain name. This is called "Sitting Ducks" and our research initiated prior to the vulnerability accouncement is at https://dnsinstitute.com/research/2024/hijack-registered-domains-202408.html. As you can see, there is a close relationship with various dangling DNS types and lame servers scenarios.
Many Dangling DNS target domains currently still resolve because they are owned and managed by third-party domain resellers or squatters. Detecting these is more difficult since often errors are not quickly seen when using the domain names that utilize these unknown targets. (DNS Institute has maintained and extended a database of squatters and resellers for over five years to help detect these.) Check out this example:
cssdrive.com. 86400 IN NS dns2.javascriptkit.com.
(This is an interesting example as there is two different dangling DNS: parent TLD nameserver delegations still work but using wrong name and working glue address; and the now real DNS for the authoritative NS targets are available for sale.)
Dangling DNS targets may also be under subdomains that exist and managed by dynamic DNS or free domain hosting providers. The use of these targets may or may not result in DNS failures so they may be more difficult to quickly identify. (DNS Institute utilizes third-party sub-domain provider lists plus supplements it with its own list.) In our research of the top 100,000 in the Tranco list, we found only 30 candidates and none appear to be exploitable. Two examples are:
tstt.net.tt. 60 IN MX 10 tstt-elb-1272377737.us-east-1.elb.amazonaws.com.
footballshirtculture.com. 86400 IN NS ns2.148-251-69-212.cprapid.com.
As with dangling domains an organization owns, they may also have names that point to addresses under their assigned networks that are dangling — that is IP addresses they are assigned to but nothing at that address legitimately handles the intended destination service.
Often unknowingly or purposely internal LAN addresses using private address space is used in the public internet. The assumption is that the target internal IP addresses shouldn't be routed and won't be used. Other IP addresses that can be misused include documentation-reserved addresses. If the DNS address is resolved and used in an organization that utilized the same private address ranges, there may be unexpected consequences. For example, a device there not in control of the LAN operators may be able to accept DNS or mail server connections without others' knowledge. (See these three brief discussions with feedback warning about this at 1, 2, 3.) Do you know of any security papers or compromise examples based on this?
Check out these few examples:
stjohns.edu. 21600 IN NS awsdns2.stjohns.edu. awsdns2.stjohns.edu. 21600 IN A 10.242.152.182(While not in the parent edu delegation, it is one of their nameservers and likely some other large organization has the same IP address — as if it is running a DNS service for that same domain that is another story to consider.)
Here is another example:
vu.edu.pk. 900 IN MX 50 mail1.vu.edu.pk. mail1.vu.edu.pk. 900 IN A 172.16.103.45(While it is a lower priority than its main mail server, maybe some other large organization could see email for @vu.edu.pk and use that IP address.)
Also many DNS addresses use localhost addresses which may have unintended behavior. Even if 0.0.0.0 or 127 addresses aren't used to compromise or capture email or DNS, it may trigger unnecessary attempts.
If the target DNS points to a public IP address that is no longer in control of by the domain owner or its (target) service provider, potentially someone else will soon gain ownership of it. This is becoming very common with cloud providers and with IPv4. (We are currently researching detection methods for this.) This can also be caused by typos too.
Various other typos in DNS may not be considered Dangling DNS. especially if they cause errors where they normally cannot be abused. Examples are using IP addresses as MX mail server targets as domains ending with a TLD of just digits should not resolve. But since you don't know what environments where the DNS is used, there is still potential for abuse. We have 20 articles about typos in DNS such as https://dnsinstitute.com/research/2020/dns-mistakes-part-2-typos.html. For more formal descriptions of Dangling DNS with many more examples, follow our research at https://dnsinstitute.com/research/dangling-dns/.
Please let us know how you analyze your DNS. If you'd like a demo or would like us to automate analysis for you (with full citations and consulting as needed), let us know.
(For information about the source list of domains, see A Research-Oriented Top Sites Ranking Hardened Against Manipulation (Tranco).)
Gab
Twitter