[转载]Understanding the DNS Protocol(了解DNS协议)
原始连接：[url]http://www.windowsnetworking.com/articles_tutorials/Understanding-DNS-Protocol-Part1.html[/url]信息来源：邪恶八进制信息安全团队（[url]www.eviloctal.com[/url]）
Domain Name Service aka DNS
The Domain Name Service is what I would call a 揹ense?protocol. I would call it dense because there is so much to DNS that it has resulted in many books being written solely on DNS, what it is, and what it does. Unlike some other application layer protocols, which perform only one function, DNS does the normal resolution of domain name to IP address and other things like help route your email. By route I don抰 mean that DNS has suddenly turned into a routing protocol, but rather that, through the propagation of something called MX records, your email can be sent to the right mail server.
In this series of articles on DNS we will cover the structure of the domain name service as a whole. We will then go on to cover a bit more about how DNS actually works via its hierarchical design. Furthermore we will cover quite a few examples of what are called resource records and RCODES, also what they mean and how we can break them out. This will be done at the packet level to help give us context in case you have to investigate your network at the packet level at some future date. Just remember that, as I mentioned before, this series of articles will really only just scratch the surface of DNS. What I won抰 be covering is the actual setup of DNS on a network, and the troubleshooting of it. With that said let抯 begin our exploration of this often unappreciated protocol.
The humble beginnings
For those system administrators out there, you can almost map the early beginnings of DNS to the growth of internal DNS as viewed by Microsoft. In Windows NT we had what was called the LM Hosts file. Contained in the LMHosts file was a mapping of NetBIOS names to IP addresses. This was done to ease the task of finding computers and services offered on the internal network. That was quickly followed by the WINS server, and then by Active Directory.
One goal of these various schemes was to map an IP address to a host name. This static mapping of IP addresses to computer names was actually the beginning of DNS, as we know it today. Back in the early days of ARPA you simply had a file with a list of computers and their names on a computer. There was no such thing as DNS in the form we know it today. It was most certainly not distributed as it is now, but more so held on individual computers. The link provided on ARPA makes for some interesting reading as it details briefly the birth of the Internet. Though the holding of a list of names on each computer quickly became impractical as the Internet grew. Due to this DNS as we know it today slowly began to grow. Some know DNS as Distributed Name Service and that is a fairly accurate term for no one computer holds a list of all domain names to IP addresses. Please look here for an example of the distributed nature of DNS.
You will see that at the top of the diagram I just linked to is where the DNS root server would reside. Below the root server are the top-level domains, as exemplified by the .com .edu and .mil amongst others. Several of these domains are for the exclusive use of the United States, as that is where the Internet actually originated. On the far left of that diagram is where you see the .arpa. This is used for 搑everse lookups?/A> and in essence is the opposite of what DNS is normally used for. In a reverse lookup you are asking that an IP address be resolved to a domain name. That is what the arpa domain is used for. Each of the levels seen on that diagram holds the IP address of the DNS server above it. While you may think that a root DNS server contains a vast amount of entries, this is actually not the case at all. You can check this site or this site out to view the DNS root servers.
So what is actually contained in the root DNS server? Good question. It actually contains a file called the 揜oot Zone File? This file contains all of the names and IP addresses for the authoritative DNS servers at the Top Level Domain aka: TLD. An example of a top level domain would be the .com and .edu amongst others. How does the root name server抯 contents get built then? Well that is largely done by the folks at IANA. Contained in this link is a wealth of information as well. You can check for port assignments, as well as protocol assignments here. You could definitely consider IANA a definitive source of information as they are the 揑nternet Assigned Numbers Authority?
Back to the DNS root servers though. There is no actual traffic that goes through the DNS root servers as such. They will do no actual routing. These servers as mentioned simply contain a mapping of the IP addresses of the domain DNS servers for the top-level domain. If you recall I mentioned earlier that DNS is actually very much a 揹istributed?name service. As such there is no one computer which contains a list of all the DNS information. It would be pretty much impossible to do so, or impractical at best.
Anyhow I do not want to delve too deeply into the breakdown of the DNS hierarchy itself, as there are many excellent sites that already do just that. Another part of DNS has to do with caching of the DNS records themselves. To take a look at the DNS cache on your home computer simply type in as follows at a DOS prompt;
ipconfig /displaydns
This will bring up the DNS records that the (lets say you are using Windows XP) XP resolver will check before going out to your ISP抯 DNS server to have the query you are issuing resolved. You may want to give the following link a read as well for it contains some excellent information about DNS caching on a Windows XP computer. Contained in the information that the above noted command outputs to the DOS prompt is the record name, record type, ttl value of the cached DNS record as measured in seconds, data length, section, and lastly the record type. You can see a sample output of the ipconfig /displaydns command below. Pretty neat stuff!
testlab-cs4
------------------------------------------------------
Record Name . . . . . : testlab-cs4
Record Type . . . . . : 1
Time To Live . . . . : 30318069
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . :
192.168.1.110
The record type number you see above relates to the 揂?record. A full list of the record type numbers and their corresponding record types can be found here. Well on that note I will wrap up part one of this three part series on DNS. In part two and three we will dig deeper into this multi-faceted protocol. Till then!
DNS, Resource Records and RCODE抯
We are now familiar with the domain name service at a high level. What we now need to do is become familiar with some specifics. To that end we will take a look at about a half dozen or so resource records, and explain what they mean. This will be done with example packets so that we can visualize them, vice simply read about them. The resource records we will cover below are in no specific order. On that note let抯 get on with it!
Seen in the packets below are various non-routable IP抯, namely 192.168.1.200 and 192.168.1.100, which I put in place to substitute the real IP addresses that were in the packets. Lastly, I have included a selection of both RCODE抯 and Resource Records for us to take a look at. With that said let抯 take a look at our first packet, which contains an RCODE.
There is no such domain!
During your everyday surfing of the web it may happen that a link you click on fails to load the requested page. Well, just like in the real world of business, sometimes web sites will disappear for a variety of reasons. Bearing this in mind DNS needs a way of communicating this back to the client that originally made the request. This is done via a DNS RCODE ie: response code known as NX or non-existent domain. It means literally just that, there is no such domain to be found. Please note that I have snipped the below noted packet for brevity, and that in reality the length of the packet should have been 143 bytes as reflected in the 搇en 143?field highlighted below.
So with that said we can see that the DNS server located at 192.168.1.200 is telling 192.168.1.100 (who originally must have asked for DNS resolution on a domain) that the domain it wanted resolution on does not exist. The number that we see below ie: 17165 is the DNS transaction number, and allows the client requesting DNS resolution to keep track of what answer goes with what DNS request. After all, your computer is likely making quite a few DNS resolution requests, and having this number allows it to keep track of what belongs with what.
11:00:06.289070 192.168.1.200.53 > 192.168.1.100.155: 17165 NXDomain 0/1/0 (115) (ttl 58, id 43899, len 143)
0x0000 4500 008f ab7b 0000 3a11 26d7 c0a8 01c8 E....{..:.&...e.
0x0010 c0a8 0164 0035 009b 007b 3410 430d 8183 .....5...{4.C...
0x0020 0001 0000 0001 0000 xxxx xxxx xxxx xxxx .........xxxxxxx
0x0030 xxxx xxxx xxxx xxxx xxxx 6e2d 6164 6472 .xxxxx.in-addr
0x0040 0461 7270 6100 000c 0001 c014 0006 0001 .arpa...........
I want answers!
What we see below is an Answer resource record as evidenced by the underlined part seen below. Specifically the 揂?corresponds to the 揂?resource record. The A record is used to define an IP address. In our case below it is the IP address for the banner.paypopup.com domain. From the below we can deduce once again that 192.168.1.100 issued an 揂??request for the IP address of the banner.paypopup domain. This resource record is very common, and you would indeed see a lot of these were you sniffing your connection while you were surfing. Once again for brevities sake I have snipped part of the packet.
11:00:09.511821 192.168.1.200.53 > 192.168.1.100.155: 17170 1/5/5 banner.paypopup.com. A 66.48.78.203 (242) (ttl 58, id 47434, len 270)
0x0000 4500 010e b94a 0000 3a11 1889 c0a8 01c8 E....J..:.....e.
0x0010 c0a8 0164 0035 009b 00fa 4ae2 4312 8180 .....5....J.C...
0x0020 0001 0001 0005 0005 0662 616e 6e65 7208 .........banner.
0x0030 7061 7970 6f70 7570 0363 6f6d 0000 0100 paypopup.com....
0x0040 01c0 0c00 0100 0100 000d 7200 0442 304e ..........r..B0N
CNAME record
CNAME stands for canonical name, and is also a DNS resource record, much like the A resource record seen above. The CNAME resource record is used to indicate the true host name of a computer. There can however be more then one domain name that is associated with an IP address. In essence a computer can have a whole lot of aliases, which resolve to the one IP address, and that is why the CNAME record is there. The CNAME record must be in the DNS database for each alias.
11:00:11.484898 192.168.1.200.53 > 192.168.1.100.155: 17189 3/7/7 fpdownload.macromedia.com. CNAME fpdownload.macromedia.speedera.net., fpdownload.macromedia.speedera.net. A 216
.200.249.204, [|domain] (ttl 58, id 49656, len 375)
0x0000 4500 0177 c1f8 0000 3a11 0f72 c0a8 01c8 E..w....:..r..e.
0x0010 c0a8 0164 0035 009b 0163 16bb 4325 8180 .....5...c..C%..
0x0020 0001 0003 0007 0007 0a66 7064 6f77 6e6c .........fpdownl
0x0030 6f61 640a 6d61 6372 6f6d 6564 6961 0363 oad.macromedia.c
ServFail RCODE
Another cryptic packet you may encounter is the 揝ervFail?which is an RCODE just like the NXDomain is. What the ServFail tells you is that there was possibly an error experienced by the DNS server itself, or a timeout occurred during forwarding. This in reality is telling you that it could not honor your DNS request due to a server side issue in all likelihood.
01:04:37.291738 192.168.1.200.53 > 192.168.1.100.649: [udp sum ok] 60301 ServFail 0/0/0 (33) (ttl 58, id 25184, len 61)
0x0000 4500 003d 6260 0000 3a11 7043 c0a8 01c8 E..=b`..:.pC..e.
0x0010 c0a8 0164 0035 0289 0029 1266 eb8d 8182 .....5...).f....
0x0020 0001 0000 0000 0000 0b6d 7966 756e 6e79 .........myfunny
0x0030 6d61 696c 0363 6f6d 0000 1c00 01 mail.com.....
What does a DNS query look like?
Well so far we have looked at quite a few DNS responses, and have yet to actually look at a DNS query. Without further ado let抯 take a look at what a query looks like. From the underlined portion below we can see the 揂??which means that 192.168.1.200 is asking for an Answer record from 192.168.1.100. In essence he is asking for an IP address for the domain listed after the 揂??
We can see that we have an overall packet length of 61 as evidenced by the 搇en 61?which is also underlined below. Also we can see that we have thirty three data bytes in the packet as noted in the ?33)?also underlined below. Why is there a disparity between the two numbers you ask? Good question. Well we have an overall packet size of sixty one, and a data payload of thirty three. That makes for a difference of twenty eighty bytes. Where those twenty eight bytes are is twenty bytes for the IP header, and eight bytes for the UDP header. Once we add those in we are able to account for the overall packet size of sixty one.
09/06/2005 21:00:38.294185 192.168.1.200.32768 > 192.168.1.100.53: [udp sum ok] 56810 A? amextipe.opt.mr. (33) (DF) (ttl 254, id 27836, len 61)
0x0000 4500 003d 6cbc 4000 fe11 e2d4 c0a8 01c8 E..=l.@.........
0x0010 c0a8 0164 8000 0035 0029 64c8 ddea 0000 R.Z....5.)d.....
0x0020 0001 0000 0000 0000 0861 6d65 7874 6970 .........amextip
0x0030 6503 6f70 7402 6d72 0000 0100 01 e.opt.mr.....
So we have covered so far several resource records and RCODE抯. This will wrap up part two of the DNS series. In part three we will wrap our coverage of DNS and till then, keep learning!
DNS and it抯 bits and bytes
Over the course of the past two articles we have covered DNS at a fairly high level. We did not delve into any system administration content really, but concentrated more on getting a solid feel for what the protocol does, and how it does it. Lastly we also took a look at how a DNS packet looks like on the wire as it were. In this last part of the DNS article series we will take one DNS packet and go through the DNS header. This will allow you to hopefully better understand the protocol itself, and how it works. You may feel that going through the DNS packet, hex value by hex value, as unimportant.
My feelings on the matter are that being able to completely parse the packet will give you a sense of confidence when dealing with DNS. This in turn will allow you to approach any network related issue involving DNS with self-assurance. That kind of self-assurance will only come from having an understanding of not only how the protocol itself works, but also what it looks like in a packet format.
Lets pick this packet apart!
Well before we begin to pick the below noted packet apart you will need to make sure you have the SANS TCP/IP and tcpdump flyer located at the bottom of the page. This will allow you to navigate the DNS packet with a minimum of effort. I will now comment on the packet directly beneath it.
01:00:09.684739 192.168.1.200.53 > 192.168.1.100.616: [udp sum ok] 59930 NXDomain 0/1/0 (102) (ttl 58, id 55787, len 130)
0x0000 4500 0082 d9eb 0000 3a11 f873 c0a8 01c8 E.......:..s..e.
0x0010 c0a8 0164 0035 0268 006e ba41 ea1a 8183 .....5.h.n.A....
0x0020 0001 0000 0001 0000 0133 0234 3503 3139 .........3.45.19
0x0030 3103 3230 3605 646e 7362 6c05 736f 7262 1.206.dnsbl.sorb
0x0040 7303 6e65 7400 0001 0001 c019 0006 0001 s.net...........
0x0050 0000 0e10 002c 0772 626c 646e 7330 c01f .....,.rbldns0..
0x0060 0364 6e73 0469 7375 7803 636f 6d00 431c .dns.isux.com.C.
0x0070 e07e 0000 1c20 0000 1c20 0009 3a80 0000 .~..........:...
0x0080 0e10 ..
As a refresher I will quickly go through all of the fields starting from the first line and work my way through going from right to left. The first line has the time stamp, which is the time that the destination computer 192.168.1.100 received this DNS packet at.
Next we have the source IP address and source port ie: 192.168.1.200.53 followed by the director sign, which signifies the flow of the conversation as it were. After that we then have the destination IP address and destination port.
Now we have the [udp sum ok] signifying that the udp checksum is correct. After that we have the DNS transaction number of 59930. This is, as mentioned before, used to keep track of the DNS queries and responses by the originator of the query.
Next we see the RCODE of NXDomain and that means that the domain that resolution was requested for does not exist. Following that are the numbers 0/1/0 and they mean that there is zero answer records, one authoritative record, and zero additional records in this packet.
Following that we have the value of 102 in brackets. That is the amount of DNS data contained in this packet. Next up is the ttl value of 58, an IP ID value of 55787, and lastly the overall packet length of 130. It is important to remember that the 搇en 130?field as seen in the above packet refers to overall packet size, and that includes both the protocol headers, and data if present.
We won抰 bother going through the hex values below that represent the IP and UDP header, but rather skip ahead to the DNS header and data. Once again a quick way to navigate to key points in the packet is to do the following.
We know that our IP header will end at bytes ?164?as underlined on line 0x0010. We also know there are no IP options due to the half-byte value of 5 as underlined on line 0x0000. Due to this we then know that the UDP header will start at bytes ?035?and end at bytes 揵a41? So from this we can ascertain that our DNS header will begin at byte 揺a?as underlined on line 0x0010.
With that out of the way we will now break out the DNS header values. If you check your TCP/IP and tcpdump flyer that you downloaded you will note that the first field in the DNS header relates to the ID number. This field is assigned two bytes or 16 bits. You will need to write out a small chart like the one below.
| 32768 | 16384 | 8192 | 4096 | 2048 | 1024 | 512 | 256 | 128 | 64 | 32 | 16 | 8 | 4 | 2 | 1 |
What we now need to do is take the two bytes represented by the characters 揺a1a?and enter them in a calculator, which will perform hex to decimal conversions. You will note that once you convert 揺a1a?to decimal that you indeed come up with the value of 59930 in the packet above. So far so good, the DNS record number matches.
Now we will see that the next values as noted on our SANS cheat sheet have a variety of different meanings. So far we have seen mostly values reflected in a header that break neatly either on a nibble (half of a byte or four bits) or a full byte or bytes. Well in DNS we have several values contained in a byte. That is why we need the chart shown above.
We will need to take the value of the two bytes ?183?and convert that to a decimal number. From that decimal number we will be able to determine what values are set, and which are not. Well 8183 in hex or as it should be written 0x8183 breaks out to 33155 in decimal.
Using the above chart as noted we begin to divide 33155 by the values assigned to the two byte field, which contain the values on your cheat sheet ie: QR, Opcode, and so on. So we know then that the first position of 32768 is set, thus we know this to be a Response, vice a Query. Having subtracted 33155 from 32768 we have a remainder of 387.
We now subtract 387 from the next closest fit. In this case that would be 256. So that value is also set, which tells us that the 揜ecursion Desired? or RD field is set. Now we have a remainder of 131. This we subtract from 128 on our chart above, which tells us that the 揜ecursion Available?field is set. That now leaves us with a remainder of 3.
Here is the tricky part. You have to take this decimal value of 3 and look at your 揜esponse code?field seen on your SANS cheat sheet, under the DNS header. You will see that a decimal value of 3 reflects that the 揘on-existent domain?or NXDomain RCODE is set. We can see that it is in the header of this packet, as evidenced by the NXDomain underlined.
Following these values it is simply a matter of applying the same logic to the remainder of the values in the DNS header. As you can see it is not much more difficult then breaking out the normal TCP/IP packets that we have done before. It was only a bit more confusing as we were now looking at application layer data as well now. You have now successfully parsed a DNS packet. That is a skill not very many people have! On that note I will wrap up this three part article series on DNS, and sincerely hope that it was useful to you. I always welcome comments, so please feel free to write me. Till next time! 好不容易找到一个介绍dns数据包的
还是英文的,能否提供中文的
页:
[1]