Skip to content

Knowledgebase

Troubleshooting DNS changes that do not appear from DirectAdmin

control-panels, domains-dns

When a DirectAdmin DNS edit does not appear publicly, first check whether the domain actually uses that DNS service. A hosting account can contain a local zone even while the registrar delegates public DNS to an external provider. Editing the wrong copy will not change the authoritative answer.

Gather the details you will need

Record the full hostname, record type, intended value and previous TTL. Identify the registrar, current nameservers and any DirectAdmin multi-server arrangement. Preserve existing mail and verification records before changing a zone.

01 Troubleshoot DNS changes that do not appear from DirectAdmin

  1. Check the public nameserver delegation and query an authoritative nameserver for the exact record.
  2. Open DirectAdmin DNS management for the correct domain and compare its records with the authoritative result. Check whether the local zone is primary, mirrored or unused publicly.
  3. If authority is external, make the change at that DNS provider. If DirectAdmin is authoritative, edit the exact record using the panel and save.
  4. For clustered DNS, confirm the update reached each authoritative server. Compare zone serials and inspect synchronization errors if one answer differs.
  5. Check normal recursive lookups after the authoritative answer is correct. Existing caches can retain the earlier value until its TTL expires.

02 Example: compare the authoritative answer with your resolver

On a computer with dig installed, replace the example domain with yours. First inspect the listed nameservers:

Command example
dig example.com NS +short

Use an authoritative server confirmed by the registrar delegation, replacing ns1.example.net below, and query the exact hostname and record type you changed:

Command example
dig @ns1.example.net www.example.com A +noall +answer
dig www.example.com A +noall +answer

The first command asks the named server directly; the second uses your configured resolver. If the authoritative value is correct but the resolver still shows the old address, investigate caching and the earlier TTL. If the authoritative value is wrong, fix the zone or synchronization first. Repeat against every delegated server and use AAAA, MX or TXT when that is the actual record involved. These lookups do not edit DNS.

How do I verify the public DNS answer?

Test the service using both IPv4 and IPv6 where records exist. Confirm the intended website or mail endpoint receives traffic. Querying only a cached resolver or seeing a record in the panel is not enough to verify authority.

If the problem continues

If answers are inconsistent, separate delegation, zone synchronization and caching before making more edits. Do not change nameservers as a shortcut without copying the complete required zone. For a DNSSEC validation failure, inspect the trust chain because ordinary record corrections may remain invisible to validating clients until it is repaired.

Was this answer helpful?

Need a little more help?

Our support team can help you find the next step.

Contact support