Skip to content
HackIndex.io

DNS Misconfiguration Probing

5 min read Created Jan 3, 2026 Last updated May 15, 2026

DNS misconfigurations are often overlooked during setup and rarely audited afterward. A few targeted queries reveal behaviors like open recursion, wildcard resolution, and missing DNSSEC, all without needing special access or tools beyond dig. Run these against the target's DNS server before committing to a full brute force or zone transfer attempt. They take seconds and sharpen the picture of what the server is actually doing.

  • Open recursion the server resolves arbitrary external names, enabling cache snooping and amplification attacks.
  • Wildcard records all nonexistent subdomains resolve to a single IP, poisoning brute-force results.
  • DNSSEC status missing DNSSEC opens the door to spoofing, and NSEC zones can be walked without a wordlist.
  • TCP fallback blocked TCP breaks large responses and zone transfers, revealing edge resolvers vs. authoritative servers.
  • TTL anomalies inconsistent or extreme TTLs signal manual edits, dynamic DNS, or primary/secondary mismatches.
  • Delegation tracing +trace follows the full path from root to authoritative, exposing shadowing or split-horizon setups.

Recursion Check

┌──(kali㉿kali)-[~]
└─$ dig google.com @$TARGET_IP +short

If the server returns a result for an external domain, recursion is open. This means the server resolves arbitrary names on behalf of any client, not just its own zone. Open recursion enables cache snooping: query for names the server has recently resolved to infer internal browsing or connectivity patterns. It also makes the server usable in DNS amplification attacks, which is worth including in the report. A server that refuses with REFUSED or returns SERVFAIL is not open.

Wildcard Detection

┌──(kali㉿kali)-[~]
└─$ dig nonexistent123.$DOMAIN @$TARGET_IP +short

A wildcard record returns a valid response for any subdomain that does not exist as an explicit entry in the zone. If the nonexistent name resolves to an IP, every brute-force subdomain hit will appear valid. Filter brute-force results by recording the wildcard IP and excluding any results that match it. The NS query confirms which servers are authoritative. If the target appears as an authoritative nameserver for the domain, zone transfer attempts against it become directly relevant.

Additional Probes

Authoritative NS:

┌──(kali㉿kali)-[~]
└─$ dig NS $DOMAIN @$TARGET_IP

The SOA record reveals the primary nameserver, an admin contact address with a period replacing the @ symbol, and the zone serial number. A stale or predictable serial can indicate infrequent zone updates. The refresh, retry, and expiry values show how secondary servers are configured. These values matter when planning timing-sensitive follow-up work or assessing whether the zone is actively maintained.

┌──(kali㉿kali)-[~]
└─$ dig SOA $DOMAIN @$TARGET_IP

If the response includes RRSIG or DNSKEY records, DNSSEC is deployed. This limits certain spoofing opportunities but does not prevent enumeration. Zones using NSEC instead of NSEC3 can be walked to enumerate all records without brute force. Missing DNSSEC on a zone where the registrar supports it is worth noting in the report as a configuration gap.

┌──(kali㉿kali)-[~]
└─$ dig $DOMAIN +dnssec @$TARGET_IP

DNS normally uses UDP. Some servers restrict or disable TCP fallback, which breaks large responses and prevents zone transfers over that server. If TCP fails but UDP works, the server is likely an edge resolver or load balancer rather than the true authoritative source. This affects which queries will succeed and where to direct zone transfer attempts.

┌──(kali㉿kali)-[~]
└─$ dig $DOMAIN @$TARGET_IP +tcp
┌──(kali㉿kali)-[~]
└─$ dig $DOMAIN @$TARGET_IP +notcp

Very short TTLs, under 60 seconds, suggest dynamic DNS or expected frequent changes. Very long TTLs indicate static infrastructure that changes rarely. Inconsistent TTLs across records for the same domain can signal manually edited zone files or mismatches between primary and secondary servers. These inconsistencies sometimes reveal which nameserver is actually the source of truth.

┌──(kali㉿kali)-[~]
└─$ dig A $DOMAIN @$TARGET_IP +ttlunits

+trace follows the full delegation path from root servers down to the authoritative nameserver, ignoring the local cache. This reveals which servers are actually authoritative versus what the target claims. Mismatches between the registered NS and the servers that respond authoritatively can indicate domain shadowing, split-horizon DNS, or misconfigured delegations worth investigating further.

┌──(kali㉿kali)-[~]
└─$ dig +trace $DOMAIN

Querying the target server for its own reverse record reveals whether it manages reverse zones. A result confirms the server has authority over its own PTR records. No result is expected if it only manages forward zones. When reverse resolution works, query neighboring IPs in the same range to enumerate additional hostnames without relying on forward DNS brute force at all.

┌──(kali㉿kali)-[~]
└─$ dig -x $TARGET_IP @$TARGET_IP

Open recursion and wildcard behavior both expand the attack surface in different directions. An open resolver can be used for cache snooping: query for internal hostnames you already know to confirm whether the server has recently resolved them. Wildcards block reliable brute force but confirm the domain is live and resolvable. Both findings belong in the report regardless of whether they enable direct exploitation. For zones that allow unauthenticated updates, see Insecure DNS Dynamic Updates. For AD-integrated DNS poisoning via wildcards and WPAD records, see ADIDNS Poisoning and Hijacking and WPAD DNS Credential Capture with Responder.