Skip to content
novasean.

DNS and email authentication

Check whether DNSSEC works for your domain with dig

Use dig to distinguish a signed zone from a validated DNSSEC chain, compare DS and DNSKEY, and investigate SERVFAIL without changing live DNS blindly.

By Team Novasean · Published

Decide what you need to verify

Do not treat a visible DNSSEC signature as proof that your domain validates. A signed DNS zone publishes records such as DNSKEY and RRSIG. For normal DNSSEC validation, a validating resolver must also be able to follow a trusted chain through the parent zone's DS record to the current zone key. Check those two questions separately before a nameserver, registrar or certificate change.

This guide is for the owner or authorised operator of a domain. It is a read-only check: the dig commands below do not change DNS. Use the registrar and authoritative DNS provider named in your actual domain records; a DirectAdmin zone, Cloudflare account or Novasean hosting plan is not automatically the authority for every domain. If your domain is already failing after a nameserver move, use the SERVFAIL recovery guide for the repair sequence.

Ask a validating resolver for an answer

Replace example.com with the zone you control. Query its SOA record through a known validating resolver and retain the full header:

dig @1.1.1.1 example.com SOA +dnssec

Look for status: NOERROR and the ad flag in the reply's flags line. An ad flag from a validating resolver means that resolver authenticated the returned answer. An RRSIG in the answer shows signing material was returned; +dnssec asks for that material but does not make dig independently validate it. Record the resolver, timestamp, name, record type, status and flags, not just the answer section. If the zone is intentionally unsigned, a normal NOERROR answer without ad can be expected. If ad is absent, do not immediately call the zone broken: the resolver, checking flags, response type or an unsigned delegation may explain it.

Repeat with a second validating resolver if a result is surprising. Differences can reflect cache age or resolver behaviour; they are a reason to inspect the chain, not to make a blind registrar change.

Compare the parent DS with the zone's DNSKEY

Ask for the domain's DS record and its reported NS set, then confirm the parent-side delegation if these differ from your provider's records:

dig example.com DS +noall +answer
dig example.com NS +noall +answer

The DS belongs to the parent delegation and normally reaches the registry through your registrar. The DNSKEY is served by the child zone's authoritative DNS provider. To inspect the current child keys, replace the illustrative server below with a nameserver actually delegated for your domain:

dig @ns1.provider.example example.com DNSKEY +dnssec +noall +answer

A DS and DNSKEY both appearing is not by itself proof that their digest, algorithm and signatures form a valid chain. A signed zone can publish DNSKEY and RRSIG while the parent has no DS; ordinary resolvers then cannot build a parent-to-child trust chain for that zone. Conversely, a parent DS that points to a missing or different child key can make validating resolvers return SERVFAIL. Use dig example.com DS +trace to see the delegation path if parent-side results are unclear; a trace shows responses but does not itself validate the chain. During a planned migration, old values may remain cached until their TTLs expire. Compare with the actual provider's current key details and the registrar's recorded DS, rather than copying example values.

Interpret the result without a false pass or false alarm

  • NOERROR with ad on a validating resolver: that resolver authenticated this answer at the test time. It does not prove that every resolver has the same cached state or that every subdomain and record type works.
  • NOERROR without ad: the name answered, but this reply does not establish a validated chain. Check whether the domain is intentionally unsigned, whether the resolver validates, and whether the parent DS exists.
  • DNSKEY or RRSIG visible but no parent DS: the zone may be signed without a parent trust link. Do not label it fully validated from the signature alone.
  • SERVFAIL from a validating resolver: DNSSEC is one possible cause, alongside unreachable or inconsistent authoritative servers and other DNS faults. Preserve the full response and compare carefully before changing DS.

Do not infer a domain's security state from +short output alone: it omits the response header and its validation flag. A single checker badge also cannot replace the domain's parent, child and resolver evidence.

Narrow a possible validation failure

If the normal validating query returns SERVFAIL, run the same name and type against the same resolver with checking disabled:

dig @1.1.1.1 example.com SOA +dnssec +cd

If the normal query fails but the +cd query returns the expected answer, a validation problem is likely. The +cd switch is a diagnostic for this one query; it does not repair DNS for visitors. If both queries fail, investigate delegation, reachability and the zone as well. Compare the parent DS, each delegated authoritative server's DNSKEY response and the DNS provider's current signing state. The nameserver-change SERVFAIL guide covers a broken migration in more detail.

Do not remove or replace a DS record on the strength of one test. A wrong change can break validation or temporarily remove the protection for an otherwise healthy domain. Coordinate any repair with the domain owner, registrar and DNS operator using their supported DNSSEC migration or rollover procedure. Keep the pre-change NS and DS values and a rollback path.

Give the right evidence to the right operator

When asking for help, provide the exact domain and affected name, current registrar and authoritative DNS provider, the time and resolver used, full dig replies for the validating and +cd tests, parent DS and child DNSKEY observations, and any recent NS or DNSSEC change. Omit account credentials and private keys. Ask the operator to confirm the effective delegation and intended signing state before editing anything.

For a Novasean-hosted site, check which party actually controls authoritative DNS and the registrar DS for the domain in your accepted service arrangement. Website hosting, DNS hosting and registration can belong to different providers. A successful DNSSEC check proves neither that a website is healthy nor that Novasean operates that domain's signing keys.

Common questions

Does dig +dnssec validate DNSSEC? No. It requests DNSSEC records. Read the ad flag from a resolver you know validates, or use an independent validator for a full chain assessment.

Does a missing DS mean the domain is broken? Not necessarily. An intentionally unsigned domain can resolve normally. A signed child without a parent DS lacks the ordinary parent trust link; establish the intended state before changing it.

Does +trace prove validation? No. It reveals the delegation path and answers from servers; it does not substitute for a validating resolver's authenticated result.

Should I edit DNSSEC in DirectAdmin? Only if that account is authoritative for the child zone and the actual service supports the intended change. Parent DS is controlled through the registrar or registry route, which may be elsewhere.

Sources and technical references

Prepared by Team Novasean from the references above. Menus and available features depend on your installed version and service permissions.

Related guides

Was this guide helpful?

If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .

Need help with your service?

Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.