Recently, while driving to my work, I listened to radio as usual. Because of the establishment of the new EU (European Union) domain, there was an interview with a representative of one of the Internet Service Providers. For some time the interview went on, boringly similar to other common radio interviews, but suddenly the presswoman started to improvise and she asked, "But isn’t the DNS too vulnerable? Is it prepared for terrorist attacks?" The ISP representative enthusiastically answered, "The whole Internet arose more than 30 years ago, initiated by the American Department of Defense. From the very beginning, the Internet architecture took into account that it should be able to keep the communication functional even if a part of the infrastructure of the USA were destroyed, i.e., it must be able to do without a destroyed area."
He went on enthusiastically, "We have 13 root name servers in total. Theoretically, only one is enough to provide the complete DNS function." At this point, we must stop for a moment our radio interview to remind you that a role and principle of usage of root name servers are described in the first chapter of this book. Now, let’s go back to our interview again. The presswoman, not satisfied with the answer, asked, "All these root name servers are in the USA, aren’t they? What will happen if someone or something cuts off the international connectivity, and I am not be able to reach any root name server?" The specialist, caught by the presswoman’s questions, replied, "This would be a catastrophe. In such a case, the whole Internet would be out of order."
That time I did not immediately came upon the solution that an area cut off this way is by nature similar to an Intranet. In such a case, it would be enough to create national (or continental) recovery plan and put into work a fake national (or continental) name server, exactly according to the description in Chapter 9, describing closed company networks. The result would be that the Internet would be limited only to our national (or continental) network; however, it would be at least partially functional.
In fact at that time, the specialist’s answer made me angry. "So what?", I thought, "Only DNS would be out of order; i.e., names could not be translated to IP addresses. If we do not use names but use IP addresses instead, we could still communicate. The whole network infrastructure would be intact in that case!"
But working according to my way would be lengthy, and I thought about it over and over. After some time I realized that the present Internet is not the same as it was in the early 1990s. At that time the handful of academics involved with the Internet would have remembered those few IP addresses. But in the present scenario, the number of IP addresses is in the millions, and the number of people using the Internet is much higher still. Most of them are not IT experts and know nothing about IP addresses and DNS. For such people, the Internet is either functional or not—similar to, for example, an automatic washing machine. From this point of view, the Internet without functional DNS would be really out of order (in fact it would still be functional, but only IT experts would be able to use it).
The goal of this publiction is to illustrate to readers the principles on which the DNS is based. This publication is generously filled with examples. Some are from a UNIX environment, some from Microsoft. The concrete examples mostly illustrate some described problem. The publication is not a text book of a DNS implementation for a concrete operating system, but it always tries to find out the base of the problem. The reader is led to create similar examples according to his or her concrete needs by him- or herself.
The goal of this book is to give the reader a deep understanding of DNS, independent of any concrete DNS implementation. After studying this book, the reader should be able to study DNS standards directly from the countless Requests for Comments (RFC). Links to particular RFCs are listed in the text. In fact, it is quite demanding to study the unfriendly RFCs directly without any preliminary training. For a beginner, only to find out the right RFC could be a problem.
Before studying this book, the reader should know the IP principles covered in the Understanding TCP/IP book published by Packt Publishing (ISBN: 1-904811-71-X) because this publication is a logical follow-on from that book.
The authors wish you good luck and hope that you get a lot of useful information by reading this publication.
Chapter 1 begins to explain basic DNS principles. It introduces essential names, for example, domain and zone, explaining the difference between them. It describes the iteration principle by which the DNS translates names to IP addresses. It presents a configuration of a resolver both for UNIX and for Windows. The end of the chapter explains name server principles and describes various name server types.
Chapter 2 is fully focused on the most basic DNS procedure, the DNS query. Through this procedure, the DNS translates names to IP addresses. In the very beginning, however, this chapter describes in detail the Resource Record structure. At the end of this chapter, many practical examples of DNS exchanges are listed.
Chapter 3 deals with other DNS procedures (DNS Extensions), i.e., DNS Update, DNS Notify, incremental zone transfer, negative caching, IPv6 Extensions, IPsec, and TSIG.
Chapter 4 talks about the DNS implementation. It is derived from its historical evolution. From the historical point of view, the oldest DNS implementation that is still sometimes used is BIND version 4. This implementation is very simple so it is suitable to describe basic principles with it. Next, the new generations of BIND are discussed followed by the Windows 2000 implementation.
Chapter 5 discusses the tools for debugging DNS such as nslookup, dnswalk, and dig, how to control a name server using the rndc program, and the common errors that might occur while configuring DNS.
Chapter 6 deals with the creation of DNS domains (domain delegation) and with the procedure of domain registration.
Chapter 7 also talks about domain delegation. In contrast to Chapter 6, here the domain registration relates not to forward domains but to reverse domains.
Chapter 8 deals with international organizations, called Internet Registries, which are responsible for assigning IP addresses and domain registration.
Chapter 9 describes the DNS architecture of closed intranets.
Chapter 10 talks about the DNS architecture from the point of view of firewalls.
This publication is created to help beginners, who are already familiar with computers, to discover DNS secrets. It will be also useful for computer administrators and, specifically, for network administrators. It will be also useful as a textbook for DNS lectures.
This book discusses the fundamentals of DNS; it is not a manual for some concrete DNS implementation. It contains examples from both Windows and UNIX environments. It explains the DNS concepts to a user, independently of the hardware and software he or she uses. We can work effectively with DNS even in a not-so-powerful personal computer.
In this book, you will find a number of styles of text that distinguish between different kinds of information. Here are some examples of these styles, and an explanation of their meaning.
There are three styles for code. Code words in text are shown as follows: "We can include other contexts through the use of the include directive."
A block of code will be set as follows:
[statistics-file path_name] [zone-statistics yes_or_no] [auth-nxdomain yes_or_no] *[deallocate-on-exit yes_or_no] [dialup dialup_option]
When we wish to draw your attention to a particular part of a code block, the relevant lines or items will be made bold:
[statistics-file path_name]
[zone-statistics yes_or_no]
[auth-nxdomain yes_or_no]
*[deallocate-on-exit yes_or_no]
[dialup dialup_option]
Any command-line input and output is written as follows:
$ORIGIN default_domain
New terms and important words are introduced in a bold-type font. Words that you see on the screen, in menus or dialog boxes for example, appear in our text like this: "clicking the Next button moves you to the next screen".
Feedback from our readers is always welcome. Let us know what you think about this book, what you liked or may have disliked. Reader feedback is important for us to develop titles that you really get the most out of.
To send us general feedback, simply drop an email to <[email protected]>, making sure to mention the book title in the subject of your message.
If there is a book that you need and would like to see us publish, please send us a note in the SUGGEST A TITLE form on www.packtpub.com or email <[email protected]>.
If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide on www.packtpub.com/authors.
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
Although we have taken every care to ensure the accuracy of our contents, mistakes do happen. If you find a mistake in one of our books—maybe a mistake in text or code—we would be grateful if you would report this to us. By doing this you can save other readers from frustration, and help to improve subsequent versions of this book. If you find any errata, report them by visiting http://www.packtpub.com/support, selecting your book, clicking on the Submit Errata link, and entering the details of your errata. Once your errata have been verified, your submission will be accepted and the errata added to the list of existing errata. The existing errata can be viewed by selecting your title from http://www.packtpub.com/support.
You can contact us at <[email protected]> if you are having a problem with some aspect of the book, and we will do our