diff -Nru /tmp/egCNdQmGfx/dnswalk-2.0.2/debian/changelog /tmp/qyNfJsiKVX/dnswalk-2.0.2.dfsg.1/debian/changelog
--- /tmp/egCNdQmGfx/dnswalk-2.0.2/debian/changelog	2007-11-25 09:24:34.000000000 +0930
+++ /tmp/qyNfJsiKVX/dnswalk-2.0.2.dfsg.1/debian/changelog	2007-11-25 09:24:35.000000000 +0930
@@ -1,3 +1,11 @@
+dnswalk (2.0.2.dfsg.1-0.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Remove non-free RFC from the source package (Closes: #393366)
+  * Add get-orig-source target to recreate the new orig.tar.gz
+
+ -- Paul Wise <pabs@debian.org>  Sat, 24 Nov 2007 18:49:56 +0930
+
 dnswalk (2.0.2-8) unstable; urgency=low
 
   * Removed rfc which was distributed with dnswalk 
diff -Nru /tmp/egCNdQmGfx/dnswalk-2.0.2/debian/rules /tmp/qyNfJsiKVX/dnswalk-2.0.2.dfsg.1/debian/rules
--- /tmp/egCNdQmGfx/dnswalk-2.0.2/debian/rules	2007-11-25 09:24:34.000000000 +0930
+++ /tmp/qyNfJsiKVX/dnswalk-2.0.2.dfsg.1/debian/rules	2007-11-25 09:24:35.000000000 +0930
@@ -84,4 +84,14 @@
 binary-arch: build install
 
 binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary install
+
+VERSION=2.0.2
+
+get-orig-source:
+	wget http://downloads.sourceforge.net/dnswalk/dnswalk-$(VERSION).tar.gz
+	mkdir dnswalk-$(VERSION)
+	cd dnswalk-$(VERSION) && tar zxf ../dnswalk-$(VERSION).tar.gz && rm -f rfc1912.txt
+	tar zcf dnswalk-$(VERSION).dfsg.1.tar.gz dnswalk-$(VERSION)
+	rm -rf dnswalk-$(VERSION) dnswalk-$(VERSION).tar.gz
+
+.PHONY: build clean binary-indep binary-arch binary install get-orig-source
diff -Nru /tmp/egCNdQmGfx/dnswalk-2.0.2/rfc1912.txt /tmp/qyNfJsiKVX/dnswalk-2.0.2.dfsg.1/rfc1912.txt
--- /tmp/egCNdQmGfx/dnswalk-2.0.2/rfc1912.txt	2000-08-06 19:21:25.000000000 +0930
+++ /tmp/qyNfJsiKVX/dnswalk-2.0.2.dfsg.1/rfc1912.txt	1970-01-01 09:30:00.000000000 +0930
@@ -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]
-
