🎯 Quick Reference

Key Points

Main technique:
DNS Zone Transfer (AXFR)
Subdomain Enumeration
DNS Record Analysis
Internal Domain Discovery
Critical tools:
dig - Primary DNS query tool
dig ns - Nameserver queries
dig axfr - Zone transfers
dig @server domain - Targeted queries
dnsenum - Advanced enumeration
/usr/share/seclists wordlists
Common pitfalls:
Assuming root domain transfer failure means no access
Always check subdomains and internal domains
Missing follow-up enumeration
One finding should lead to more tests
Forgetting to check different record types
A, TXT, CNAME, etc.
Not documenting found information
IPs, hostnames, and patterns are important

Purpose of exercise/Question
Start with a clear statement of the exercise's main goal
The primary objective of this exercise is to demonstrate comprehensive DNS enumeration techniques and
understand how misconfigured DNS servers can lead to information disclosure. Through a series of
interconnected challenges, you learn how initial discoveries can lead to deeper enumeration opportunities.

Enumerate the specific skills or competencies this exercise aims to

develop
 Technical Command Mastery
Using dig for different types of DNS queries
Understanding zone transfers (AXFR)
Employing DNS enumeration tools like dnsenum
Interpreting DNS records and responses
Methodological Thinking
Sequential information gathering
Building on discovered information
Understanding relationships between different DNS zones
Recognizing patterns in naming conventions
Security Assessment Skills
Identifying DNS misconfigurations
Understanding the impact of information disclosure
Recognizing security boundaries and their breaches
Evaluating the severity of findings
Documentation and Analysis
Recording and organizing findings
Understanding the significance of discovered information
Connecting separate pieces of information
Drawing conclusions from technical data

Describe what you are expected to learn or be able to do by the end of

this exercise
Technical Competencies
Execute DNS queries using appropriate tools and commands
Perform zone transfers when permitted
Navigate between different DNS zones
Use subdomain enumeration techniques effectively
Security Understanding
Identify common DNS security misconfigurations
Understand the risks of unrestricted zone transfers
Recognize sensitive information exposure
Appreciate the importance of proper DNS security controls
Methodological Approach
Develop a systematic approach to DNS enumeration
Build an information gathering strategy
Use discovered information to guide further investigation
Document and track findings effectively
Real-World Application
Apply enumeration techniques in a practical scenario
 Understand how DNS reconnaissance fits into security assessments
Recognize similar patterns in real-world environments
Develop remediation recommendations for discovered issues

Steps taken to get to the answer

Walkthrough of process taken to get to answer: Include images/Diagrams

Question: Interact with the target DNS using its IP address and enumerate the FQDN of
it for the "inlanefreight.htb" domain.

Answer: ns.inlanefreight.htb.
Hint:

Queryinng the domain using the command

dig ns inlanefreight.htb @10.129.82.99

we get ns.inlanefreight.htb

Related Section
 Question: Identify if its possible to perform a zone transfer and submit the TXT record
as the answer. (Format: HTB{...})

Answer: HTB{DN5_z0N3_7r4N5F3r_iskdufhcnlu34}

to do this we are going to try and performa an internal zone transfer on the domain

dig axfr inlanefreight.htb @10.129.82.99

This gives us a bunch of information

Open: Pasted image 20241120200314.png

The Zone Transfer Worked on the Root Domain

Root domains should typically block zone transfers
The fact that inlanefreight.htb allowed it is already a security misconfiguration
Sensitive Information Exposed:
Mail server locations ( mail1.inlanefreight.htb )
Internal IP addresses (10.129.x.x range)
Development server ( dev.inlanefreight.htb )
Application server ( app.inlanefreight.htb )
Internal systems ( internal.inlanefreight.htb )

Related Section

Open: Pasted image 20241120194615.png

This one took a little more work so here is a graph explaining why

This did not give me what I was looking for when it comes to the txt file
 dig axfr inlanefreight.htb @10.129.14.128

but

dig axfr internal.inlanefreight.htb @10.129.82.99

did give me the answer I was looking for

