- Shopping Bag ( 0 items )
Perform advanced configuration tasks. Clear, in-depth coverage of every aspect of the domain name system. Master the features of...
Ships from: san francisco, CA
Usually ships in 1-2 business days
Perform advanced configuration tasks. Clear, in-depth coverage of every aspect of the domain name system. Master the features of BIND 8-and look ahead to the forthcoming BIND 9.
The technical details of protocols and packet structure can be complex and intimidating, particularly if your background is system administration and not network design. A protocol designer would probably feel the same way if asked to read one of your shell scripts. If this chapter is not your cup of tea, feel free to jump ahead to more practical chapters. But if you do, I urge you to come back and read this chapter after you have worked with DNS configuration. You will find an elegant linkage between the actions you take in configuring your system and the packets your system puts on the network.
This chapter tells you the rules that DNS uses to exchange information, not so you can master the protocols but so you can master the DNS servers that depend on these protocols. Understanding how data moves through the network helps in understanding why certain configuration parameters are required and what can be done to optimize them. Let's begin by understanding the protocol suite that DNS is part of.
The Internet Protocol is the foundation of the protocol suite. IP defines the network addressing, thus the term IP address, and it defines the basic unit of information that moves though the network. This unit of information is a block of data, called a datagram, that contains addressing and administrative information, as well as application-specific data. Because the datagram carries its own addressing information with it, it can move through the network independent of any other datagram. The benefits of this independence are robustness and efficiency. Robustness comes from the fact that each datagram can choose its own path through the network. If part of the network fails, the datagram can move around it on any available path. Efficiency comes from the minimal overhead involved in this scheme. Because each packet is independent, there is no need to keep track of other packets in the flow, which simplifies processing. The weakness of this independence is that sometimes the application data must span multiple datagrams. The IP protocol does not provide a way to sequence the data across datagrams.
Application programs access the IP protocol through two transport protocols: UDP and TCP. The User Datagram Protocol (UDP) provides the application with full access to the strengths of IP. With UDP, an application creates a message that becomes the data portion of a datagram. Each UDP message is an independent entity that moves through the network without depending on any other message.
The Transport Control Protocol (TCP) offers the application a way to address the weaknesses of IP. When an application needs to send a stream of related data, TCP provides the features necessary for the data to arrive at the remote location reliably and in sequence. TCP maintains the sequence by embedding sequence numbers in the stream of transmitted data and ensures reliability by requiring acknowledgements from the remote end. DNS is a network application that uses both UDP and TCP to send data over IP. Figure 2.1 shows these protocol layers....
...The only time DNS uses TCP is when distributed servers synchronize their databases by transferring entire domain database files. One of the challenges of a distributed database system is ensuring that all of the servers in that system provide accurate answers. The backup servers and the master servers must provide information of the same high quality. DNS keeps each backup server's data accurate by periodically transferring the entire domain database from the master server. During a file transfer, many related records are transmitted and it is important to keep the data in sequence. TCP is perfect for this. It has the reliability mechanisms needed to ensure that the entire database is received by the distributed servers, and it has sequence numbering to guarentee that all of the database records are received in order.
DNS uses UDP for the majority of its network traffic. It sends queries and receives responses as UDP packets. Given the critical nature of DNS, some people question the wisdom of sending DNS data over the unreliable UDP protocol. But the truth is, DNS is a perfect match for UDP. A DNS query fits into a single UDP packet and so does the response to the query—one packet is sent and one packet is received. No overhead is needed to establish a connection and no overhead is needed to sequence records because each DNS message is an independent entity. The response to the query is the acknowl-edgment of the request so there is no need to use a separate protocol for acknowledg-ments. Teaming a request/response protocol like DNS with UDP is highly efficient. The queries and responses that DNS sends over UDP have a well-defined message format.
The header section provides administrative information about the message, including information about what is contained in subsequent sections of the message.
The question section defines the question being asked by a query. When the question section is returned in a response, it is used to help determine which question the response is answering.
The answer section is found in a response and it contains the answer to the specific question sent in the query.
The authority section is found in a response and it contains pointers to the servers responsible for the domain being queried. Chapter 1, "The DNS Architecture," shows how important these pointers are for locating information within the DNS hierarchy, even when the first server queried cannot provide a real answer to the question.
The additional section is found in a response. This section contains database records that provide additional, important information that supports the answer. These are not database records directly requested by the query, but they help in interpreting or utilizing the response.
The format of the DNS message is clearly shown by the dig test tool. dig is one of the DNS test tools included with Linux. It is used throughout this text and covered extensively in Chapter 11, "Testing DNS." A nice feature of dig is that it shows the entire DNS message, not just the answer to the query. Listing 2.1 shows the DNS message format, as displayed by dig....