Fix DNS_ERROR_RCODE_YXRRSET (0x232F)

YXRRSET means 'RRset exists when it should not' — a DNS server refused your dynamic update because the record already lives there. Here's how to clear it.

I know this error is infuriating because it looks like it's telling you the opposite of what you expected — you tried to add a record, and DNS is complaining something already exists.

Here's the short version: YXRRSET stands for "RRset exists (value dependent)." A DNS server received a dynamic update (RFC 2136) that said "create this A record," and the server said nope — a resource record set with that name and type is already present. The prerequisite clause in your update failed.

The real fix

You have three paths, depending on what you actually want.

1. You want the record updated, not created

Stop using ADD. Send a delete-then-add, or a replace.

With nsupdate on Linux or macOS:

nsupdate -k /etc/bind/Kmykey.+165+12345.key
> server ns1.example.com
> zone corp.example.com
> update delete host01.corp.example.com A
> update add host01.corp.example.com 3600 A 10.20.30.40
> send
> quit

With PowerShell against a Windows DNS server:

Remove-DnsServerResourceRecord -ZoneName "corp.example.com" -Name "host01" -RRType "A" -Force
Add-DnsServerResourceRecordA -ZoneName "corp.example.com" -Name "host01" -IPv4Address "10.20.30.40" -TimeToLive 01:00:00

Or if you're using dnscmd:

dnscmd /RecordDelete corp.example.com host01 A 10.20.30.99 /f
dnscmd /RecordAdd corp.example.com host01 A 10.20.30.40

2. You want to know what's actually there first

Before you delete anything, look at the record. 90% of the time it's a stale A record from a laptop that got a new DHCP lease.

dig host01.corp.example.com A +noall +answer
nslookup -type=A host01.corp.example.com 10.0.0.10

On Windows DNS, open the zone in DNS Manager and enable View > Advanced. You'll see tombstoned records that nslookup won't show you. Tombstones are records kept around after deletion for the tombstone lifetime (default 7 days) so replication doesn't resurrect them.

3. Your DHCP server is doing the update, not you

If this error appears in DHCP server event logs (Event ID 2032 or 2031 on Windows Server), the client already registered itself and now DHCP is trying to register the same name. The fix:

Set the DHCP scope to Always dynamically update DNS A and PTR records, not "according to client request."
Enable Discard A and PTR records when lease is deleted.
On the client, disable the "Register this connection's addresses in DNS" checkbox under IPv4 Advanced TCP/IP settings if DHCP owns the record.

That one setting — the client registering itself and DHCP registering it — is the number one cause of YXRRSET I've seen in production.

Why this works

DNS dynamic updates are atomic-ish, and the server evaluates prerequisites before it acts. When your update packet includes "prerequisite: name is not in use" but the name is in use, the server short-circuits with RCODE 7 (YXRRSET).

The wire response is: UPDATE REFUSED YXRRSET — you'll see it in packet captures as extended RCODE 0x232F when the OPT pseudo-RR carries the extended RCODE bits.

Deleting first clears the prerequisite. Re-adding after resets the TTL and timestamp so the record ages out cleanly next time. Just updating in place works too, but only if your tooling sends a proper replace (delete RRset + add).

Less common variations

YXRRSET on DNSSEC-signed zones

If you're running BIND 9.16+ with inline signing, a stale RRSIG or NSEC record can trigger YXRRSET even after you think you cleared the A record. Force a re-sign:

rndc sign corp.example.com
rndc freeze corp.example.com
rndc thaw corp.example.com

YXRRSET from an Active Directory-integrated zone

You might be updating a different DC than the one whose copy you can see. Force replication first:

repadmin /syncall /AdeP

Then retry the update. If it still fails, check whether the record lives in the _msdcs partition or a different application partition.

YXRRSET on a CNAME to A record

Some tools silently attempt to add both a CNAME and an A at the same name. That's illegal in DNS (CNAME can't coexist with anything else). The server may answer YXRRSET because the CNAME is already there. Pick one. If you need multiple addresses at one name that's also aliased, use A records and forget the CNAME.

Third-party DNS providers (Cloudflare, Route 53, Azure DNS)

You won't see RCODE 7 over their APIs — they translate it. But the underlying cause is the same: their API tried an ADD when it should have used UPSERT. Route 53's ChangeResourceRecordSets with action CREATE against an existing name returns InvalidChangeBatch. Use UPSERT instead.

Prevention

Turn on scavenging. No-scavenging zones accumulate stale records forever. Set no-refresh 7 days, refresh 7 days, scavenge period 7 days. Yes, you'll scare people the first week. Do it anyway.
Decide who owns the record. Either the client registers itself or DHCP does. Never both.
Use UPSERT semantics in your automation. Terraform's aws_route53_record, Ansible's route53 module, and any sane DNS wrapper should default to upsert. If yours doesn't, fix the playbook.
Add a monitoring check that alerts on duplicate A records in the same zone (same name, different IP, both non-tombstoned). It catches the mess before a user does.
Set realistic TTLs on dynamic records. 300–3600 seconds for host records. If you set TTL 86400 on a laptop's A record, you'll be explaining YXRRSET to yourself tomorrow.

That's the whole thing. Clear the stale record, then make sure your updater uses upsert semantics so this error never bites you twice.