DNS offers a variety of information about public and private organization servers, such as IP addresses, server names and server functions. A DNS server will usually divulge DNS and Mail server information for the domain which it is authoritative.
This is a necessity, as public requests for mail server addresses and DNS server addresses make up our basic internet experience.We can interact with a DNS server using various DNS clients such as host, nslookup, dig, etc.
NSLOOKUP
In this example, we've connected to our local DNS server (192.168.195.2) and asked it to resolve the A record for www.hackblitz.blogspot.com. The DNS server replies with the address 74.125.236.171
MX Queries
In order to identify the Mail Servers belonging to an organization, we can simply ask the DNS server to show us all the MX records available for that domain:
> set type=mx
> myexample.com
Server: 192.168.195.2
Address: 192.168.195.2#53
Non-authoritative answer:
myexample.com mail exchanger = 30 mfnbm2.myexample.com.
myexample.com mail exchanger = 5 mx1.myexample.com.
myexample.com mail exchanger = 20 mfnbm1.myexample.com.
Authoritative answers can be found from:
Notice the 3 mail servers that were listed - mfnbm2, mx1 and mfnbm1. Each server has a “value” associated with it - 30 , 5 and 20 respectively. This value indicates the preference of arrival of mails to the mail servers listed. Lower values are preferred. From this we can assume that mx1 is the primary mail server and that the others are backups in case mx1 fails.
NS Queries
With a similar query, we can identify all the DNS servers authoritative for a domain:
> set type=ns
> myexample.com
Server: 192.168.195.2
Address: 192.168.195.2#53
Non-authoritative answer:
myexample.com nameserver = ns1.myexample.com.
myexample.com nameserver = ns4.myexample.com.
Authoritative answers can be found from:
We identify two DNS servers serving the myexample.com domain – ns1 and ns4. (Now think what happened to ns2 and ns3 ?) This information can be useful when we attempt to perform zone transfers.
Information gathering using DNS is divided into 3 main techniques:
1. Forward lookup
2. Reverse lookup
3. Zone transfers
Forward lookup
The idea behind this method is to try to guess valid names of organizational servers. We try to resolve a given name. If it resolves then the server exists. Let's try a short example using the host command.
BT ~ # host www.myexample.com
www.myexample.com has address 216.200.241.66
BT ~ # host idontexist.myexample.com
Host idontexist.myexample.com not found: 3(NXDOMAIN)
BT ~ #
Notice that the name www.myexample.com resolved, and the host command (which acts as a DNS client) returned the IP address belonging to that FQDN. The name idontexist.myexample.com did not resolve, and we got a “not found” result.you may automate this attack using bash scripting.
Reverse lookup bruteforce
Armed with these IP network blocks, we can now try the second method of DNS information gathering – reverse lookup bruteforce. This method relies on the existence of PTR host records being configured on the organizational nameserver. PTR records are becoming more widely used as many mail systems require PTR verification before accepting mail. Using the host command, we can perform a PTR DNS query on an IP, and if that IP has a PTR record configured, we will receive its FQDN.
BT ~ # host 216.200.241.69
69.241.200.216.in-addr.arpa domain name pointer us.myexample.com.
BT ~ #
From this result, we see that the IP 216.200.241.64 back resolves to us.myexample.com. Using a bash script, we can automate the backward resolution of all the hosts present on the myexample.com IP blocks.
Zone Transfer
Basically, a zone transfer can be compared to a “database replication” act between related DNS servers. Changes to zone files are usually made on the Primary DNS server and are then replicated by a zone transfer request to the secondary server. Unfortunately, many administrators misconfigure their DNS servers and, as a result, anyone asking for a copy of the DNS server zone will receive one.
It is important to say that a successful zone transfer does not directly result in a penetration. However it definitely aids the hacker in the process. Let's attempt a zone transfer on myexample.com. We can use the host or dig command in Linux for this.
host -l <domain> <DNS server name>
We can gather the DNS server names either by using nslookup (as mentioned above), or by using the host command.
BT ~ # host -t ns myexample.com
myexample.com name server ns4.myexample.com.
myexample.com name server ns1.myexample.com.
BT ~ #
Now that we have the DNS server addresses, we can try performing the zone transfer.
BT ~ # host -l myexample.com ns1.myexample.com
Using domain server:
Name: ns1.myexample.com
Address: 194.29.32.197#53
Aliases:
Host myexample.com not found: 5(REFUSED)
; Transfer failed.
BT ~ #
Not surprisingly, the myexample network admin have configured their DNS servers well. We can see that our attempt has been refused.