Continuing the discussion from Academy - Footprinting - DNS:
Another great way to learn and think outside the box. Few wordlists that can be useful
jhaddix my main man,
namelist your favorite player
Be fierce about it
Finally sortedcombined-knock-dns*********
I dont care about spoil. Can you give me answer - which subdomain we must find - I try every thing and spent 4 days just for it. try sorted_knock_dnsrecon_fierce_recon-ng.txt but nothing back… Pls tell me how to solve it.
the first question of this section is: Interact with the target DNS using its IP address and enumerate the FQDN of it for the “inlanefreight.htb” domain.
I don’t know what exactly are they asking for. Is there any FQDN like HTB{xxxx}?
via Discord I figuere out. No need further explanations now. But I am not sure if it is something about my english skills or it is something about how they write the questions.
I understand where you are coming from. I wouldn’t want to say it’s your English skills. It’s just about breaking down the question to know exactly what they want you to do. In other assessments in the modules, I’m sure you gonna hit a brick wall and you gonna fill like you doing something wrong but when you finally get it done maybe through the help in the forum or discord, you gonna realize that you’re actually on the right track. I’m almost done with the whole module, right now, I’m doing the Attacking Enterprise Network, after which I’m gonna sit for the certification. Anyways let me know if you have any questions
It is not a big deal. But sometimes, how is written the question could be quite confusing. But it is also my work figure out what does it mean.
Actually I have a question of this part (DNS). During some zone transfers, I obtains several FQDN with an IP (A records). But if I performed a NSLOOKUP, dig or dnsenum of that FQDN I get nothing. No records found. So, why does this happen? Thank you
See (Not spoiler due it is explained in the leson)
user@machine:~$ dig axfr inlanefreight.htb @10.129.14.128
<snip>
app.inlanefreight.htb. 604800 IN A 10.129.18.15
dev.inlanefreight.htb. 604800 IN A 10.12.0.1
<snip>
the next is what I expected
dig app.inlanefreight.htb @10.129.14.128
<SNIP>
;; ANSWER SECTION:
app.inlanefreight.htb. 604800 IN A 10.129.18.15
but this is unexpected (No answer section)
dig app.inlanefreight.htb @10.129.14.128
<SNIP>
;; AUTHORITY SECTION:
dev.inlanefreight.htb. 604800 IN SOA inlanefreight.htb. root.inlanefreight.htb. 2 604800 86400 2419200 604800
<SNIP>
Not all support zone transfers. That is why you have to iterate over the subdomains you’ve got to see if zone transfer is possible on the subdomain as well. For example, if you try zone transfer:
[+] dig axfr inlanefreight.local @xx.xx.xx.xx
assuming you got dev.inlanefreight.local,
You can as well try another zone transfer on the subdomain.
[+] dig axfr dev.inlanefreight.local @xx.xx.xx.xx
The questions are already solved. I iterate and I tried several wordlists. My question is specific. If I obtain an A record via Zone transfer (host.mydomain.com 604800 IN A 10.10.10.12). Why I cannot get the same record via NSLOOKUP? Case of dev.inlanefreight.htb. In other words: I expected to find same records via zone transfer than via brute-force (Assiming that all subdomains in my dictionary exists in the zone transfer results). The rest of the lesson is ok, I guess.
The goal of zone transfer is copying the zone file from one DNS server to a second DNS server. Therefore, if the zone you’re querying doesn’t support zone transfer, you will only be able to query the particular records on the server you’re querying. So when using nslookup or dig (without specifying zone transfer flag), your query result should be the same. However, if you opt to perform zone transfer, the result will be slightly different because other DNS server will be contacted requesting for records in the server to be transfer (maybe from primary server to secondary server). The idea of you bruteforcing the records is to educate us that administrators might mistakenly configure zone transfer which on a normal day is not dangerous if the server requesting zone transfer is authenticated server within the network.
Hi,
Thank you for your patience. I understand the goal of zone transfer. Having the same information in all name servers involved in a domain(s). As Administrators, the goal is limit those zone transfers to the desired hosts. Not everyone can access this information because it can be dangerous in terms of enumeration.
I think I don’t explain well or I don’t fully understand your explanations. If a DNS Server is misconfigured and I can perform a zone transfer via dig axfr , I expect that doing a query brute force I obtain at least, the same entries than zone transfer. Am I right?
In the exersises a zone transfer reveals several subdomains. One of them was dev with an IP. But quering the dns server abour this subdomain return no answer. What I expected here, was the same record with that IP. My question is: Why I cannot get the same information? In terms of enumeration of those exercises, If I cannot perform a zone transfer, I could not have answer most of the questions of this module.
I like fully understand what I study 
thank you
hey darvidor.
hope you are doing great.
I am also stuck on this question for long time. Could you help me with this?
Hi,
Sometimes is a matter of understand the question. I am not native english speaker and sometimes the question is not clear in the sense I don’t exactly knows what they ask me.
So, via the given IP use the techniques explained in that section to retrieve a FQDN. There is a brute force method, or you can use one of the tools such as dig. They ask you about something like:
whatever.inlanefreight.htb.