DNS

Intro

When you type "http://www.hackepedia.org" into the URL bar of your browser, you are using the Domain Name System (DNS). This makes things a little easier for us, considering things actually use IPs instead. It would be a lot more difficult to memorize http://64.111.114.195 which would actually be a little faster for you as then you don't have to resolve DNS, but then again, that IP could change so DNS makes things more easy.

Distributed Database

DNS is a distributed database. It is build like a tree and does delegations from the root up to organization dns servers. Here is how a DNS tree would look like.

The tree set-up of delegating nameservers is intended to keep loads managable on the entire internet. If you have an organization named "skankyreggae" and wanted to be on the internet then you could take skankyreggae.tld as your domain name. The root would point to .tld and .tld would point to the nameservers serving skankyreggae. You can host skankyreggae on your own computers, by means of a DNS Server, provided they are reliably on the Internet all the time. When others seek skankyreggae.tld they would speak directly with your nameservers to get the IP of the www servers if they were seeking web. They would look up MX records if they tried to send mail to bob@skankyreggae.tld and so on.

DNS is best explained in RFC's 1034 and 1035.

gTLD and ccTLD domains

These can be viewed here in the Root Zone database.

Resolving

Let's try and find out what the IP of hackepedia.org is at the time of writing this:

$ nslookup hackepedia.org
Server:         66.33.216.129
Address:        66.33.216.129#53
Non-authoritative answer:
Name:   hackepedia.org
Address: 64.111.114.195

This means we asked the DNS server 66.33.216.129 what IP hackepedia.org has. That server answered back, I'm not the authoriatative answer, but it was 64.111.114.195 last I checked. Why did we ask 66.33.216.129? Well, that is the first nameserver line in /etc/resolv.conf (On Windows it's under your TCP/IP properties in Network configuration). You can have up to three listed, and it will try them in order. If the first one isn't answering, it will try the second. If we don't get a reply from the 2nd, we'll try the third. You want to all of your DNS servers to be as few hops away from you as possible, as you can imagine, you make a lot of requests to them if you're an avid websurfer. If you're really impatient, you should look at running your own caching nameserver.

If there is too much output for you there, or you don't care which DNS server you're querying, you can use host instead of nslookup:

$ host hackepedia.org
hackepedia.org has address 64.111.114.195

But when we asked 66.33.216.129, it said it wasn't the authoritative answer.. out of curiousity, who is?

$ whois hackepedia.org | grep "Name Server"
Name Server:NS1.DREAMHOST.COM
Name Server:NS2.DREAMHOST.COM
Name Server:NS3.DREAMHOST.COM

If you don't include the | grep "Name Server" part, you will get a lot of other information about that domain, like who owns it, where they are located, contact information etc, although the whois information is often faked for privacy reasons.

Now we will ask NS1.DREAMHOST.COM what the ip is:

$ nslookup hackepedia.org ns1.dreamhost.com
Server:         ns1.dreamhost.com
Address:        66.33.206.206#53
Name:   hackepedia.org
Address: 64.111.114.195

You can see the "Non-authoritative answer" bit is no longer there, as they are the authoritative DNS server for that domain name. How to find the authoritative source is interesting to know, but for all practical purposes, you will probably never have to do this manually as it all happens behind the scenes. See the Manual gethostbyname(3) to see how programs make this call in the background.

A sample DNS answer

I took this from a packet dump (tcpdump) of a lookup of my domain, it shows in detail the individual sections inside a UDP DNS packet.

The nameserver that gave this reply is nsd. The domain looked up is somewhere in the centroid.eu zone.

List of DNS Server Software

• BIND
• nsd
• wildcarddnsd