How do I install the Dns Recon skill?

Run npx skillmds@latest add jihedbfr-art/dns-recon in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Dns Recon safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Dns Recon?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Dns Recon free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Dns Recon?

jihedbfr-art (@jihedbfr-art) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Dns Recon by jihedbfr-art — Agent Skill

Name: Dns Recon
Author: jihedbfr-art

File contents

Prerequisites

Target system, dependencies and environment configured.

Usage

Purpose

DNS tells you where things live before you ever connect. Mail servers, cloud providers, old hosts nobody cleaned up, sometimes a whole zone if the server is misconfigured. This skill walks the record types worth pulling and what each one gives away.

When to use it

Early recon, right alongside subdomain enumeration. It's passive against public resolvers, so it's safe to run before active scanning is authorised — you're asking the internet's phone book, not knocking on doors.

Procedure

Pull the core records for the domain. Each answers a different question — who hosts mail, who's authoritative, what the apex points at:
```
dig example.com ANY +noall +answer
dig example.com MX +short
dig example.com NS +short
dig example.com TXT +short
```
Read the TXT records carefully. SPF, DKIM, DMARC, and verification tokens for third-party services (google-site-verification, atlassian-, etc.) quietly reveal which SaaS the org uses.
Try a zone transfer against each authoritative nameserver. It should fail — when it doesn't, you get the entire zone in one request:
```
dig AXFR example.com @ns1.example.com
```
Check for wildcard DNS before you trust any brute-force list, or you'll chase ghosts:
```
dig random-does-not-exist-12345.example.com +short
```
Reverse-map the IP ranges you've found to tie hosts back to the org and spot shared infrastructure:
```
dig -x 203.0.113.10 +short
```

Cheatsheet

dig example.com MX +short           # mail infra
dig example.com NS +short           # authoritative servers
dig example.com TXT +short          # spf/dkim/dmarc, saas tokens
dig AXFR example.com @ns1...         # zone transfer (should fail)
dig -x 203.0.113.10 +short           # reverse lookup
dnsrecon -d example.com -a           # automated sweep incl. AXFR attempt
dnsx -l names.txt -cname -resp        # resolve + show CNAME targets

Reading the output

A successful AXFR is a finding on its own — the nameserver hands you every record, a full map of the internal naming.
CNAMEs pointing at a dead SaaS target (a storage bucket or app that no longer exists) is a subdomain-takeover lead.
SPF/DMARC missing or ~all/?all means the domain is spoofable — flag it for the phishing-defence work.
TXT verification tokens enumerate the org's third-party stack without touching any of it.

Pitfalls

Wildcard DNS makes every name resolve. Confirm it exists before brute-forcing, or filter wildcards in your resolver.
Cached vs live. Public resolvers cache; query the authoritative server directly (@ns1...) when you need current truth.
Assuming AXFR is always closed. It usually is — but it costs one query to check, and the payoff when it's open is the whole zone.

References

OWASP WSTG-INFO-02 (Fingerprint, DNS)
RFC 1035, RFC 7208 (SPF)
dnsrecon and dnsx documentation

Inputs

Relevant source code, logs, network traces, or system specifications.

Outputs

Analysis findings, security audit report, or generated code artifacts.

---name: dns-recondescription: Use when you want to pull records, zone data, and infrastructure hints out of a target's DNS alone — the quiet recon step before you touch a single host.---## Prerequisites- Target system, dependencies and environment configured.## Usage### PurposeDNS tells you where things live before you ever connect. Mail servers, cloud providers, old hosts nobody cleaned up, sometimes a whole zone if the server is misconfigured. This skill walks the record types worth pulling and what each one gives away.### When to use itEarly recon, right alongside subdomain enumeration. It's passive against public resolvers, so it's safe to run before active scanning is authorised — you're asking the internet's phone book, not knocking on doors.### Procedure1. Pull the core records for the domain. Each answers a different question — who hosts mail, who's authoritative, what the apex points at: ``` dig example.com ANY +noall +answer dig example.com MX +short dig example.com NS +short dig example.com TXT +short ```2. Read the TXT records carefully. SPF, DKIM, DMARC, and verification tokens for third-party services (`google-site-verification`, `atlassian-`, etc.) quietly reveal which SaaS the org uses.3. Try a zone transfer against each authoritative nameserver. It should fail — when it doesn't, you get the entire zone in one request: ``` dig AXFR example.com @ns1.example.com ```4. Check for wildcard DNS before you trust any brute-force list, or you'll chase ghosts: ``` dig random-does-not-exist-12345.example.com +short ```5. Reverse-map the IP ranges you've found to tie hosts back to the org and spot shared infrastructure: ``` dig -x 203.0.113.10 +short ```### Cheatsheet```bashdig example.com MX +short # mail infradig example.com NS +short # authoritative serversdig example.com TXT +short # spf/dkim/dmarc, saas tokensdig AXFR example.com @ns1... # zone transfer (should fail)dig -x 203.0.113.10 +short # reverse lookupdnsrecon -d example.com -a # automated sweep incl. AXFR attemptdnsx -l names.txt -cname -resp # resolve + show CNAME targets```### Reading the output- A **successful AXFR** is a finding on its own — the nameserver hands you every record, a full map of the internal naming.- **CNAMEs pointing at a dead SaaS target** (a storage bucket or app that no longer exists) is a subdomain-takeover lead.- **SPF/DMARC missing or `~all`/`?all`** means the domain is spoofable — flag it for the phishing-defence work.- **TXT verification tokens** enumerate the org's third-party stack without touching any of it.### Pitfalls- **Wildcard DNS** makes every name resolve. Confirm it exists before brute-forcing, or filter wildcards in your resolver.- **Cached vs live.** Public resolvers cache; query the authoritative server directly (`@ns1...`) when you need current truth.- **Assuming AXFR is always closed.** It usually is — but it costs one query to check, and the payoff when it's open is the whole zone.### References- OWASP WSTG-INFO-02 (Fingerprint, DNS)- RFC 1035, RFC 7208 (SPF)- dnsrecon and dnsx documentation## Inputs- Relevant source code, logs, network traces, or system specifications.## Outputs- Analysis findings, security audit report, or generated code artifacts.

Frequently asked questions

Dns Recon