res_findzonecut2() problem/question

[Mark Andrews]

> 
> 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_IPV4ON
> LY
> >,
> >>                         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".)

	They respond that 120.40.64.IN-ADDR.ARPA DOES NOT exist (NXDOMAIN)
	for NS queries but answer SOA queries for 120.40.64.IN-ADDR.ARPA.

	Additionally the SOA record that is returned in the NXDOMAIN
	response for 120.40.64.IN-ADDR.ARPA is 120.40.64.IN-ADDR.ARPA.

	The nameserver is seriously broken and is NOT following the
	DNS protocol.  res_findzonecut2, reasonably, expects remote
	servers to follow the DNS protocol.

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

	The zone which contains 120.40.64.in-addr.arpa is
	120.40.64.in-addr.arpa.

	If you want the parent zone you need to remove the left
	most label and try again.  That is start with 40.64.IN-ADDR.ARPA.

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

	You mimic what a recursive nameserver does and hope that
	whatever is broken doesn't effect you.  Once one of the
	parties stops following the protocol there are no rules to
	follow anymore.  If you don't see the breakage it won't
	bother you.

	"dig +trace -x 64.40.120.43 +all" will show you some of the
	queries and responses in a normal lookup.  A recursive
	nameserver will have performed address lookups and sanity
	checks on the responses.

	Normal PTR lookups for 43.120.40.64.in-addr.arpa don't see
	that the nameservers for 120.40.64.IN-ADDR.ARPA are broken
	when the NS records are queried for.
 
> 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.
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org