📄 00000002.htm
字号:
out then that such a host was supposed to (i.e., the information was <BR> in the root servers) run secondary for some domain (or reverse (in- <BR> addr.arpa)) domain, without that host's nameserver manager having <BR> been asked or even been told so! <BR> <BR> Newer BIND versions (4.9 and later) solved this problem. At the same <BR> time though the fix has the disadvantage that it's far less easy to <BR> spot this problem. <BR> <BR> Practice has shown that most domain registrars accept registrations <BR> of nameservers without checking if primary (!) and secondary servers <BR> have been set up, informed, or even asked. It should also be noted <BR> that a combination of long-lasting unreachability of primary <BR> nameservers, (therefore) expiration of zone information, plus static <BR> IP routing, can lead to massive network traffic that can fill up <BR> lines completely. <BR> <BR>4. "MX records surprise" <BR> <BR> In a sense similar to point 3. Sometimes nameserver managers enter MX <BR> records in their zone files that point to external hosts, without <BR> first asking or even informing the systems managers of those external <BR> hosts. This has to be fought out between the nameserver manager and <BR> the systems managers involved. Only as a last resort, if really <BR> nothing helps to get the offending records removed, can the systems <BR> manager turn to the naming authority of the domain above the <BR> offending domain to get the problem sorted out. <BR> <BR>5. "Name extension surprise" <BR> <BR> Sometimes one encounters weird names, which appear to be an external <BR> name extended with a local domain. This is caused by forgetting to <BR> terminate a name with a dot: names in zone files that don't end with <BR> a dot are always expanded with the name of the current zone (the <BR> domain that the zone file stands for or the last $ORIGIN). <BR> <BR> Example: zone file for foo.xx: <BR> <BR> pqr MX 100 relay.yy. <BR> xyz MX 100 relay.yy (no trailing dot!) <BR> <BR> <BR> <BR>Beertema [Page 3] <BR> <BR>RFC 1537 Common DNS Data File Configuration Errors October 1993 <BR> <BR> <BR> When fully written out this stands for: <BR> <BR> pqr.foo.xx. MX 100 relay.yy. <BR> xyz.foo.xx. MX 100 relay.yy.foo.xx. (name extension!) <BR> <BR>6. Missing secondary servers <BR> <BR> It is required that there be a least 2 nameservers for a domain. For <BR> obvious reasons the nameservers for top level domains need to be very <BR> well reachable from all over the Internet. This implies that there <BR> must be more than just 2 of them; besides, most of the (secondary) <BR> servers should be placed at "strategic" locations, e.g., close to a <BR> point where international and/or intercontinental lines come <BR> together. To keep things manageable, there shouldn't be too many <BR> servers for a domain either. <BR> <BR> Important aspects in selecting the location of primary and secondary <BR> servers are reliability (network, host) and expedient contacts: in <BR> case of problems, changes/fixes must be carried out quickly. It <BR> should be considered logical that primary servers for European top <BR> level domains should run on a host in Europe, preferably (if <BR> possible) in the country itself. For each top level domain there <BR> should be 2 secondary servers in Europe and 2 in the USA, but there <BR> may of course be more on either side. An excessive number of <BR> nameservers is not a good idea though; a recommended maximum is 7 <BR> nameservers. In Europe, EUnet has offered to run secondary server <BR> for each European top level domain. <BR> <BR>7. Wildcard MX records <BR> <BR> Wildcard MX records should be avoided where possible. They often <BR> cause confusion and errors: especially beginning nameserver managers <BR> tend to overlook the fact that a host/domain listed with ANY type of <BR> record in a zone file is NOT covered by an overall wildcard MX record <BR> in that zone; this goes not only for simple domain/host names, but <BR> also for names that cover one or more domains. Take the following <BR> example in zone foo.bar: <BR> <BR> * MX 100 mailhost <BR> pqr MX 100 mailhost <BR> abc.def MX 100 mailhost <BR> <BR> This makes pqr.foo.bar, def.foo.bar and abd.def.foo.bar valid <BR> domains, but the wildcard MX record covers NONE of them, nor anything <BR> below them. To cover everything by MX records, the required entries <BR> are: <BR> <BR> <BR> <BR> <BR> <BR>Beertema [Page 4] <BR> <BR>RFC 1537 Common DNS Data File Configuration Errors October 1993 <BR> <BR> <BR> * MX 100 mailhost <BR> pqr MX 100 mailhost <BR> *.pqr MX 100 mailhost <BR> abc.def MX 100 mailhost <BR> *.def MX 100 mailhost <BR> *.abc.def MX 100 mailhost <BR> <BR> An overall wildcard MX record is almost never useful. <BR> <BR> In particular the zone file of a top level domain should NEVER <BR> contain only an overall wildcard MX record (*.XX). The effect of such <BR> a wildcard MX record can be that mail is unnecessarily sent across <BR> possibly expensive links, only to fail at the destination or gateway <BR> that the record points to. Top level domain zone files should <BR> explicitly list at least all the officially registered primary <BR> subdomains. <BR> <BR> Whereas overall wildcard MX records should be avoided, wildcard MX <BR> records are acceptable as an explicit part of subdomain entries, <BR> provided they are allowed under a given subdomain (to be determined <BR> by the naming authority for that domain). <BR> <BR> Example: <BR> <BR> foo.xx. MX 100 gateway.xx. <BR> MX 200 fallback.yy. <BR>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -