DNS 101
As stated earlier, DNS is a distributed data base. When you pay a fee to register a domain one of the questions you answer deals with your Name Servers. You have to list two and they have to be registered in the DNS system.
The domain name system database has three levels. The first group of servers we call "root" servers. The second we call Top Level Domains or (TLDs). When your resolver needs to find the address for a web site, it makes a query.
Let's say you want to find Google.com. Your resolver asks the Root servers to identify Google.com's IP. The Root server replies, I don't know but I do now where you can find the answer. Start with the TLD servers for COM.
So, Root sends your query to a COM server. It says, OK. I don't have that information but I know a Name Server that does. It has an address of64.233.167.99 and the name ns1.google.com. So, go to that address and it will tell you the web site address of google.com
Your resolver takes the information from ns1.google.com and returns with an IP address. If Google's name server gave your resolver the correct name, you'll get a web page.
The path traveled looks like Figure 1.
Figure 1 - From Root to your Domain. （这个图解释了域名是如何被解析的：root-->一级域名服务器-->域名对应的name server）
In the upper left of Figure 1, we have depicted a set of servers with the annotation of Root. In the jargon of DNS, these servers represent the beginning of the DNS path. You will see them represented by a period or dot ("."). In your configuration files, your IP address to name mapping will end with a period. When we look at some of those files in a few minutes this will become clearer.
The Root servers are the top of the distributed DNS database. They have information about the Top Level Domains(TLDs). TLDs include com, net, org, mil, gov, edu, etc. When you contract to use a domain name, you chose which TLD you want. In my case, I have a domain in the org name space called centralsoft.org.
（com, net, org, ... 这些都是一级域名；google, baidu, ... 这些是二级域名；以此类推）
When I registered my name servers, I gave the name of server1.centralsoft.org and ns0.centralsoft.org to my registration agent. In the TLD servers for org, you will find my name servers. The org servers know where you should find information on centralsoft.
When I registered, I told the agent that I would take responsibility for maintaining a database of IP addresses and friendly names and map them to one another. So, we made an agreement and the Domain Name System said, "OK, now you have authority for the data on centralsoft.org. When someone wants to find the services you offer on the Internet, we will point them to you."
So, now I have to run an application which can answer your queries and say, "sure if you want to see my web page or send mail to one of my users, you can find them here. If you ask me for a name, I'll give you an IP address because I know you have this protocol which uses TCP/IP and I realize you need the address, even when you specify a name".
（域名服务器的作用就是：查到用户想访问的域名的IP地址）
That's where BIND comes into play. The people who maintain the BIND code make sure it meets the specifications of the Internet Engineering Task Force and will run on your server. All you have to do is learn how it does what it does.
Named lives on a domain name server and answers queries from resolvers. The application reads its data from a configuration file called named.conf. named.conf gets its information from something we call zone files. Several zone files exist, but one zone file in particular keeps a database of records that supply named with most of its answers.
In Figure 2, named had received a query. It looks to its configuration file named.conf, which looks to the primary zone file and hands off the information requested to the resolver from the outside.
Figure 2 - Answering a query
Some people refer to configuration files as rule files. BIND's configuration files seem like rule files to me. The rules of Domain Name Services require tight compliance. Making and resolving queries follow strict protocols on the Internet as does the interprocess communication within BIND.
Let's refer to Figure 2 again and look at the process. You should have BIND installed and running on your server. If not, we will address installation and configuration in one of the next sections.
The named process listens on port 53 of a Linux system. When it receives a query for an address, it looks to the first configuration file about which it knows: named.conf.
Figure 3 - named.conf （是bind的配置文件，里面含有域名的zone文件）
The following table depicts a simple named.conf file. If you have seen a file like this and didn't understand it, then let's break it down into its components. Once we do that, we can take the mystery out of it.
options { |
This file refers to the four other configuration files. The third line down lists the directory containing them all, /etc/bind where they exist.
The options statement defines the default directory for named and the location of the process ID (pid) file. named.pid represents the daemon itself. If you followed any of the Perfect Setup Tutorials, we put it in a chrooted environment.
The zone statement identifies the location of the hints, localhost, zone and reverse zone files.
- Hints file（root name server的位置：1. 一级NS的地址；2. 权威NS的地址）
This file contains the names and addresses of the root servers on the Internet. These know where the authoritative servers for your domain exist - the first one being the Top Level Domain (com, net, org, etc.) and next being the authoritative server for your domain.
- Local host file （本地NS）
Name servers are the masters of their own loopback domain (127.0.0.1). The point of creating local zone files for each aspect of your of localhost is to reduce traffic and allow the same software to work on your system as it does on the network.
- Zone file （zone文件，一个域名对应一个zone文件）
This file, also called the domain database, defines most of the information needed to resolve queries about the domain you administer. It maps names to IP addresses and provides information about the services offered by your Internet computer including your web and ftp server, email, telnet, name servers, etc.
The zone file uses several record types including the SOA or start of authority; NS or name server; A or host name to address map; PTR or pointer which maps addresses to names; MX or mail exchanger which identifies the mail servers in the domain; and CNAME or canonical name which defines an alias for a host name.
Don't try to memorize or understand what these record types mean at this point. Just realize that they exist and you will have ample opportunity to use them.
- Reverse zone file （反向域名zone文件，域名反向解析）
Another way to talk about zone files is to define them something that links all the IP addresses in your domain to their corresponding server. The reverse zone file maps IP addresses to host files. It's a mirror image of the database file above. You can recognize a reverse zone file because it has the extension of in-addr.arpa.
Figure 4 - Zone files
@ IN SOA server1.centralsoft.org. root.localhost. ( |
SOA refers to "Start of Authority" （起始授权机构）. When you look at Figure 1, remember that DNS distributes its database. By the time you enter the picture, the system has handed off authority for part of the entire database to you. So, your zone file has to indicate where your authority starts. Your authority starts in your zone file. Your Top Level Domain servers are waiting for you to do your part of the job.
（一级域名服务器把解析请求发到这儿，需要进一步做解析）
The data field of the SOA record contains several components or fields. You need to provide data or answers in the record which will allow another server on the Internet to satisfy its query. Think of the data field as a computer RECORD which has several fields. They include:
- Name
The root name of the zone. The "@" sign is a shorthand reference to the current origin (zone) in the /etc/named.conf file for that particular database file. The host name of the master server for this zone is server1.centralsoft.org. Don't worry if this jargon doesn't make sense. If just means that back in the named.conf configuration file an entry points to this file and this file points back to the entry in the configuration file.
- Class
A number of different DNS classes exist. For our purposes we will use the IN or Internet class used when defining IP address mapping information for BIND. The other classes exist for non Internet protocols and functions.
- Type
The type of DNS resource record. In the example, this is an SOA resource record.
- Name-server
Fully qualified name of your primary name server. Must be followed by a period.
- Email-address
This is the email address of the person responsible for the domain. Notice that instead of an @ sign, the address uses a period and is followed by a period. In this case, the email address is the root user or root.loalhost. In other applications the email address would be root@localhost.
- Serial-no （更新了以后，备用slave域名服务器也会更新zone文件配置）
A serial number for the current configuration is usually in a date format YYYYMMDD with an incremented double digit number tagged to the end. This allows you to do multiple edits each day with a serial number that both increments and reflects the date on which the change was made. It's a numeric value that the slave server can use to check whether the zone file has been updated. The slave periodically checks the serial number to see if it has changed. If it has, the slave will perform a zone transfer. 2006012103 is the serial number in the zone file above.
- Refresh
This field tells a slave DNS server how often it should check the master. This field represents a length in seconds. Every refresh cycle, the slave server checks to see whether it needs to perform a zone transfer. In this file we use 28800 as the value.
- Retry
This field tells the slave how often it should try to connect to the master in the event of a connection failure. The interval in our example is 7200.
- Expiry
Total amount of time a slave should retry to contact the master before expiring the data it contains. Future references will be directed towards the root servers. This is the expiration time, the length of time that the slave server should continue to respond to queries even if it cannot update the zone file. An expiration period exists under the theory that out of date data is worse than no data at all. In our example we use 604800.
- Minimum-TTL
最后，dig是一个很好的工具，
$dig www.baidu.com
; <<>> DiG 9.3.6-P1-RedHat-9.3.6-16.P1.el5 <<>> www.baidu.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19051
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 1
;; QUESTION SECTION:（请求）
;www.baidu.com. IN A
;; ANSWER SECTION:（回答）
www.baidu.com. 99 IN CNAME www.a.shifen.com. (CNAME也就是化名，重新请求解析www.a.shifen.com)
www.a.shifen.com. 458 IN A 119.75.217.56 (A记录，域名对应的IP地址)
www.a.shifen.com. 458 IN A 119.75.218.45 (A记录，域名对应的IP地址)
;; AUTHORITY SECTION:（权威服务器域名）
a.shifen.com. 5927 IN NS ns4.a.shifen.com.
a.shifen.com. 5927 IN NS ns5.a.shifen.com.
a.shifen.com. 5927 IN NS ns6.a.shifen.com.
a.shifen.com. 5927 IN NS ns2.a.shifen.com.
;; ADDITIONAL SECTION:
ns6.a.shifen.com. 76 IN A 220.181.4.178 (A记录，权威域名服务器IP地址)
;; Query time: 79 msec
;; SERVER: 222.73.13.68#53(222.73.13.68)
;; WHEN: Tue Nov 8 15:58:23 2011
;; MSG SIZE rcvd: 178