res_findzonecut2() problem/question

[Ronald F. Guilmette]

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

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

Yup.  Even a neophyte like me knows that *that* is definitely fubar.

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

Ditto.  Unquestionably fubar.

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

Seems eminently reasonable.

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

OK.  I think I understand now.  Thank you.  Really.