Dangling DNS Records, Placeholder Domains, and the Cost of Lazy IT

Dangling DNS records and careless placeholder domains can send traffic or information somewhere it does not belong. At FOO.XYZ, we receive unexpected DNS requests and sensitive emails that appear intended for other organizations. This article explains how these mistakes differ and how to check for them.

One possible cause is our domain appearing in copied configurations. Programmers often use foo, bar, and baz as stand-in names, but foo.xyz is a real registered domain belonging to FOO.XYZ. That does not prove where every request came from. We are describing the problem without sharing private messages, logs, or sender details.

What is a dangling DNS record?

DNS, the Domain Name System, helps computers find services by name. A DNS record is an entry that supplies information about a name. A CNAME record makes one name an alias of another, such as a company subdomain pointing to a cloud service.

A dangling DNS record remains after its destination is removed or falls outside the owner's control. For example, a team deletes an old cloud application but leaves its CNAME behind. The public name still refers to a resource the team no longer runs.

If someone else can claim that destination and serve content through the old name, a subdomain takeover may be possible. The attacker controls what visitors reach through that subdomain. They do not necessarily control the parent domain or its DNS account.

Not every dangling record is exploitable. A provider may block reuse or require proof of domain ownership. A failed lookup alone does not prove takeover is possible. Microsoft's guidance on preventing subdomain takeover explains this risk and some provider-specific protections.

The problem with placeholder domains

A sample configuration often becomes the starting point for a working system. Someone copies it, changes the password and server address, then overlooks a hostname or notification recipient. The example now runs with a real domain that belongs to someone else.

Consider ns1.foo.xyz, api.foo.xyz, and admin@foo.xyz. These are illustrative examples, not verified FOO.XYZ infrastructure or a claim that those services or mailboxes exist. The first resembles a name server, the second an application endpoint, and the third an email address.

A familiar programming word does not make the whole domain safe for testing. Neither foo.xyz nor bar.xyz is a reserved example domain. A setting that looks harmless on a documentation page can become a real destination when software runs.

Why FOO.XYZ receives unexpected DNS requests

Copied settings are one possible source. A forgotten development environment might keep looking up an old hostname. A hardcoded name, written directly into an application's code, may survive even after someone updates its configuration file.

Automated scanners and general background DNS traffic are other possibilities. A DNS resolver looks up names on behalf of clients, so the visible source may be that resolver. A query by itself rarely tells the whole story about the device, application, or person behind it.

A DNS request asks for information. It does not necessarily mean that an application connected to the resulting address, sent data, or suffered a breach. Establishing that chain requires separate evidence, and unexpected requests should not all be blamed on misconfiguration.

When DNS mistakes turn into email leaks

Suppose an application is configured to send alerts to admin@foo.xyz instead of an address its operator controls. If the receiving mail system accepts that address, real notifications could reach an unrelated organization. This is a hypothetical example, not a description of a particular message we received.

An MX, or mail exchanger, record identifies the mail servers for a domain. Sending systems use DNS to find where to deliver mail. The SMTP standard describes that delivery process, including DNS lookups.

DNS can work correctly while the recipient is wrong. It finds the destination for the address the application supplied; it cannot infer which organization the sender meant. An accepted message might expose operational details even though no attacker changed a DNS answer.

Testing should therefore check recipients as well as delivery success. Use a controlled test mailbox or a mail-capture tool with external delivery disabled. If real information has gone to the wrong address, stop further sends and follow your organization's incident process.

Why placeholder domains are a bad idea

The problem is using an arbitrary real domain as a placeholder. RFC 2606 reserves example.com, example.net, and example.org for examples. Names such as api.example.com make sense in documentation without borrowing another business's identity.

The same RFC reserves .test for testing and .invalid for names intended to be invalid. RFC 6761 explains their special handling. Use .test in a controlled test environment, with local DNS configured when needed. Use .invalid when a name should not resolve in normal DNS.

Reserved names do not create a working production service. An example domain may have public DNS answers, and applications may still attempt requests. Do not send private data to it or rely on it as a production dependency. Real deployments need approved domains, endpoints, and recipients under the right ownership.

Dangling DNS records and placeholder mistakes aren't the same thing

A dangling record is a stale reference in DNS. Its destination was removed or is no longer controlled by the expected owner. The risk can include failed connections or a takeover if another party can claim the destination.

A placeholder mistake starts with the wrong name or address in a configuration. The referenced domain may be active and correctly managed. No abandoned resource or takeover is required for a message to reach the wrong organization.

DNSSEC protects DNS answers against forgery, but it does not fix either ownership mistake. A signed answer can still point to a stale destination. It can also faithfully resolve a domain that an application should never have used.

Why these problems keep happening

Copied configurations save time, but they need review before use. A test that checks only whether an application starts can miss a wrong recipient. Ignored delivery failures and lookup errors let that mistake survive.

DNS inventories also lose value when nobody owns them. Each record should have a purpose, a responsible team, and a link to the service it supports. Removing a cloud application should trigger a review of its DNS records and any references left in other systems.

Leaving those jobs for someone else is careless IT practice. The cost is not just untidy configuration: it can mean outages, exposed information, and time spent investigating avoidable problems. Regular review matters more than assuming an old setting must be safe because it has always been there.

How to check your own DNS configuration

Start with records and systems you manage. dig is a command-line DNS lookup tool; the Dig and Drill troubleshooting guide explains the basics. The following commands are examples, not reported test results. DNS lookups do not change your records.

dig testing.example.com CNAME

This asks your configured resolver for a CNAME at the example name. Replace it with a hostname you manage for a useful check. If an alias is returned, compare its destination with your service inventory and provider account. No CNAME answer alone proves neither safety nor vulnerability; check the response status too.

dig example.com MX

This requests the domain's mail-routing records. Use your own domain when reviewing production mail. An MX answer does not prove a particular mailbox exists, accepts messages, or belongs to the intended recipient. Confirm the application's actual recipient settings separately.

Before searching configuration files, work in an authorized directory and keep the output private. Matching lines may contain secrets. From your project directory, run:

grep -RniE 'foo\.xyz|bar\.xyz|example\.(com|net|org)' ./config

grep searches text. Here, -R searches recursively and follows symbolic links, -n prints line numbers, and -i ignores letter case. -E enables the pattern syntax; the escaped dots match literal dots. Check where links lead before searching.

Matches are leads for review, not proof of a problem. Documentation may contain valid examples. This search also misses other domains, remote settings, and values supplied when an application starts. A clean result is not a complete audit.

A little cleanup goes a long way

Use reserved example domains in documentation, then require real, approved values before production starts. Test where notifications go without sending sensitive data. Review old DNS records against the services your team still owns.

Before removing a record, confirm its purpose and dependencies with the owner. Keep a change record and account for cached answers during the transition. Make that review part of retiring a service, so abandoned records do not become the next team's problem.

Need Help With Your DNS or Network Security?

FOO.XYZ helps businesses with DNS and network troubleshooting, routing, servers, network security, and Linux/FreeBSD infrastructure. Discuss incorrect DNS records, unwanted traffic, or misdirected notifications with us to agree on the scope of a review.

Phone: (213) 212-8317

Email: hello@foo.xyz

FOO.XYZ serves businesses in Los Angeles. Scope and scheduling are agreed before work begins.