[ Pobierz całość w formacie PDF ]
.refreshThis field specifies the interval in seconds that the secondary servers should wait between checking the SOArecord of the primary server.Again, this is a decimal number with at most eight digits.Generally, the network topology doesn't change too often, so this number should specify an interval ofroughly a day for larger networks, and even more for smaller ones.retryThis number determines the intervals at which a secondary server should retry contacting the primary serverif a request or a zone refresh fails.It must not be too low, or a temporary failure of the server or a networkproblem could cause the secondary server to waste network resources.One hour, or perhaps one-half hour, might be a good choice.expireThis field specifies the time in seconds after which a secondary server should finally discard all zone data ifit hasn't been able to contact the primary server.You should normally set this field to at least a week(604,800 seconds), but increasing it to a month or more is also reasonable.minimumThis field is the default ttl value for resource records that do not explicitly contain one.The ttl valuespecifies the maximum amount of time other name servers may keep the RR in their cache.This time appliesonly to normal lookups, and has nothing to do with the time after which a secondary server should try toupdate the zone information.If the topology of your network does not change frequently, a week or even more is probably a good choice.If single RRs change more frequently, you could still assign them smaller ttls individually.If your networkchanges frequently, you may want to set minimum to one day (86,400 seconds).AThis record associates an IP address with a hostname.The resource data field contains the address in dotted quadnotation.For each hostname, there must be only one A record.The hostname used in this A record is considered the officialor canonical hostname.All other hostnames are aliases and must be mapped onto the canonical hostname using aCNAME record.If the canonical name of our host were vlager, we'd have an A record that associated thathostname with its IP address.Since we may also want another name associated with that address, say news, we'dcreate a CNAME record that associates this alternate name with the canonical name.We'll talk more aboutCNAME records shortly.NSNS records are used to specify a zone's primary server and all its secondary servers.An NS record points to amaster name server of the given zone, with the resource data field containing the hostname of the name server.You will meet NS records in two situations: The first situation is when you delegate authority to a subordinatezone; the second is within the master zone database of the subordinate zone itself.The sets of servers specified inboth the parent and delegated zones should match.The NS record specifies the name of the primary and secondary name servers for a zone.These names must beresolved to an address so they can be used.Sometimes the servers belong to the domain they are serving, whichcauses a chicken and egg problem; we can't resolve the address until the name server is reachable, but we can'treach the name server until we resolve its address.To solve this dilemma, we can configure special A recordsdirectly into the name server of the parent zone.The A records allow the name servers of the parent domain toresolve the IP address of the delegated zone name servers.These records are commonly called glue recordsbecause they provide the glue that binds a delegated zone to its parent.CNAMEThis record associates an alias with a host's canonical hostname.It provides an alternate name by which users canrefer to the host whose canonical name is supplied as a parameter.The canonical hostname is the one the masterfile provides an A record for; aliases are simply linked to that name by a CNAME record, but don't have any otherrecords of their own.PTRThis type of record is used to associate names in the in-addr.arpa domain with hostnames.It is used for reversemapping of IP addresses to hostnames.The hostname given must be the canonical hostname.MX This RR announces a mail exchanger for a domain.Mail exchangers are discussed in the section called MailRouting on the Internet in Chapter 17.The syntax of an MX record is:[domain] [ttl] [class] MX preference hosthost names the mail exchanger for domain.Every mail exchanger has an integer preference associated withit.A mail transport agent that wants to deliver mail to domain tries all hosts who have an MX record for thisdomain until it succeeds.The one with the lowest preference value is tried first, then the others, in order ofincreasing preference value.HINFOThis record provides information on the system's hardware and software.Its syntax is:[domain] [ttl] [class] HINFO hardware softwareThe hardware field identifies the hardware used by this host.Special conventions are used to specify this
[ Pobierz całość w formacie PDF ]