A request to add or change a DNS record can arrive as a short ticket containing a hostname, value and the words “please update”. The edit itself may take seconds, but the record can affect websites, email, verification services or integrations. A small IT support team should therefore treat the request as a controlled live-service change: establish what is being changed, who authorised it, what depends on the current state and how the result will be verified.
Capture the exact requested record and purpose
Record the zone, record name, type and intended value using the information supplied through the approved request route. Also capture the business or technical purpose. Purpose helps a technician spot an obvious mismatch without inventing a different configuration on the requester's behalf.
Confirm authority for the domain and change
Access to a DNS provider does not by itself authorise a technician to alter a client's records. Apply the client's agreed approval route and distinguish between somebody supplying technical values and somebody authorised to approve the production change.
Review the current record before replacing it
Check what is currently published and whether the requested action adds, changes or removes information. Preserve the pre-change state in the normal change record so the team can understand what was altered and has a basis for reversal if the agreed plan requires it.
Consider dependencies without turning the ticket into guesswork
A record may support email, a website, a third-party service or validation process. Review known documentation and the request context for dependencies. If the effect of removing or replacing an existing value is uncertain, escalate that uncertainty rather than assuming the new instruction cannot affect anything else.
Handle timing and TTL as technical context
DNS changes may not appear identically everywhere at once because of caching and provider behaviour. Technicians should use the actual platform and record configuration when setting expectations rather than promising a universal propagation time. Where timing matters to a coordinated release or supplier change, include it in the plan.
Verify the intended record after the change
Confirm through an appropriate DNS lookup or service check that the expected record is being returned. Verification should match the purpose of the change where practical; seeing a value in the provider interface alone may not demonstrate that the intended external resolution is available.
Keep credentials and transfer controls separate
A DNS change request is not authority to transfer the domain, change registrant details or disclose provider credentials. Those are separate administrative actions with their own approval and security implications. Keeping the boundaries clear protects both the client and the support team.
Update operational documentation where the record is significant
If the DNS entry forms part of a supported service or integration, update the relevant support reference so future technicians understand its purpose. This is distinct from domain-renewal ownership: renewal records establish who controls and renews the asset, while DNS change control governs a specific live technical configuration change within that domain.