Add the new verification value without removing the existing DNS evidence

A handover should let the successor make an authorised routine change and explain what must remain intact. A document that says “replace the TXT value” can be dangerously incomplete when several values share the same DNS name and type.

This fictional exercise uses only the reserved domain handover.example and an isolated DNS model. No live domain or provider account is changed. It demonstrates the knowledge the successor needs before carrying out an approved operation through the actual provider's supported interface.

Establish the exact owner and existing set

The organisation is adding a catalogue service that requires a verification value. Its approved instruction identifies the DNS owner _verification.handover.example, record type TXT and new value catalogue-check=L9.

At that same owner, two existing TXT values are still required:

• legacy-web=K8
• document-service=P3

The account inventory identifies the organisation's authorised DNS provider and the person allowed to approve the change. The exercise does not assume that the registrar, website host and authoritative DNS service are the same account.

The current handover note shows a single-value replacement command. Inspection of this fictional provider's documented interface confirms that the operation replaces the complete TXT record set at the named owner. Sending only catalogue-check=L9 would remove the two existing values.

Understand the set before editing it

RFC 2181's record-set definition explains that records sharing a label, class and type can contain different data and form a resource record set. That DNS concept does not determine how every provider's editing interface behaves. The successor still needs the actual provider's documented update operation.

In this exercise, the supported procedure is to read the current set, prepare the complete intended set and apply it under the provider's available change controls. The successor must not confuse adding a value with replacing all values merely because both operations involve the same type of record.

The selected result is explicit:

The values are separate records in the set. Combining them into one invented verification string would not preserve the provider instructions.

Rehearse the successor's procedure

Nadine, the fictional successor, reads the current owner and type from the isolated model and compares them with the approved inventory. She prepares the three-value set and has the authorised owner review the exact difference: one addition, no removals.

Before applying it, she checks that the current set still matches the reviewed starting state. If it has changed, she stops and obtains a new review rather than overwriting a colleague's intervening change. The actual provider's supported concurrency and change controls must govern a real operation; a read followed by a write should not be described as universally race-proof.

In the exercise, the starting set is unchanged. Nadine applies the reviewed set through the model's supported operation and reads it back. All three values are present. A second application of the same intended set leaves those three values, without another copy of the new one.

Check an independent record and the verification result

The fake zone also contains an MX record at handover.example. Its target and priority remain unchanged. The change was scoped to the TXT set at _verification.handover.example; it did not replace the zone or alter mail routing.

The simulated catalogue verifier checks for the exact new value at the exact owner and reports it found. The two earlier verifier fixtures still find their own values. These results establish the bounded model, not real-world DNS propagation or completion of a live provider verification.

A real plan must identify how authoritative data and the provider's eventual verification result will be checked, including any relevant caching and timing. It should not promise that every reader sees a DNS change immediately.

Keep the operating instructions useful

The revised handover names the authoritative account, approval owner, record owner and type, expected before-and-after set, supported operation and read-back checks. Access credentials remain in the agreed protected mechanism rather than being copied into the document.

It also describes the stop condition: an unexpected existing value, changed starting set or different provider instruction requires review. The successor is not expected to guess whether an unfamiliar value can be removed.

The useful outcome is that Nadine can explain and perform the bounded change while preserving independent services. For an application-care handover, choose a similarly concrete operation. Then check what the next maintainer can do and what evidence tells them to stop.