Making tinydns-data abort on semantic errors by Jonathan de Boyne Pollard

There are several problems with the way that tinydns-data operates:

http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/djbdns-problems.html#tinydns-data-semantic-error

This patch modifies the behaviour of tinydns-data, to correct them, in the
following ways:

* tinydns-data will abort if a location code longer than 2 characters is used
  anywhere in the data file. (Location codes longer than 2 characters are not
  supported by djbdns.)

* tinydns-data will abort if a TTL field anywhere in the data file contains
  non-digit characters.

* tinydns-data will abort if a timestamp containing anything other than
  lowercase hexadecimal characters, or that is longer than 16 characters, is
  used anywhere in the data file. (The tinydns-data manual page explicitly
  specifies "16 lowercase hexadecimal characters".)

* tinydns-data will abort if it cannot decode the IP address in the second
  field of a '.', '&', '@', '+', or '=' line.

* tinydns-data will abort if the IP address in the second field of a '+' or
  '=' line is missing.

http://homepage.ntlworld.com/jonathan.deboynepollard/Softwares/djbdns/tinydns-data-semantic-error.patch

Signed-off-by: Giam Teck Choon <giamteckchoon@gmail.com>
Making tinydns and axfrdns publish complete client-side alias chains by Jonathan de Boyne Pollard

There are problems with the way that tinydns and axfrdns publish client-side
aliases.

http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/djbdns-problems.html#content-alias-chain-truncation

This patch modifies the behaviours of tinydns and axfrdns, to correct them,
such that they properly restart response processing, as per the algorithm in
RFC1034 section 4.3.2, when they encounter an alias.

http://homepage.ntlworld.com/jonathan.deboynepollard/Softwares/djbdns/tinydns-alias-chain-truncation.patch

Note that it is possible to place contradictory requirements upon tinydns and
axfrdns, by on the one hand telling them to publish resource records for the
source name of an alias whilst simultaneously on the other hand telling them
not to publish resource records for the target name. Correct publication of a
client-side alias chain involves the ability to publish both.

For example: If one's database contains

        .source.example.:
        Cwww.source.example.:www.target.example.

then one has instructed tinydns and axfrdns to publish resource records for
"source.example." and its subdomains but not to publish resource records for
"target.example." and its subdomains. Correct publication of a response to a
query against "www.source.example." involves doing both, since, as per
RFC 1034 section 4.3.2, it involves publishing the client-side alias from
"www.source.example." to "www.target.example." and then also whatever
information there is for "www.target.example.".

There are at least three ways of behaving when presented with such
contradictory requirements (whereby at any point in the chain of client-side
aliases, the administrator has instructed tinydns and axfrdns not to publish
resource records for the target name):

* One could choose to not publish anything at all, just as if the
  non-publication instruction covered the original, alias, name as well.

* One could choose to publish everything in the chain up to that point along
  with an empty resource record set for the target (which is the behaviour
  that will result from this patch).

* One could publish a "server failure" response.

However, it is strongly recommended that administrators not impose such
contradictory requirements upon tinydns and axfrdns in the first place. If one
has 'C' records in one's database, one should also have '.' or '&' records for
(some suitable enclosing superdomain of) the names in their second fields.

Signed-off-by: Giam Teck Choon <giamteckchoon@gmail.com>
Update resolving proxy DNS server's list of root content DNS servers

Signed-off-by: Giam Teck Choon <giamteckchoon@gmail.com>