diff --git a/Copyright.caching-nameserver b/Copyright.caching-nameserver
deleted file mode 100644
index 8666932..0000000
--- a/Copyright.caching-nameserver
+++ /dev/null
@@ -1,5 +0,0 @@
-
-The files included in this package are obtained from
-ftp://ftp.internic.net/domain/, where they are made
-available for free to anybody. In other words, this package
-is created under a Public Domain license.
diff --git a/bind.spec b/bind.spec
index a10aba5..f8ca12e 100644
--- a/bind.spec
+++ b/bind.spec
@@ -21,7 +21,7 @@ Summary: The Berkeley Internet Name Domain (BIND) DNS (Domain Name System) serv
Name: bind
License: ISC
Version: 9.7.1
-Release: 2.%{PATCHVER}%{?dist}
+Release: 3.%{PATCHVER}%{?dist}
Epoch: 32
Url: http://www.isc.org/products/BIND/
Buildroot:%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
@@ -32,11 +32,9 @@ Source1: named.sysconfig
Source2: named.init
Source3: named.logrotate
Source4: named.NetworkManager
-Source5: rfc1912.txt
Source7: bind-9.3.1rc1-sdb_tools-Makefile.in
Source8: dnszone.schema
Source12: README.sdb_pgsql
-Source21: Copyright.caching-nameserver
Source25: named.conf.sample
Source28: config-7.tar.bz2
Source30: ldap2zone.c
@@ -312,10 +310,6 @@ else
%install
rm -rf ${RPM_BUILD_ROOT}
-# We don't want these
-rm -f doc/rfc/fetch
-
-cp --preserve=timestamps %{SOURCE5} doc/rfc
gzip -9 doc/rfc/*
# Build directory hierarchy
@@ -385,9 +379,6 @@ touch ${RPM_BUILD_ROOT}/etc/rndc.conf
mkdir ${RPM_BUILD_ROOT}/etc/named
install -m 644 bind.keys ${RPM_BUILD_ROOT}/etc/named.iscdlv.key
-install -m 644 %{SOURCE5} ./rfc1912.txt
-install -m 644 %{SOURCE21} ./Copyright
-
# sample bind configuration files for %%doc:
mkdir -p sample/etc sample/var/named/{data,slaves}
install -m 644 %{SOURCE25} sample/etc/named.conf
@@ -569,11 +560,9 @@ rm -rf ${RPM_BUILD_ROOT}
%{_mandir}/man8/named-journalprint.8*
%{_mandir}/man8/nsec3hash.8*
%{_mandir}/man8/isc-hmac-fixup.8*
-%doc CHANGES COPYRIGHT README named.conf.default
+%doc CHANGES README named.conf.default
%doc doc/arm doc/misc doc/draft doc/rfc
%doc sample/
-%doc Copyright
-%doc rfc1912.txt
# Hide configuration
%defattr(0640,root,named,0750)
@@ -623,6 +612,7 @@ rm -rf ${RPM_BUILD_ROOT}
%files libs
%defattr(-,root,root,-)
+%doc COPYRIGHT
%{_libdir}/*so.*
%files utils
@@ -675,6 +665,7 @@ rm -rf ${RPM_BUILD_ROOT}
%if %{PKCS11}
%files pkcs11
%defattr(-,root,root,-)
+%doc COPYRIGHT
%{_sbindir}/pkcs11-destroy
%{_sbindir}/pkcs11-keygen
%{_sbindir}/pkcs11-list
@@ -682,6 +673,12 @@ rm -rf ${RPM_BUILD_ROOT}
%endif
%changelog
+* Mon Jul 12 2010 Adam Tkac <atkac redhat com> 32:9.7.1-3.P1
+- remove outdated Copyright.caching-nameserver file
+- remove rfc1912.txt, it is already located in %%doc/rfc directory
+- move COPYRIGHT to the bind-libs subpkg
+- add COPYRIGHT to the -pkcs11 subpkg
+
* Fri Jul 09 2010 Adam Tkac <atkac redhat com> 32:9.7.1-2.P1
- update to 9.7.1-P1
diff --git a/rfc1912.txt b/rfc1912.txt
deleted file mode 100644
index 8ace7d2..0000000
--- a/rfc1912.txt
+++ /dev/null
@@ -1,899 +0,0 @@
-
-
-
-
-
-
-Network Working Group D. Barr
-Request for Comments: 1912 The Pennsylvania State University
-Obsoletes: 1537 February 1996
-Category: Informational
-
-
- Common DNS Operational and Configuration Errors
-
-Status of this Memo
-
- This memo provides information for the Internet community. This memo
- does not specify an Internet standard of any kind. Distribution of
- this memo is unlimited.
-
-Abstract
-
- This memo describes errors often found in both the operation of
- Domain Name System (DNS) servers, and in the data that these DNS
- servers contain. This memo tries to summarize current Internet
- requirements as well as common practice in the operation and
- configuration of the DNS. This memo also tries to summarize or
- expand upon issues raised in [RFC 1537].
-
-1. Introduction
-
- Running a nameserver is not a trivial task. There are many things
- that can go wrong, and many decisions have to be made about what data
- to put in the DNS and how to set up servers. This memo attempts to
- address many of the common mistakes and pitfalls that are made in DNS
- data as well as in the operation of nameservers. Discussions are
- also made regarding some other relevant issues such as server or
- resolver bugs, and a few political issues with respect to the
- operation of DNS on the Internet.
-
-2. DNS Data
-
- This section discusses problems people typically have with the DNS
- data in their nameserver, as found in the zone data files that the
- nameserver loads into memory.
-
-2.1 Inconsistent, Missing, or Bad Data
-
- Every Internet-reachable host should have a name. The consequences
- of this are becoming more and more obvious. Many services available
- on the Internet will not talk to you if you aren't correctly
- registered in the DNS.
-
-
-
-
-
-Barr Informational [Page 1]
-
-RFC 1912 Common DNS Errors February 1996
-
-
- Make sure your PTR and A records match. For every IP address, there
- should be a matching PTR record in the in-addr.arpa domain. If a
- host is multi-homed, (more than one IP address) make sure that all IP
- addresses have a corresponding PTR record (not just the first one).
- Failure to have matching PTR and A records can cause loss of Internet
- services similar to not being registered in the DNS at all. Also,
- PTR records must point back to a valid A record, not a alias defined
- by a CNAME. It is highly recommended that you use some software
- which automates this checking, or generate your DNS data from a
- database which automatically creates consistent data.
-
- DNS domain names consist of "labels" separated by single dots. The
- DNS is very liberal in its rules for the allowable characters in a
- domain name. However, if a domain name is used to name a host, it
- should follow rules restricting host names. Further if a name is
- used for mail, it must follow the naming rules for names in mail
- addresses.
-
- Allowable characters in a label for a host name are only ASCII
- letters, digits, and the `-' character. Labels may not be all
- numbers, but may have a leading digit (e.g., 3com.com). Labels must
- end and begin only with a letter or digit. See [RFC 1035] and [RFC
- 1123]. (Labels were initially restricted in [RFC 1035] to start with
- a letter, and some older hosts still reportedly have problems with
- the relaxation in [RFC 1123].) Note there are some Internet
- hostnames which violate this rule (411.org, 1776.com). The presence
- of underscores in a label is allowed in [RFC 1033], except [RFC 1033]
- is informational only and was not defining a standard. There is at
- least one popular TCP/IP implementation which currently refuses to
- talk to hosts named with underscores in them. It must be noted that
- the language in [1035] is such that these rules are voluntary -- they
- are there for those who wish to minimize problems. Note that the
- rules for Internet host names also apply to hosts and addresses used
- in SMTP (See RFC 821).
-
- If a domain name is to be used for mail (not involving SMTP), it must
- follow the rules for mail in [RFC 822], which is actually more
- liberal than the above rules. Labels for mail can be any ASCII
- character except "specials", control characters, and whitespace
- characters. "Specials" are specific symbols used in the parsing of
- addresses. They are the characters "()<>@,;:\".[]". (The "!"
- character wasn't in [RFC 822], however it also shouldn't be used due
- to the conflict with UUCP mail as defined in RFC 976) However, since
- today almost all names which are used for mail on the Internet are
- also names used for hostnames, one rarely sees addresses using these
- relaxed standard, but mail software should be made liberal and robust
- enough to accept them.
-
-
-
-
-Barr Informational [Page 2]
-
-RFC 1912 Common DNS Errors February 1996
-
-
- You should also be careful to not have addresses which are valid
- alternate syntaxes to the inet_ntoa() library call. For example 0xe
- is a valid name, but if you were to type "telnet 0xe", it would try
- to connect to IP address 0.0.0.14. It is also rumored that there
- exists some broken inet_ntoa() routines that treat an address like
- x400 as an IP address.
-
- Certain operating systems have limitations on the length of their own
- hostname. While not strictly of issue to the DNS, you should be
- aware of your operating system's length limits before choosing the
- name of a host.
-
- Remember that many resource records (abbreviated RR) take on more
- than one argument. HINFO requires two arguments, as does RP. If you
- don't supply enough arguments, servers sometime return garbage for
- the missing fields. If you need to include whitespace within any
- data, you must put the string in quotes.
-
-2.2 SOA records
-
- In the SOA record of every zone, remember to fill in the e-mail
- address that will get to the person who maintains the DNS at your
- site (commonly referred to as "hostmaster"). The `@' in the e-mail
- must be replaced by a `.' first. Do not try to put an `@' sign in
- this address. If the local part of the address already contains a
- `.' (e.g., John.Smith@widget.xx), then you need to quote the `.' by
- preceding it with `\' character. (e.g., to become
- John\.Smith.widget.xx) Alternately (and preferred), you can just use
- the generic name `hostmaster', and use a mail alias to redirect it to
- the appropriate persons. There exists software which uses this field
- to automatically generate the e-mail address for the zone contact.
- This software will break if this field is improperly formatted. It
- is imperative that this address get to one or more real persons,
- because it is often used for everything from reporting bad DNS data
- to reporting security incidents.
-
- Even though some BIND versions allow you to use a decimal in a serial
- number, don't. A decimal serial number is converted to an unsigned
- 32-bit integer internally anyway. The formula for a n.m serial
- number is n*10^(3+int(0.9+log10(m))) + m which translates to
- something rather unexpected. For example it's routinely possible
- with a decimal serial number (perhaps automatically generated by
- SCCS) to be incremented such that it is numerically larger, but after
- the above conversion yield a serial number which is LOWER than
- before. Decimal serial numbers have been officially deprecated in
- recent BIND versions. The recommended syntax is YYYYMMDDnn
- (YYYY=year, MM=month, DD=day, nn=revision number. This won't
- overflow until the year 4294.
-
-
-
-Barr Informational [Page 3]
-
-RFC 1912 Common DNS Errors February 1996
-
-
- Choose logical values for the timer values in the SOA record (note
- values below must be expressed as seconds in the zone data):
-
- Refresh: How often a secondary will poll the primary server to see
- if the serial number for the zone has increased (so it knows
- to request a new copy of the data for the zone). Set this to
- how long your secondaries can comfortably contain out-of-date
- data. You can keep it short (20 mins to 2 hours) if you
- aren't worried about a small increase in bandwidth used, or
- longer (2-12 hours) if your Internet connection is slow or is
- started on demand. Recent BIND versions (4.9.3) have optional
- code to automatically notify secondaries that data has
- changed, allowing you to set this TTL to a long value (one
- day, or more).
-
- Retry: If a secondary was unable to contact the primary at the
- last refresh, wait the retry value before trying again. This
- value isn't as important as others, unless the secondary is on
- a distant network from the primary or the primary is more
- prone to outages. It's typically some fraction of the refresh
- interval.
-
-
- Expire: How long a secondary will still treat its copy of the zone
- data as valid if it can't contact the primary. This value
- should be greater than how long a major outage would typically
- last, and must be greater than the minimum and retry
- intervals, to avoid having a secondary expire the data before
- it gets a chance to get a new copy. After a zone is expired a
- secondary will still continue to try to contact the primary,
- but it will no longer provide nameservice for the zone. 2-4
- weeks are suggested values.
-
- Minimum: The default TTL (time-to-live) for resource records --
- how long data will remain in other nameservers' cache. ([RFC
- 1035] defines this to be the minimum value, but servers seem
- to always implement this as the default value) This is by far
- the most important timer. Set this as large as is comfortable
- given how often you update your nameserver. If you plan to
- make major changes, it's a good idea to turn this value down
- temporarily beforehand. Then wait the previous minimum value,
- make your changes, verify their correctness, and turn this
- value back up. 1-5 days are typical values. Remember this
- value can be overridden on individual resource records.
-
-
-
-
-
-
-
-Barr Informational [Page 4]
-
-RFC 1912 Common DNS Errors February 1996
-
-
- As you can see, the typical values above for the timers vary widely.
- Popular documentation like [RFC 1033] recommended a day for the
- minimum TTL, which is now considered too low except for zones with
- data that vary regularly. Once a DNS stabilizes, values on the order
- of 3 or more days are recommended. It is also recommended that you
- individually override the TTL on certain RRs which are often
- referenced and don't often change to have very large values (1-2
- weeks). Good examples of this are the MX, A, and PTR records of your
- mail host(s), the NS records of your zone, and the A records of your
- nameservers.
-
-2.3 Glue A Records
-
- Glue records are A records that are associated with NS records to
- provide "bootstrapping" information to the nameserver. For example:
-
- podunk.xx. in ns ns1.podunk.xx.
- in ns ns2.podunk.xx.
- ns1.podunk.xx. in a 1.2.3.4
- ns2.podunk.xx. in a 1.2.3.5
-
- Here, the A records are referred to as "Glue records".
-
- Glue records are required only in forward zone files for nameservers
- that are located in the subdomain of the current zone that is being
- delegated. You shouldn't have any A records in an in-addr.arpa zone
- file (unless you're using RFC 1101-style encoding of subnet masks).
-
- If your nameserver is multi-homed (has more than one IP address), you
- must list all of its addresses in the glue to avoid cache
- inconsistency due to differing TTL values, causing some lookups to
- not find all addresses for your nameserver.
-
- Some people get in the bad habit of putting in a glue record whenever
- they add an NS record "just to make sure". Having duplicate glue
- records in your zone files just makes it harder when a nameserver
- moves to a new IP address, or is removed. You'll spend hours trying
- to figure out why random people still see the old IP address for some
- host, because someone forgot to change or remove a glue record in
- some other file. Newer BIND versions will ignore these extra glue
- records in local zone files.
-
- Older BIND versions (4.8.3 and previous) have a problem where it
- inserts these extra glue records in the zone transfer data to
- secondaries. If one of these glues is wrong, the error can be
- propagated to other nameservers. If two nameservers are secondaries
- for other zones of each other, it's possible for one to continually
- pass old glue records back to the other. The only way to get rid of
-
-
-
-Barr Informational [Page 5]
-
-RFC 1912 Common DNS Errors February 1996
-
-
- the old data is to kill both of them, remove the saved backup files,
- and restart them. Combined with that those same versions also tend
- to become infected more easily with bogus data found in other non-
- secondary nameservers (like the root zone data).
-
-2.4 CNAME records
-
- A CNAME record is not allowed to coexist with any other data. In
- other words, if suzy.podunk.xx is an alias for sue.podunk.xx, you
- can't also have an MX record for suzy.podunk.edu, or an A record, or
- even a TXT record. Especially do not try to combine CNAMEs and NS
- records like this!:
-
-
- podunk.xx. IN NS ns1
- IN NS ns2
- IN CNAME mary
- mary IN A 1.2.3.4
-
-
- This is often attempted by inexperienced administrators as an obvious
- way to allow your domain name to also be a host. However, DNS
- servers like BIND will see the CNAME and refuse to add any other
- resources for that name. Since no other records are allowed to
- coexist with a CNAME, the NS entries are ignored. Therefore all the
- hosts in the podunk.xx domain are ignored as well!
-
- If you want to have your domain also be a host, do the following:
-
- podunk.xx. IN NS ns1
- IN NS ns2
- IN A 1.2.3.4
- mary IN A 1.2.3.4
-
- Don't go overboard with CNAMEs. Use them when renaming hosts, but
- plan to get rid of them (and inform your users). However CNAMEs are
- useful (and encouraged) for generalized names for servers -- `ftp'
- for your ftp server, `www' for your Web server, `gopher' for your
- Gopher server, `news' for your Usenet news server, etc.
-
- Don't forget to delete the CNAMEs associated with a host if you
- delete the host it is an alias for. Such "stale CNAMEs" are a waste
- of resources.
-
-
-
-
-
-
-
-
-Barr Informational [Page 6]
-
-RFC 1912 Common DNS Errors February 1996
-
-
- Don't use CNAMEs in combination with RRs which point to other names
- like MX, CNAME, PTR and NS. (PTR is an exception if you want to
- implement classless in-addr delegation.) For example, this is
- strongly discouraged:
-
- podunk.xx. IN MX mailhost
- mailhost IN CNAME mary
- mary IN A 1.2.3.4
-
-
- [RFC 1034] in section 3.6.2 says this should not be done, and [RFC
- 974] explicitly states that MX records shall not point to an alias
- defined by a CNAME. This results in unnecessary indirection in
- accessing the data, and DNS resolvers and servers need to work more
- to get the answer. If you really want to do this, you can accomplish
- the same thing by using a preprocessor such as m4 on your host files.
-
- Also, having chained records such as CNAMEs pointing to CNAMEs may
- make administration issues easier, but is known to tickle bugs in
- some resolvers that fail to check loops correctly. As a result some
- hosts may not be able to resolve such names.
-
- Having NS records pointing to a CNAME is bad and may conflict badly
- with current BIND servers. In fact, current BIND implementations
- will ignore such records, possibly leading to a lame delegation.
- There is a certain amount of security checking done in BIND to
- prevent spoofing DNS NS records. Also, older BIND servers reportedly
- will get caught in an infinite query loop trying to figure out the
- address for the aliased nameserver, causing a continuous stream of
- DNS requests to be sent.
-
-2.5 MX records
-
- It is a good idea to give every host an MX record, even if it points
- to itself! Some mailers will cache MX records, but will always need
- to check for an MX before sending mail. If a site does not have an
- MX, then every piece of mail may result in one more resolver query,
- since the answer to the MX query often also contains the IP addresses
- of the MX hosts. Internet SMTP mailers are required by [RFC 1123] to
- support the MX mechanism.
-
- Put MX records even on hosts that aren't intended to send or receive
- e-mail. If there is a security problem involving one of these hosts,
- some people will mistakenly send mail to postmaster or root at the
- site without checking first to see if it is a "real" host or just a
- terminal or personal computer that's not set up to accept e-mail. If
- you give it an MX record, then the e-mail can be redirected to a real
- person. Otherwise mail can just sit in a queue for hours or days
-
-
-
-Barr Informational [Page 7]
-
-RFC 1912 Common DNS Errors February 1996
-
-
- until the mailer gives up trying to send it.
-
- Don't forget that whenever you add an MX record, you need to inform
- the target mailer if it is to treat the first host as "local". (The
- "Cw" flag in sendmail, for example)
-
- If you add an MX record which points to an external host (e.g., for
- the purposes of backup mail routing) be sure to ask permission from
- that site first. Otherwise that site could get rather upset and take
- action (like throw your mail away, or appeal to higher authorities
- like your parent DNS administrator or network provider.)
-
-2.6 Other Resource Records
-
-2.6.1 WKS
-
- WKS records are deprecated in [RFC 1123]. They serve no known useful
- function, except internally among LISP machines. Don't use them.
-
-2.6.2 HINFO
-
- On the issue HINFO records, some will argue that these is a security
- problem (by broadcasting what vendor hardware and operating system
- you so people can run systematic attacks on known vendor security
- holes). If you do use them, you should keep up to date with known
- vendor security problems. However, they serve a useful purpose.
- Don't forget that HINFO requires two arguments, the hardware type,
- and the operating system.
-
- HINFO is sometimes abused to provide other information. The record
- is meant to provide specific information about the machine itself.
- If you need to express other information about the host in the DNS,
- use TXT.
-
-2.6.3 TXT
-
- TXT records have no specific definition. You can put most anything
- in them. Some use it for a generic description of the host, some put
- specific information like its location, primary user, or maybe even a
- phone number.
-
-2.6.4 RP
-
- RP records are relatively new. They are used to specify an e-mail
- address (see first paragraph of section 2.2) of the "Responsible
- Person" of the host, and the name of a TXT record where you can get
- more information. See [RFC 1183].
-
-
-
-
-Barr Informational [Page 8]
-
-RFC 1912 Common DNS Errors February 1996
-
-
-2.7 Wildcard records
-
- Wildcard MXs are useful mostly for non IP-connected sites. A common
- mistake is thinking that a wildcard MX for a zone will apply to all
- hosts in the zone. A wildcard MX will apply only to names in the
- zone which aren't listed in the DNS at all. e.g.,
-
- podunk.xx. IN NS ns1
- IN NS ns2
- mary IN A 1.2.3.4
- *.podunk.xx. IN MX 5 sue
-
- Mail for mary.podunk.xx will be sent to itself for delivery. Only
- mail for jane.podunk.xx or any hosts you don't see above will be sent
- to the MX. For most Internet sites, wildcard MX records are not
- useful. You need to put explicit MX records on every host.
-
- Wildcard MXs can be bad, because they make some operations succeed
- when they should fail instead. Consider the case where someone in
- the domain "widget.com" tries to send mail to "joe@larry". If the
- host "larry" doesn't actually exist, the mail should in fact bounce
- immediately. But because of domain searching the address gets
- resolved to "larry.widget.com", and because of the wildcard MX this
- is a valid address according to DNS. Or perhaps someone simply made
- a typo in the hostname portion of the address. The mail message then
- gets routed to the mail host, which then rejects the mail with
- strange error messages like "I refuse to talk to myself" or "Local
- configuration error".
-
- Wildcard MX records are good for when you have a large number of
- hosts which are not directly Internet-connected (for example, behind
- a firewall) and for administrative or political reasons it is too
- difficult to have individual MX records for every host, or to force
- all e-mail addresses to be "hidden" behind one or more domain names.
- In that case, you must divide your DNS into two parts, an internal
- DNS, and an external DNS. The external DNS will have only a few
- hosts and explicit MX records, and one or more wildcard MXs for each
- internal domain. Internally the DNS will be complete, with all
- explicit MX records and no wildcards.
-
- Wildcard As and CNAMEs are possible too, and are really confusing to
- users, and a potential nightmare if used without thinking first. It
- could result (due again to domain searching) in any telnet/ftp
- attempts from within the domain to unknown hosts to be directed to
- one address. One such wildcard CNAME (in *.edu.com) caused
- Internet-wide loss of services and potential security nightmares due
- to unexpected interactions with domain searching. It resulted in
- swift fixes, and even an RFC ([RFC 1535]) documenting the problem.
-
-
-
-Barr Informational [Page 9]
-
-RFC 1912 Common DNS Errors February 1996
-
-
-2.8 Authority and Delegation Errors (NS records)
-
- You are required to have at least two nameservers for every domain,
- though more is preferred. Have secondaries outside your network. If
- the secondary isn't under your control, periodically check up on them
- and make sure they're getting current zone data from you. Queries to
- their nameserver about your hosts should always result in an
- "authoritative" response. If not, this is called a "lame
- delegation". A lame delegations exists when a nameserver is
- delegated responsibility for providing nameservice for a zone (via NS
- records) but is not performing nameservice for that zone (usually
- because it is not set up as a primary or secondary for the zone).
-
- The "classic" lame delegation can be illustrated in this example:
-
- podunk.xx. IN NS ns1.podunk.xx.
- IN NS ns0.widget.com.
-
- "podunk.xx" is a new domain which has recently been created, and
- "ns1.podunk.xx" has been set up to perform nameservice for the zone.
- They haven't quite finished everything yet and haven't made sure that
- the hostmaster at "ns0.widget.com" has set up to be a proper
- secondary, and thus has no information about the podunk.xx domain,
- even though the DNS says it is supposed to. Various things can
- happen depending on which nameserver is used. At best, extra DNS
- traffic will result from a lame delegation. At worst, you can get
- unresolved hosts and bounced e-mail.
-
- Also, sometimes a nameserver is moved to another host or removed from
- the list of secondaries. Unfortunately due to caching of NS records,
- many sites will still think that a host is a secondary after that
- host has stopped providing nameservice. In order to prevent lame
- delegations while the cache is being aged, continue to provide
- nameservice on the old nameserver for the length of the maximum of
- the minimum plus refresh times for the zone and the parent zone.
- (See section 2.2)
-
- Whenever a primary or secondary is removed or changed, it takes a
- fair amount of human coordination among the parties involved. (The
- site itself, it's parent, and the site hosting the secondary) When a
- primary moves, make sure all secondaries have their named.boot files
- updated and their servers reloaded. When a secondary moves, make
- sure the address records at both the primary and parent level are
- changed.
-
- It's also been reported that some distant sites like to pick popular
- nameservers like "ns.uu.net" and just add it to their list of NS
- records in hopes that they will magically perform additional
-
-
-
-Barr Informational [Page 10]
-
-RFC 1912 Common DNS Errors February 1996
-
-
- nameservice for them. This is an even worse form of lame delegation,
- since this adds traffic to an already busy nameserver. Please
- contact the hostmasters of sites which have lame delegations.
- Various tools can be used to detect or actively find lame
- delegations. See the list of contributed software in the BIND
- distribution.
-
- Make sure your parent domain has the same NS records for your zone as
- you do. (Don't forget your in-addr.arpa zones too!). Do not list
- too many (7 is the recommended maximum), as this just makes things
- harder to manage and is only really necessary for very popular top-
- level or root zones. You also run the risk of overflowing the 512-
- byte limit of a UDP packet in the response to an NS query. If this
- happens, resolvers will "fall back" to using TCP requests, resulting
- in increased load on your nameserver.
-
- It's important when picking geographic locations for secondary
- nameservers to minimize latency as well as increase reliability.
- Keep in mind network topologies. For example if your site is on the
- other end of a slow local or international link, consider a secondary
- on the other side of the link to decrease average latency. Contact
- your Internet service provider or parent domain contact for more
- information about secondaries which may be available to you.
-
-3. BIND operation
-
- This section discusses common problems people have in the actual
- operation of the nameserver (specifically, BIND). Not only must the
- data be correct as explained above, but the nameserver must be
- operated correctly for the data to be made available.
-
-3.1 Serial numbers
-
- Each zone has a serial number associated with it. Its use is for
- keeping track of who has the most current data. If and only if the
- primary's serial number of the zone is greater will the secondary ask
- the primary for a copy of the new zone data (see special case below).
-
- Don't forget to change the serial number when you change data! If
- you don't, your secondaries will not transfer the new zone
- information. Automating the incrementing of the serial number with
- software is also a good idea.
-
- If you make a mistake and increment the serial number too high, and
- you want to reset the serial number to a lower value, use the
- following procedure:
-
-
-
-
-
-Barr Informational [Page 11]
-
-RFC 1912 Common DNS Errors February 1996
-
-
- Take the `incorrect' serial number and add 2147483647 to it. If
- the number exceeds 4294967296, subtract 4294967296. Load the
- resulting number. Then wait 2 refresh periods to allow the zone
- to propagate to all servers.
-
- Repeat above until the resulting serial number is less than the
- target serial number.
-
- Up the serial number to the target serial number.
-
- This procedure won't work if one of your secondaries is running an
- old version of BIND (4.8.3 or earlier). In this case you'll have to
- contact the hostmaster for that secondary and have them kill the
- secondary servers, remove the saved backup file, and restart the
- server. Be careful when editing the serial number -- DNS admins
- don't like to kill and restart nameservers because you lose all that
- cached data.
-
-3.2 Zone file style guide
-
- Here are some useful tips in structuring your zone files. Following
- these will help you spot mistakes, and avoid making more.
-
- Be consistent with the style of entries in your DNS files. If your
- $ORIGIN is podunk.xx., try not to write entries like:
-
- mary IN A 1.2.3.1
- sue.podunk.xx. IN A 1.2.3.2
-
- or:
-
- bobbi IN A 1.2.3.2
- IN MX mary.podunk.xx.
-
-
- Either use all FQDNs (Fully Qualified Domain Names) everywhere or
- used unqualified names everywhere. Or have FQDNs all on the right-
- hand side but unqualified names on the left. Above all, be
- consistent.
-
- Use tabs between fields, and try to keep columns lined up. It makes
- it easier to spot missing fields (note some fields such as "IN" are
- inherited from the previous record and may be left out in certain
- circumstances.)
-
-
-
-
-
-
-
-Barr Informational [Page 12]
-
-RFC 1912 Common DNS Errors February 1996
-
-
- Remember you don't need to repeat the name of the host when you are
- defining multiple records for one host. Be sure also to keep all
- records associated with a host together in the file. It will make
- things more straightforward when it comes time to remove or rename a
- host.
-
- Always remember your $ORIGIN. If you don't put a `.' at the end of
- an FQDN, it's not recognized as an FQDN. If it is not an FQDN, then
- the nameserver will append $ORIGIN to the name. Double check, triple
- check, those trailing dots, especially in in-addr.arpa zone files,
- where they are needed the most.
-
- Be careful with the syntax of the SOA and WKS records (the records
- which use parentheses). BIND is not very flexible in how it parses
- these records. See the documentation for BIND.
-
-3.3 Verifying data
-
- Verify the data you just entered or changed by querying the resolver
- with dig (or your favorite DNS tool, many are included in the BIND
- distribution) after a change. A few seconds spent double checking
- can save hours of trouble, lost mail, and general headaches. Also be
- sure to check syslog output when you reload the nameserver. If you
- have grievous errors in your DNS data or boot file, named will report
- it via syslog.
-
- It is also highly recommended that you automate this checking, either
- with software which runs sanity checks on the data files before they
- are loaded into the nameserver, or with software which checks the
- data already loaded in the nameserver. Some contributed software to
- do this is included in the BIND distribution.
-
-4. Miscellaneous Topics
-
-4.1 Boot file setup
-
- Certain zones should always be present in nameserver configurations:
-
- primary localhost localhost
- primary 0.0.127.in-addr.arpa 127.0
- primary 255.in-addr.arpa 255
- primary 0.in-addr.arpa 0
-
- These are set up to either provide nameservice for "special"
- addresses, or to help eliminate accidental queries for broadcast or
- local address to be sent off to the root nameservers. All of these
- files will contain NS and SOA records just like the other zone files
- you maintain, the exception being that you can probably make the SOA
-
-
-
-Barr Informational [Page 13]
-
-RFC 1912 Common DNS Errors February 1996
-
-
- timers very long, since this data will never change.
-
- The "localhost" address is a "special" address which always refers to
- the local host. It should contain the following line:
-
- localhost. IN A 127.0.0.1
-
- The "127.0" file should contain the line:
-
- 1 PTR localhost.
-
- There has been some extensive discussion about whether or not to
- append the local domain to it. The conclusion is that "localhost."
- would be the best solution. The reasons given include:
-
- "localhost" by itself is used and expected to work in some
- systems.
-
- Translating 127.0.0.1 into "localhost.dom.ain" can cause some
- software to connect back to the loopback interface when it didn't
- want to because "localhost" is not equal to "localhost.dom.ain".
-
- The "255" and "0" files should not contain any additional data beyond
- the NS and SOA records.
-
- Note that future BIND versions may include all or some of this data
- automatically without additional configuration.
-
-4.2 Other Resolver and Server bugs
-
- Very old versions of the DNS resolver have a bug that cause queries
- for names that look like IP addresses to go out, because the user
- supplied an IP address and the software didn't realize that it didn't
- need to be resolved. This has been fixed but occasionally it still
- pops up. It's important because this bug means that these queries
- will be sent directly to the root nameservers, adding to an already
- heavy DNS load.
-
- While running a secondary nameserver off another secondary nameserver
- is possible, it is not recommended unless necessary due to network
- topologies. There are known cases where it has led to problems like
- bogus TTL values. While this may be caused by older or flawed DNS
- implementations, you should not chain secondaries off of one another
- since this builds up additional reliability dependencies as well as
- adds additional delays in updates of new zone data.
-
-
-
-
-
-
-Barr Informational [Page 14]
-
-RFC 1912 Common DNS Errors February 1996
-
-
-4.3 Server issues
-
- DNS operates primarily via UDP (User Datagram Protocol) messages.
- Some UNIX operating systems, in an effort to save CPU cycles, run
- with UDP checksums turned off. The relative merits of this have long
- been debated. However, with the increase in CPU speeds, the
- performance considerations become less and less important. It is
- strongly encouraged that you turn on UDP checksumming to avoid
- corrupted data not only with DNS but with other services that use UDP
- (like NFS). Check with your operating system documentation to verify
- that UDP checksumming is enabled.
-
-References
-
- [RFC 974] Partridge, C., "Mail routing and the domain system", STD
- 14, RFC 974, CSNET CIC BBN Laboratories Inc, January 1986.
-
- [RFC 1033] Lottor, M, "Domain Administrators Operations Guide", RFC
- 1033, USC/Information Sciences Institute, November 1987.
-
- [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
- STD 13, RFC 1034, USC/Information Sciences Institute,
- November 1987.
-
- [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
- Specification", STD 13, RFC 1035, USC/Information Sciences
- Institute, November 1987.
-
- [RFC 1123] Braden, R., "Requirements for Internet Hosts --
- Application and Support", STD 3, RFC 1123, IETF, October
- 1989.
-
- [RFC 1178] Libes, D., "Choosing a Name for Your Computer", FYI 5, RFC
- 1178, Integrated Systems Group/NIST, August 1990.
-
- [RFC 1183] Ullman, R., Mockapetris, P., Mamakos, L, and C. Everhart,
- "New DNS RR Definitions", RFC 1183, October 1990.
-
- [RFC 1535] Gavron, E., "A Security Problem and Proposed Correction
- With Widely Deployed DNS Software", RFC 1535, ACES
- Research Inc., October 1993.
-
- [RFC 1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S.
- Miller, "Common DNS Implementation Errors and Suggested
- Fixes", RFC 1536, USC/Information Sciences Institute, USC,
- October 1993.
-
-
-
-
-
-Barr Informational [Page 15]
-
-RFC 1912 Common DNS Errors February 1996
-
-
- [RFC 1537] Beertema, P., "Common DNS Data File Configuration Errors",
- RFC 1537, CWI, October 1993.
-
- [RFC 1713] A. Romao, "Tools for DNS debugging", RFC 1713, FCCN,
- November 1994.
-
- [BOG] Vixie, P, et. al., "Name Server Operations Guide for BIND",
- Vixie Enterprises, July 1994.
-
-5. Security Considerations
-
- Security issues are not discussed in this memo.
-
-6. Author's Address
-
- David Barr
- The Pennsylvania State University
- Department of Mathematics
- 334 Whitmore Building
- University Park, PA 16802
-
- Voice: +1 814 863 7374
- Fax: +1 814 863-8311
- EMail: barr@math.psu.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Barr Informational [Page 16]
-