On TCP/IP-based networks, addressing and routing are performed using IP addresses (like 192.168.0.1), but people have difficulty remembering numbers so that's why the Domain Name System or DNS is necessary. The DNS protocol (RFC 1304 and 1305 with additional updates) is the "glue" that allows names that people can decipher easily (like http://www.google.com and http://www.yahoo.com).
The Domain Name System, along with BGP and a few other protocols, is a primary requirement for today's networks (especially the Internet). You specify names, rather than IP addresses, on countless configurations every day, including your web browsing. For this reason, problems with DNS can quickly and deeply affect an entire infrastructure— even though you can still reach services by IP address alone.
Other than the interactive translation of names, a number of protocols and applications use DNS directly for their main activity. The most notable example is SMTP, which uses DNS for mapping email addresses to their respective mail server(s). DNS is also used for resolving information other than IP addresses, such as SPF records, telephone numbers, and addresses (http://e164.org is one example). It is also used for certificates and other information that can be stored in DNS zone records that many applications use daily.
Every time an application is told to contact a host with its name rather than its IP address, it performs a query using the DNS server specified in the local configuration. As you can imagine, DNS traffic is a consistent portion of all network traffic and lots of services depend on it. For this reason the main transport protocol for DNS is User Datagram Protocol (UDP). UDP allows for faster communications and smaller overhead. TCP is also used if explicitly requested or when replies exceed 512 bytes in size. A useful listing of all DNS-related RFCs can be found at http://www.bind9.net/rfc.
Here's an example of the ping tool performing DNS resolution:
$ ping cns1.cw.net
64 bytes from cns1.cw.net (188.8.131.52): icmp seq=1 ttl=53 time=71.7 ms
64 bytes from euro-cns3.cw.net (184.108.40.206): icmp seq=2 ttl=53 time=68.0 ms
64 bytes from cns1.cw.net (220.127.116.11): icmp seq=3 ttl=53 time=63.9 ms 64 bytes from euro-cns3.cw.net (18.104.22.168): icmp seq=4 ttl=53 time=68.1 ms
4 packets transmitted, 4 received, 0% packet loss, time 3003ms rtt min/avg/max/mdev = 63.981/67.977/71.762/2.759 ms
As you can see, the name cns1.cw.net is resolved to IP address 22.214.171.124.
Other than the built-in name resolution capabilities of every networked application, many tools are available for manually querying DNS servers. The primary set of tools is the one provided by the Berkeley Internet Name Domain (BIND) software, which is also the most widely deployed DNS server implementation.
The tools provided by BIND are host, which is a basic utility, and the more flexible dig. Refer to their respective man pages for the full documentation of their available features.
$ host cns1.cw.net cns1.cw.net has address 126.96.36.199
$ host -a cns1.cw.net Trying "cns1.cw.net"
;; ->\>HEADER<<- opcode: QUERY, status: NOERROR, id: 4 9588
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; ANSWER SECTION: cns1.cw.net.
86279 IN A 188.8.131.52
;; AUTHORITY SECTION:
6279 IN NS 6279 IN NS
;; ADDITIONAL SECTION: ans1.cw.net. 4820 IN A
ans2.cw.net. 4820 IN A
Received 115 bytes from 184.108.40.206#53 in 133 ms
$ dig cns1.cw.net
<<>\> DiG 9.3.0 <<>\> cns1.cw.net global options: printcmd Got answer:
->\>HEADER<<- opcode: QUERY, status: NOERROR, id: 25312
; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION: ;cns1.cw.net.
;; ANSWER SECTION: cns1.cw.net.
86140 IN A 220.127.116.11
;; AUTHORITY SECTION:
86140 IN NS ans1.cw.net. 86140 IN NS ans2.cw.net.
;; ADDITIONAL SECTION:
;; SERVER: 18.104.22.168#53(22.214.171.124) ;; WHEN: Fri Oct 20 15:11:09 2006 ;; MSG SIZE rcvd: 115
As you can see, the output shows the different sections of a query.
• The question section provides the DNS query (in this case, an authoritative one for cns1.cw.net).
• The answer section shows the answer (the name resolves to 126.96.36.199).
• The authority section shows which DNS server can provide an authoritative reply to the query. The DNS server being queried obtained the answer from one of these servers and is now caching that information. We'll discuss the cache and recursive queries later in "The Technical Aspect: Spoofing, Cache Poisoning, and Other Attacks."
• The additional section provides every other piece of information the server might add if necessary. Most of the time you get "glue" records with the IP addresses of the name servers specified in the authority resource record. This is done for better efficiency; what the client is looking for are IP addresses and providing them in advance saves the client an additional query.
In most DNS transactions, two packets are exchanged: the UDP request and the UDP reply. Here's an example of a www.google.com lookup as seen by tcpdump:
17:30:57.728410 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 60) 10.1.7.1.1055 > 188.8.131.52.53: 49786+ A? www.google.com. (32)
17:30:57.796432 IP (tos 0x0, ttl 53, id 54990, offset 0, flags [none], proto: UDP (17), length: 368) 184.108.40.206.53 > 10.1.7.1.1055: 49786 5/7/7 www.google.com.
Unlike TCP, there are no sequence numbers. The validity of the reply is tracked internally by the DNS protocol using the identification value. In this example, the identification number is 4 97 8 6, which you can clearly see in the traffic dump.
The + after the request ID number means that a recursive query has been made. This means that you're asking for the information needed from your target name server and you are also asking it to perform all necessary queries further down the DNS tree for getting the final answer.
From the previous output, you can also see that 'www.google.com' doesn't resolve directly to an IP address. It resolves to a CNAME, which is an alias to another name, www.l.google.com in this reply. The CNAME is then resolved to three different IP addresses. This is done for load balancing purposes. Every time a client resolves the name, it will get a different IP address and possibly a different CNAME.
If you run the query directly against the Google name server (using the IP address you can obtain with queries like the ones already shown), you'll see a slightly different output.
Let's force a specific name server like this:
$ dig @220.127.116.11 www.l.google.com And here's the tcpdump output:
17:34:20.270098 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 62) 10.1.7.1.1055 > 18.104.22.168.53: 30188+ A? www.l.google.com. (34)
17:34:20.498833 IP (tos 0x0, ttl 44, id 32971, offset 0, flags [none], proto: UDP (17), length: 126) 22.214.171.124.53 > 10.1.7.1.1055: 30188*- 4/0/0 www.l.google.com. A 2 0 126.96.36.199, www.l.google.com. A 188.8.131.52, www.l.google.com. A 2 0 184.108.40.206, www.l.google.com. A 220.127.116.11 (98)
First, you probably notice the IP addresses in the output are different than the ones provided by the earlier query. That's due to the reply being dynamic and dependent on the client IP address space, among other possible factors. In this instance, you are querying the name server directly and other name servers aren't querying on your behalf as they did before with a recursive query.
The important difference is the *, which indicates that the authoritative answer bit is set since you are querying a server that's configured to be authoritative for that domain. The bit was off in the previous query since the information was relayed by a different DNS server.
So far we have shown examples of resolutions from names to IPv4 addresses. DNS will, however, have a major role when IPv6 (RFC 2460) is deployed. Having a 128-bit address space (as opposed to a 32-bit address space used in IPv4) means much larger subnets and ranges for every connected organization.
It also means that the usual subnet port scanning will be impossible to perform sequentially. The use of names will become a primary way for addressing network elements (much more than it is now), and scanning techniques will shift to address lookup by other means since brute-force scanning will no longer be feasible. DNS servers will increase their critical role when IPv6 is fully adopted.
$ host netgroup2.ipv6.polito.it netgroup2.ipv6.polito.it has address 18.104.22.168
netgroup2.ipv6.polito.it has IPv6 address 2001:6b8:401:3:213:20ff:fe18:9735
Was this article helpful?
Read how to maintain and repair any desktop and laptop computer. This Ebook has articles with photos and videos that show detailed step by step pc repair and maintenance procedures. There are many links to online videos that explain how you can build, maintain, speed up, clean, and repair your computer yourself. Put the money that you were going to pay the PC Tech in your own pocket.