Use PD Google Cloud DNS’s BIND-format controls for a reviewed ordinary-record migration. Do not assume importing a complete file reproduces every provider setting or rolls a zone back exactly.

Review the input and target

Keep the source file and identify the intended project, managed-zone resource name and DNS suffix. Review website, mail, verification and child-zone requirements before any cutover.

Prepare the supported ordinary records you intend to add. The current module import compares the staged file with live records, skips existing values and duplicates, and leaves provider-owned SOA and apex NS records alone. Child-domain NS delegations are different records; review any required child delegation. Signing keys and other provider configuration are outside this record-file workflow.

Apply and read back

1. Open the intended zone’s Records page.
2. Use its available import control and supply the reviewed BIND data.
3. Check the target and displayed input information before applying.
4. Inspect the result and actual record sets, including any reported refusal.
5. Compare required names, values and TTLs with the original plan.

Import adds missing values; it does not remove live values absent from the file. An already-present value is skipped rather than rewritten solely to change its TTL. Adding a new value can affect the shared name/type TTL, and a CNAME can be refused when a conflicting target already exists. Use a deliberate record edit or the separate snapshot-restore workflow when replacement is intended.

The planned missing records are checked against the owning customer’s record allowance before the import starts. A later provider refusal can still follow earlier successful writes. Reconcile actual state before repeating the file. If an authority record is refused, keep the error for support rather than deleting the zone to force the import through.

Export and finish deliberately

Use the zone’s available export control to inspect or save its current BIND data; customer downloads are available in the supported client workflow. Keep signing and other provider configuration separately. An exported file is not proof an unchanged round trip will restore everything safely.

Change registrar nameservers only after the destination is ready and retain the previous DNS through cache transition. See the delegation guide and snapshot limitations guide for those separate operations.

Check the imported records

Your hosting team should compare the staged file with the current destination and review the missing-record count and owning customer’s allowance. The allowance check happens before import writes, but a later Google Cloud refusal can leave an earlier row added. Check child NS delegations separately from provider-owned apex NS/SOA. Describe affected rows rather than attaching the whole customer zone file.

See the PD Google Cloud DNS Blesta guide for related tasks, or explore the module.