VpnWP

How to Edit DNS Records in WP Squared Without Breaking Web or Mail

danroo
How to Edit DNS Records in WP Squared Without Breaking Web or Mail

WP Squared includes a Zone Editor for creating, modifying, and deleting DNS records. The controls are simple; the dangerous part is deciding whether that zone is authoritative and understanding what else depends on the record being changed.

Editing a correct-looking local zone has no effect if the domain delegates DNS elsewhere. Editing the live authoritative zone without accounting for mail, verification records, DNSSEC, or cached answers can create an outage that appears only after some resolvers refresh.

This workflow starts with delegation and ends with direct validation against the authoritative server.

First prove where DNS is hosted

Before opening WP Squared, query the domain’s nameserver delegation:

dig NS example.com +short

The returned nameservers identify the service expected to answer authoritatively. Confirm the full path when the result is unexpected:

dig +trace example.com NS

If the domain uses nameservers operated by the WP Squared server or its hosting provider, the WP Squared zone may be the live source. If the registrar delegates to another DNS provider, changing the local WP Squared copy will not change public answers. Make the edit at the authoritative provider or deliberately change the delegation as a separate migration.

Also check for split DNS. An internal resolver can return a private answer while public resolvers see a different zone. Compare a normal query with an explicit query to each authoritative nameserver:

dig example.com A
dig @ns1.example.net example.com A

Do not continue until you know which system owns the answer that users receive.

Where the Zone Editor is in WP Squared

The current WP Squared website-management documentation places Zone Editor in the website’s Advanced tab. It supports creating, editing, and deleting these record types:

The interface accepts @ in the Zone Name field as a shortcut for the domain apex. A hosting provider can restrict which zones or actions are available, so missing controls may be a provider policy rather than a browser problem.

The Advanced tab carries a warning for good reason. Export or capture the existing zone before a material change. At minimum, record the old name, type, value, priority, and TTL so that rollback does not depend on memory.

Choose the record by function

An A record points a name to an IPv4 address. Use it for the apex or a host such as www when the destination is a stable IPv4 address:

@      A      192.0.2.40
www    A      192.0.2.40

An AAAA record performs the same function for IPv6. Do not publish one merely because the editor allows it. The destination must accept and correctly serve IPv6 traffic; otherwise some clients will prefer a broken route.

A CNAME makes one hostname an alias of another:

www    CNAME  example.com.

Do not place other record types at the same owner name as a CNAME. Be especially cautious at the zone apex, where NS and SOA data already exist and standards-based CNAME use is unsuitable. Some DNS providers offer flattened or alias-style apex features, but those are provider functions, not ordinary CNAME records. WP Squared’s documented editor does not list such a separate record type.

MX records direct mail to hostnames, not raw IP addresses:

@      MX  10 mail.example.com.
mail   A      192.0.2.25

The priority is part of the routing decision; lower values are preferred. Changing the website’s A record does not automatically change MX delivery, and moving mail requires more than editing MX.

TXT records commonly carry SPF policy, DKIM public keys, DMARC policy, and service-verification tokens. They are independent records even though they share one type. Replace only the intended value, and avoid accidentally publishing multiple SPF policies at the same owner name.

Account for every service before changing the apex

A domain that appears to host one WordPress site can have several DNS-dependent services:

Inventory the current zone rather than copying only A and MX records. A website migration can succeed while mail silently fails because a DKIM selector or MX target was omitted.

If the new web server uses HTTPS, ensure that it is configured for the domain and can obtain a certificate before directing production traffic to it. DNS propagation is not a substitute for server readiness.

Use TTL as a migration tool

TTL tells recursive resolvers how long an answer may be cached. Lowering it immediately before a cutover does not purge answers already cached under the old, higher value.

For a planned migration:

  1. Reduce the relevant TTL at least one old-TTL interval before the cutover.
  2. Wait for existing cached answers to age out.
  3. Make the value change.
  4. Validate the authoritative answer and application behavior.
  5. Restore a normal TTL after the system is stable.

Resolvers may still retain negative answers according to zone policy, and local operating-system or application caches can make results appear inconsistent. Judge the authoritative response first, then investigate caching.

Keep DNSSEC delegation synchronized

DNSSEC can turn an otherwise correct migration into a complete resolution failure if the registrar’s DS record no longer matches the keys used by the authoritative provider. A validating resolver rejects a broken chain instead of falling back to unsigned DNS.

If only an A or TXT value changes inside the same signed zone, the DNS provider normally signs the new data. If nameservers or DNS providers change, coordinate key generation, DS publication, and removal according to both providers’ procedures. Do not delete or replace DS records as an improvised troubleshooting step.

ICANN’s DNSSEC overview explains that validation depends on a chain of trust. Preserve that chain throughout the move.

Validate the change from the source outward

After saving a record in WP Squared, query every authoritative nameserver directly:

dig @ns1.example.net example.com A +noall +answer
dig @ns2.example.net example.com A +noall +answer

Check the exact record type you changed. For mail-related work, query MX and the relevant policy names:

dig @ns1.example.net example.com MX +noall +answer
dig @ns1.example.net example.com TXT +noall +answer
dig @ns1.example.net _dmarc.example.com TXT +noall +answer

Then query more than one recursive resolver. Differences immediately after a cutover can be normal caching; differences between authoritative servers are not. All authoritative servers for the zone should return the intended data and a consistent serial.

DNS answers are only one half of validation. Test the actual services:

Roll back the value, not the entire zone

If a change fails, restore the recorded prior value and validate the authoritative answer again. Avoid importing a full old zone over a live one unless the entire zone truly needs rollback; that can erase unrelated edits made in the meantime.

Keep the old web or mail endpoint available until the longest relevant cache interval has elapsed and logs show that traffic has moved. A rollback target that was shut down too early is not a rollback plan.

The safe WP Squared DNS workflow

For each change, preserve a short evidence trail:

  1. Confirm the registrar’s nameserver delegation.
  2. Query the current answer directly from each authoritative server.
  3. Export or record the current zone data.
  4. Inventory web, mail, verification, and DNSSEC dependencies.
  5. Lower TTL in advance when planning a cutover.
  6. Edit only the required record in WP Squared’s Advanced > Zone Editor.
  7. Verify the new authoritative answer and zone consistency.
  8. Test the service, not just the DNS response.
  9. Restore a normal TTL and retain the rollback record.

The Zone Editor is the right tool only when WP Squared is authoritative for the domain. Establishing that fact before clicking Save prevents the two most common outcomes: a change that does nothing and a change that disrupts more than the website it was meant to move.

Related Guides

Exit mobile version