[dns-operations] Accurately identifying glue records

[Roy Arends]

On May 15, 2006, at 10:52 PM, John Kristoff wrote:

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

So, glue-report takes a name, say oarci.net, finds the parent zone  
and shows the delegation material and glue (if exists).

Does it judge the 'properness' of glue or the non-existence of it?  
(not that it needs to, just curious).

i.e. if a server responsible for 'net' is asked for 'example.net',  
which happens to reside on nameservers with a 'org' name, glue should  
not be included. Not even when that same server is authoritative for  
that 'org' name. This out-of-bailiwick glue is poisonous and correct  
resolvers must ignore it. It only leads to inflated packets.

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

Note that the AA bit is only valid for the answer and authority  
sections. Not for the additional section.
Does it really matter where the glue in the additional section comes  
from ? Even when its through cached material instead of glue included  
in the zone. As long as the glue is in-bailiwick, the resolver can't  
tell.

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

Thanks !

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

It does not check for recursion. It happens to list it for some bind  
versions. This was actually done to differentiate between bind  
servers that do 'recursion' and 'recursion local'. Both servers will  
have the 'ra' bit set, but the latter only offers recursion for a  
local net (assuming fpdns in not run on the local net).

> For example, fpdns will fail to identify some open recursive servers
> because it only looks at whether the ra bit is set.

Not really. Some requests send by fpdns may have the RA bit set. Some  
servers may set or clear the RA bit, dependend or independed if it  
was set in the request. As set, the term 'recursion' in some of the  
fpdns outputs was to differentiate between configurations. This will  
be gone in newer versions of fpdns, so others do not assume that  
fpdns 'checks' recursion.

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

The reason it asks for '.' type A is that this results in a negative  
response that is similar across most implementations, and thus it can  
focus on the header bits.

> Of course fpdns also suffers from the usual fingerprinting problems
> when implementations change.

Yes. Those silly implementors always fail to notify me whenever  
they've updated their code. ;)

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

That has been fixed already, but haven't released the code yet.  
(yeah, roy was listening)

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

Well, it could be worse:

dig @udns1.ultradns.net ch . a

:-)

Roy