resolv.conf and first nameserver lookup failures
in [Linux Networking]
|
From: Alessandro on 28 Nov 2009 10:04 Hi list. Working on Kubuntu 9.10. I am actually connected at my home network (192.168.100.0/24) and I have two openvpn links to as many remote offices (192.168.50.0/24 and 192.168.7.0/24). My /etc/resolv.conf looks like this: # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 192.168.7.1 nameserver 192.168.50.6 nameserver 192.168.50.8 search domain1 domain2 /etc/nsswitch.conf looks like this: passwd: compat group: compat shadow: compat hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4 networks: files protocols: db files services: db files ethers: db files rpc: db files netgroup: nis The problem is that I cannot resolv any name belonging to domain2; it seems the resolver stops after any answer given by first nameserver in resolv.conf. This is not a routing problem because pinging IP addresses belonging to any domain works fine. If I try to nslookup a box belonging to domain1 everything works fine: $ nslookup box1 Server: 192.168.7.1 Address: 192.168.7.1#53 Name: box1.domain1 Address: 192.168.7.1 (BTW box1 is also the OpenVPN and BIND server for that branch office). If I try to do the same with any box in domain2 it always fails: $ nslookup box2.domain2 Server: 192.168.7.1 Address: 192.168.7.1#53 ** server can't find box2.domain2: NXDOMAIN If I nslookup to the second nameserver it works: $ nslookup box2.domain2 192.168.50.6 Server: 192.168.50.6 Address: 192.168.50.6#53 Name: box2.domain2 Address: 192.168.50.1 How can I tell the local resolver that it should move to the second nameserver if the first couldn't give an authoritative answer?
From: Moe Trin on 28 Nov 2009 14:08 On Sat, 28 Nov 2009, in the Usenet newsgroup comp.os.linux.networking, in article <bf7fd417-b219-4970-846d-20aa6766fb87(a)r24g2000yqd.googlegroups.com>, Alessandro wrote: NOTE: Posting from groups.google.com (or some web-forums) dramatically reduces the chance of your post being seen. Find a real news server. >I am actually connected at my home network (192.168.100.0/24) and I >have two openvpn links to as many remote offices (192.168.50.0/24 >and 192.168.7.0/24). My /etc/resolv.conf looks like this: >nameserver 192.168.7.1 >nameserver 192.168.50.6 >nameserver 192.168.50.8 >search domain1 domain2 OK >/etc/nsswitch.conf looks like this: OK >The problem is that I cannot resolv any name belonging to domain2; >it seems the resolver stops after any answer given by first >nameserver in resolv.conf. This is not a routing problem because >pinging IP addresses belonging to any domain works fine. Yup - working as designed. Your problem is that for efficiency, the resolver believes the first answer it gets. Were you to sniff the wire, you'd see your system ask DNS1 for an address/name for Domain2. Because Domain2 is not known to DNS1, it has no way to answer, so it MAY try to resolve the name on the Internet. When that fails, it replies "NXDOMAIN" and the game is over. The resolver _has_ an answer - the answer is that the name or address does not exist. Why should it ask anyone else? The normal solution is to fix the DNS - so that all name servers can provide an answer of some kind. If I understand you, you may be saying that DNS1 and DNS2 are in different branches of the same company. Perhaps you can convince the two administrators to (at the very least) provide "Glue" records - which allow DNS1 to tell clients that ask about the "other" domain to ask DNS2 and vice versa. Another solution would be to list only a local DNS, and have it provide Glue records to the separate domains. >How can I tell the local resolver that it should move to the second >nameserver if the first couldn't give an authoritative answer? The resolver wasn't designed with that idea. Old guy
From: Günther Schwarz on 28 Nov 2009 16:49 Moe Trin wrote: > On Sat, 28 Nov 2009, in the Usenet newsgroup comp.os.linux.networking, > in article > <bf7fd417-b219-4970-846d-20aa6766fb87(a)r24g2000yqd.googlegroups.com>, > Alessandro wrote: >>I am actually connected at my home network (192.168.100.0/24) and I have >>two openvpn links to as many remote offices (192.168.50.0/24 and >>192.168.7.0/24). My /etc/resolv.conf looks like this: >>The problem is that I cannot resolv any name belonging to domain2; it >>seems the resolver stops after any answer given by first nameserver in >>resolv.conf. This is not a routing problem because pinging IP addresses >>belonging to any domain works fine. > > Yup - working as designed. Your problem is that for efficiency, the > resolver believes the first answer it gets. > The normal solution is to fix the DNS - so that all name servers can > provide an answer of some kind. If I understand you, you may be saying > that DNS1 and DNS2 are in different branches of the same company. > Perhaps you can convince the two administrators to (at the very least) > provide "Glue" records - which allow DNS1 to tell clients that ask about > the "other" domain to ask DNS2 and vice versa. Another solution would > be to list only a local DNS, and have it provide Glue records to the > separate domains. Here the DNS admins simply put all host names on the "public" name servers. So also "local" host names with IPs as the ones above can be resolved from any servers. Reverse lookups fail outside the local net, of course. A quick and dirty fix for the problem might be to simply put the host names that are needed most often into /etc/hosts. I do not have much experience with bind: but won't defining DNS1 and DNS2 as forwarders in / etc/named.conf for a local name server fix the issue? Bind will ask the second one if the first one does not resolve, right? Günther
From: Chris Davies on 30 Nov 2009 16:31 > On Sat, 28 Nov 2009, in the Usenet newsgroup comp.os.linux.networking, in > article <bf7fd417-b219-4970-846d-20aa6766fb87(a)r24g2000yqd.googlegroups.com>, > Alessandro wrote: >>The problem is that I cannot resolv any name belonging to domain2; >>it seems the resolver stops after any answer given by first >>nameserver in resolv.conf. This is not a routing problem because >>pinging IP addresses belonging to any domain works fine. Moe Trin <ibuprofin(a)painkiller.example.tld> wrote: > Yup - working as designed. Your problem is that for efficiency, > the resolver believes the first answer it gets. [...] >>How can I tell the local resolver that it should move to the second >>nameserver if the first couldn't give an authoritative answer? > The resolver wasn't designed with that idea. The approach I've taken with my laptop may help you. (It sits comfortably within either one of two domains that internetwork but don't know about each other.) Basically, you have to run a DNS server on your local machine, which secondaries from the two domains in question. Your resolv.conf then only ever contains these two lines: nameserver 127.0.0.1 search domain.one domain.two If you use ISC DHCP (Debian's dhcp3* packages) you can fix up these values - overriding the values provided via DHCP - in its /etc/dhcp3/dhclient.conf file: supersede domain-name " domain.one domain.two"; supersede domain-name-servers 127.0.0.1; Chris
From: David W. Hodgins on 4 Dec 2009 13:33
On Fri, 04 Dec 2009 12:49:09 -0500, Alessandro <faglia(a)gmail.com> wrote: > So why do we have many NS in resolv.conf and why can we set many search > domains for the "search" option? See "man resolv.conf". When multiple name servers are listed in resolv.conf, the resolver trys them each, in the order listed (unless the option rotate is specified), until it finds one that doesn't timeout. Once a name server has been found, that doesn't timeout, the remaining name servers are not used. The name server that does respond, will use it's files to determine the ip address. If it doesn't have the info for the name, it will use the root servers to find the appropriate name server. It will not use other name servers listed in resolv.conf. The search option is only used to specify what to append to a name that doesn't have enough dots in it. Regards, Dave Hodgins -- Change nomail.afraid.org to ody.ca to reply by email. (nomail.afraid.org has been set up specifically for use in usenet. Feel free to use it yourself.) |