[dns-operations] Accurately identifying glue records

[John Kristoff]

On Mon, 15 May 2006 13:31:58 -0500
Brad Knowles <brad at stop.mail-abuse.org> wrote:

> >                                                            So I used
> >  dig +trace +nosearch +all to fetch the NS RRSet from the parent. I

FYI... I also forget to mention +norecursive.  :-)

> 	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).

I happened upon that tool in my looking around, but not only did it
look a little old, but it didn't look like it was going to give me the
easy to work with output I wanted (something that was much more easily
parsed than dig output) so I moved on.

> 	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.

Thanks, hadn't thought about truncations.  I'll find some examples and
verify and if necessary correct how I handle those scenarios.

> 	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.

I've already been told by one colleague that I too should use a real
language called Python.  :-)

Net::DNS seems to be OK in my tests in the way I've used it.  You
can seed it with your own root server list (-r option in my script),
but even if not I beleive it is still safe, but please point out a
potential problem I may be missing.

If not seeded with a root hints file, glue-report will first do a
recursive query based on your local resolver configuration for the NS
RRSet for '.'.  Actually, even if you seed it with a root hints,
Net::DNS::Resolver::Recurse will send it's first query towards one of
the roots with recursion enabled.  I'm not sure why it does this, but
I did end up patching my copy so that it won't, but I don't think it
would generally affect the results so I didn't mention it.  I sent a
note to Olaf regarding this to see if there was some reason for this
behavior or if it was a bug.  I haven't heard back yet.

> 	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 may not have made it clear, but for my purposes all I really cared
about were glue records at one of the parents.  I am assuming, but
perhaps incorrectly that all parents are properly synchronized.  Yes,
I could have done all those things you mentioned, but it was out of
scope at the time.

> 	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).

That may be a worthy test and I considered it also.  From the code:

      # should we check for cached answer by querying again and comparing TTLs?

The obvious non-existent check is a good idea as well.

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

Yes and you've given me, or someone, a list of improvements if so
inclined to take them on, thanks.

> 	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.

I'll have to give doc a closer look before I can really say much.

I've sent a couple things to to the fpdns maintains offline and to
the fpdns list, but I guess I can say a couple things about checking
for recursive servers and fpdns I've recently learned.  First, I
should say fpdns is quite cool and the developers can probably beat
me handily in Perl-to-Perl combat.  That said, it's technique, though
I found complex to untangle as I was learning how it worked, lacks
some rigor in the way it does it's checks.

For example, fpdns will fail to identify some open recursive servers
because it only looks at whether the ra bit is set.  In addition, it
issues an A query for '.', and some servers will reply in interesting
ways compared to other qnames you may have ask them about.

Of course fpdns also suffers from the usual fingerprinting problems
when implementations change.  I found eNom DNS to come up as sheerdns
for example.  Although I think I may have a new fingerprint for eNom
if Roy is listening and eNom doesn't change things any time soon.
Examine the response you get for one of these:

  dig @dns[1-5].name-services.com ch a .

I don't know anyone else who does that.  :-)

John