In message <200808230233.m7N2X0Ax012840@drugs.dv.isc.org>,
Mark Andrews 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.