NS CNAME Indirection

What This Check Does

This check inspects each nameserver hostname listed in your domain's NS records and verifies that those hostnames resolve directly to IP addresses. If any of them resolve through a CNAME chain instead of an A or AAAA record, the check flags it.

This is not a theoretical edge case. Tools like dig will happily follow CNAME chains and return an IP address at the end, so everything looks fine from a basic resolution test. The problem lives underneath, in the way the DNS specification actually requires NS records to work.

Security Risk: Subdomain Takeover via NS Delegation

The specific attack this check is designed to catch is a form of subdomain takeover that targets the nameserver layer directly.

The scenario works like this: Your NS hostname resolves through a CNAME to a third-party name. That third-party name belongs to a hosting provider, a DNS vendor, or some backend infrastructure you once used. If that provider decommissions the name, stops renewing it, or changes their naming scheme, that hostname becomes available for public registration.

An attacker registers it. From that point on, your NS hostname resolves to infrastructure the attacker controls. Any DNS query for your domain gets answered by their servers. They can return whatever records they want, including pointing your domain to phishing pages, intercepting mail, or serving fraudulent content under your name. This is not a slow or noisy attack—it can be set up quietly, and the time between a name becoming available and someone registering it can be very short.

Severity Assessment

The check uses provider context to assign severity. If the CNAME chain ends at a well-known, stable provider like AWS, Cloudflare, Google, or Azure, the risk is lower and the finding is flagged as a warning. If the chain ends at an unknown provider, or if the name does not resolve consistently across multiple public resolvers, the finding is critical. Inconsistent resolution across resolvers is a separate signal worth paying attention to—it can indicate that a name is in the process of being removed or has already partially disappeared from the DNS.

How to Fix It

The fix is to ensure every nameserver hostname in your NS records has a direct A or AAAA record, with no CNAME involved at any point in the resolution path.

If your DNS provider manages these records, check whether they are using CNAMEs internally for their nameserver infrastructure. A provider that routes NS hostnames through CNAMEs is introducing this risk on your behalf. It is worth raising with them directly.

If you manage the NS hostnames yourself, remove the CNAME and replace it with a static address record.

Correct nameserver entry (direct A record):

ns1.example.com.    IN    A    192.0.2.1

Entry that triggers this check (CNAME indirection):

ns1.example.com.    IN    CNAME    ns1.some-backend.net.

If you are migrating away from a provider that owned one of these backend names, verify the old name is either still registered and controlled by a party you trust, or that the CNAME has been fully removed before you let the name expire.