Skip to content

Knowledgebase

Editing an authoritative DNS zone in Webuzo

control-panels, domains-dns

Edit a Webuzo DNS zone only when it is part of the authoritative DNS service for the domain, or when you intentionally maintain it for another documented purpose. A local record can look correct while public resolvers continue using a different provider.

What you need before you begin

Check the domain delegated nameservers and save the current record values. Identify the required record type, exact owner name, value and TTL. For mail or verification records, obtain the values from the service being configured rather than copying another domain example.

01 Edit an authoritative DNS zone in Webuzo

  1. In the end-user panel open Domain > DNS Zone Setting and select the correct domain. Confirm that its authoritative nameservers actually serve this zone.
  2. Choose Add Record or edit the existing intended record. Use A for IPv4, AAAA for IPv6, CNAME for a hostname alias where valid, and TXT for the appropriate text value.
  3. Enter the owner name according to the form convention and inspect the resulting full name. Avoid accidentally appending the domain twice.
  4. Preserve unrelated MX, TXT and other records. Do not place a CNAME at a name that must also contain incompatible record types.
  5. Save the change and query the authoritative nameserver directly for the exact record. Then compare a normal recursive lookup, accounting for the previous TTL.
  6. For a production address move, test both IPv4 and IPv6 and keep the former endpoint available as required during cached traffic overlap.

Does lowering TTL clear existing caches immediately?

No. A resolver can retain an earlier answer until its previously received TTL expires. Lower the TTL in advance when planning a controlled cutover.

Verify the authoritative DNS result

Confirm the authoritative answer contains the intended record and that public queries converge after relevant caches expire. Test the actual dependent service, such as HTTPS or mail delivery, because a syntactically valid DNS answer can still point to the wrong destination.

Troubleshoot unexpected results

If nothing changes publicly, check delegation before repeatedly editing the local zone. If validation fails, correct the record type or name instead of deleting the whole zone. Restore the recorded value for an incorrect change and consider that resolvers may cache either value temporarily.

Was this answer helpful?

Need a little more help?

Our support team can help you find the next step.

Contact support