In message <[EMAIL PROTECTED]>, Mark Andrews <[EMAIL PROTECTED]> 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.
