Newly Registered Domains: Risk, Feeds and Blocking Policy
A newly registered domain (NRD) is a name that appeared in DNS recently. Security teams treat age as a risk signal because attackers burn through fresh domains quickly. This guide covers the evidence, where NRD lists come from, and how to use them without breaking legitimate traffic.
What "newly registered" means in practice
There is no standard definition. Vendors usually pick a window of 24 hours, 7 days, 14 days, 30 days or so, and call anything inside it an NRD. The choice matters more than it looks, because the same domain can be an NRD in one feed and ordinary in another.
Three different events get lumped together under the label:
- First registration. The name was never in the zone before, or it was deleted long ago and is being registered fresh.
- Re-registration after a drop. A previously used name was deleted, then registered by someone new. Its history (old backlinks, old mail reputation) may still follow it. See the domain lifecycle for how a name gets there.
- Newly delegated. The registration is older, but the domain only just received nameservers, so it first appears in the zone today.
A feed built from DNS data can see the first and third events, and often the second. It cannot see a change of ownership, because a transfer or sale does not alter the delegation.
Why age is a security signal
Phishing kits, malware command-and-control and spam campaigns need infrastructure that has no bad reputation yet. Blocklists work by remembering past abuse; a domain registered this morning has none. Attackers therefore register in bulk, use the names for hours or days, and discard them when they are listed.
The best-known public analysis is Palo Alto Networks Unit 42's 2019 article "Newly Registered Domains: Malicious Abuse by Bad Actors". Using March to May 2019 data, the authors reported that more than 70% of NRDs they examined fell into a malicious, suspicious or not-safe-for-work category, roughly ten times the rate (about 7.6%) in a reference set of Alexa's top 10,000 domains. Strictly malicious categories (malware, command and control, phishing) were a much smaller slice, about 1.27% in their data against about 0.07% for the reference set. The authors counted a domain as new for 32 days and recommended blocking or at least alerting on NRDs.
Read those figures carefully. The 70% figure combines malicious, suspicious and not-safe-for-work classes, and only a small part of it is confirmed malware, command and control or phishing. The finding is that a new domain is statistically riskier than an old one, not that most new domains are criminal. It is also one vendor's classifier on 2019 traffic.
Anti-abuse organisations such as Spamhaus publish periodic domain reputation reports that look at how many domains in each TLD are very new compared with the size of the zone. A zone where almost everything is recent is a sign of high churn, which is a useful hint but not proof of abuse. Reputation also varies between registrars and between price tiers within the same TLD, so avoid blanket rules based on the TLD alone.
Where NRD lists come from
| Source | What it sees | Weak spot |
|---|---|---|
| Daily zone-file diff | Names that entered a TLD zone since the last snapshot | Only TLDs whose zone you can obtain; one-day granularity; no registrant data |
| Certificate Transparency logs | Names for which a certificate was issued | Misses sites without TLS; includes old domains getting new certificates |
| Passive DNS | Names that someone queried | Depends on sensor coverage; a name nobody queried is invisible |
| Registrar or registry feeds | True creation events | Contractual, limited to the provider's own customers or TLDs |
| WHOIS/RDAP creation date | The registration date of one known name | Per-name lookup, rate limited; not a discovery mechanism |
Most commercial feeds blend several of these. A zone diff is the easiest to reproduce yourself and gives complete coverage of the TLDs it applies to, which is the approach behind the newly registered domain lists on this site.
Building an NRD list from zone-file diffs
A TLD zone file lists the delegated second-level names, one set of records per delegation. Download it once a day, extract the unique names, sort, and compare with yesterday's snapshot:
# names.txt = unique, lower-cased second-level names, one per line
sort -u today.txt > today.sorted
sort -u yesterday.txt > yesterday.sorted
comm -13 yesterday.sorted today.sorted > added.txt # new today
comm -23 yesterday.sorted today.sorted > removed.txt # gone todayadded.txt is your NRD candidate list and removed.txt is the raw material for expired and dropped lists. Both need cleaning before use.
What pollutes a raw diff
- Returning names. A domain placed on hold (for non-payment or a dispute) leaves the zone, then re-enters when resolved. It looks new but is not.
- Nameserver changes. If you diff whole records rather than names, every NS change looks like churn. Diff the name set only.
- Short-lived registrations. A name registered and deleted between two snapshots never shows up. Registries have grace rules that let registrars cancel quickly, and abusers exploit them.
- Missing or partial snapshots. A failed download makes thousands of names appear "new" the next day. Sanity-check the size of each file against the previous one.
Limits that no diff can fix
A zone file shows that a delegation exists. It does not show who registered the name, when the registrar actually created it, or whether the name is in use. A name can be registered days before it is delegated, and some registries publish zone updates only a few times per day. Names without nameservers never appear at all. Treat the diff as "first seen in DNS" and label it that way. Details on the source are in the guide to zone files and ICANN CZDS.
Policy choices: block, challenge, or watch
Blocking all NRDs is the strongest control and the most disruptive. Most organisations end up with a graduated policy instead.
| Action | Typical use | Cost |
|---|---|---|
| Log only | First weeks of a rollout; threat hunting | No protection; large volumes to review |
| Alert on first contact | Servers, finance users, SOC triage | Analyst time |
| Browser isolation or warning page | General staff web traffic | Friction; users learn to click through |
| Block DNS resolution | Servers, kiosks, email link rewriting | Breaks legitimate launches and partners |
| Block outbound email from or to NRDs | Invoice and payment workflows | Delays from new suppliers |
A common compromise is to use a shorter window for blocking (for example a week or two) and a longer window for alerting, with an exception list for known partners.
False positives and how to cut them
Legitimate new domains are not rare: product launches, campaign microsites, acquisitions, event pages, and brand-protection registrations. They tend to share some traits that you can use to reduce noise:
- The registrant or its sibling domains are already known to you. Compare with an allowlist of partner and vendor names.
- The new name is a close variant of a domain your own organisation owns.
- Nameservers belong to a mainstream DNS provider already used by trusted sites, as opposed to a throwaway host. The DNS nameserver providers overview shows common providers.
- Combine age with other signals: lookalike of a brand, newly issued certificate, newly seen infrastructure, URL shape such as login paths, or a user's first visit. Age alone is a weak score; age plus two more is strong.
Build an explicit exception process. If staff cannot get a legitimate site unblocked within the hour, they will find ways around the control. Track how many blocks were later overturned and review the window length every quarter.
Practical checklist
- Define NRD precisely (source, window, timezone) and write it down.
- Start in log-only mode and measure what users actually touch.
- Strip returning names and check each snapshot for completeness.
- Join NRD data with lookalike detection (see typosquatting and lookalike domains) rather than using it alone.
- Keep an allowlist and a fast exception path.
- Re-check a domain's age with RDAP at decision time for high-value cases.
Sources
- Palo Alto Networks Unit 42 (20 August 2019): Newly Registered Domains: Malicious Abuse by Bad Actors
Frequently asked questions
What is a newly registered domain?
A domain that was registered, or first appeared in DNS, within a chosen recent window, commonly 24 hours to 30 days. There is no official definition, so always check how a given feed defines it.
Are most newly registered domains malicious?
No. Unit 42's 2019 analysis classed over 70% as malicious, suspicious or not safe for work, but only about 1.27% as confirmed malware, command-and-control or phishing. New domains are riskier than old ones on average, which is different from being mostly malicious.
Can I find newly registered domains from zone files alone?
Yes, as "first seen in the zone". Compare today's list of names with yesterday's. You will miss names that were created and removed between snapshots, names without nameservers, and TLDs whose zones you cannot access, and you will wrongly include names that returned from hold.
Should a company block all NRDs?
Only where the business can tolerate it. Servers, payment systems and email gateways are good candidates. For general browsing, warning or isolation with a quick exception path usually causes less disruption than a hard block.
How does a zone diff differ from a WHOIS creation date?
A diff tells you when a name entered DNS. The creation date in WHOIS or RDAP tells you when the registrar registered it, which can be earlier. RDAP is per-name and rate limited, so use the diff for discovery and RDAP for confirmation.
Do ownership changes make a domain "new"?
Not in DNS data. A sale or transfer leaves the delegation unchanged, so zone-based feeds cannot flag it. Some vendor definitions count ownership change as new; zone diffs do not.