The Tutorial is also attached and available for download.

The host command is perhaps one of the most valuable if you are trying to do some enumeration of your system, or anyone else's. The host command will help you find machines, as well as the properties of many of the same machines, so that you can get a better idea of what is out there early on.

Using it in conjunction with a few other trusty commands, you can garner a lot about nearly any computer system or network.


The system that I'll be using in these examples is real, and is letnet.net, the system for my school's network.

You can, after typing in the hostname you wish to look-up, type in the server that you wish to look it up in. For example:

maccurdy@DBurnet:~> host DBurnet letnet.net
Using domain server:
Name: letnet.net
Address: 10.0.2.5#53
Aliases:

DBurnet.ph1.resnet.letnet.net has address 10.31.162.90
This will probably be especially useful if you want to look it up under servers that are not the default, such as an outside server, or some sort of proxy.

The main purpose of the host command is to do DNS look-ups, to convert from that DNS address to an IP address. For instance:
maccurdy@DBurnet:~> host letnet.net
letnet.net has address 10.0.2.5
letnet.net has address 10.0.4.11
As you can see, letnet.net has two IP addresses behind the DNS.

Typing in the host command, we find the following output, which tells us about the various modifiers:

maccurdy@DBurnet:~> host
Usage: host [-aCdlrTwv] [-c class] [-n] [-N ndots] [-t type] [-W time]
[-R number] hostname [server]
-a is equivalent to -v -t *
-b Use the bitstring form of IPv6 reverse lookup (deprecated)
-c specifies query class for non-IN data
-C compares SOA records on authoritative nameservers
-d is equivalent to -v
-l lists all hosts in a domain, using AXFR
-n Use the nibble form of IPv6 reverse lookup (default)
-N changes the number of dots allowed before root lookup is done
-r disables recursive processing
-R specifies number of retries for UDP packets
-t specifies the query type
-T enables TCP/IP mode
-v enables verbose output
-w specifies to wait forever for a reply
-W specifies how long to wait for a reply
My personal favorite modifiers when using the host command is -v, which as we see above gives us more accurate and complete output.

Regular host command, without modifiers:
maccurdy@DBurnet:~> host letnet.net
letnet.net has address 10.0.2.5
letnet.net has address 10.0.4.11
When we use host -v, however:
maccurdy@DBurnet:~> host -v letnet.net
Trying "letnet.net"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44080
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;letnet.net. IN A

;; ANSWER SECTION:
letnet.net. 600 IN A 10.0.2.5
letnet.net. 600 IN A 10.0.4.11

Received 60 bytes from 10.0.2.5#53 in 2 ms
The average users attention should immediately focus on:
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
"QUERY 1" tells us that there was only one host request, while "ANSWER: 2" says that two different things returned, which means that there were are seperate routers, computers, or subnets running directly under the address which was originally queried.

You can also use it to do a reverse look-up on IP Addresses. When we take one of the IP addresses that was returned when we typed in "host letnet.net"

maccurdy@DBurnet:~> host 10.0.2.5
5.2.0.10.in-addr.arpa domain name pointer david.letnet.net.
So we see that the reverse look-up tells us that david.letnet.net belongs to 10.0.2.5.

However, we still get more information with the -v modifier:
maccurdy@DBurnet:~> host -v 10.0.2.5
Trying "5.2.0.10.in-addr.arpa"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23530
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;5.2.0.10.in-addr.arpa. IN PTR

;; ANSWER SECTION:
5.2.0.10.in-addr.arpa. 1200 IN PTR david.letnet.net.

Received 69 bytes from 10.0.2.5#53 in 2 ms
We can get a listing of all of the machines, as well as extra information when we use the -a command, combining -v and -t.

maccurdy@DBurnet:~> host -a letnet.net
Trying "letnet.net"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55727
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 3

;; QUESTION SECTION:
;letnet.net. IN ANY

;; ANSWER SECTION:
letnet.net. 600 IN A 10.0.2.5
letnet.net. 600 IN A 10.0.4.11
letnet.net. 3600 IN NS david.letnet.net.
letnet.net. 3600 IN NS solomon.letnet.net.
letnet.net. 3600 IN SOA david.letnet.net. admin. 189949 900 600 86400 3600
letnet.net. 3600 IN MX 10 rachael.letnet.net.

;; ADDITIONAL SECTION:
david.letnet.net. 3600 IN A 10.0.2.5
solomon.letnet.net. 3600 IN A 10.0.4.11
rachael.letnet.net. 1200 IN A 10.0.2.20

