Re: res_findzonecut2() problem/question
In message <200808230233.m7N2X0Ax012840@drugs.dv.isc.org>,
Mark Andrews <Mark_Andrews@isc.org> wrote:
>> > The nameservers for 120.40.64.in-addr.arpa are broken.[/color]
>> 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".)[/color]
> 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.[/color]
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.[/color]
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.[/color]
Seems eminently reasonable.
>> Can you tell me how to do that? Can you tell me how to do that even for
>> 188.8.131.52? (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.)[/color]
> 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 184.108.40.206 +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 220.127.116.11.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.[/color]
OK. I think I understand now. Thank you. Really.