Developer Offshore guide
DNS Cutover Evidence Handoff for Offshore Infrastructure Work
A practical buyer guide for infrastructure owners preparing a hostname cutover without delegating domain authority. Build a cutover packet with zone and record identifiers, old and new answers, TTL history, resolver samples, certificate names, health evidence, rollback, and approver before committing budget, access, or delivery expectations.
Published October 2, 2026
DNS Cutover Evidence Handoff for Offshore Infrastructure Work
- Frame the decision explicitly: rehearse record changes, resolver behavior, certificate coverage, health checks, rollback, and observation across the real TTL window.
- Require a concrete output: a cutover packet with zone and record identifiers, old and new answers, TTL history, resolver samples, certificate names, health evidence, rollback, and approver.
- Keep priority, sensitive access, accepted risk, commercial approval, and production authority with named buyer-side owners.
Map every name and endpoint before changing records
Lowering TTL shortly before a cutover does not change cached answers already retained under the older value. Record the old TTL early, authoritative nameservers, record chain, DNSSEC state, health-check behavior, proxy or CDN mode, certificate names, HTTP host handling, mail or verification dependencies, and rollback target. Query authoritative service plus a bounded set of independent resolvers before, during, and after the window, preserving answer, TTL, response code, and timestamp. Test the new origin directly with the intended Host and TLS name before changing DNS. During cutover, compare traffic and application health at both destinations until the longest relevant cache window has passed. Do not promise global propagation from a few samples. Domain owners approve record changes; service owners approve application readiness; the engineer collects evidence and stops on certificate, resolution, or health failures.
Record the public hostname, authoritative zone and record identifiers, current answers, target answers, TTL history, aliases, address families, certificate names, health paths, origin configuration, and dependent records. Query A, AAAA, CNAME, HTTPS or SVCB, and CAA where they apply. A plan based only on the visible A record can leave IPv6 users or alias targets on a different path.
Prove the new origin without public DNS
Send the intended Host and TLS server name directly to the new endpoint using a safe test path. Check the certificate chain, hostname coverage, expiry, renewal arrangement, redirects, application response, asset loading, and health behavior. Test both IPv4 and IPv6 when both will be published. This separates origin defects from resolver caching before the cutover begins.
Repeat the same checks against the old origin. Rollback is credible only while the old path remains healthy and its certificate still covers the name. Record how long it will remain available and which configuration changes after cutover could make it unsafe to restore.
Buyer decision record
Scroll sideways to read every column on a small screen.
| Decision point | Evidence to request | Owner |
|---|---|---|
| Outcome | Decision statement and a cutover packet with zone and record identifiers, old and new answers, TTL history, resolver samples, certificate names, health evidence, rollback, and approver | engineering manager |
| Operating model | Scope, access, review, acceptance, and escalation map | Delivery owner |
| Failure test | the record changes correctly but a cached resolver continues directing users to an origin whose certificate or application is no longer valid | System owner |
| Review | Baseline and answer distribution, TTL expiry, resolver failures, certificate checks, health responses, traffic split, and rollback time | Buyer sponsor |
Treat TTL as a cache horizon, not a switch
Record when the previous TTL became authoritative and allow its full window before relying on a lower value. At cutover, sample the authoritative servers and a bounded set of recursive resolvers with timestamps and network context. Mixed answers can be expected during cache expiry; the plan should distinguish that state from a wrong authoritative record.
Do not claim that several public resolvers represent every user. Use them as evidence of propagation paths, then pair answer distribution with application health and traffic at the origins. A resolver can retain data according to behavior outside the planned sample, and clients may add local caching.
Follow delegation and DNSSEC when they are in scope
If nameservers, DS records, or signed-zone material change, trace delegation from the parent and validate the chain. Record serials, signer state, and responses from each authoritative server. A correct record on one server is insufficient when the delegation still reaches another server with old data.
A DNSSEC validation failure may look like a missing domain to validating resolvers while direct authoritative queries appear correct. Make validation a stop condition. Ownership of registrar and parent-zone changes stays with the domain owner; an infrastructure developer can prepare evidence but should not improvise around failed delegation.
Observe the application through the cutover
Query A, AAAA, CNAME, HTTPS or SVCB, CAA, and other applicable records rather than assuming the visible A answer is the complete route. Follow delegation from the parent when nameserver or DNSSEC changes are involved. Check both IPv4 and IPv6 origins, because a forgotten AAAA record can split clients after an otherwise correct cutover. Certificate validation should cover the real chain, SNI, hostname, expiry, and renewal path. Preserve resolver samples with their network and time, but do not turn public resolvers into a claim about every user. The rollback threshold names an application symptom and duration, who can change the record, and how long mixed answers remain expected afterward.
Chart authoritative answers, sampled recursive answers, certificate checks, health responses, origin request counts, error rates, and traffic split on one timeline. Send a unique harmless synthetic request through old and new answers so evidence identifies the responding origin. Check redirects and asset hosts, not only the first HTML response.
Write rollback as another DNS transition
Define the application symptom, duration, and owner that trigger rollback. Preserve the exact old value and the authority needed to restore it. After restoration, expect mixed answers for another cache window and keep both origins healthy accordingly. Rollback time is not the moment a record is edited; it includes the period in which resolvers and clients still use the failed target.
If data or sessions change during the cutover, verify that directing traffic back is safe. DNS can restore routing but cannot reverse a database migration, queued side effect, or incompatible cookie. Assign those dependencies to their owners and block the cutover when the rollback story requires untested application behavior.
Check certificate renewal after routing changes
Confirm which endpoint answers the certificate authority’s validation method after cutover and after rollback. A certificate that is valid on release day can still fail at renewal if validation reaches an origin without the required challenge or if CAA no longer permits the issuer. Record the renewal owner and the next test date alongside the current certificate evidence.
The release packet establishes authority and timing
The cutover is ready when the new endpoint serves the intended Host with valid TLS and health, authoritative answers are correct, rollback remains viable, and the observation plan spans known cache windows. DNSSEC errors, certificate mismatch, unhealthy old or new origins, and undocumented dependent records are stop conditions.
The infrastructure owner receives zone identifiers, old and new record sets, TTL history, direct-origin checks, TLS evidence, resolver samples, delegation and DNSSEC results where applicable, timeline, health and traffic observations, rollback threshold, old-origin retention, and named approvers. The developer may rehearse and monitor the change. Domain authority and the decision to cut over or restore remain with the designated owner.
Questions about assessing Philippine developers
Should the provider make this decision for the buyer?
The provider can supply evidence, options, and implementation detail. The buyer should retain final authority for business priority, budget, sensitive access, accepted risk, and production changes.
What should be documented before work starts?
Record the decision, owner, assumptions, boundaries, review date, and a cutover packet with zone and record identifiers, old and new answers, TTL history, resolver samples, certificate names, health evidence, rollback, and approver.
How should an unresolved risk be handled?
Name the risk, evidence, potential impact, owner, due date, and safe default. Do not treat silence or a sales assurance as acceptance.
Sources
International Labour Organization guidance on remote work arrangements reinforces why remote role briefs should document expectations, communication rhythms, and accountable handoffs.