How to profile domain DNS records with dig

A domain can keep resolving even when its delegation, mail routing, or certificate policy has drifted from the intended design. A useful DNS profile therefore records several resource-record families from the same resolver view instead of treating one address answer as a complete health check.

The dig command can place several typed lookups in one request while +noall +answer retains the owner, TTL, class, type, and record data. Pinning one recursive resolver makes the snapshot internally consistent, although cache age can still make its TTL values and answers differ from another resolver.

The profile proves what public DNS returned at that moment; it does not prove that a website responds, a mail exchanger accepts messages, or a certificate can be issued. Each present or absent record needs the context of the domain's intended role, while the service itself needs a separate protocol-specific check.

Related: How to query DNS records with dig
Related: How to compare DNS answers across resolvers with dig
Tool: DNS Configuration Report

Steps to profile domain DNS records with dig:

  1. Replace iana.org and 1.1.1.1 with one authorized apex domain and recursive resolver.

    The example uses the public iana.org zone through Cloudflare's recursive resolver. One unchanged resolver keeps the snapshot internally consistent. Every queried owner name is visible to that resolver, which makes private or customer-only names unsuitable without permission.

  2. Query the apex address, mail, authority, and certificate-policy records in one resolver view. 
    $ dig @1.1.1.1 +noall +answer \
    iana.org A \
    iana.org AAAA \
    iana.org MX \
    iana.org NS \
    iana.org SOA \
    iana.org CAA
iana.org.        3459  IN  A     192.0.43.8
iana.org.        1363  IN  AAAA  2001:500:88:200::8
iana.org.        3600  IN  MX    10 pechora1.icann.org.
##### snipped #####
iana.org.        85229 IN  NS    a.iana-servers.net.
iana.org.        85229 IN  NS    b.iana-servers.net.
##### snipped #####
iana.org.        3600  IN  SOA   sns.dns.icann.org. noc.dns.icann.org. 2026070816 7200 3600 1209600 3600
iana.org.        600   IN  CAA   0 issue "digicert.com"
iana.org.        600   IN  CAA   0 issue "letsencrypt.org"
##### snipped #####

    Multi-value MX, NS, and CAA answers are unordered sets, so their printed order can change. A missing AAAA can be correct for an IPv4-only service, and a null MX value of 0 . deliberately states that the domain accepts no mail.

  3. Query the apex text records and the dedicated DMARC owner in the same resolver view. 
    $ dig @1.1.1.1 +noall +answer iana.org TXT _dmarc.iana.org TXT
iana.org.          86400  IN  TXT  "MS=ms22660639"
iana.org.          86400  IN  TXT  "v=spf1 redirect=icann.org"
##### snipped #####
_dmarc.iana.org.   3600   IN  TXT  "v=DMARC1; p=none;fo=1; rua=mailto:tutnr7vw@ag.us.dmarcian.com; ruf=mailto:dmarc-ruf@iana.org;"

    Apex TXT answers can mix SPF with unrelated ownership-verification tokens. DMARC is queried separately at _dmarc.<domain>, so an apex TXT lookup alone does not profile that policy.

  4. Verify the A answer against the IPv4 address in the approved DNS change plan.

    An A record proves IPv4 publication rather than HTTP, TLS, SSH, or application availability.

  5. Verify the AAAA answer against the IPv6 address or intentional omission in the approved DNS change plan.

    A blank AAAA answer is acceptable only when the approved plan intentionally omits IPv6.

  6. Verify the MX answer against the priorities and mail exchangers in the approved mail-routing plan.

    A null MX value of 0 . deliberately states that the domain accepts no mail, while an unintended blank answer leaves no explicit mail route.

  7. Verify the apex and DMARC TXT answers against the approved mail-policy and service-verification inventory.

    Apex TXT values can mix SPF with unrelated ownership-verification tokens, while DMARC belongs at _dmarc.<domain>.

  8. Verify the NS answer set against the authoritative DNS provider inventory.

    The complete unordered set matters because a stale or missing nameserver can leave delegation inconsistent across resolvers.

  9. Verify the SOA answer against the primary nameserver and zone parameters in the approved DNS change plan.

    The SOA serial identifies the published zone version, while a cached TTL can decrease without a record-data change.

  10. Verify the CAA answer set against the approved certificate-authority policy.

    A blank CAA answer is valid only when the approved policy does not restrict which certificate authorities may issue certificates.

  11. Classify a blank record lookup with response status and authority details. 
    $ dig @1.1.1.1 +noall +comments +answer +authority +nocookie iana.org HTTPS
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65036
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; AUTHORITY SECTION:
iana.org.        3600  IN  SOA  sns.dns.icann.org. noc.dns.icann.org. 2026070816 7200 3600 1209600 3600

    status: NOERROR with ANSWER: 0 and the zone's SOA proves that this owner exists but has no HTTPS answer in the selected resolver view. NXDOMAIN would mean the queried owner name does not exist. dig can exit successfully after either DNS response, so the header and section counts are the fail-capable evidence for an apparently blank profile row.