Primary cannot dig

Kevin Darcy kcd at daimlerchrysler.com
Wed Sep 28 23:20:51 UTC 2005


Gregory W Zill wrote:

>My secondary DNS host can easily resolve any domains, those hosted or 
>those external. However the primary DNS host cannot. I have come to 
>require this information for some query_log reporting whcih I am 
>currently analyzing. All of the query source address could be resolved 
>if only the primary could do it during the repoprt run. Any pointers 
>would really be appreciated.
>  
>
Well, you have given us absolutely nothing to work with here other than 
the labels "secondary DNS" and "primary DNS". Is this Internet DNS, or 
some internal-root namespace of your own? Are you querying authoritative 
data, or does the server in question need to recurse to get the answer, 
and, if it does, does it recurse based on the referral information it 
builds up using a hints zone a starting point, based on the contents of 
a stub zone, based on forwarding, or some combination of the above?

One thing to consider while you're gathering that background information 
is that any process which attempts to resolve many DNS names (reverse 
lookups also count as name lookups), where the input data is likely to 
have many duplicate instances, should, for efficiency reasons, have some 
sort of caching built into it, so that it doesn't beat up the local 
nameserver with redundant queries. In Perl, with the Net::DNS module, 
for instance, I often have some code like:

sub get_addr {
        ($target) = @_;

        return($name_cache{$target}) if (exists($name_cache{$target}));

        ($query = $res->query($target)) ||
                die "query for $target failed: " . $res->errorstring;
        $rr = ($query->answer)[-1];
        ($rr->type eq "A") ||
                die "query for $target yielded no address record!";
        $name_cache{$target} = $rr->rdatastr;
        return($rr->rdatastr);
}

If you're dealing with a *huge* number of names, you may want a more 
sophisticated approach to limit your memory consumption...

                                                                         
                                             - Kevin





More information about the bind-users mailing list