Rules of Engagement
What we scan, what we don’t, and where we draw the line.
Purpose & Mission
DNS Tool is a passive OSINT platform. We observe. We don’t exploit. Period.
Every query we make is something any DNS resolver, mail server, or web browser already does millions of times a day. We read what’s publicly available, analyze it with RFC-grounded intelligence, and present findings you can independently verify. That’s the entire scope.
There is no grey area here. We built this platform to help defenders understand their own infrastructure — not to give attackers a head start.
What We Do
- Read public DNS records — A, AAAA, MX, TXT, NS, SOA, CAA, CNAME, DNSKEY, DS, NSEC, SVCB/HTTPS, TLSA. Standard queries via five independent resolvers.
- Check publicly accessible URLs — MTA-STS policy files, BIMI records, well-known paths. The same GET requests your browser makes.
- Analyze certificate transparency logs — Querying crt.sh for publicly logged certificates. This data is append-only and designed to be public.
- RDAP lookups — Domain registration data from the registrar’s public RDAP service. The successor to WHOIS, built for programmatic access.
- SMTP banner checks — Connecting to port 25 and reading the server’s greeting banner and STARTTLS capability. Every mail server on the internet expects this — it’s how email delivery works.
- SPF, DKIM, DMARC analysis — Parsing publicly published TXT records and evaluating them against RFC specifications.
What We Don’t Do
- No vulnerability scanning
- No exploitation of any kind
- No credential testing or brute-forcing
- No intrusive probing or active reconnaissance
- No port scanning beyond published service ports
- No payload delivery, injection, or manipulation
- No access to anything that requires authentication or authorization
If it requires permission to access, we don’t touch it. Full stop.
The Nmap Decision
Our probe infrastructure uses Nmap — yes, that Nmap. But with a very deliberate constraint. We allow exactly six NSE scripts:
We deliberately excluded all vuln, exploit, brute, and active-scan script categories. Every single one.
Would vulnerability scanning produce richer intelligence? Yes. Would it cross the ethical boundary between observing and probing? Also yes.
We chose the boundary.
Expanded Exposure Checks
These are opt-in, sequential, and rate-limited. They check for common misconfigurations that are visible to anyone with a browser:
- Exposed
.gitdirectories - Exposed
.envfiles - Directory listings left enabled
- Common sensitive paths (
wp-config.php.bak,.DS_Store, etc.)
Every check requests resources the same way a browser would — a standard HTTP GET. No fuzzing. No brute-forcing. No exploitation. If the resource is publicly accessible, we note it. If it’s not, we move on.
The Sidewalk Observer
Think of it this way: a penetration tester tries to break into your house. They test the locks, check the windows, try the back door.
We observe that your front door is locked from the sidewalk. That’s it.
That’s the line, and we stay on this side of it.
Covert Recon Mode
Same intelligence data. Different cognitive lens.
The adversarial interface exists for education — to help defenders think like attackers. When you see your domain through red-tinted glass, you ask different questions. You notice things the blue-team view normalizes. That’s the point.
No additional scanning or probing is performed. Covert Recon Mode doesn’t unlock secret capabilities or hidden scanners. It reframes the same publicly available data through an offensive-awareness perspective.
Data Handling
- DNS queries — Live, every time. Cache disabled (TTL=0). When you change a record and rescan, you see the new state immediately.
- RDAP data — Cached 24 hours. This is rate-limit protection — registrar RDAP services throttle aggressively, and hammering them helps nobody.
- Certificate Transparency data — Cached 1 hour. CT logs are append-only by design, so historical data doesn’t go stale.
- Scan results — Stored for history and drift analysis. All scans query public DNS records — the same data anyone can retrieve with
dig. We never share user accounts, sessions, or private settings with anyone. - RFC metadata — Cached 24 hours. Reference data that changes on the scale of years, not minutes.
All findings include verification commands — dig, openssl, curl — so you can reproduce every result independently in your own terminal. We don’t ask you to trust us. We give you the tools to verify.
Your Responsibilities
This platform produces intelligence. What you do with it is your decision and your responsibility.
If you use intelligence from this platform to attack, disrupt, or exploit any system — that’s on you. Not on us. Not on the tool.
DNS Tool exists for defense, education, and awareness. Use it that way.
Contact & Updates
Found a vulnerability in DNS Tool itself? We have a Security Policy & Safe Harbor that protects good-faith security researchers. Report it responsibly and we’ll work with you.
These Rules of Engagement may be updated as the platform evolves. New capabilities will be documented here with the same transparency. The ethical boundary doesn’t move — but the specifics of what we scan and how we scan it will grow over time, and you deserve to know exactly what that looks like.