How to Recover 13 Deleted DNS Records in 11 Minutes

📝 Originally published (in Japanese) at forge.workstyle.tech.

TL;DR We selected a live domain beside the intended domain in the DNS management UI and deleted 13 records. AXFR was refused, but the pre-deletion list and authoritative DNS data were still available. We enumerated names, queried them with dig, cross-checked public DNS caches, and manually restored the records in about 11 minutes.

Conclusion First

If you accidentally delete DNS records, the last known list and values retrieved from the authoritative DNS server (the server that returns the domain’s official DNS information) can help you restore them. AXFR was refused in this case, but by enumerating names, querying them with dig, and cross-checking public DNS caches, I manually restored 13 records in about 11 minutes.

Where the DNS Records Were Before Deletion

Thirteen records were deleted: 11 A records, one CNAME record, and one MX record. The recovery source was a complete list that another operator had copied from the management console just before deletion. They were working in a separate AI session.

After deletion, it becomes difficult to remember the original values one by one. In this case, the list had been saved, so there was enough information to re-create all 13 records manually.

However, the list alone could not confirm the state of the authoritative DNS. Immediately after the deletion request was submitted, the update to the authoritative DNS was delayed. Running dig still returned every record that existed before deletion.

How I Verified Every Record After AXFR Was Denied

The AXFR request to transfer the entire DNS zone was denied. So I enumerated the names and queried them with dig, then checked the results against a recently copied list and the records retrieved from the authoritative DNS server.

I also compared them with public DNS caches—temporarily stored DNS information. I used results from 8.8.8.8 and 1.1.1.1 to double-check, and verified what was visible through those separate caches instead of relying only on the list retrieved from the authoritative DNS server.

I had three sources to guide the manual restoration: the surviving list, the full set of records retrieved from the authoritative DNS server right after deletion, and the public DNS cache results.

Verifying Recovery Time Using TTL and SOA Serial

The A record’s TTL (the length of time DNS information is kept in cache) was 3,600 seconds, and the negative cache TTL (how long a “does not exist” response is cached) was 300 seconds. The SOA serial (the zone’s update number) showed that the zone became empty at 10:06 and was restored by re-registration at 10:17. According to the records, recovery took about 11 minutes.

Recovery depended on more than the TTL values. Even after deletion, we could retrieve all records from the authoritative DNS server and compare them with the previous list and the results from public DNS caches. This let us verify what to enter manually.

We didn’t undo the deletion in the admin console. Instead, we gathered information to verify the records and re-registered them manually. Because the original values were still available, we could proceed.

How to Avoid Accidentally Deleting DNS Records

This mistake happened while I was working with domains that had similar names on the same screen. I meant to delete an unused domain, but selected the adjacent one that was still active. The lesson: don’t manage similarly named domains on the same screen, and export the entire zone before deleting anything.

Even when you try to retrieve every record in a zone with AXFR, the request may be denied. That happened here, so I enumerated the names and queried them with dig. Keeping a copy of the list before deleting records means you won’t have to start from scratch searching for their values afterward.

I restored everything in 11 minutes, not because I found a special recovery feature, but because I had a recently copied list, could retrieve every record with dig while the changes were still propagating to the authoritative DNS servers, and could cross-check the results against public DNS caches.

Key takeaways

• Check for a pre-deletion record list in the management UI.
• If authoritative DNS propagation is delayed, enumerate names and use dig to see whether all records can be retrieved.
• Cross-check results against the public DNS caches at 8.8.8.8 and 1.1.1.1.
• Manually re-register the verified values and check the time with the SOA serial.
• Before the next deletion, identify the target domain and export the full zone.