DNS Reconnaissance — Find the Leaked Internal Endpoint
Easy Reconnaissance · 20 min
DNS Reconnaissance
Scenario
You are in the passive recon phase of an external pentest engagement against acme-corp.example. Your scope is "anything publicly available via DNS — no active scanning."
A dig-style dump of all public DNS records for the apex domain is in the right pane.
One of these records leaks the hostname of an internal infrastructure endpoint that the customer almost certainly didn't intend to expose externally. Find it.
Objective
Submit the fully-qualified hostname of the leaked internal endpoint.
Answer format
<subdomain>.acme-corp.example
All lowercase. Example shape (NOT the answer):
internal-api.acme-corp.example
Tips
- Don't bother with the obvious public records (
www,mail,ftp— those are intentionally public). - Look at TXT records carefully — SPF/DKIM/DMARC records often reveal subdomains that the customer uses for outbound mail / API integrations.
- A subdomain prefixed
internal-,staging-,dev-,vpn-,admin-is a strong tell. - One DNS record type that is famous for over-disclosure is TXT (SPF specifically — it lists every server allowed to send mail).
Hints
Hint 1 (−10 pts)
Focus on the TXT records. SPF policies list every host allowed to send mail for the domain — and frequently include internal hostnames as `a:<host>` or `include:<host>` directives.
Hint 2 (−10 pts)
The SPF record (v=spf1) contains an `a:` directive pointing at a hostname starting with `internal-`. That's your leak.
Hint 3 (−10 pts)
Full answer: internal-mail-relay.acme-corp.example
Lab environment · sandboxed iframe · auto-resets every 60 min