gecloud.ch/security-scripts
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

changed dns to dns-projects to divide scripts and projects

Browse source
This commit is contained in:
Peter Baumann 2013-06-04 15:25:58 +02:00
parent 3d48acb497
commit 3b3722425e
125 changed files with 40001 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

164
dns-projects/dnswalk/CHANGES Normal file
View 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
View 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
View 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
View 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
View 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
View 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
View 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
View 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
View 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
View 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