DNS Record Set Deduper

The DNS Record Set Deduper analyzes zone files or DNS record lists to identify duplicate entries, conflicting configurations, and redundant records that cause unpredictable resolution behavior. Paste your zone file contents and get a cleaned output with exact duplicates removed, TTL conflicts resolved, and CNAME violations flagged.

Understanding DNS Record Duplication

DNS zones accumulate cruft over time. Every administrator who has inherited a zone file from a predecessor knows the feeling: hundreds of records, some clearly outdated, some suspiciously similar, and no documentation explaining which ones are actually needed. Duplicate and conflicting records do not always cause obvious failures -- they cause intermittent, hard-to-diagnose problems that waste hours of troubleshooting time.

The most dangerous type of duplication is the CNAME conflict. The DNS specification (RFC 1034) is explicit: if a CNAME record exists at a name, no other record types can exist at that same name. When this rule is violated, different DNS resolvers handle the conflict differently. Some return the CNAME and ignore the A record, others return the A record and ignore the CNAME, and some return a SERVFAIL error. The result is that your service works from some locations but not others, or works intermittently, depending on which resolver the client happens to use. These failures are notoriously difficult to track down because the symptoms do not point to DNS as the root cause.

Less dramatic but still problematic are exact duplicates and TTL-differing duplicates. Exact duplicates (same name, type, and value appearing twice) are harmless but add noise to your zone and make maintenance harder. TTL-differing duplicates (same name, type, and value but different TTL) can cause caching inconsistencies: one resolver might cache the record for 300 seconds while another caches it for 3600 seconds, leading to different behavior across clients. This deduper scans for all these categories and provides clear recommendations for each issue found.

How to Deduplicate DNS Records

1. Paste your zone file contents or a list of DNS records (name, type, TTL, value)
2. The deduper scans for exact duplicates, TTL-differing duplicates, and CNAME conflicts
3. Review each flagged issue with its explanation and suggested resolution
4. Accept or reject suggested changes for each category
5. Copy the cleaned output with duplicates removed and conflicts resolved

Types of DNS Duplicates Detected

Exact Duplicates

Records where name, type, and value are identical -- only one is needed.

; Before deduplication
www    A    203.0.113.10
www    A    203.0.113.10    <- duplicate

; After deduplication
www    A    203.0.113.10

TTL-Differing Duplicates

Same name, type, and value but different TTL values. DNS servers may return unpredictable TTLs.

; Before -- conflicting TTLs
api    A    300    198.51.100.5
api    A    3600   198.51.100.5

; After -- keep lowest TTL
api    A    300    198.51.100.5

CNAME Conflicts

A name has both a CNAME record and other record types, which violates RFC 1034. CNAME records must be the only record at a name (except for DNSSEC-related types).

; Invalid -- CNAME coexists with A record
shop    CNAME    store.example.com.
shop    A        203.0.113.20       <- conflict

; Resolution: choose CNAME or A, not both

Multiple CNAMEs

Multiple CNAME records for the same name is invalid -- a name can have at most one CNAME.

; Invalid -- two CNAMEs for same name
cdn    CNAME    d1234.cloudfront.net.
cdn    CNAME    cdn.otherprovider.com.  <- conflict

When to Use the DNS Record Set Deduper

• Consolidating zones from multiple DNS providers or administrators into a single zone
• Cleaning up legacy zones that have accumulated redundant entries over years of manual edits
• Pre-migration validation before moving zones between DNS providers to avoid carrying over problems
• Troubleshooting intermittent DNS resolution that might stem from conflicting records
• Post-merge cleanup after combining zone files from acquired companies or merged departments
• Periodic zone hygiene as part of regular DNS administration practice

How DNS Record Conflicts Cause Problems

Unpredictable Resolution

When duplicate records with different TTLs exist, DNS caches may store different TTL values depending on which response they received first. This leads to inconsistent caching behavior across different resolvers, making debugging difficult.

CNAME Violations

The DNS specification (RFC 1034, Section 3.6.2) states that if a CNAME record is present at a node, no other data should exist at that node. When this rule is violated:

• Some resolvers return the CNAME, ignoring other records
• Other resolvers return the A/AAAA records, ignoring the CNAME
• Some resolvers return an error (SERVFAIL)
• Behavior may vary by resolver software and version

Zone Apex CNAME Issues

A common mistake is placing a CNAME at the zone apex (example.com), which conflicts with the required SOA and NS records. This is always invalid. Use ALIAS or ANAME records (provider-specific) or A/AAAA records instead.

Deduplication Statistics

The deduper provides a summary of actions taken:

Zone Maintenance in Practice

The best time to deduplicate a zone is before a migration. When you move your DNS from one provider to another, you are typically exporting the zone from the old provider and importing it into the new one. This is the ideal moment to clean up the zone because you are already touching every record. Run the zone through the deduper, resolve the flagged issues, and import the cleaned version. You avoid carrying years of accumulated problems into your new infrastructure.

For ongoing maintenance, make zone deduplication part of your regular change management process. Every time you make DNS changes, run the deduper against the zone before and after the change. Before the change, it catches pre-existing problems that might interfere with your new records. After the change, it catches accidental duplicates you might have introduced. This is especially important in environments where multiple administrators make changes, because coordination mistakes are the most common source of duplicate records.

A practical tip for large zones: focus on CNAME conflicts first, because those are the records most likely to cause production issues. Exact duplicates and TTL mismatches are lower priority because they typically cause subtle rather than breaking problems. If your deduper flags a CNAME conflict, resolve it immediately -- do not wait for a scheduled maintenance window, because CNAME conflicts can cause intermittent outages that are actively harming your users right now.

Frequently Asked Questions

Is it safe to have multiple A records for the same name?

Yes. Multiple A records for the same name is a valid and common DNS configuration called round-robin DNS. For example, www.example.com can have multiple A records pointing to 203.0.113.10 and 203.0.113.11 for basic load distribution. The deduper does not flag these as duplicates because the values differ.

What should I do when a CNAME conflict is detected?

Decide whether the name should be an alias (CNAME) or have its own direct records (A/AAAA/MX/etc.). A CNAME redirects all queries for that name to the target, so you cannot have both a CNAME and an MX record at the same name. If you need both web hosting and email at a name, use A/AAAA records instead of CNAME.

Does the deduper handle DNSSEC records?

The deduper correctly recognizes that DNSSEC records (RRSIG, NSEC, NSEC3) can coexist with CNAME records, which is an exception to the standard CNAME exclusivity rule defined in RFC 4035.

Why do I have duplicate records if I only have one administrator?

Duplicate records often accumulate through small operational habits: re-adding a record that was temporarily removed for testing, pasting records from documentation without checking if they already exist, or applying Terraform or Ansible configurations that do not check for pre-existing records. Automated provisioning tools are especially prone to creating duplicates if they use create-only operations without checking for existing records first.

Should I keep the higher or lower TTL when resolving TTL conflicts?

In most cases, keep the lower TTL. A lower TTL means changes propagate faster, which is generally desirable for operational agility. The exception is if the lower TTL was clearly a mistake (e.g., a TTL of 1 second on a production record) or if you specifically want longer caching to reduce DNS query volume. When in doubt, 300 seconds (5 minutes) is a reasonable default for most records.

Related Tools

• SPF Record Builder - Build SPF records with proper syntax
• DKIM TXT Record Formatter - Format DKIM records with proper quoting
• DMARC Record Builder - Build DMARC records with all policy tags
• Zone File Linter - Check zone files for syntax errors and duplicates
• BIND Zone A/AAAA Generator - Generate BIND zone A and AAAA records from CSV