changed dns to dns-projects to divide scripts and projects
This commit is contained in:
parent
3d48acb497
commit
3b3722425e
125 changed files with 40001 additions and 0 deletions
164
dns-projects/dnswalk/CHANGES
Normal file
164
dns-projects/dnswalk/CHANGES
Normal file
|
@ -0,0 +1,164 @@
|
|||
$Id: CHANGES,v 1.11 1997/10/06 13:27:37 barr Exp barr $
|
||||
|
||||
Version 2.0.2
|
||||
|
||||
Silly bug in output, SOA= was listing the domain, not the master.
|
||||
Reported by Jeff Miller <jmiller@smart.net>.
|
||||
|
||||
dnswalk now checks to see that target of MX, CNAME and NS are a hostname,
|
||||
not an IP addr.
|
||||
|
||||
Version 2.0.1
|
||||
|
||||
Regexp bug in 'makereports' script. (chopped off last charcter of
|
||||
contact address).
|
||||
|
||||
Version 2.0.0 (beta)
|
||||
|
||||
Ported to Net::DNS. Now no longer relies on 'dig'. Some less-used
|
||||
error messages removed, such as the 'double domain' check.
|
||||
|
||||
dnswalk now no longer saves zone transferrs to local files, due to
|
||||
the fact that dnswalk no longer uses 'dig'. The zone transfer itself
|
||||
doesn't take that long -- mostly it's CPU time churning on what comes
|
||||
in. I may add it back if there's enough demand (using the "Storage"
|
||||
perl package, like what is used by the Net::DNS package's examples)
|
||||
|
||||
Added 'WARN', 'FAIL', and 'BAD' prefixes to error messages, to indicate
|
||||
some level of 'badness' associated with a particular message. Makes
|
||||
machine parsing easier, as well as human interpreting. ('FAIL'
|
||||
was called 'ERROR' before beta release).
|
||||
|
||||
dnswalk now exits with a return code equal to the number of 'BAD' things
|
||||
found. (from an request by Dave Crocker)
|
||||
|
||||
dnswalk (with -F fascist checking) no longer gives A record warnings
|
||||
with hosts like "neptune" and "neptune-le0" (it treats them as the
|
||||
same host). Formerly it would warn that A record for neptune-le0
|
||||
"points to" neptune. (this is a common situation with multi-homed
|
||||
hosts, where A records pointing just to individual interfaces are used).
|
||||
Anything "host-something" is treated the same as "host". (request
|
||||
from David Nelson <dnelson@iphase.com>)
|
||||
|
||||
perform some rudimentary checks on SOA contact field. (99% of
|
||||
the time the error is someone forgetting you have to replace the
|
||||
"@" sign in the email address with a ".".)
|
||||
|
||||
Reformatted the code to be a bit more readable.
|
||||
|
||||
Version 1.8.3
|
||||
Miscellaneous fixes, getautservers(). Condensed code.
|
||||
|
||||
Hack added to ignore RFC 1101 netmasks encoding.
|
||||
|
||||
Assigning $1 wasn't working, use local variable. Patch from Mark
|
||||
Andrews <Mark.Andrews@dms.csiro.au>.
|
||||
|
||||
New Perl script "makereports" included to take output and generate
|
||||
reports for each hostmaster for the problems within his/her zone.
|
||||
|
||||
Suggestion by marka@syd.dms.CSIRO.AU (Mark Andrews) to only
|
||||
check for invalid characters on A or MX records. I could probably
|
||||
do two-level checking, one for 1033 compliance on all records
|
||||
and 1035 compliance on mail-able names (A and MX). However
|
||||
this is a reasonable compromise for now.
|
||||
|
||||
Version 1.8.2
|
||||
Fixed spelling errors and shoddy syntax in getauthservers(), from
|
||||
Jost Krieger <Jost.Krieger@rz.ruhr-uni-bochum.de>
|
||||
|
||||
Accounted for Solaris's broken gethostbyname() which includes trailing
|
||||
dots in retuned name.
|
||||
|
||||
Minor fixes in lame delegation checking, and getauthservers().
|
||||
|
||||
Version 1.8.1
|
||||
One-line fix to remove reference to non-existent parameter to getmaster().
|
||||
Reported by petri@ibr.cs.tu-bs.de (Stefan Petri).
|
||||
|
||||
Version 1.8
|
||||
Typos, documentation corrections, additions to TIPS as well as
|
||||
stuff for TODO from Piete Brooks <Piete.Brooks@cl.cam.ac.uk>.
|
||||
|
||||
Patch from Thorsten Lockert <tholo@sigmasoft.com>: remove directory
|
||||
if zone transfer fails.
|
||||
|
||||
Fixed getauthservers() routine. Sometimes had list of servers
|
||||
which contained each server listed twice. Also fixed it to
|
||||
use the 'master server' field of the SOA record as a 'hint'
|
||||
to which server to check first.
|
||||
|
||||
Fixed typo in dot-death checking. Error message forgot \n.
|
||||
|
||||
Added -D flag to set base directory for saved axfr files.
|
||||
|
||||
Version 1.7
|
||||
Added "_" to list of invalid characters in a hostname. (Painful
|
||||
because we have hundreds of PCs and Macs here with one.) Can
|
||||
now be supressed with '-i' option (whew).
|
||||
|
||||
Fixed wildcard RR's being marked as having invalid characters.
|
||||
(Thanks to Paul Turner <turner@telstar.kodak.com> for reporting it)
|
||||
|
||||
Changed how the return codes for gethostby*() routines were being
|
||||
checked. Added caveat in README about herror(). Thanks to Bill Fenner
|
||||
|
||||
Suppresses duplicate error message per zone. Idea from Paul Turner.
|
||||
|
||||
Checks for dom.ain.dom.ain. in data, in case someone forgot the
|
||||
trailing '.'.
|
||||
|
||||
Finally added a man page. Trimmed out redundant information
|
||||
from the README file.
|
||||
|
||||
Version 1.6
|
||||
removed -c switch, since I thought it would work a long time ago, but
|
||||
later found out it could never be made to work. Well, it could, just
|
||||
not very nicely. (nor efficiently)
|
||||
|
||||
Fixed bug with parsing of dig output. Newer dig has slightly different
|
||||
output, causing serial numbers to not be pulled out.
|
||||
|
||||
Changed the do-dnswalk script to use exec > logfile instead of
|
||||
redirecting every invocation to a logfile. Idea from Dan Ehrlich.
|
||||
|
||||
Fixed problem with dnswalk using old list of subdomains in axfr file,
|
||||
ignoring the new zone transfer if it was needed.
|
||||
|
||||
Accounted for annoying behavior of new dig to print duplicate SOA's.
|
||||
|
||||
Documented nameserver error reporting.
|
||||
|
||||
Version 1.5
|
||||
|
||||
added -F switch. This performs "fascist" checking. For every A record,
|
||||
it checks to see that it actually points to the canonical name listed
|
||||
for the PTR and reports mismatches. Try this switch at least once to see
|
||||
what kind of things pop up. (You may be surprised)
|
||||
|
||||
added -m switch. Performs check on zone only if it has been modified
|
||||
(serial number changed) since the previous run.
|
||||
|
||||
changed format of messages to be shorter and more precise. (and hopefully
|
||||
easier to read) Read the README section for a full description.
|
||||
|
||||
warns if a zone has only one authoratative nameserver
|
||||
*** in later versions of 1.3, not posted here, but available for ftp,
|
||||
there was a bad bug which caused erroneous warnings about having only
|
||||
one nameserver. (was using the wrong variable)
|
||||
|
||||
reports any errors listed in dig zone transfer output. (usually
|
||||
caused by a corrupted zone file, or invalid syntax in data; for example
|
||||
only one field in an HINFO record.)
|
||||
|
||||
now reports any resolver errors from gethostbyname and gethostbyaddr.
|
||||
(for example, a server timeout, connection refused, etc)
|
||||
|
||||
sorts output by zone (correctly -- some versions of 1.3 didn't quite do
|
||||
this right)
|
||||
|
||||
displays server of authority and zone contact for each zone it checks.
|
||||
|
||||
I've now included a 'do-dnswalk' script that is an example wrapper
|
||||
that I use around dnswalk to turn on status debugging and put the
|
||||
results in a log file. Salt to taste.
|
95
dns-projects/dnswalk/README
Normal file
95
dns-projects/dnswalk/README
Normal file
|
@ -0,0 +1,95 @@
|
|||
dnswalk 2.0 - August 4, 1997
|
||||
|
||||
Author: David Barr <barr@cis.ohio-state.edu>
|
||||
$Id: README,v 1.6 1997/08/04 19:09:34 barr Exp barr $
|
||||
|
||||
INTRO
|
||||
|
||||
dnswalk is a DNS debugger. It performs zone transfers of specified
|
||||
domains, and checks the database in numerous ways for internal
|
||||
consistency, as well as accuracy.
|
||||
|
||||
dnswalk requires perl and the Net::DNS Perl package. If you do not have
|
||||
these, get them. (perl is assumed to be in /usr/local/bin, edit the first
|
||||
line of dnswalk if it is not)
|
||||
|
||||
They can be found by at:
|
||||
http://www.perl.com/perl/
|
||||
|
||||
dnswalk used to require 'dig' (part of the BIND distribution). However,
|
||||
different versions of dig gave output which was ever so slightly different,
|
||||
causing dnswalk to break. (This is usually easy to fix, even in a
|
||||
backward-compatible fashion, but it was annoying nonetheless) Also,
|
||||
using an external program made error checking more difficult and not
|
||||
very reliable. Since error checking is the heart of what dnswalk is about,
|
||||
this wasn't good. I finally got off my duff and ported dnswalk to Michael
|
||||
Fuhr's Net::DNS package, something I've been wanting to do for a while.
|
||||
(actually another reason I waited so long was the Net::DNS package wasn't
|
||||
complete enough initially for for a complete port.)
|
||||
|
||||
|
||||
dnswalk is not for the faint of heart. It should NOT be used
|
||||
without a firm knowledge of the DNS RFC's. The warnings and errors
|
||||
must be interpreted within the context they are being used. Something
|
||||
may be flagged as a warning, but in reality it is a really bad error.
|
||||
Conversely dnswalk will flag things as warnings and possibly even
|
||||
errors, but they may actually be perfectly "legal" or normal in your
|
||||
specific situation. dnswalk is not an AI engine. It just provides
|
||||
useful information which you need to interpret. If you use this tool
|
||||
for cracking or otherwise evil purposes, the author hereby considers
|
||||
you a slime-ball. See the end of this README file for a list of good
|
||||
reading material.
|
||||
|
||||
dnswalk is not a replacement for doc, although dnswalk is starting
|
||||
to incorporate some of the things doc checks for. dnswalk was written to
|
||||
check individual database entries, while 'doc' ensures that the overall
|
||||
database structure and authority records are consistent. dnswalk may
|
||||
not even function correctly (or find real problems) if authority records
|
||||
are missing or incorrect.
|
||||
|
||||
This program may be freely distributed, as long as this notice
|
||||
and documentation are distributed with the program. This program is
|
||||
released as-is, with no warranty expressed or implied. Some assembly
|
||||
required, contents may settle during shipment. This program can be
|
||||
found at
|
||||
|
||||
http://www.cis.ohio-state.edu/~barr/dnswalk/
|
||||
|
||||
dnswalk tends to produce lots of output, so I'd suggest
|
||||
redirecting this into a file of your choice. I debated using doc's
|
||||
strategy of automatically putting it in a logfile, but decided not
|
||||
to. (The author reserves the right to change his mind) For small,
|
||||
mostly-correct domains it is pretty manageable, however. For larger
|
||||
domains, use the included 'do-dnswalk' script as a guide.
|
||||
|
||||
Please refer to the man page on what dnswalk checks for, and
|
||||
the format of the output.
|
||||
|
||||
*** NOTICE ***
|
||||
I fully realize that while some of the rules are not in
|
||||
violation of an RFC, it might be wise to reconsider their usage
|
||||
anyway. dnswalk was written to be a tool to let the hostmaster decide
|
||||
what are troublesome areas, not as a program that has all the answers.
|
||||
*** NOTICE ***
|
||||
|
||||
This program was originally tested with data from the psu.edu domain.
|
||||
If your site does things differently than the way we do things, then you
|
||||
may see it report things as errors, when in fact they are "okay".
|
||||
If you notice something not being reported, or something reported that
|
||||
is not an error, please send me output! I fully admit that I'm not
|
||||
an expert in DNS and the requirements. My rules tend to be skewed to
|
||||
my personal feelings about what "nice" DNS databases look like. Others
|
||||
are free to differ. (and tell me so)
|
||||
|
||||
Author:
|
||||
David Barr <barr@cis.ohio-state.edu>
|
||||
Lead System Administrator
|
||||
The Ohio State University, Department of Computer and Information Science
|
||||
|
||||
Thanks:
|
||||
|
||||
Bill Fenner - tips with perl
|
||||
Michael Fuhr - for writing Net::DNS!
|
||||
Dave Crocker - for providing the spark necessary for me to pick up
|
||||
developement of dnswalk-2.0 again.
|
||||
|
18
dns-projects/dnswalk/TODO
Normal file
18
dns-projects/dnswalk/TODO
Normal file
|
@ -0,0 +1,18 @@
|
|||
replace remaining gethostby*() calls with Net::DNS calls. (better
|
||||
error reporting)
|
||||
|
||||
compare serial number of zone transfer data and report differences
|
||||
|
||||
Check RP records that they point to a TXT record.
|
||||
|
||||
Check for CNAME and other data. (modern BIND versions disallow this,
|
||||
but not everyone sadly is up to date)
|
||||
|
||||
Check parent delegation (a la doc) and check for lame delegations.
|
||||
Compare serial numbers of all NS servers and report differences.
|
||||
(a la doc)
|
||||
|
||||
./dnswalk non-existant.domain doesn't generate a very useful message
|
||||
|
||||
complete RFC 1101 check.. A records in rev file
|
||||
|
414
dns-projects/dnswalk/dnswalk
Executable file
414
dns-projects/dnswalk/dnswalk
Executable file
|
@ -0,0 +1,414 @@
|
|||
#!/usr/contrib/bin/perl
|
||||
#
|
||||
# dnswalk Walk through a DNS tree, pulling out zone data and
|
||||
# dumping it in a directory tree
|
||||
#
|
||||
# $Id: dnswalk,v 1.18 1997/10/06 13:23:58 barr Exp barr $
|
||||
#
|
||||
# check data collected for legality using standard resolver
|
||||
#
|
||||
# invoke as dnswalk domain > logfile
|
||||
# Options:
|
||||
# -r Recursively descend subdomains of domain
|
||||
# -i Suppress check for invalid characters in a domain name.
|
||||
# -a turn on warning of duplicate A records.
|
||||
# -d Debugging
|
||||
# -m Check only if the domain has been modified. (Useful only if
|
||||
# dnswalk has been run previously.)
|
||||
# -F Enable "facist" checking. (See man page)
|
||||
# -l Check lame delegations
|
||||
|
||||
use Getopt::Std;
|
||||
use IO::Socket;
|
||||
use Net::DNS;
|
||||
|
||||
getopts("D:rfiadmFl");
|
||||
|
||||
$num_error{'FAIL'}=0; # failures to access data
|
||||
$num_error{'WARN'}=0; # questionable data
|
||||
$num_error{'BAD'}=0; # bad data
|
||||
|
||||
# Where all zone transfer information is saved. You can change this to
|
||||
# something like /tmp/dnswalk if you don't want to clutter up the current
|
||||
# directory
|
||||
if ($opt_D) {
|
||||
$basedir = $opt_D;
|
||||
} else {
|
||||
$basedir = ".";
|
||||
}
|
||||
($domain = $ARGV[0]) =~ tr/A-Z/a-z/;
|
||||
if ($domain !~ /\.$/) {
|
||||
die "Usage: dnswalk domain\ndomain MUST end with a '.'\n";
|
||||
}
|
||||
if (! -d $basedir) {
|
||||
mkdir($basedir,0777) || die "FAIL: Cannot create $basedir: $!\n";
|
||||
}
|
||||
|
||||
&dowalk($domain);
|
||||
print STDERR "$num_error{'FAIL'} failures, $num_error{'WARN'} warnings, $num_error{'BAD'} errors.\n";
|
||||
exit $num_error{'BAD'};
|
||||
|
||||
sub dowalk {
|
||||
my (@subdoms);
|
||||
my (@sortdoms);
|
||||
my ($domain)=$_[0];
|
||||
$modified=0;
|
||||
return unless $domain;
|
||||
print "Checking $domain\n";
|
||||
@subdoms=&doaxfr($domain);
|
||||
&check_zone($domain) if (defined(@zone) && @zone);
|
||||
undef @zone;
|
||||
return if (!(defined(@subdoms) && @subdoms));
|
||||
@sortdoms = sort byhostname @subdoms;
|
||||
local ($subdom);
|
||||
if ($opt_r) {
|
||||
foreach $subdom (@sortdoms) {
|
||||
&dowalk($subdom);
|
||||
}
|
||||
}
|
||||
}
|
||||
# try to get a zone transfer, trying each listed authoritative server if
|
||||
# if fails.
|
||||
sub doaxfr {
|
||||
local ($domain)=@_[0];
|
||||
local (%subdoms)=();
|
||||
local ($subdom);
|
||||
local(@servers) = &getauthservers($domain);
|
||||
&printerr("BAD", "$domain has only one authoritative nameserver\n")
|
||||
if (scalar(@servers) == 1);
|
||||
&printerr("BAD", "$domain has NO authoritative nameservers!\n")
|
||||
if (scalar(@servers) == 0);
|
||||
SERVER:
|
||||
foreach $server (@servers) {
|
||||
print STDERR "Getting zone transfer of $domain from $server...";
|
||||
my $res = new Net::DNS::Resolver;
|
||||
$res->nameservers($server);
|
||||
@zone=$res->axfr($domain);
|
||||
unless (defined(@zone) && @zone) {
|
||||
print STDERR "failed\n";
|
||||
&printerr("FAIL",
|
||||
"Zone transfer of $domain from $server failed: ".
|
||||
$res->errorstring. "\n");
|
||||
next SERVER;
|
||||
}
|
||||
@subdoms=undef;
|
||||
foreach $rr (@zone) {
|
||||
if ($rr->type eq "NS") {
|
||||
$subdom = $rr->name;
|
||||
$subdom =~ tr/A-Z/a-z/;
|
||||
if ((!&equal($subdom,$domain)) && ( !$subdoms{$subdom})) {
|
||||
$subdoms{$subdom}=1;
|
||||
}
|
||||
}
|
||||
}
|
||||
print STDERR "done.\n";
|
||||
last SERVER;
|
||||
} # foreach #
|
||||
unless (defined(@zone) && @zone) {
|
||||
&printerr("BAD","All zone transfer attempts of $domain failed!\n");
|
||||
return undef;
|
||||
}
|
||||
return (keys %subdoms);
|
||||
}
|
||||
|
||||
sub getauthservers {
|
||||
my ($domain)=$_[0];
|
||||
my ($master)=&getmaster($domain);
|
||||
my ($foundmaster)=0;
|
||||
my ($ns);
|
||||
my ($ns_tmp);
|
||||
my ($res);
|
||||
my ($ns_req);
|
||||
my (@servers);
|
||||
my (%servhash);
|
||||
return if (!$master); # this is null if there is no SOA or not found
|
||||
return if (!$domain);
|
||||
$res = new Net::DNS::Resolver;
|
||||
$ns_req = $res->query($domain, "NS");
|
||||
&printerr("FAIL", "No nameservers found for $domain: ".
|
||||
$res->errorstring ."\n")
|
||||
unless (defined($ns_req) and ($ns_req->header->ancount > 0));
|
||||
foreach $ns ($ns_req->answer) {
|
||||
$ns_tmp = $ns->nsdname;
|
||||
$ns_tmp =~ tr/A-Z/a-z/;
|
||||
if (&equal($ns_tmp,$master)) {
|
||||
$foundmaster=1; # make sure the master is at the top
|
||||
} else {
|
||||
push(@servers,$ns_tmp) if ($servhash{$ns_tmp}++<1);
|
||||
}
|
||||
}
|
||||
if ($foundmaster) {
|
||||
unshift(@servers,$master);
|
||||
}
|
||||
return @servers;
|
||||
}
|
||||
|
||||
# return 'master' server for zone
|
||||
sub getmaster {
|
||||
my ($zone)=$_[0];
|
||||
my ($res) = new Net::DNS::Resolver;
|
||||
my ($packet) = new Net::DNS::Packet($zone, "SOA", "IN");
|
||||
my ($soa_req) = $res->send($packet);
|
||||
unless (defined($soa_req)) {
|
||||
&printerr("FAIL", "Cannot get SOA record for $zone:".
|
||||
$res->errorstring ."\n");
|
||||
return "";
|
||||
}
|
||||
unless (($soa_req->header->ancount >= 1) &&
|
||||
(($soa_req->answer)[0]->type eq "SOA")) {
|
||||
&printerr("BAD", "SOA record not found for $zone\n");
|
||||
return "";
|
||||
}
|
||||
return ($soa_req->answer)[0]->mname;
|
||||
}
|
||||
|
||||
# open result of zone tranfer and check lots of nasty things
|
||||
# here's where the fun begins
|
||||
sub check_zone {
|
||||
my ($domain)=$_[0];
|
||||
local (%glues)=(); # look for duplicate glue (A) records
|
||||
local ($name, $aliases, $addrtype, $length, @addrs);
|
||||
local ($prio,$mx);
|
||||
local ($soa,$contact);
|
||||
local ($lastns); # last NS record we saw
|
||||
local (@keys); # temp variable
|
||||
foreach $rr (@zone) {
|
||||
# complain about invalid chars only for mail names
|
||||
if ((($rr->type eq "A") || ($rr->type eq "MX")) && (!$opt_i) &&
|
||||
($rr->name =~ /[^\*][^-A-Za-z0-9.]/)) {
|
||||
&printerr("WARN", $rr->name .": invalid character(s) in name\n");
|
||||
}
|
||||
if ($rr->type eq "SOA") {
|
||||
print STDERR 's' if $opt_d;
|
||||
print "SOA=". $rr->mname ." contact=". $rr->rname ."\n";
|
||||
# basic address check. No "@", and user.dom.ain (two or more dots)
|
||||
if (($rr->rname =~ /@/)||!($rr->rname =~ /\..*\./)) {
|
||||
&printerr("WARN", "SOA contact name (".
|
||||
$rr->rname .") is invalid\n");
|
||||
}
|
||||
} elsif ($rr->type eq "PTR") {
|
||||
print STDERR 'p' if $opt_d;
|
||||
if (scalar((@keys=split(/\./,$rr->name))) == 6 ) {
|
||||
# check if forward name exists, but only if reverse is
|
||||
# a full IP addr
|
||||
# skip ".0" networks
|
||||
if ($keys[0] ne "0") {
|
||||
($name, $aliases, $addrtype, $length,
|
||||
@addrs)=gethostbyname($rr->ptrdname);
|
||||
# if (!(($name, $aliases, $addrtype, $length,
|
||||
# @addrs)=gethostbyname($rr->ptrdname))) {
|
||||
# &printerr("FAIL", "gethostbyname(".
|
||||
# $rr->ptrdname ."): $!\n");
|
||||
# }
|
||||
# else {
|
||||
if (!$name) {
|
||||
&printerr("WARN", $rr->name
|
||||
." PTR ". $rr->ptrdname .": unknown host\n");
|
||||
}
|
||||
elsif (!&equal($name,$rr->ptrdname)) {
|
||||
&printerr("WARN", $rr->name
|
||||
." PTR ". $rr->ptrdname .": CNAME (to $name)\n");
|
||||
}
|
||||
elsif (!&matchaddrlist($rr->name)) {
|
||||
&printerr("WARN", $rr->name
|
||||
." PTR ". $rr->ptrdname .": A record not found\n");
|
||||
}
|
||||
# }
|
||||
}
|
||||
}
|
||||
} elsif (($rr->type eq "A") ) {
|
||||
print STDERR 'a' if $opt_d;
|
||||
# check to see that a reverse PTR record exists
|
||||
($name,$aliases,$addrtype,$length,@addrs)=gethostbyaddr(pack('C4',
|
||||
split(/\./,$rr->address)),2);
|
||||
if (!$name) {
|
||||
# hack - allow RFC 1101 netmasks encoding
|
||||
if ($rr->address !=~ /^255/) {
|
||||
&printerr("WARN", $rr->name ." A ".
|
||||
$rr->address .": no PTR record\n");
|
||||
}
|
||||
}
|
||||
elsif ($opt_F && !&equal($name,$rr->name)) {
|
||||
# Filter out "hostname-something" (like "neptune-le0")
|
||||
if (index(split (/\./, $rr->name, 2) . "-",
|
||||
split (/\./, $name, 2)) == -1 ) {
|
||||
&printerr("WARN", $rr->name ." A ".
|
||||
$rr->address .": points to $name\n")
|
||||
if ((split(/\./,$name))[0] ne "localhost");
|
||||
}
|
||||
}
|
||||
if ($main'opt_a) {
|
||||
# keep list in %glues, report any duplicates
|
||||
if ($glues{$rr->address} eq "") {
|
||||
$glues{$rr->address}=$rr->name;
|
||||
}
|
||||
elsif (($glues{$rr->address} eq $rr->name) &&
|
||||
(!&equal($lastns,$domain))) {
|
||||
&printerr("WARN", $rr->name
|
||||
.": possible duplicate A record (glue of $lastns?)\n");
|
||||
}
|
||||
}
|
||||
} elsif ($rr->type eq "NS") {
|
||||
$lastns=$rr->name;
|
||||
print STDERR 'n' if $opt_d;
|
||||
# check to see if object of NS is real
|
||||
&checklamer($rr->name,$rr->nsdname) if ($main'opt_l);
|
||||
# check for bogusnesses like NS->IP addr
|
||||
if (&isipv4addr($rr->nsdname)) {
|
||||
&printerr("BAD", $rr->name
|
||||
." NS ". $rr->nsdname .": Nameserver must be a hostname\n");
|
||||
}
|
||||
($name, $aliases, $addrtype, $length,
|
||||
@addrs)=gethostbyname($rr->nsdname);
|
||||
# if (!(($name, $aliases, $addrtype, $length,
|
||||
# @addrs)=gethostbyname($rr->nsdname))) {
|
||||
# &printerr("FAIL", "gethostbyname(". $rr->nsdname ."): $!\n");
|
||||
# }
|
||||
# else {
|
||||
if (!$name) {
|
||||
&printerr("BAD", $rr->name
|
||||
." NS ". $rr->nsdname .": unknown host\n");
|
||||
} elsif (!&equal($name,$rr->nsdname)) {
|
||||
&printerr("BAD", $rr->name
|
||||
." NS ". $rr->nsdname .": CNAME (to $name)\n");
|
||||
}
|
||||
# }
|
||||
} elsif ($rr->type eq "MX") {
|
||||
print STDERR 'm' if $opt_d;
|
||||
# check to see if object of mx is real
|
||||
if (&isipv4addr($rr->exchange)) {
|
||||
&printerr("BAD", $rr->name
|
||||
." MX ". $rr->exchange .": Mail exchange must be a hostname\n");
|
||||
}
|
||||
($name, $aliases, $addrtype, $length,
|
||||
@addrs)=gethostbyname($rr->exchange);
|
||||
# if (!(($name, $aliases, $addrtype, $length,
|
||||
# @addrs)=gethostbyname($rr->exchange))) {
|
||||
# &printerr("FAIL", "gethostbyname(". $rr->exchange ."): $!\n");
|
||||
# }
|
||||
# else {
|
||||
if (!$name) {
|
||||
&printerr("WARN", $rr->name
|
||||
." MX ". $rr->exchange .": unknown host\n");
|
||||
}
|
||||
elsif (!&equal($name,$rr->exchange)) {
|
||||
&printerr("WARN", $rr->name
|
||||
." MX ". $rr->exchange .": CNAME (to $name)\n");
|
||||
}
|
||||
# }
|
||||
} elsif ($rr->type eq "CNAME") {
|
||||
print STDERR 'c' if $opt_d;
|
||||
($name, $aliases, $addrtype, $length,
|
||||
@addrs)=gethostbyname($rr->cname);
|
||||
if (&isipv4addr($rr->cname)) {
|
||||
&printerr("BAD", $rr->name
|
||||
." CNAME ". $rr->cname .": alias must be a hostname\n");
|
||||
}
|
||||
# if (!(($name, $aliases, $addrtype, $length,
|
||||
# @addrs)=gethostbyname($rr->cname))) {
|
||||
# &printerr("FAIL", "gethostbyname(". $rr->cname ."): $!\n");
|
||||
# }
|
||||
# else {
|
||||
if (!$name) {
|
||||
&printerr("WARN", $rr->name
|
||||
." CNAME ". $rr->cname .": unknown host\n");
|
||||
} elsif (!&equal($name,$rr->cname)) {
|
||||
&printerr("WARN", $rr->name
|
||||
." CNAME ". $rr->cname .": CNAME (to $name)\n");
|
||||
}
|
||||
# }
|
||||
}
|
||||
}
|
||||
print STDERR "\n" if $opt_d;
|
||||
close(FILE);
|
||||
}
|
||||
|
||||
# prints an error message, suppressing duplicates
|
||||
sub printerr {
|
||||
my ($type, $err)=@_;
|
||||
if ($errlist{$err}==undef) {
|
||||
print "$type: $err";
|
||||
$num_error{$type}++;
|
||||
print STDERR "!" if $opt_d;
|
||||
$errlist{$err}=1;
|
||||
} else {
|
||||
print STDERR "." if $opt_d;
|
||||
}
|
||||
}
|
||||
|
||||
sub equal {
|
||||
# Do case-insensitive string comparisons
|
||||
local ($one)= $_[0];
|
||||
local ($two)= $_[1];
|
||||
$stripone=$one;
|
||||
if (chop($stripone) eq '.') {
|
||||
$one=$stripone;
|
||||
}
|
||||
$striptwo=$two;
|
||||
if (chop($striptwo) eq '.') {
|
||||
$two=$striptwo;
|
||||
}
|
||||
$one =~ tr/A-Z/a-z/;
|
||||
$two =~ tr/A-Z/a-z/;
|
||||
return ($one eq $two);
|
||||
}
|
||||
|
||||
# check if argument looks like an IPv4 address
|
||||
sub isipv4addr {
|
||||
my ($host)=$_[0];
|
||||
my ($one,$two,$three,$four);
|
||||
($one,$two,$three,$four)=split(/\./,$host);
|
||||
my $whole="$one$two$three$four";
|
||||
# strings evaluated as numbers are zero
|
||||
return (($whole+0) eq $whole);
|
||||
}
|
||||
sub matchaddrlist {
|
||||
local($match)=pack('C4', reverse(split(/\./,$_[0],4)));
|
||||
local($found)=0;
|
||||
foreach $i (@addrs) {
|
||||
$found=1 if ($i eq $match);
|
||||
}
|
||||
return $found;
|
||||
}
|
||||
|
||||
# there's a better way to do this, it just hasn't evolved from
|
||||
# my brain to this program yet.
|
||||
sub byhostname {
|
||||
@c = reverse(split(/\./,$a));
|
||||
@d = reverse(split(/\./,$b));
|
||||
for ($i=0;$i<=(($#c > $#d) ? $#c : $#d) ;$i++) {
|
||||
next if $c[$i] eq $d[$i];
|
||||
return -1 if $c[$i] eq "";
|
||||
return 1 if $d[$i] eq "";
|
||||
if ($c[$i] eq int($c[$i])) {
|
||||
# numeric
|
||||
return $c[$i] <=> $d[$i];
|
||||
}
|
||||
else {
|
||||
# string
|
||||
return $c[$i] cmp $d[$i];
|
||||
}
|
||||
}
|
||||
return 0;
|
||||
}
|
||||
|
||||
sub checklamer {
|
||||
my ($zone,$nameserver)=@_;
|
||||
my ($packet) = new Net::DNS::Packet($zone, "SOA", "IN");
|
||||
my ($soa_req);
|
||||
my ($res) = new Net::DNS::Resolver;
|
||||
unless ($res->nameservers($nameserver)) {
|
||||
&printerr("FAIL", "Cannot find address for nameserver: ".
|
||||
$res->errorstring. "\n");
|
||||
}
|
||||
$soa_req = $res->send($packet);
|
||||
unless (defined($soa_req)) {
|
||||
&printerr("FAIL",
|
||||
"Cannot get SOA record for $zone from $nameserver (lame?): ".
|
||||
$res->errorstring ."\n");
|
||||
return;
|
||||
}
|
||||
&printerr("BAD", "$zone NS $nameserver: lame NS delegation\n")
|
||||
unless ($soa_req->header->aa);
|
||||
return;
|
||||
}
|
221
dns-projects/dnswalk/dnswalk.1
Normal file
221
dns-projects/dnswalk/dnswalk.1
Normal file
|
@ -0,0 +1,221 @@
|
|||
.TH DNSWALK 1
|
||||
.SH NAME
|
||||
dnswalk \- A DNS database debugger
|
||||
.SH SYNOPSIS
|
||||
.B dnswalk
|
||||
[
|
||||
.BR \- adilrfFm
|
||||
]
|
||||
.I domain.
|
||||
.SH "DESCRIPTION"
|
||||
.B dnswalk
|
||||
is a DNS debugger. It performs zone transfers of specified domains,
|
||||
and checks the database in numerous ways for internal consistency, as
|
||||
well as for correctness according to accepted practices with the Domain
|
||||
Name System.
|
||||
.PP
|
||||
The
|
||||
.I domain
|
||||
name specified on the command line MUST end with a '.'.
|
||||
You can specify a forward domain, such as
|
||||
.B dnswalk podunk.edu.
|
||||
or a reverse domain, such as
|
||||
.B dnswalk 3.2.1.in-addr.arpa.
|
||||
.SH OPTIONS
|
||||
.PD 0
|
||||
.TP
|
||||
.BI \-r
|
||||
Recursively descend sub-domains of the specified
|
||||
domain. Use with care.
|
||||
.TP
|
||||
.BI \-a
|
||||
Turn on warning of duplicate A records. (see below)
|
||||
.TP
|
||||
.BI \-d
|
||||
Print debugging and 'status' information to stderr.
|
||||
(Use only if redirecting stdout) See DIAGNOSTICS section.
|
||||
.TP
|
||||
.BI \-m
|
||||
Perform checks only if the zone has been modified since the previous run.
|
||||
.TP
|
||||
.BI \-F
|
||||
perform "fascist" checking. When checking an A record,
|
||||
compare the PTR name for each IP address with the forward
|
||||
name and report mismatches. (see below) I recommend
|
||||
you try this option at least once to see what sorts of
|
||||
errors pop up - you might be surprised!.
|
||||
.TP
|
||||
.BI \-i
|
||||
Suppress check for invalid characters in a domain name. (see below)
|
||||
.TP
|
||||
.BI \-l
|
||||
Perform "lame delegation" checking. For every NS record,
|
||||
check to see that the listed host is indeed returning
|
||||
authoritative answers for this domain.
|
||||
.TP
|
||||
.SH ERRORS
|
||||
The following the list of error messages that
|
||||
.B dnswalk
|
||||
will return
|
||||
if it sees a potential problem with the database. Duplicate messages
|
||||
will be suppressed automatically for each zone. Error messages are
|
||||
prefixed by a keyword indiciating the message type: "WARN" (possible
|
||||
data problem), "FAIL" (failure to access data), or "BAD" (invalid data).
|
||||
.B dnswalk
|
||||
exits with a return code equal to the number of "BAD" errors.
|
||||
.TP
|
||||
.PD 0
|
||||
.BI "X PTR Y: unknown host"
|
||||
X is a PTR record to Y, but Y is not a valid host (no A record).
|
||||
These are often left over from when someone deleted a host from
|
||||
the DNS and forgot to delete the PTR record.
|
||||
.TP
|
||||
.BI "X PTR Y: A record not found"
|
||||
X is a PTR record to Y, but the IP address associated with the PTR
|
||||
record is not listed as an address for Y. There should be an A
|
||||
record for every valid IP address for a host. Many Internet services
|
||||
will not talk to you if you have mismatched PTR records.
|
||||
.TP
|
||||
.BI "X PTR Y: CNAME (to Z)"
|
||||
X is a PTR record to Y, but Y is a CNAME to Z. PTR records MUST point
|
||||
to the canonical name of a host, not an alias.
|
||||
.TP
|
||||
.BI "X CNAME Y: unknown host"
|
||||
X is aliased to Y, but Y is not a valid host (no A record).
|
||||
.TP
|
||||
.BI "X CNAME Y: CNAME (to Z)"
|
||||
X is aliased to Y, but Y is aliased to Z. CNAMEs should not be chained.
|
||||
.TP
|
||||
.BI "X MX Y: unknown host"
|
||||
X is an MX to Y, but Y is not a valid host (no A record).
|
||||
.TP
|
||||
.BI "X MX Y: CNAME (to Z)"
|
||||
X is an MX to Y, but Y is an alias for Z. MX records must point to
|
||||
the canonical name, not an alias.
|
||||
.TP
|
||||
.BI "X A Y: no PTR record"
|
||||
X has an IP address Y, but there is no PTR record to map the IP address
|
||||
Y back to a hostname (usually X). Many Internet servers (such as anonymous
|
||||
FTP servers) will not talk to addresses that don't have PTR records.
|
||||
.TP
|
||||
.BI "warning: X has only one authoritative nameserver"
|
||||
Zones must have at least one authoritative nameserver, in case
|
||||
one is down or unreachable. Make sure the parent and child domains
|
||||
list all authoritative nameservers for a zone.
|
||||
.TP
|
||||
.BI "Cannot check X: no available nameservers!"
|
||||
The X zone was delegated with NS records but all the nameservers
|
||||
for the zone are either unavailable or say that they have no data for
|
||||
the zone (are lame). Verify that the X zone isn't a typo, and if so
|
||||
make sure that all the listed nameservers are configured to answer
|
||||
with data for the zone.
|
||||
.TP
|
||||
.BI "X: invalid character(s) in name"
|
||||
Allowable characters in a domain name are the ASCII letters a through Z
|
||||
the digits 0 through 9,
|
||||
and the "-" character. A "." may be used only as a domain separator.
|
||||
(checking can be suppressed with
|
||||
.B \-i
|
||||
)
|
||||
.TP
|
||||
.BI "X: domain occurred twice, forgot trailing '.'?"
|
||||
A sanity check which looks for "dom.ain.dom.ain." in a name. This
|
||||
is often caused by forgetting to put a trailing '.' on the end of
|
||||
a name.
|
||||
.TP
|
||||
(with -a switch)
|
||||
.TP
|
||||
.BI "X: possible duplicate A record (glue of Z?)"
|
||||
A duplicate A records is listed for X. NOTE: this is most
|
||||
often caused by the practice of always putting A records for all
|
||||
secondaries after NS glue records. While this is not an error, it is
|
||||
usually redundant and makes changing IP addresses later more difficult,
|
||||
since they occur more than one time in the file (and in multiple
|
||||
files). You may get spurious errors, mostly because of a quirk in
|
||||
BIND releases before 4.9.x that reports cached glue A records in a zone
|
||||
transfer even though they don't exist in the original zone file.
|
||||
.TP
|
||||
(with -F switch)
|
||||
.TP
|
||||
.BI "X A Y: points to Z"
|
||||
X has Y for an IP address, but the PTR record associated with Y
|
||||
returns "Z" as the name associated with that host. This is not
|
||||
necessarily an error (for example if you have an A record for your
|
||||
domain name), but can be useful to check for A records which point
|
||||
to the wrong host, or PTR records that point to the wrong host.
|
||||
.TP
|
||||
.BI "Cannot find address for nameserver X"
|
||||
This error is generated if the address for a delegated nameserver X
|
||||
cannot be resolved. This could be a lame delegation (due to a typo
|
||||
in delegation), or a temporary DNS error.
|
||||
.TP
|
||||
(with -l switch)
|
||||
.TP
|
||||
.BI "X NS Y: lame NS delegation"
|
||||
Y is a listed nameserver for zone X, but Y is not returning
|
||||
authoritative data for zone X. This is usually the result of a
|
||||
lack of communication on the part of the respective hostmasters. Lame
|
||||
delegations are not fatal problems except in severe cases, they just
|
||||
tend to create significant increases in DNS traffic. NS records for
|
||||
the parent and child domains should be consistent, and each server
|
||||
listed in the NS record MUST be able to answer with authoritative data,
|
||||
either by being a primary or secondary for the zone.
|
||||
.TP
|
||||
.BI "Cannot get SOA record for X from Y (lame?)"
|
||||
This error is generated if dnswalk cannot get the SOA record for
|
||||
zone X from the nameserver Y. This could
|
||||
mean a lame delegation, or simply that the host is temporarily
|
||||
unreachable.
|
||||
.SH "SEE ALSO"
|
||||
.nf
|
||||
RFC 1034 - "DOMAIN NAMES - CONCEPTS AND FACILITIES"
|
||||
RFC 1035 - "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"
|
||||
RFC 1123 - "Requirements for Internet Hosts -- Application and Support"
|
||||
Paul Albitz, Cricket Liu: "DNS and BIND" O'Reilly & Associates.
|
||||
.SH DIAGNOSTICS
|
||||
When invoked with the
|
||||
.B \-d
|
||||
option,
|
||||
.B dnswalk
|
||||
will print status information to stderr. It consists of information
|
||||
about what zone is being checked, and a single letter corresponding
|
||||
to the resource record checked, and any errors.
|
||||
.TP
|
||||
.BI a
|
||||
A record
|
||||
.TP
|
||||
.BI c
|
||||
CNAME record
|
||||
.TP
|
||||
.BI p
|
||||
PTR record
|
||||
.TP
|
||||
.BI m
|
||||
MX record
|
||||
.TP
|
||||
.BI s
|
||||
SOA record
|
||||
.TP
|
||||
.BI !
|
||||
An error occurred
|
||||
.TP
|
||||
.BI .
|
||||
A previous error in the zone was repeated, but suppressed.
|
||||
.PP
|
||||
.SH BUGS
|
||||
dnswalk will make the directory tree before it has a chance to
|
||||
find out that you gave it a bogus domain name.
|
||||
.PP
|
||||
When checking lots of hosts and lots of options, it is very
|
||||
slow. Running dnswalk on a machine with a local nameserver helps
|
||||
considerably.
|
||||
.PP
|
||||
Perl's gethostby{name,addr}() routine doesn't seem to
|
||||
consistently return an error whenever it is unable to resolve an
|
||||
address. Argh. This will mean lots of "no PTR record" and "host unknown"
|
||||
errors if a server is unavailable, or for some reason the lookup fails.
|
||||
You may get strange error messages if your perl was compiled without
|
||||
support for herror().
|
||||
.PP
|
||||
.SH AUTHOR
|
||||
David Barr <barr@cis.ohio-state.edu>
|
96
dns-projects/dnswalk/dnswalk.errors
Normal file
96
dns-projects/dnswalk/dnswalk.errors
Normal file
|
@ -0,0 +1,96 @@
|
|||
The following the list of error messages that dnswalk will
|
||||
return if it sees a potential problem with the database.
|
||||
Duplicate messages will be suppressed automatically for each
|
||||
zone.
|
||||
X PTR Y: unknown host
|
||||
X is a PTR record to Y, but Y is not a valid host (no A
|
||||
record). These are often left over from when someone
|
||||
deleted a host from the DNS and forgot to delete the
|
||||
PTR record. These records should be removed.
|
||||
X PTR Y: A record not found
|
||||
X is a PTR record to Y, but the IP address associated
|
||||
with the PTR record is not listed as an address for Y.
|
||||
There should be an A record for every valid IP address
|
||||
for a host. Many Internet services will not talk to
|
||||
you if you have mismatched PTR records.
|
||||
X PTR Y: CNAME (to Z)
|
||||
X is a PTR record to Y, but Y is a CNAME to Z. PTR
|
||||
records should point to the real name of a host, not an
|
||||
alias.
|
||||
X CNAME Y: unknown host
|
||||
X is aliased to Y, but Y is not a valid host (no A
|
||||
record). This is a stale entry and should be removed.
|
||||
X CNAME Y: CNAME (to Z)
|
||||
X is aliased to Y, but Y is aliased to Z. CNAMEs
|
||||
should not be chained together. It has been known to
|
||||
cause problems with some software.
|
||||
X MX Y: unknown host
|
||||
X is an MX to Y, but Y is not a valid host (no A
|
||||
record). This is a stale entry and should be removed.
|
||||
X MX Y: CNAME (to Z)
|
||||
X is an MX to Y, but Y is an alias for Z. MX records
|
||||
must point to the canonical name, not an alias.
|
||||
X A Y: no PTR record
|
||||
X has an IP address Y, but there is no PTR record to
|
||||
map the IP address Y back to a hostname (usually X).
|
||||
Many Internet servers (such as anonymous FTP servers)
|
||||
will not talk to addresses that don't have PTR records.
|
||||
warning: X has only one authoritative nameserver
|
||||
Zones should have more than one authoritative name-
|
||||
server, in case one is down or unreachable. Preferably
|
||||
one should be off-site. Make sure the parent and child
|
||||
nameservers list all authoritative nameservers for a
|
||||
zone in the NS list.
|
||||
X: invalid character(s) in name
|
||||
Allowable characters in a domain name are the ASCII
|
||||
letters a through Z the digits 0 through 9, and the "-"
|
||||
character. A "." may be used only as a domain separa-
|
||||
tor. Using non-standard characters can cause unexpected
|
||||
software problems.
|
||||
X: domain occurred twice, forgot trailing '.'?
|
||||
A sanity check which looks for "dom.ain.dom.ain." in a
|
||||
name. This is often caused by forgetting to put a
|
||||
trailing '.' on the end of a name.
|
||||
X A Y: points to Z
|
||||
X has Y for an IP address, but the PTR record associ-
|
||||
ated with Y returns "Z" as the name associated with
|
||||
that host. This is not necessarily an error (for exam-
|
||||
ple if you have an A record for your domain name), but
|
||||
may be an indication of an A record which points to the
|
||||
wrong host, or a PTR record that points to the wrong
|
||||
host. You will get this error if you are trying to
|
||||
alias one host to another with an A record. You should
|
||||
use a CNAME instead.
|
||||
X NS Y: lame NS delegation
|
||||
Y is a listed nameserver for zone X, but Y is not
|
||||
returning authoritative data for zone X. This is usu-
|
||||
ally the result of a lack of communication on the part
|
||||
of the respective hostmasters. Lame delegations are
|
||||
not fatal problems except in severe cases, they just
|
||||
tend to create significant increases in DNS traffic.
|
||||
NS records for the parent and child domains should be
|
||||
consistent, and each server listed in the NS record
|
||||
MUST be able to answer with authoritative data, by
|
||||
being explicitly configured as a primary or secondary
|
||||
for the zone.
|
||||
X NS Y: nameserver error (lame?)
|
||||
These are any errors returned while contacting other
|
||||
nameservers (like connection refused or timeout) This
|
||||
could mean a lame delegation (the host is not running
|
||||
a nameserver or is misconfigured), or simply that the
|
||||
nameserver is temporarily unreachable.
|
||||
Cannot check X: no available nameservers!
|
||||
The X zone was delegated with NS records but all the
|
||||
nameservers for the zone are either unavailable or say
|
||||
that they have no data for the zone (are lame). Verify
|
||||
that the X zone isn't a typo, and if not make sure that
|
||||
all the listed nameservers are configured to answer
|
||||
with data for the zone.
|
||||
|
||||
SEE ALSO
|
||||
RFC 1034 - "DOMAIN NAMES - CONCEPTS AND FACILITIES"
|
||||
RFC 1035 - "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"
|
||||
RFC 1123 - "Requirements for Internet Hosts -- Application and Support"
|
||||
Paul Albitz, Cricket Liu: "DNS and BIND" O'Reilly & Associates.
|
||||
RFC 1912 - "Common DNS Operational and Configuration Errors"
|
||||
http://www.dns.net/dnsrd/ - DNS Resources Directory
|
16
dns-projects/dnswalk/do-dnswalk
Executable file
16
dns-projects/dnswalk/do-dnswalk
Executable file
|
@ -0,0 +1,16 @@
|
|||
#!/bin/sh
|
||||
# Here's an example script for a hostmaster of a large site
|
||||
# to automate the process
|
||||
# You can also run "./makereports <logfile" to generate an error report for
|
||||
# each hostmaster. Then cd to the rep.orts directory, remove any files
|
||||
# you don't wish to send, then run "../sendreports"
|
||||
# try adding '-F' here once just to see what pops up
|
||||
flags='-r -d'
|
||||
logfile=podunk.errors
|
||||
trap "" 2 15;
|
||||
exec > ${logfile}
|
||||
./dnswalk ${flags} $* podunk.edu.
|
||||
./dnswalk ${flags} $* 1.1.in-addr.arpa.
|
||||
./dnswalk ${flags} $* 2.1.in-addr.arpa.
|
||||
./dnswalk ${flags} $* 1.2.1.in-addr.arpa.
|
||||
./dnswalk ${flags} $* 2.2.1.in-addr.arpa.
|
30
dns-projects/dnswalk/makereports
Executable file
30
dns-projects/dnswalk/makereports
Executable file
|
@ -0,0 +1,30 @@
|
|||
#!/usr/contrib/bin/perl
|
||||
# This takes output from dnswalk and makes a "rep.orts" directory
|
||||
# with one file per contact. Great for sending mail to all the admins.
|
||||
|
||||
mkdir("rep.orts",0777);
|
||||
|
||||
while (<>) {
|
||||
if (/^Checking (.*).$/) {
|
||||
$zone=$1;
|
||||
next;
|
||||
}
|
||||
if (/^warning: .* has /) { # ugly
|
||||
$warning=$_;
|
||||
next;
|
||||
}
|
||||
if (/^SOA.*contact=(.*)$/) {
|
||||
close(REPORT);
|
||||
$contact=$1;
|
||||
$contact=~ tr/A-Z/a-z/;
|
||||
print "writing report for $contact\n";
|
||||
open(REPORT,">>rep.orts/$contact") || die "cannot write to rep.orts/$1: $!\n";
|
||||
print REPORT "Potential errors for zone: $zone\n";
|
||||
if ($warning) {
|
||||
print REPORT $warning;
|
||||
undef $warning;
|
||||
}
|
||||
}
|
||||
print REPORT;
|
||||
}
|
||||
close(REPORT);
|
899
dns-projects/dnswalk/rfc1912.txt
Normal file
899
dns-projects/dnswalk/rfc1912.txt
Normal file
|
@ -0,0 +1,899 @@
|
|||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
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]
|
||||
|
28
dns-projects/dnswalk/sendreports
Executable file
28
dns-projects/dnswalk/sendreports
Executable file
|
@ -0,0 +1,28 @@
|
|||
#!/bin/sh
|
||||
DATE=`date +%m/%y`
|
||||
for file in *; do
|
||||
hostmaster=`echo $file | sed 's/\./@/'`
|
||||
echo Sending report to "$hostmaster"
|
||||
(
|
||||
cat <<EOF
|
||||
The following is a report made by the 'dnswalk' program for the DNS
|
||||
data under your control. You are getting this report because dnswalk
|
||||
found potential errors in your DNS. Please refer to the following
|
||||
explanations of the error messages and why they are important and make
|
||||
the necessary corrections to your DNS.
|
||||
|
||||
If you would like a more extended discussion of common mistakes people
|
||||
make in setting up and running a DNS server, see RFC 1912 at
|
||||
ftp.internic.net:/rfc/rfc1912.txt
|
||||
|
||||
If you would like the source to the program which generates this
|
||||
data, you can get it at http://www.cis.ohio-state.edu/~barr/dnswalk/
|
||||
|
||||
EOF
|
||||
cat ../dnswalk.errors;\
|
||||
echo "";\
|
||||
cat $file;\
|
||||
) | /usr/ucb/Mail -s "DNS error report for $DATE" $hostmaster
|
||||
# ) | cat >/tmp/reports/$file
|
||||
sleep 1
|
||||
done
|
Loading…
Add table
Add a link
Reference in a new issue