Accessible Zone Restricted Zone

internal.inlanefreight.htb inlanefreight.htb

Contains TXT Record Access Denied

Primary DNS Server

2. Zone Data 1. AXFR Request 3. Zone Transfer

DNS Client Secondary DNS Server

dig axfr internal.inlanefreight.htb @10.129.82.99

This command targeted the internal subdomain not the root domain
The AXFR (zone transfer) request was successful because:
Zone transfers were likely enabled for the internal zone
No transfer restrictions were in place
This domain contained the TXT record we were looking for

dig axfr inlanefreight.htb @10.129.14.128

This command targeted the root domain

The AXFR request failed because:
Zone transfers were likely disabled for the root domain
Transfer restrictions were properly configured
This is a common security practice for public-facing domains

Key Technical Points:

 AXFR (Asynchronous Full Transfer Zone) is a DNS protocol feature that allows a secondary DNS server
to copy the entire zone file from a primary DNS server
Many organizations intentionally allow zone transfers for internal domains while restricting them for
external/public domains
The TXT record was specifically placed in the internal zone, making it accessible only through the
successful zone transfer

The diagram above illustrates how:

The green zone represents the accessible internal subdomain

The orange zone represents the restricted root domain
The blue servers show the DNS infrastructure
The red client represents your dig command attempts

This is a common scenario in security assessments where internal DNS zones might have weaker controls
than external ones, allowing for information disclosure through zone transfers.

Question: What is the IPv4 address of the hostname DC1? ​

Answer: 10.129.34.16
Hint: Zones often have the name of a subdomain.

This one can be found in the previous screenshot

where we see dc1. sub domain and the IP after it

Question: What is the FQDN of the host where the last octet ends with "x.x.x.203"? ​

Answer: win2k.dev.inlanefreight.htb
Hint: Remember that different wordlists do not always have the same entries.
This one took a little work for me to get through as well (I had also read through the question a little too fast
and didnt break it down as much as I should have) they were looking for the hostname or FQDN that ended
in .203 as the last octet

where I went wrong was attempting to brute force the normal domain trying to find the answer when I should
have been brute forcing the subdomains for hosts

dnsenum --dnsserver 10.129.82.99 --enum -p 0 -s 0 -o subdomains.txt -f

/usr/share/seclists/Discovery/DNS/fierce-hostlist.txt dev.inlanefreight.htb

is what ended up giving me the answer

Open: Pasted image 20241120202640.png

after looking through the subdomains we had and running fierce_hostlist.txt against each of them this is what
I came up with for the answer

DNS Enumeration Process and Findings

 Initial DNS Recon

Step 1: NS Query

dig ns inlanefreight.htb @10.129.82.99

ns.inlanefreight.htb

Step 2: Root Domain Transfer

dig axfr inlanefreight.htb @10.129.82.99

Transfer Successful

Found Subdomains Step 3: Internal Domain Transfer

dig axfr internal.inlanefreight.htb @10.129.82.99

dev.inlanefreight.htb Transfer Successful

dnsenum with fierce-hostlist

win2k.dev.inlanefreight.htb TXT Record Found Found in Zone Data

IP Ends With

.203 DC1: 10.129.34.16

Personal reflection: This could include your thoughts on the exercise's

difficulty, its relevance to your training, or how it ties into broader
cybersecurity concepts.
I definitely need to slow down and read the questions better to not go down false tracks this would end up
really hurting me in the future but im feeling good moving forward after catching myself here

Feynman Technique explanation of the steps taken to get the

answers to the questions we were asked
Step 1: Finding the Name Server

What we did: We used dig ns inlanefreight.htb @10.129.82.99 to find the nameserver.

Simple explanation: Think of a name server like a phone book operator. Before we can ask for any other
information, we need to know who to ask. The dig ns command is like asking "Who's in charge of the phone
book for inlanefreight.htb?"

Result: We found ns.inlanefreight.htb - this is our operator who knows all the information.

Step 2: Trying to Get All Information at Once

What we did: We used dig axfr inlanefreight.htb @10.129.82.99 to attempt a zone transfer.

