[dns-operations] Accurately identifying glue records

[Brad Knowles]

At 12:33 PM -0500 2006-05-15, John Kristoff wrote:

>  I had taken a look at accurately identifying glue records for domain
>  names and discovered that it was a little trickier than I thought.
>  Especially if looking at a large list of names.  One lesson I had to
>  first learn was never to trust any local caching server.

	Yup.

>                                                            So I used
>  dig +trace +nosearch +all to fetch the NS RRSet from the parent. I had
>  written some scripts to parse the dig output, but it wasn't very pretty.
>  I tried rewriting this using the Perl Net::DNS module and I think I
>  have something satisfactory and wanted to share it and open it up for
>  review.

	This is one of the things that is done by the Bourne shell script 
"doc", for which I am the official maintainer (although I haven't 
done anything with the code in years).

	The trick is that you've got to start at the root nameservers, 
and walk the chain down yourself.  You can't trust caching at any 
level, and if you get any truncations you should restart the query 
yourself with TCP.  Don't trust any resolver or resolver library to 
do anything beyond the absolute basics.


	Unfortunately, I think that this means you can't use Net::DNS. 
I've been thinking for years that what "doc" really needs is a 
complete rewrite in a "real" language -- like Perl -- but one of the 
things that has kept me from seriously considering that leap has been 
the fact that I wasn't looking forward to doing my own complete 
re-write of something like Net::DNS.

	I'd be very interested to hear your own experiences in this matter.


	Regardless of whether you have to write your own resolver code, 
you should check all possible servers at each level, to see if they 
have the same SOA (and serial number), as well as the same contents 
for the question you are asking.  If you find any servers that are 
advertised at a lower level that are not advertised at the parent, 
you should make a note of that and check their complete hierarchy. 
If you find any lame delegations, you should do the same.

	I'd also encourage you to check to see if the server is actually 
recursive/caching as opposed to what it claims -- query for obvious 
non-existent stuff (both in-zone and out-of-zone) with recursion 
turned off, then query for it again with recursion turned on, then 
query for it a third time with recursion turned off again, and note 
any and all differences (especially TTLs).

	Then you need to keep track of and report on all the differences.


	Oh, and keep in mind that some people operate multiple nameserver 
machines behind load-balancing switches, so I'd actually run all the 
tests multiple times, and do queries for things like "version.bind", 
"authors.bind", "version.server", "authors.server", etc... for each 
series of queries.

	Do thirty or forty cycles of each series, and I suspect that you 
should probably hit at least most of the servers more than once.  Of 
course, sites that do this sort of thing will tend to do 
rate-limiting per client IP, so you're going to want to run these 
sequences over an extended period of time.

	And you might want to run fpdns.pl against them, too.


	Ferreting out all the back-end weirdness that people try to hide 
from the outside world takes a fair amount of work.  ;)

>   I didn't find any simple command line tool that summarized
>  what I wanted for easy parsing, but if someone knows of something
>  better or can suggest how to change this tool to be more elegant I'd
>  appreciated a pointer.

	If you have any feedback you'd like to give me regarding "doc", 
I'd love to hear what you've got.  I'd also like to hear any comments 
you may have regarding fpdns.pl.

-- 
Brad Knowles, <brad at stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

  LOPSA member since December 2005.  See <http://www.lopsa.org/>.