Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống
1
/ 133 trang
THÔNG TIN TÀI LIỆU
Thông tin cơ bản
Định dạng
Số trang
133
Dung lượng
479,45 KB
Nội dung
Chapter Introduction Table of Contents Scope of Document Organization of This Document Conventions Used in This Document The Domain Name System (DNS) DNS Fundamentals Domains and Domain Names Zones Authoritative Name Servers Caching Name Servers Name Servers in Multiple Roles The Internet Domain Name System (DNS) consists of the syntax to specify the names of entities in the Internet in a hierarchical manner, the rules used for delegating authority over names, and the system implementation that actually maps names to Internet addresses DNS data is maintained in a group of distributed hierarchical databases Scope of Document The Berkeley Internet Name Domain (BIND) implements a domain name server for a number of operating systems This document provides basic information about the installation and care of the Internet Systems Consortium (ISC) BIND version software package for system administrators This version of the manual corresponds to BIND version 9.4 Organization of This Document In this document, Section introduces the basic DNS and BIND concepts Section describes resource requirements for running BIND in various environments Information in Section is task-oriented in its presentation and is organized functionally, to aid in the process of installing the BIND software The taskoriented section is followed by Section 4, which contains more advanced concepts that the system administrator may need for implementing certain options Section describes the BIND lightweight resolver The contents of Section are organized as in a reference manual to aid in the ongoing maintenance of the software Section addresses security considerations, and Section contains troubleshooting help The main body of the document is followed by several Appendices which contain useful reference information, such as a Bibliography and historic information related to BIND and the Domain Name System Conventions Used in This Document In this document, we use the following general typographic conventions: To describe: a pathname, filename, URL, hostname, mailing list name, or new term or concept We use the style: Fixed width literal user input Fixed Width Bold program output Fixed Width The following conventions are used in descriptions of the BIND configuration file: To describe: keywords variables Optional input We use the style: Fixed Width Fixed Width [Text is enclosed in square brackets] The Domain Name System (DNS) The purpose of this document is to explain the installation and upkeep of the BIND software package, and we begin by reviewing the fundamentals of the Domain Name System (DNS) as they relate to BIND DNS Fundamentals The Domain Name System (DNS) is a hierarchical, distributed database It stores information for mapping Internet host names to IP addresses and vice versa, mail routing information, and other data used by Internet applications Clients look up information in the DNS by calling a resolver library, which sends queries to one or more name servers and interprets the responses The BIND software distribution contains a name server, named, and two resolver libraries, liblwres and libbind Domains and Domain Names The data stored in the DNS is identified by domain names that are organized as a tree according to organizational or administrative boundaries Each node of the tree, called a domain, is given a label The domain name of the node is the concatenation of all the labels on the path from the node to the root node This is represented in written form as a string of labels listed from right to left and separated by dots A label need only be unique within its parent domain For example, a domain name for a host at the company Example, Inc could be ourhost.example.com, where com is the top level domain to which ourhost.example.com belongs, example is a subdomain of com, and ourhost is the name of the host For administrative purposes, the name space is partitioned into areas called zones, each starting at a node and extending down to the leaf nodes or to nodes where other zones start The data for each zone is stored in a name server, which answers queries about the zone using the DNS protocol The data associated with each domain name is stored in the form of resource records (RRs) Some of the supported resource record types are described in the section called “Types of Resource Records and When to Use Them” For more detailed information about the design of the DNS and the DNS protocol, please refer to the standards documents listed in the section called “Request for Comments (RFCs)” Zones To properly operate a name server, it is important to understand the difference between a zone and a domain As stated previously, a zone is a point of delegation in the DNS tree A zone consists of those contiguous parts of the domain tree for which a name server has complete information and over which it has authority It contains all domain names from a certain point downward in the domain tree except those which are delegated to other zones A delegation point is marked by one or more NS records in the parent zone, which should be matched by equivalent NS records at the root of the delegated zone For instance, consider the example.com domain which includes names such as host.aaa.example.com and host.bbb.example.com even though the example.com zone includes only delegations for the aaa.example.com and bbb.example.com zones A zone can map exactly to a single domain, but could also include only part of a domain, the rest of which could be delegated to other name servers Every name in the DNS tree is a domain, even if it is terminal, that is, has no subdomains Every subdomain is a domain and every domain except the root is also a subdomain The terminology is not intuitive and we suggest that you read RFCs 1033, 1034 and 1035 to gain a complete understanding of this difficult and subtle topic Though BIND is called a "domain name server", it deals primarily in terms of zones The master and slave declarations in the named.conf file specify zones, not domains When you ask some other site if it is willing to be a slave server for your domain, you are actually asking for slave service for some collection of zones Authoritative Name Servers Each zone is served by at least one authoritative name server, which contains the complete data for the zone To make the DNS tolerant of server and network failures, most zones have two or more authoritative servers, on different networks Responses from authoritative servers have the "authoritative answer" (AA) bit set in the response packets This makes them easy to identify when debugging DNS configurations using tools like dig (the section called “Diagnostic Tools”) The Primary Master The authoritative server where the master copy of the zone data is maintained is called the primary master server, or simply the primary Typically it loads the zone contents from some local file edited by humans or perhaps generated mechanically from some other local file which is edited by humans This file is called the zone file or master file In some cases, however, the master file may not be edited by humans at all, but may instead be the result of dynamic update operations Slave Servers The other authoritative servers, the slave servers (also known as secondary servers) load the zone contents from another server using a replication process known as a zone transfer Typically the data are transferred directly from the primary master, but it is also possible to transfer it from another slave In other words, a slave server may itself act as a master to a subordinate slave server Stealth Servers Usually all of the zone's authoritative servers are listed in NS records in the parent zone These NS records constitute a delegation of the zone from the parent The authoritative servers are also listed in the zone file itself, at the top level or apex of the zone You can list servers in the zone's top-level NS records that are not in the parent's NS delegation, but you cannot list servers in the parent's delegation that are not present at the zone's top level A stealth server is a server that is authoritative for a zone but is not listed in that zone's NS records Stealth servers can be used for keeping a local copy of a zone to speed up access to the zone's records or to make sure that the zone is available even if all the "official" servers for the zone are inaccessible A configuration where the primary master server itself is a stealth server is often referred to as a "hidden primary" configuration One use for this configuration is when the primary master is behind a firewall and therefore unable to communicate directly with the outside world Caching Name Servers The resolver libraries provided by most operating systems are stub resolvers, meaning that they are not capable of performing the full DNS resolution process by themselves by talking directly to the authoritative servers Instead, they rely on a local name server to perform the resolution on their behalf Such a server is called a recursive name server; it performs recursive lookups for local clients To improve performance, recursive servers cache the results of the lookups they perform Since the processes of recursion and caching are intimately connected, the terms recursive server and caching server are often used synonymously The length of time for which a record may be retained in the cache of a caching name server is controlled by the Time To Live (TTL) field associated with each resource record Forwarding Even a caching name server does not necessarily perform the complete recursive lookup itself Instead, it can forward some or all of the queries that it cannot satisfy from its cache to another caching name server, commonly referred to as a forwarder There may be one or more forwarders, and they are queried in turn until the list is exhausted or an answer is found Forwarders are typically used when you not wish all the servers at a given site to interact directly with the rest of the Internet servers A typical scenario would involve a number of internal DNS servers and an Internet firewall Servers unable to pass packets through the firewall would forward to the server that can it, and that server would query the Internet DNS servers on the internal server's behalf Name Servers in Multiple Roles The BIND name server can simultaneously act as a master for some zones, a slave for other zones, and as a caching (recursive) server for a set of local clients However, since the functions of authoritative name service and caching/recursive name service are logically separate, it is often advantageous to run them on separate server machines A server that only provides authoritative name service (an authoritative-only server) can run with recursion disabled, improving reliability and security A server that is not authoritative for any zones and only provides recursive service to local clients (a caching-only server) does not need to be reachable from the Internet at large and can be placed inside a firewall Name Server Operations Tools for Use With the Name Server Daemon This section describes several indispensable diagnostic, administrative and monitoring tools available to the system administrator for controlling and debugging the name server daemon Diagnostic Tools The dig, host, and nslookup programs are all command line tools for manually querying name servers They differ in style and output format dig The domain information groper (dig) is the most versatile and complete of these lookup tools It has two modes: simple interactive mode for a single query, and batch mode which executes a query for each in a list of several query lines All query options are accessible from the command line dig [@server] domain [query-type] [query-class] [+queryoption] [-dig-option] [%comment] The usual simple use of dig will take the form dig @server domain query-type query-class For more information and a list of available commands and options, see the dig man page host The host utility emphasizes simplicity and ease of use By default, it converts between host names and Internet addresses, but its functionality can be extended with the use of options host [-aCdlrTwv] [-c class] [-N ndots] [-t type] [-W timeout] [-R retries] hostname [server] For more information and a list of available commands and options, see the host man page nslookup nslookup has two modes: interactive and non-interactive Interactive mode allows the user to query name servers for information about various hosts and domains or to print a list of hosts in a domain Non-interactive mode is used to print just the name and requested information for a host or domain nslookup [-option ] [[host-to-find] | [- [server]]] Interactive mode is entered when no arguments are given (the default name server will be used) or when the first argument is a hyphen (`-') and the second argument is the host name or Internet address of a name server Non-interactive mode is used when the name or Internet address of the host to be looked up is given as the first argument The optional second argument specifies the host name or address of a name server Due to its arcane user interface and frequently inconsistent behavior, we not recommend the use of nslookup Use dig instead Administrative Tools Administrative tools play an integral part in the management of a server named-checkconf The named-checkconf program checks the syntax of a named.conf file named-checkconf [-jvz] [-t directory] [filename] named-checkzone The named-checkzone program checks a master file for syntax and consistency named-checkzone [-djqvD] [-c class] [-o output] [-t directory] [-w directory] [-k (ignore|warn|fail)] [-n (ignore|warn|fail)] [-W (ignore|warn)] zone [filename] named-compilezone Similar to named-checkzone, but it always dumps the zone content to a specified file (typically in a different format) rndc The remote name daemon control (rndc) program allows the system administrator to control the operation of a name server If you run rndc without any options it will display a usage message as follows: rndc [-c config] [-s server] [-p port] [-y key] command [command ] The command is one of the following: reload Reload configuration file and zones reload zone [class [view]] Reload the given zone refresh zone [class [view]] Schedule zone maintenance for the given zone retransfer zone [class [view]] Retransfer the given zone from the master freeze [zone [class [view]]] Suspend updates to a dynamic zone If no zone is specified, then all zones are suspended This allows manual edits to be made to a zone normally updated by dynamic update It also causes changes in the journal file to be synced into the master and the journal file to be removed All dynamic update attempts will be refused while the zone is frozen thaw [zone [class [view]]] Enable updates to a frozen dynamic zone If no zone is specified, then all frozen zones are enabled This causes the server to reload the zone from disk, and re-enables dynamic updates after the load has completed After a zone is thawed, dynamic updates will no longer be refused notify zone [class [view]] Resend NOTIFY messages for the zone reconfig Reload the configuration file and load new zones, but not reload existing zone files even if they have changed This is faster than a full reload when there is a large number of zones because it avoids the need to examine the modification times of the zones files stats Write server statistics to the statistics file querylog Toggle query logging Query logging can also be enabled by explicitly directing the queries category to a channel in the logging section of named.conf or by specifying querylog yes; in the options section of named.conf dumpdb [-all|-cache|-zone] [view ] Dump the server's caches (default) and/or zones to the dump file for the specified views If no view is specified, all views are dumped stop [-p] Stop the server, making sure any recent changes made through dynamic update or IXFR are first saved to the master files of the updated zones If -p is specified named's process id is returned This allows an external process to determine when named had completed stopping halt [-p] Stop the server immediately Recent changes made through dynamic update or IXFR are not saved to the master files, but will be rolled forward from the journal files when the server is restarted If -p is specified named's process id is returned This allows an external process to determine when named had completed halting trace Increment the servers debugging level by one trace level Sets the server's debugging level to an explicit value notrace Sets the server's debugging level to flush Flushes the server's cache flushname name Flushes the given name from the server's cache status Display status of the server Note that the number of zones includes the internal bind/CH zone and the default /IN hint zone if there is not an explicit root zone configured recursing Dump the list of queries named is currently recursing on In BIND 9.2, rndc supports all the commands of the BIND ndc utility except ndc start and ndc restart, which were also not supported in ndc's channel mode Roo Server ot r–A DNS server th contains a root zone is called a hat root server t Roo Zone–A zone th conta ot hat ains the D DNS root domain is called the root zone e TTL L–Time-To o-Live (TT is a d TL) duration o time w of when a specific reso ource record could be cached d UCS S-2–Also known as Unicode is a cha e aracter en ncoding p protocol UTF F-8–A cha aracter encoding p protocol, specified in RFC d 2044 WIN NS–Wind dows Nam System (WINS) is the pre-DNS n me m ) name syst tem It is still supp ported in the Wind dows 200 in orde to 00 er maintain inte eroperabi ility betw ween the d different generatio ons of mputers Windows com ne plication of the zone from Master to o Zon Transfer–Process of rep Slav server ve 109 99 Top of page e Be erkeley Inte ernet Name Domain - B BIND 8.1.1 DNS Serv impleme ver entation su upports both SRV RRs and Dynam Update, but it dum core wh h mic , mps hen Windows 200 W 00-based cl lients send c certain updates to it 8.1.2 is the f first BIND ve ersion that works reliab w bly S entals DNS Fundame tion Solut Startlogic S DNS Fundame S entals What is DNS? DNS is an acronym that stands for Domain Name System AND Server One acronym defines the protocol; the other defines the machines that provide the service The job that DNS performs is very simple: it translates hostnames into routable IP addresses and back The Basics Human-readable names like "startlogic.com" are easy for people to remember, but they don't machines any good All networked machines use names called IP addresses to refer to one another For example, the machine that humans refer to as "www.startlogic.com" has the IP address 216.69.226.150 Every time you use a domain name, you use the Internet's domain name servers (DNS) to translate the human-readable domain name into the machine-readable IP address During a day of browsing and e-mailing, you might access the domain name servers hundreds of times! Domain name servers translate domain names to IP addresses That sounds like a simple task, and it would be except for five things: • • • • • There are billions of IP addresses currently in use, and most machines have a human-readable name as well There are many billions of DNS requests made every day A single person can easily make a hundred or more DNS requests a day, and there are hundreds of millions of people and machines using the Internet daily Domain names and IP addresses change daily New domain names get created daily Millions of people the work to change and add domain names and IP addresses every day The DNS system is a database, and no other database on the planet gets this many requests No other database on the planet has millions of people changing it every day, either That is what makes the DNS system so unique! IP Addresses To keep all of the machines on the Internet straight, each machine is assigned a unique address called an IP address IP stands for Internet protocol, and these addresses are 32-bit numbers normally expressed as four "octets" in a "dotted decimal number." A typical IP address looks like this: The four numbers in an IP address are called octets and have values between and 255 (28 possibilities per octet) Every machine on the Internet has its own IP address A server has a static IP address that does not change very often A home machine that is connecting through a modem often has a Dynamic IP address that is assigned by the ISP That IP address is unique for your session and may be different the next time you connect, unless you specifically ask for a static IP In this way, an ISP only needs one IP address for each modem it supports, rather than for every customer If you are working on a Windows machine, you can view your current IP address with the command WINIPCFG.EXE (IPCONFIG.EXE for Windows 2000/XP) On a UNIX machine, type nslookup along with a machine name to display the IP address of the machine (use the command hostname to learn the name of your machine) As far as the Internet's machines are concerned, an IP address is all that you need to talk to a server For example, you can type in your browser the URL http://216.69.226.150 and you will arrive at the machine that contains the Web server for STARTLOGICWEB Domain names are strictly a human convenience Domain Names If we had to remember the IP addresses of all of the Web sites we visit every day, we would all go nuts Human beings just are not that good at remembering strings of numbers We are good at remembering words, however, and that is where domain names come in You probably have hundreds of domain names stored in your head For example: • • • • • • www.startlogic.com www.google.com www.mit.edu encarta.msn.com - a Web server that does not start with www www.bbc.co.uk - a name using four parts rather than three ftp.microsoft.com - an FTP server rather than a Web server The COM, EDU and UK portions of these domain names are called the top-level domain or first-level domain There are several hundred toplevel domain names, including COM, EDU, GOV, MIL, NET, ORG and INT, as well as unique two-letter combinations for every country Within every top-level domain there is a huge list of second-level domains For example, in the COM first-level domain, you've got: • • • • • startlogic google msn microsoft plus millions of others In the case of bbc.co.uk, it is a third-level domain Up to 127 levels are possible, although more than four is rare The left-most word, such as www or encarta, is the host name It specifies the name of a specific machine (with a specific IP address) in a domain A given domain can potentially contain millions of host names as long as they are all unique within that domain Note: The same IP address may be used for multiple hostnames, but one hostname may only use one IP address Creating a New Domain Name When someone wants to create a new domain, he or she has to two things: • • Find a name server for the domain name to live on Register the domain name Technically, there does not need to be a machine in the domain -there just needs to be a name server that can handle the requests for the domain name There are two ways to get a name server for a domain: • • You can create and administer it yourself You can pay an ISP or hosting company to handle it for you Most, larger companies have their own domain name servers Most, smaller companies pay someone To create a domain, you fill out a form with a company that does domain name registration (examples: register.com, tucows.com, networksolutions.com) They create an "under construction page," create an entry in their name server, and submit the form's data into the whois database Twice a day, the COM, ORG, NET, etc name servers get updates with the newest IP address information At that point, a domain exists and people can go see the "under construction" page Our primary DNS is ns1.startlogic.net Any changes we make to it propagate automatically to the secondary (ns1.ipowerdns.com), tertiary (ns2.startlogic.net), and quaternary (ns2.ipowerdns.com ) name servers All of these machines run name server software called BIND BIND knows about all of the machines in our domain through a text file on the main server that looks like this: Decoding this file from the top, you can see that: • • • • • • The first four lines point to the primary, secondary, tertiary, and quaternary name servers The next line is called the MX record When you send e-mail to anyone at startlogic.com, the piece of software sending the email contacts the name server to get the MX record so it knows where the SMTP server for STARTLOGIC is Many larger systems have multiple machines handling incoming e-mail, and therefore multiple MX records The next line points to the machine that will handle a request to startlogic.com The next line points to the machine that will handle a request to www.startlogic.com The next line points to the IP address that will handle a request to ftp.startlogic.com The next line points to the IP address that will handle a request to mail.startlogic.com You can see from this file that there are several physical machines at separate IP addresses that make up the STARTLOGIC server infrastructure There are aliases for hosts like mail and www There can be aliases for anything For example, there could be an entry in this file for scoobydoo.startlogic.com, and it could point to the physical machine called walnut There could be an alias for google.startlogic.com, and it could point to google There really is no limit to it We could also create multiple name servers and segment our domain The Distributed System How does it work? Name servers two things all day long: • • They accept requests from programs to convert domain names into IP addresses They accept requests from other name servers to convert domain names into IP addresses When a request comes in, the name server can one of four things with it: • • • • It can answer the request with an IP address because it already knows the IP address for the domain It can contact another name server and try to find the IP address for the name requested It may have to this multiple times It can say, "I don't know the IP address for the domain you requested, but here's the IP address for a name server that knows more than I do." It can return an error message because the requested domain name is invalid or does not exist When you type a URL into your browser, the browser's first step is to convert the domain name and host name into an IP address so that the browser can go request a Web page from the machine at that IP address To this conversion, the browser has a conversation with a name server When you set up your machine on the Internet, you (or the software that you installed to connect to your ISP) had to tell your machine what name server it should use for converting domain names to IP addresses On some systems, the DNS is dynamically fed to the machine when you connect to the ISP, and on other machines it is hard-wired Any program on your machine that needs to talk to a name server to resolve a domain name knows what name server to talk to because it can get the IP address of your machine's name server from the operating system The browser therefore contacts its name server and says, "I need for you to convert a domain name to an IP address for me." For example, if you type "www.startlogic.com" into your browser, the browser needs to convert that URL into an IP address The browser will hand "wwwstartlogic.com" to its default name server and ask it to convert it The name server may already know the IP address for www.startlogic.com That would be the case if another request to resolve www.startlogic.com came in recently (name servers cache IP addresses to speed things up) In that case, the name server can return the IP address immediately Let's assume, however, that the name server has to start from scratch A name server would start its search for an IP address by contacting one of the root name servers The root servers know the IP address for all of the name servers that handle the top-level domains Your name server would ask the root for www.startlogic.com, and the root would say (assuming no caching), "I don't know the IP address for www.startlogic.com, but here's the IP address for the COM name server." Obviously, these root servers are vital to this whole process, so: • • There are many of them scattered all over the planet Every name server has a list of all of the known root servers It contacts the first root server in the list, and if that doesn't work it contacts the next one in the list, and so on The root server knows the IP addresses of the name servers handling the several hundred top-level domains It returns to your name server the IP address for a name server for the COM domain Your name server then sends a query to the COM name server asking it if it knows the IP address for www.startlogic.com The name server for the COM domain knows the IP addresses for the name servers handling the STARTLOGIC.COM domain, so it returns those Your name server then contacts the name server for STARTLOGIC.COM and asks if it knows the IP address for www.startlogic.com It does, so it returns the IP address to your name server, which returns it to the browser, which can then contact the server for www.startlogic.com to get a Web page One of the keys to making this work is redundancy There are multiple name servers at every level, so if one fails, there are others to handle the requests There are, for example, four different machines running name servers for STARTLOGIC.COM requests All four would have to fail for there to be a problem The other key is caching Once a name server resolves a request, it caches all of the IP addresses it receives Once it has made a request to a root server for any COM domain, it knows the IP address for a name server handling the COM domain, so it doesn't have to bug the root servers again for that information Name servers can this for every request, and this caching helps to keep things from bogging down Name servers not cache forever, though The caching has a component, called the Time To Live (TTL), that controls how long a server will cache a piece of information When the server receives an IP address, it receives the TTL with it The name server will cache the IP address for that period of time (ranging from minutes to days) and then discard it The TTL allows changes in name servers to propagate However, not all name servers respect the TTL they receive Types of Records Zone Records (Files) A zone record or file is a small set of instructions for resolving a specified Internet domain name to the appropriate IP address These instructions are kept on the authoritative name servers Each Zone Record will contain other DNS records telling how a request should be handled Records always read from left to right, with the subject to be queried about on the left and the answer to the query on the right Below is an example of a full Zone Record: Address Records (A) Address, or "A" records, map the name of a machine to its numeric IP address In clearer terms, this record states the hostname and IP address of a certain machine To "resolve" a hostname means to find its matching IP address This is the record that a name server would send another name server to answer a resolution query The record below is an example of how an A record should look: The first column contains the machine's hostname When the column is left blank, it means the entry is for the hostname belonging to the Zone Record If the column has a name entered, then it will take that name and add the hostname to the end An example is the “www” entry will actually read www.ipwtraining.com The second column lists what class the record is For most Zone Record entries, all you will need is the IN designation, which stands for InterNet The next column denotes the type of record the entry actually is, and the last column is the IP address itself It is possible to map more than one host name to one IP address This is how our shared hosting plans work We have on an average of 600 accounts mapped to one IP address Canonical Name Records (CNAME) "CNAME" records simply allow a machine to be known by more than one hostname There must always be an A record for the machine before aliases can be added The hostname of a machine that is stated in an A record is called the canonical, or official name of the machine Other records should point to the canonical name The record below is an example of how a CNAME record should look: You can see the similarities to the previous record The same rule applies that the name entered in the column will have the hostname added to the end For the first entry it would be snoopy.ipwtraining.com and mail.ipwtraining.com However, a period ( ) can be added at the end of the name entered to keep the hostname from being added to the end; basically meaning “this is the end of the entry…PERIOD.” With that said, the second entry would read support.ipwtraining.com and ipower.com; requests for support.ipwtraining.com will go to ipower.com A machine can have an unlimited number of CNAME aliases A new record must be entered for each alias Mail Exchange Records (MX) "MX" records are far more important than they sound They allow all mail for a domain to be routed to one host This is exceedingly useful it abates the load on your internal hosts since they not have to route incoming mail, and it allows your mail to be sent to any address in your domain even if that particular address does not have a computer associated with it For example, we have a mail server running on mail.ipwtraining.com The column on the far left signifies the hostname that you want to use as an Internet email address Again, a blank entry means it’s the hostname that the Zone Record (ipwtraining.com) The next two entries have been explained thoroughly in previous records The next column, the number "10", is different from the normal DNS record format It is a signifier of priority Often larger systems will have backup mail servers, perhaps more than one Obviously, you will only want the backups receiving mail if something goes wrong with the primary mail server You can indicate this with your MX records A lower number in an MX record means a higher priority, and mail will be sent to the server with the lowest number (the lowest possible being 0) If something happens so that this server becomes unreachable, the computer delivering the mail will attempt every other server listed in the DNS tables, in order of priority It is common to set the priorities in increments of “10” but it is not required Obviously, you can have as many MX records as you would like It is also a good idea to include an MX record even if you are having mail sent directly to a machine with an A record Some sendmail programs only look for MX records Pointer Records (PTR) Although there are different ways to set up PTR records, we will be explaining only the most frequently used method, called "inaddr.arpa" In-addr.arpa PTR records are the exact inverse of A records They allow your machine to be recognized by its IP address Resolving a machine in this fashion is called a "reverse lookup" It is becoming more and more common that a machine will a reverse lookup on your machine before allowing you to access a service (such as a World Wide Web page) Reverse lookups are a good security measure, verifying that your machine is exactly who it claims to be In-addr.arpa records look as such: As you can see from the example for the A record in the Zone Record, the PTR record simply has the IP address in reverse for the host name in the last column Name Server Records (NS) NS records are imperative to functioning DNS entries They are very simple; they merely state the authoritative name servers for the given domain There must be at least two NS records in every DNS entry NS records look like this: Remember, a blank entry refers to the hostname for the Zone Record For each name server, there must be an A record that exists somewhere in the world Typically the hosting provider will already have name servers setup and registered with Verisign that can be used Start of Authority Records (SOA) The "SOA" record is the most crucial record in a DNS entry It conveys more information than all the other records combined This record is called the start of authority because it denotes the DNS entry as the official source of information for its domain Here is an example of a SOA record, then each part of it will be explained: The first column contains the domain for which this record begins authority for The next two entries should look familiar The "ns1.startlogic.net" entry is the primary name server for the domain The last entry on this row is actually an email address, if you substituted a "@" for the first "." There should always be a viable contact address in the SOA record The serial number is a record of how often this DNS entry has been updated Every time a change is made to the entry, the serial number must be incremented Other name servers that pull information for a zone from the primary only pull the zone if the serial number on the primary name server's entry is higher than the serial number on its entry In this way the name servers for a domain are able to update themselves A recommended way of using your serial number is the YYYYMMDDNN format shown above, where the NN is the number of times that day the DNS has been changed Please note that “00” equals one update; “01” means updates have happened for that day; etc All the rest of the numbers in the record are measurements of time, in seconds The "refresh" number stands for how often secondary name servers should check the primary for a change in the serial number "Retry" is how long a secondary server should wait before trying to reconnect to primary server if the connection was refused "Expire" is how long the secondary server should use its current entry if it is unable to perform a refresh, and "minimum" is how long other name servers should cache, or save, this entry There can only be one SOA record per domain Like NS records, Startlogic sets up this record for you if you are not running your own name server You can download the entire article: http://support.startlogic ... Organizational Unit • DnsZone • DnsNode In DS integrated DNS, each DNS zone becomes an Active Directory service container object (DnsZone) The DnsZone object will contain a DnsNode leaf object... Clarifications to the DNS Specification • 2308 Negative Caching of DNS Queries (DNS NCACHE) Drafts: • Draft-ietf-dnsind-rfc2052bis-02.txt (A DNS RR for Specifying the Location of Services (DNS SRV)) •... While this paper assumes familiarity with DNS it provides a quick overview of the DNS basics in "DNS Fundamentals" The Windows 2000 implementation of DNS supports various new features (as compared