Simple explanation: A zone transfer is like asking the phone book operator "Can I have a copy of the entire
phone book?" Usually, they should say no - but sometimes they accidentally say yes! This is what happened
here. We got information about different parts of the network, including a subdomain called
dev.inlanefreight.htb .

It's like finding out there's not just one phone book, but several different ones for different departments.

Step 3: Checking Other Phone Books

What we did: After finding out there was an internal domain, we tried dig axfr
internal.inlanefreight.htb @10.129.82.99

Simple explanation: We found out there was another phone book for "internal" numbers. When we asked
for a copy of this one, we got:

A special code (TXT record) that was our flag

Information about DC1's IP address (10.129.34.16)

This is like finding the internal company directory that shouldn't have been shared with outsiders.

Step 4: Looking for Specific Information

What we did: Used dnsenum with a special wordlist to look deeper at dev.inlanefreight.htb

Simple explanation: After finding the development subdomain, we used a tool that's like a really fast
assistant that tries common computer names. It's like going through the phone book and looking for specific
types of entries.

We used dnsenum --dnsserver 10.129.82.99 --enum -p 0 -s 0 -o subdomains.txt -f

/usr/share/seclists/Discovery/DNS/fierce-hostlist.txt dev.inlanefreight.htb

This found win2k.dev.inlanefreight.htb which had an IP ending in .203.

Why This Worked

Each step built on the previous one:

1. First, we found who to ask (the nameserver)

2. Then we asked for everything (and surprisingly got it!)
3. We found more places to look (internal and dev subdomains)
4. Finally, we looked carefully at those new places

It's like finding one key that opens a door, behind which there are more keys and more doors!

The Security Lesson

This worked because the system was misconfigured:

It gave away entire "phone books" when asked (zone transfers)

It showed internal information to outside people
It didn't have proper restrictions on who could ask for what

In a secure system:

Zone transfers should be restricted

Internal information should stay internal
Systems should verify who's asking before giving information

MITRE ATT&CK Relevance:

Technique T1590: Gather Victim Network Information

Sub-technique T1590.002: DNS

🔗 Cross-References
Related Techniques
Zone Transfer Attacks
DNS Reconnaissance
Subdomain Enumeration

🎓 Additional Resources
 Official documentation:
BIND 9 Documentation
RFC 1035 - Domain Names Implementation and Specification
Helpful blogs:
HackTricks - DNS Pentesting
Port Swigger - DNS Enumeration
Video tutorials:
IppSec's DNS Enumeration Techniques
TCM Security - DNS Recon
Practice labs:
HackTheBox Academy - DNS Enumeration
TryHackMe - DNS in Detail

Command Variations

dig Command Variations

1. Basic NS query:

dig ns domain.com @DNS_SERVER

2. Zone Transfer (AXFR):

dig axfr domain.com @DNS_SERVER

3. Specific record query:

dig domain.com A/MX/TXT/CNAME @DNS_SERVER

dnsenum Command Variations

1. Basic enumeration:

dnsenum --dnsserver DNS_SERVER domain.com

2. With custom wordlist:

dnsenum --dnsserver DNS_SERVER --enum -f wordlist.txt domain.com

3. Full enumeration with options:

 dnsenum --dnsserver DNS_SERVER --enum -p 0 -s 0 -o output.txt -f wordlist.txt
domain.com

Other Useful Tools

1. fierce:

fierce --domain domain.com --dns-servers DNS_SERVER

2. host command:

host -t NS/A/AXFR domain.com DNS_SERVER

3. nslookup:

nslookup -type=NS/A/AXFR domain.com DNS_SERVER

Common Wordlists for DNS Enumeration

/usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt
/usr/share/seclists/Discovery/DNS/fierce-hostlist.txt
/usr/share/seclists/Discovery/DNS/namelist.txt

Best Practices
1. Always start with passive reconnaissance
2. Use multiple tools to validate findings
3. Document all discovered subdomains and records
4. Check both root domain and subdomains for zone transfers
5. Verify findings with multiple DNS servers when possible