In message <>,
Mark Andrews wrote:

>> > The nameservers for 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
>> (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 +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 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.