On 13/08/2013 08:31, gevisz wrote: > 2013/8/12 Alan McKinnon <alan.mckin...@gmail.com>: >> On 12/08/2013 09:13, gevisz wrote: >>> The response of the first router contained an error that prevented all the >>> other applications to use it, the system knew about it (for example from >>> the output of the host utility) but, nevertheless did not proceeded with >>> the next router listed in resolv.conf. >>> >>> I do undersand that this may be because of the layered structure of the >>> networked software. But, nevertheless, I think that something is >>> fundamentally >>> wrong with this. >> >> What kind of error did you get? > > As I have already wrote it earlier, with three different DNS in > /etc/resolv.conf and /etc/conf.d/net files, the host utility correctly > reported IP address of a site (eg, www.google.com) but added > the following message: > ;; Warning: query response not set > > With only the first (my local DNS) in /etc/resolv.conf and > /etc/conf.d/net files, > the output of the host utility was as follows: > > # host www.google.com > www.google.com has address 74.125.232.52 > www.google.com has address 74.125.232.48 > www.google.com has address 74.125.232.49 > www.google.com has address 74.125.232.50 > www.google.com has address 74.125.232.51 > ;; Warning: query response not set > ;; Warning: query response not set > Host www.google.com not found: 4(NOTIMP) > > In both cases above no internet application (eg, links or firefox) > could convert site names to IP adresses and only after deleting > the first (local) DNS from /etc/resolv.conf and /etc/conf.d/net files, > internet applications started to work as expected (and the host > utility, in this case, returned no error or warning message) > > That have proved to myself that > > "The response of the first router contained an error > that prevented all the other applications to use it, > the system knew about it (for example from > the output of the host utility) but, nevertheless, > did not proceeded with the next router listed in > resolv.conf [or /etc/conf.d/net]. > I do undersand that this may be because of > the layered structure of the networked software. > But, nevertheless, I think that something is fundamentally > wrong with this."
the host command is not your local resolver in libc, you cannot take the output of host and conclude anything about your resolver, as they operate in fundamentally different ways with entirely different purposes. Your DNS setup is doing exactly what it is supposed to do - the first cache returned an error and your local resolver concludes the query cannot be resolved, so stops trying. Solution: upgrade your router's firmware. It looks like it's bust. > >> If complete garbage came back, I'm not sure what the resolver does with >> that (oddly enough, I never tested that) >> >> The more usual case is you get a proper DNS result of NXDOMAIN which >> indicates the query is valid, but the entry is not in DNS. It's >> pointless trying another cache as per DNS, they should all then return >> that result. >> >> This is why the router did not try the other entries in resolv.conf - >> that usually only happens when a cache does not respond. So the >> behaviour you saw is probably correct albeit not the behaviour you wanted. >> >> >> -- >> Alan McKinnon >> alan.mckin...@gmail.com >> >> > -- Alan McKinnon alan.mckin...@gmail.com