Received 215 bytes from 10.0.2.5#53 in 3 ms
As you can see, this not only gives us a more complete listing of machines, but it also gives us the data on several of the machines hooked up to letnet.net, including their IP Address, which saves us the trouble of doing a reverse look-up later on.

This is a very useful command, and is a large part of the foot-printing process.

One thing that is very odd is that one machine that is hooked up to the network, seth.letnet.net. When I do a query of it:
maccurdy@DBurnet:~> host -a seth.letnet.net
Trying "seth.letnet.net"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22259
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;seth.letnet.net. IN ANY

;; ANSWER SECTION:
seth.letnet.net. 3600 IN A 10.0.4.220

Received 49 bytes from 10.0.2.5#53 in 2 ms
So we're able to pick up on more of the machines much more quickly, getting IPs, as well as machine names so that it becomes easier to pick out servers.

But lets try the host command on myself, as one computer that is hooked up to this very network. My host name is DBurnet, so we'll try that:

Trying "DBurnet.ph1.resnet.letnet.net"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17077
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;DBurnet.ph1.resnet.letnet.net. IN ANY

;; ANSWER SECTION:
DBurnet.ph1.resnet.letnet.net. 900 IN A 10.31.162.90

Received 63 bytes from 10.0.2.5#53 in 2 ms
So we can see that my IP address, within the network, is 10.31.162.90 (this is quite accurate.) The DNS can also reveal a good bit of information if you know how to read it...

DBurnet is my machine. ph1 refers to Penn Hall, Resnet is the Resident network, letnet.net being the main network. If you know a bit about the network or the lay-out of the area, you can read a bit into the DNS reports.

At the bottom of that report, we see that all of this information comes from the IP address 10.0.2.5. We can either scroll up to find out what this is, or in the case that it isn't listed...
maccurdy@DBurnet:~> host 10.0.2.5
5.2.0.10.in-addr.arpa domain name pointer david.letnet.net.
Let's check out the DNS information for someone else on my campus.
maccurdy@DBurnet:~> host -a 10.31.150.90
Trying "90.150.31.10.in-addr.arpa"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37484
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;90.150.31.10.in-addr.arpa. IN PTR

;; ANSWER SECTION:
90.150.31.10.in-addr.arpa. 900 IN PTR stephenake.thom1.resnet.letnet.net.

Received 91 bytes from 10.0.2.5#53 in 2 ms
Sthepenake is the computer name, thom1 is the floor he lives on, resnet and letnet.net are the same as above. Once more, the DNS tells us the location of the computer, both physically and on the network.

Now lets try using the host command on one of the sub-addresses above, which for now we can assume are routers.

maccurdy@DBurnet:~> host -a resnet.letnet.net
Trying "resnet.letnet.net"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35796
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;resnet.letnet.net. IN ANY

;; ANSWER SECTION:
resnet.letnet.net. 600 IN A 10.0.2.80
resnet.letnet.net. 600 IN A 10.0.2.75

Received 67 bytes from 10.0.2.5#53 in 2 ms
This reveals a fair amount of information to us, and once again reveals the controlling computer to be 10.0.2.5, or David. So obviously that computer is vital, and should be doubly protected from attack.

Later on, we'll see that 10.0.2.5 is always the returning IP address, for every one of my scans, including those of completely unrelated networks. It seems to either be the location for their proxy or their firewall. If we followed the logic above purely, we would have reached the right conclusion for the wrong reasons. Many ISPs will give the same result, as will many networks, if you happen to be on the inside of one.

Let's find out exactly what the other two IP addresses were, shall we?

maccurdy@DBurnet:~> host -a 10.0.2.80
Trying "80.2.0.10.in-addr.arpa"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3877
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;80.2.0.10.in-addr.arpa. IN PTR

;; ANSWER SECTION:
80.2.0.10.in-addr.arpa. 1200 IN PTR resnet1.resnet.letnet.net.

Received 79 bytes from 10.0.2.5#53 in 2 ms
maccurdy@DBurnet:~> host -a 10.0.2.75
Trying "75.2.0.10.in-addr.arpa"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12545
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;75.2.0.10.in-addr.arpa. IN PTR

;; ANSWER SECTION:
75.2.0.10.in-addr.arpa. 1200 IN PTR resnet2.resnet.letnet.net.

Received 79 bytes from 10.0.2.5#53 in 1 ms
We're able to see that they each relate to their own little sub-router, resnet1 and 2, each beneath resnet.letnet.net. What if we were to do a host on ph1.resnet.letnet.net?

