📄 00000002.htm
字号:
*.foo.xx. MX 100 gateway.xx. <BR> MX 200 fallback.yy. <BR>8. Hostnames <BR> <BR> People appear to sometimes look only at STD 11, RFC 822 to determine <BR> whether a particular hostname is correct or not. Hostnames should <BR> strictly conform to the syntax given in STD 13, RFC 1034 (page 11), <BR> with *addresses* in addition conforming to RFC 822. As an example <BR> take "c&w.blues" which is perfectly legal according to RFC 822, but <BR> which can have quite surprising effects on particular systems, e.g., <BR> "telnet c&w.blues" on a Unix system. <BR> <BR>9. HINFO records <BR> <BR> There appears to be a common misunderstanding that one of the data <BR> fields (usually the second field) in HINFO records is optional. A <BR> recent scan of all reachable nameservers in only one country revealed <BR> some 300 incomplete HINFO records. Specifying two data fields in a <BR> HINFO record is mandatory (RFC 1033), but note that this does *not* <BR> mean that HINFO records themselves are mandatory. <BR> <BR> <BR> <BR> <BR> <BR>Beertema [Page 5] <BR> <BR>RFC 1537 Common DNS Data File Configuration Errors October 1993 <BR> <BR> <BR>10. Safety measures and specialties <BR> <BR> Nameservers and resolvers aren't flawless. Bogus queries should be <BR> kept from being forwarded to the root servers, since they'll only <BR> lead to unnecessary intercontinental traffic. Known bogus queries <BR> that can easily be dealt with locally are queries for 0 and broadcast <BR> addresses. To catch such queries, every nameserver should run <BR> primary for the 0.in-addr.arpa and 255.in-addr.arpa zones; the zone <BR> files need only contain a SOA and an NS record. <BR> <BR> Also each nameserver should run primary for 0.0.127.in-addr.arpa; <BR> that zone file should contain a SOA and NS record and an entry: <BR> <BR> 1 PTR localhost. <BR> <BR> There has been extensive discussion about whether or not to append <BR> the local domain to it. The conclusion was that "localhost." would be <BR> the best solution; reasons given were: <BR> <BR> - "localhost" itself is used and expected to work on some systems. <BR> <BR> - translating 127.0.0.1 into "localhost.my_domain" can cause some <BR> software to connect to itself using the loopback interface when <BR> it didn't want to. <BR> <BR> Note that all domains that contain hosts should have a "localhost" A <BR> record in them. <BR> <BR> People maintaining zone files with the Serial number given in dotted <BR> decimal notation (e.g., when SCCS is used to maintain the files) <BR> should beware of a bug in all BIND versions: if the serial number is <BR> in Release.Version (dotted decimal) notation, then it is virtually <BR> impossible to change to a higher release: because of the wrong way <BR> that notation is turned into an integer, it results in a serial <BR> number that is LOWER than that of the former release. <BR> <BR> For this reason and because the Serial is an (unsigned) integer <BR> according to STD 13, RFC 1035, it is recommended not to use the <BR> dotted decimal notation. A recommended notation is to use the date <BR> (yyyymmdd), if necessary with an extra digit (yyyymmddn) if there is <BR> or can be more than one change per day in a zone file. <BR> <BR> Very old versions of DNS resolver code have a bug that causes queries <BR> for A records with domain names like "192.16.184.3" to go out. This <BR> happens when users type in IP addresses and the resolver code does <BR> not catch this case before sending out a DNS query. This problem has <BR> been fixed in all resolver implementations known to us but if it <BR> still pops up it is very serious because all those queries will go to <BR> <BR> <BR> <BR>Beertema [Page 6] <BR> <BR>RFC 1537 Common DNS Data File Configuration Errors October 1993 <BR> <BR> <BR> the root servers looking for top level domains like "3" etc. It is <BR> strongly recommended to install the latest (publicly) available BIND <BR> version plus all available patches to get rid of these and other <BR> problems. <BR> <BR> Running secondary nameserver off another secondary nameserver is <BR> possible, but not recommended unless really necessary: there are <BR> known cases where it has led to problems like bogus TTL values. This <BR> can be caused by older or flawed implementations, but secondary <BR> nameservers in principle should always transfer their zones from the <BR> official primary nameserver. <BR> <BR>11. Some general points <BR> <BR> The Domain Name System and nameserver are purely technical tools, not <BR> meant in any way to exert control or impose politics. The function of <BR> a naming authority is that of a clearing house. Anyone registering a <BR> subdomain under a particular (top level) domain becomes naming <BR> authority and therewith the sole responsible for that subdomain. <BR> Requests to enter MX or NS records concerning such a subdomain <BR> therefore always MUST be honored by the registrar of the next higher <BR> domain. <BR> <BR> Examples of practices that are not allowed are: <BR> <BR> - imposing specific mail routing (MX records) when registering <BR> a subdomain. <BR> <BR> - making registration of a subdomain dependent on to the use of <BR> certain networks or services. <BR> <BR> - using TXT records as a means of (free) commercial advertising. <BR> <BR> In the latter case a network service provider could decide to cut off <BR> a particular site until the offending TXT records have been removed <BR> from the site's zone file. <BR> <BR> Of course there are obvious cases where a naming authority can refuse <BR> to register a particular subdomain and can require a proposed name to <BR> be changed in order to get it registered (think of DEC trying to <BR> register a domain IBM.XX). <BR> <BR> There are also cases were one has to probe the authority of the <BR> person: sending in the application - not every systems manager should <BR>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -