res_findzonecut2() problem/question

Ronald F. Guilmette rfg at tristatelogic.com
Fri Aug 22 20:51:56 UTC 2008


In message <200808221433.m7MEX7Rb006711 at drugs.dv.isc.org>, 
Mark Andrews <Mark_Andrews at isc.org> wrote:

>rfg:
>> 
>> I'm calling res_findzonecut2() in the following way:
>> 
>>    r = resfindzonecut2 (res, "120.40.64.in-addr.arpa", ns_c_in, RES_IPV4ONLY
>,
>>                         zone_name, zone_size, NULL, 0);
>> 
>> I just want to get the name of the zone that "120.40.64.in-addr.arpa" is
>> part of.
>> 
>> Unfortunately, the above call returns -1 and errno is set to EPROTOTYPE
>> (Protocol wrong type for socket).  I have no understanding of this error
>> or how to work around it.  Can anyone explain to me why the error is
>> occuring and what I need to do in order to find the containing zone for
>> "120.40.64.in-addr.arpa" ?

>	The nameservers for 120.40.64.in-addr.arpa are broken.

Could you elaborate please?  In what sense exactly are they broken?
(I am always eager to learn more about how DNS works, "under the hood".)

>	res_findzonecut2() detects that brokenness and aborts.

That's good, I guess, but it leaves me still needing a work around for
the problem I was trying to solve.

Here's the _actual_ problem I'm trying to solve in a nutshell:

Given some arbitrary IP address... let's take 64.40.120.43 just as an
example... I need to create a function that will provide me with the
names of all of the name servers that could provide (or that do provide)
reverse DNS for that specific IP address.  (Note that that specific IP
address _does_ have reverse DNS established for it, and the correct
answer to the question "Which name servers are providing that?" would
appear to be "ns1.netnation.com" and "ns2.netnation.com".  Those are
the answers I need to get at.)

I've tried to implement this functionality via judicious use of the
res_findzonecut2() function.  I basically start out calling that library
function on/for the full name, i.e. "43.120.40.64.in-addr.arpa".  That
initial call provides me with the name of the zone in which that full
name resides, i.e. "120.40.64.in-addr.arpa".  That is the containing
zone.  So now, to get the names of the name servers for this zone,
I simply call res_query on "120.40.64.in-addr.arpa" with the query type
set to NS.  Logically now, this _should_ yield back to me the names
"ns1.netnation.com" and "ns2.netnation.com", but instead I get only
NXDOMAIN and no actual answers... probably because, as you said, these
folks have their name server configuration screwed up.

But I am trying hard to work around even other people's screw ups.  So
I switch to plan B, because I'm still attempting to get those two names
of the two name servers that _are_ quite clearly serving up the rDNS for
64.40.120.43.  So I back up one level and now try calling res_findzonecut2()
on the zone WHICH CONTAINS the "120.40.64.in-addr.arpa" zone, in the hopes
of getting a list of name servers for that, which I could then query and
ask _them_ what name servers they know about and that they think are
associated with the "120.40.64.in-addr.arpa" zone.  But then bang!  I run
into this very inexplicable EPROTOTYPE error, which still doesn't make a lot
of sense to me, even though I can tell it is, as you said, almost certainly
due to brokenness out somewhere in the general vicinity of netnation.com.
But knowing that still doesn't help me to get to my goal.  My goal, again,
is to get the names of name servers that are currently serving up the rDNS
for _any_ arbitrary IPv4 address... even a goofy/botched one like 64.40.120.43.

Can you tell me how to do that?  Can you tell me how to do that even for
64.40.120.43?  (Remember, it quite clearly _does_ have rDNS, and so
_some_ name server(s) is/are providing that  And those name servers _do_
have names.  I just need to get their names, even regardless of the
brokenness in the DNS setup out on somebody else's network.)

Rule:  If it has rDNS, then _some_ name server _is_ providing that.  I just
need to get the name(s) of those, even when something about the DNS setup,
when considered as a whole, isn't 100% kosher.


More information about the bind-users mailing list