maccurdy@DBurnet:~> host -a ph1.resnet.letnet.net
Trying "ph1.resnet.letnet.net"
Host ph1.resnet.letnet.net not found: 3(NXDOMAIN)
Received 86 bytes from 10.0.2.5#53 in 1 ms
Hmm...it seems to not be showing up. But the information is still being routed to and from david. Either its a blocked/stealthed range, an artificial one, or something weird is going on.

The same thing happens with thom1.resnet.letnet.net:
maccurdy@DBurnet:~> host -a thom1.resnet.letnet.net
Trying "thom1.resnet.letnet.net"
Host thom1.resnet.letnet.net not found: 3(NXDOMAIN)
Received 88 bytes from 10.0.2.5#53 in 1 ms
This is one example of the -a being a very useful addition to the command. Without it, we are simply given:
maccurdy@DBurnet:~> host thom1.resnet.letnet.net
Host thom1.resnet.letnet.net not found: 3(NXDOMAIN)
While this is good to know, knowing that the information is being routed to david is quite good, and lets us peek a bit further into the lay-out of the network.

Let's think back, though, to one of our first queries. "host -a letnet.net" revealed:
maccurdy@DBurnet:~> host -a letnet.net
Trying "letnet.net"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58149
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 3

;; QUESTION SECTION:
;letnet.net. IN ANY

;; ANSWER SECTION:
letnet.net. 600 IN A 10.0.2.5
letnet.net. 600 IN A 10.0.4.11
letnet.net. 3600 IN NS david.letnet.net.
letnet.net. 3600 IN NS solomon.letnet.net.
letnet.net. 3600 IN SOA david.letnet.net. admin. 189955 900 600 86400 3600
letnet.net. 3600 IN MX 10 rachael.letnet.net.

;; ADDITIONAL SECTION:
david.letnet.net. 3600 IN A 10.0.2.5
solomon.letnet.net. 3600 IN A 10.0.4.11
rachael.letnet.net. 1200 IN A 10.0.2.20

Received 215 bytes from 10.0.2.5#53 in 3 ms
This very bit of information came from david. So david may be the network controlling computer. This is re-inforced by the second to last line in the answer section:
letnet.net. 3600 IN SOA david.letnet.net. admin. 189955 900 600 86400 3600

Basic queries of the other computers, solomon and rachael turn up void, and do not seem to be of much help at the moment.

At this point, we're pretty much done with footprinting for letnet.net. Let's do a quick nmap of david.letnet.net, just to see what's there:
maccurdy@DBurnet:~> nmap david.letnet.net

Starting nmap 3.30 ( http://www.insecure.org/nmap/ ) at 2003-12-03 16:10 CST
Interesting ports on david.letnet.net (10.0.2.5):
(The 1623 ports scanned but not shown below are in state: closed)
Port State Service
42/tcp open nameserver
53/tcp open domain
88/tcp open kerberos-sec
135/tcp open loc-srv
139/tcp open netbios-ssn
389/tcp open ldap
445/tcp open microsoft-ds
464/tcp open kpasswd5
593/tcp open http-rpc-epmap
636/tcp open ldapssl
1026/tcp open LSA-or-nterm
1029/tcp open ms-lsa
1058/tcp open nim
1068/tcp open instl_bootc
1723/tcp open pptp
2105/tcp open eklogin
3268/tcp open globalcatLDAP
3269/tcp open globalcatLDAPssl
3372/tcp open msdtc
3389/tcp open ms-term-serv
27000/tcp open flexlm0

Nmap run completed -- 1 IP address (1 host up) scanned in 0.509 seconds
Wow. That would make some people VERY happy. :-) It is interesting to note that the exact same ports are open on david.letnet.net as just at letnet.net. This is either purely by chance or by coincidence.

Now, let us take a look at a completely different server, one that happens to be the one hosting my website.

maccurdy@DBurnet:~> host -la www.nintendogeneration.com
Trying "www.nintendogeneration.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49759
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;www.nintendogeneration.com. IN ANY

;; ANSWER SECTION:
www.nintendogeneration.com. 86391 IN A 64.177.96.218
www.nintendogeneration.com. 86391 IN MX 10 mail.nintendogeneration.com.

;; ADDITIONAL SECTION:
mail.nintendogeneration.com. 26068 IN A 64.177.96.218

Received 97 bytes from 10.0.2.5#53 in 2 ms
Notice that there are only two answers when we use the full name, including the www. If we were to exclude that, however, we would get a full five answers.

maccurdy@DBurnet:~> host -la nintendogeneration.com
Trying "nintendogeneration.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16877
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 3

;; QUESTION SECTION:
;nintendogeneration.com. IN ANY

