How to check a CNAME chain with dig

CNAME records let one DNS name answer through another name, which is common for CDNs, hosted applications, and SaaS endpoints. Checking the alias path with dig shows whether the requested hostname reaches the expected target or stops at an alias that has no usable final record.

An address lookup for A or AAAA records can include the CNAME rows that the resolver followed before returning the final address rows. A direct CNAME lookup is useful for confirming the first alias, but it does not prove that the final target has the address record clients need.

Use the exact hostname that clients request, not only the zone apex or provider target. A chain that ends with no requested address type usually points to the final target name or record type, while a missing first CNAME points back to the source label.

Steps to check a CNAME chain with dig:

  1. Query the hostname for the address type that clients use.
    $ dig +noall +answer www.example.net A
    www.example.net.              300 IN CNAME cdn.example.net.
    cdn.example.net.              300 IN CNAME edge.example.net.
    edge.example.net.              60 IN A     203.0.113.42

    Replace www.example.net with the exact hostname being tested. Each CNAME target is the next name in the chain, and the final A row proves the IPv4 answer for that hostname.

  2. Query the hostname for CNAME when only the first alias target is needed.
    $ dig +noall +answer www.example.net CNAME
    www.example.net.              300 IN CNAME cdn.example.net.

    A direct CNAME query can stop at the alias record. Keep the A or AAAA lookup when the final address is the success state.

  3. Check the IPv6 path separately when clients or monitors use IPv6.
    $ dig +noall +answer www.example.net AAAA
    www.example.net.              300 IN CNAME cdn.example.net.
    cdn.example.net.              300 IN CNAME edge.example.net.
    edge.example.net.              60 IN AAAA  2001:db8::42

    IPv4 and IPv6 answers can differ behind the same alias path. A working A chain does not prove that AAAA records exist.

  4. Show the response status when the answer section stops at a CNAME.
    $ dig +noall +comments +answer www.example.net AAAA
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42176
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1
    
    ;; ANSWER SECTION:
    www.example.net.              300 IN CNAME cdn.example.net.
    cdn.example.net.              300 IN CNAME edge.example.net.

    NOERROR with only CNAME rows means the alias name exists, but the requested final record type was not returned.

  5. Query the last CNAME target directly to isolate the broken link.
    $ dig +noall +comments +answer edge.example.net AAAA
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18620
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

    ANSWER: 0 at the final target confirms that the alias chain reaches the target name, but that name has no AAAA answer in this resolver view.