Date: Wed, 13 Feb 2008 11:23:50 -0800 From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <Jinmei_Tatuya@isc.org> To: d@delphij.net Cc: freebsd-net@freebsd.org, ume@FreeBSD.org Subject: Re: Strange resolver behavior Message-ID: <m2ejbgy81l.wl%Jinmei_Tatuya@isc.org> In-Reply-To: <47B2488D.70707@delphij.net> <47B2591D.4000703@delphij.net> References: <47B2488D.70707@delphij.net>
next in thread | previous in thread | raw e-mail | index | archive | help
At Tue, 12 Feb 2008 17:31:57 -0800, Xin LI <delphij@delphij.net> wrote: > It looks like that certain (mis)configuration by the baidu.com DNS > administrators has caused this, but I have no clue why our resolver > would return NXDOMAIN after it gets a positive response? (Yes, I know > that _ is not appropriate for domain names :) (I've read the entire thread, but since there still seems to be some confusion, so I'm responding to the very original post of the thread). This problem is not related to the "_". The fundamental problem is, as Edwin already pointed out, (one of) the authoritative server(s) of the shifen.com zone returns NOTIMP for MX of ps_other.a.shifen.com (this is a non-compliant behavior; see RFC4074 - though the main focus of this RFC is AAAA, not MX). So, what should have happened is: > > Received 127 bytes from 127.0.0.1#53 in 0 ms > [delphij@charlie] ~> host ps_other.a.shifen.com > ps_other.a.shifen.com has address 202.108.22.46 So far, fine. > Host ps_other.a.shifen.com not found: 3(NXDOMAIN) At this point host first queried for MX of ps_other.a.shifen.com. This failed with NOTIMP or SERVFAIL (the latter would be returned from a caching server). If your /etc/resolv.conf contains a "domain" or "search" directive (which I guess is the case), (recent versions of) host then tried the same query using the specified domain name(s), e.g., ps_other.a.shifen.com.isc.org. This normally resulted in an NXDOMAIN error, which you saw as the final output. You should be able to see this process by "host -v dict.baidu.com". It should also be noted that this is irrelevant to the "resolver" implementation in libc. The host command uses its own parser of /etc/resolv.conf and resolution routine and doesn't rely on the libc version of resolver. Finally, one thing I still don't understand is this symptom: > Em... That's fine I think, it does not seem to be the MX to cause the > problem, though. I have tried to visit 'dict.baidu.com' in Firefox and > it told me that the name can not resolve. tcpdump indicates that the > server has respond the A RR but resolver still queries AAAA... As far as I can see, there's no problem in resolving AAAA (although the response is negative) unlike the MX case. Can you show the exact output of tcpdump? --- JINMEI, Tatuya Internet Systems Consortium, Inc.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m2ejbgy81l.wl%Jinmei_Tatuya>