;; ANSWER SECTION:
nintendogeneration.com. 86099 IN A 64.177.96.218
nintendogeneration.com. 86099 IN NS ns.websitebusinesshost.com.
nintendogeneration.com. 86099 IN NS ns2.websitebusinesshost.com.
nintendogeneration.com. 86099 IN SOA ns.websitebusinesshost.com. hostmaster.websitebusinesshost.com. 200311321 86000 7200 3600000 43200
nintendogeneration.com. 86099 IN MX 10 mail.nintendogeneration.com.

;; ADDITIONAL SECTION:
ns.websitebusinesshost.com. 86164 IN A 208.56.157.150
ns2.websitebusinesshost.com. 86053 IN A 216.147.108.157
mail.nintendogeneration.com. 26059 IN A 64.177.96.218

Received 227 bytes from 10.0.2.5#53 in 3 ms
Wow. Some completely new websites. Let's check them out real quick.

maccurdy@DBurnet:~> host -la ns.websitebusinesshost.com
Trying "ns.websitebusinesshost.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32201
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 3

;; QUESTION SECTION:
;ns.websitebusinesshost.com. IN ANY

;; ANSWER SECTION:
ns.websitebusinesshost.com. 86077 IN A 208.56.157.150
ns.websitebusinesshost.com. 86077 IN NS ns.thehostgroup.com.
ns.websitebusinesshost.com. 86077 IN NS ns2.thehostgroup.com.
ns.websitebusinesshost.com. 86077 IN SOA ns.thehostgroup.com. hostmaster.thehostgroup.com. 200220513 86000 7200 3600000 600
ns.websitebusinesshost.com. 86077 IN MX 10 mail.ns.websitebusinesshost.com.

;; ADDITIONAL SECTION:
ns.thehostgroup.com. 86077 IN A 208.56.139.98
ns2.thehostgroup.com. 86077 IN A 208.56.138.82
mail.ns.websitebusinesshost.com. 86077 IN A 208.56.157.150

Received 224 bytes from 10.0.2.5#53 in 3 ms
Hmm...thehostgroup.com. I wonder if that might be the root of all of this?

maccurdy@DBurnet:~> host -la ns.thehostgroup.com
Trying "ns.thehostgroup.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7086
;; flags: qr aa ra; QUERY: 1, ANSWER: 5, AUTHORITY: 2, ADDITIONAL: 3

;; QUESTION SECTION:
;ns.thehostgroup.com. IN ANY

;; ANSWER SECTION:
ns.thehostgroup.com. 86400 IN MX 10 mail.ns.thehostgroup.com.
ns.thehostgroup.com. 86400 IN A 208.56.139.98
ns.thehostgroup.com. 86400 IN NS ns.thehostgroup.com.
ns.thehostgroup.com. 86400 IN NS ns2.thehostgroup.com.
ns.thehostgroup.com. 86400 IN SOA ns.thehostgroup.com. hostmaster.thehostgroup.com. 200323715 86000 7200 3600000 600

;; AUTHORITY SECTION:
ns.thehostgroup.com. 86400 IN NS ns.thehostgroup.com.
ns.thehostgroup.com. 86400 IN NS ns2.thehostgroup.com.

;; ADDITIONAL SECTION:
mail.ns.thehostgroup.com. 86400 IN A 208.56.139.98
ns.thehostgroup.com. 86400 IN A 208.56.139.98
ns2.thehostgroup.com. 86400 IN A 64.177.65.2

Received 229 bytes from 10.0.2.5#53 in 51 ms
You'll notice here that we're still getting results from 10.0.2.5, which is david.letnet.net. Its probably the proxy or firewall, as I mentioned above.

Hmm. No new servers this time. I'm willing to wager that we're dealing with closely related servers, if not a real, live virtual server. Let's compare the IP address given for ns2.thehostgroup.com to that given to nintendogeneration.com
64.177.65.2 for ns2.thehostgroup.com
64.177.96.218 for nintendogeneration.com

So now let's review exactly what the host command has brought us so far:
It has revealed four machines/routers running under letnet.net, as well as pointed to the one which seems to be most critical (firewall/proxy).
We've been able to find DNS sub-domains, and guess at the physical location of computers from them. (If you know about about the network location and the lay-out of it from before hand, useful for schools or businesses that you've had dealings with.)
We've found related domains, and have been able to accurately guess that a domain is a part of a virtual server, with DNS splits, routers, and other fun stuff.
Lastly, we've found our way to the core computer on several networks.

host is a very powerful command for footprinting a system, if you're either doing a security audit or just doing some light probes. After some skillful host probes and nmaps, you'll find your far more prepared to attack or defend a network, or at least understand it better.