finding authoritative nameservers

[Danny Mayer]

Howard Wilkinson wrote:
> Ronald F. Guilmette wrote:
>> This question has probably been asked and answered a zillion times
>> already, but I hope I will be forgiven for feeling less-then-eager
>> about searching through that past 20 years worth of bind-users list
>> archives for the answer.
>>
>> I'd just like to know if there is any "sure fire" (or mostly sure fire)
>> way of getting a list of the real, true, and actual authoritative name
>> servers for one or both of:
>>
>>    (*)  A fully-qualified domain name, which is believed to be
>> 	associated with at least one A record, or...
>>
>>    (*)  some proper sort of ...in-addr.arpa name that is believed to
>> 	be associated with at least one PTR record.
>>
>> I've tried all sorts of things, in my abundant ignorance, and nothing
>> seems to work entirely reliably 100% of the time.  (Maybe its just
>> an impossible goal?)
>>
>> I've written code (both Perl and C) to perform simple querying for the
>> applicable A and PTR records, and then tried to fish out the right-hand-
>> sides of all of the type NS AUTHORITY records contained in the responses,
>> but this often gives what, in the context of what I want to do, are "wrong"
>> results.  (I am presuming that this is probably because some name server
>> _other than_ one of the authoritative ones cached an answer and is helpfully
>> giving that to me, along with its own identity in the AUTHORITY section,
>> yes?  If I have misunderstood the situation entirely, then please do
>> straighten me out.)
>>
>> To get a list of the _actually authoritative_ name servers corresponding
>> to a given A or PTR record, I have also tried the approach of querying
>> first for some obscure type of record (e.g. MG and/or ISDN) that isn't
>> used a lot... and that thus is highly unlikely to be in anybody's cache...
>> and _then_ performing an ANY query for the FQDN or the ...in-addr.arpa
>> name, and _then_ looking at the AUTHORITY section of the response to that
>> second query, and this approach does seem to produce the true and correct
>> list of authoritative nameserver names that I want about 99.99% of the time.
>> But there are still rare occasional ``glitches'', i.e.  cases where the
>> AUTHORITY section of the response to the second query mentions one or more
>> of the *.gtld-servers.net nameservers (for FQDNs) or else where the AUTHORITY
>> section of the response to the second query mentions one or more of the
>> *.arin.net nameservers (for ...in-addr.arpa names) and these AUTHORITY RRs
>> are quite definitely NOT what I want, because they are _not_ telling me
>> names of any of the actually authoritative nameservers for the FQDNs or IP
>> addresses that I want information about.
>>
>> Footnote:
>>
>> Before anybody begins to beat me (verbally) about the head and neck for my
>> failure to adequately RTFM, let me just say that I _did_ try to read up on
>> topic of AUTHORITY sections (in RFC 1035) before posting here, but alas,
>> both RFC 1035 and Cricket Liu's book were rather entirely uninformative
>> about AUTHORITY sections generally, so I'm still ignorant about what these
>> sections are even _supposed_ to contain, even when everything is going right...
>> which, as we all know, on the Internet things don't always.
>>
>> Thanks in adance for any enlightenment/assistance.
>>
>>   
> I have recently been writing some code to cover this problem and I think 
> my approach works. But I do not claim it is the best and especially the 
> correct one.
> 
> What I do is query down from the root servers following the delegations 
> given by each server queried. By querying for the NS servers of the 
> target domain at each level in the hierarchy you eventually get a parent 
> response. The algorithm is applied recursively to find the parent's 
> parents by stripping one (or more) of the prefixes from the domain target.
> 
> As the algorithm only accepts non-recursive answers from delegated 
> parents the list of name servers retrieved are the only servers that can 
> be authoritative (rather than claim to be authoritative) The final step 
> is to query each of these name servers for their known name server list. 
> They SHOULD all respond authoritatively  with a list of name servers the 
> same as the parents if everything is set up right. If not the 
> intersection of what the parent delegates and what the zone servers that 
> responded authoritatively are the best you are going to do.
> 
> By using non-recursive lookups and crawling down the tree you SHOULD get 
> a valid answer. However, if you have a set of interceptors in the way 
> then the bets are off. Load balancers are an example that will defeat 
> this if they are in your path but not everybody elses.
> 
> Hope this makes sense (and is right!)
> 
> Howard

Since dig +trace already does this why bother to write your own unless 
you just want to do it for your own edification? I'm not sure what Load 
Balancers have to do with anything since only authorative servers will 
be used anyway if you are starting at the root.

Danny