resolv.conf and first nameserver lookup failures
in [Linux Networking]
|
From: Chris Davies on 8 Dec 2009 17:12 David Schwartz <davids(a)webmaster.com> wrote: > It seemed to me that the OP's "problem" was that the "nslookup" > command was performing its intended function. Unusually, I'm going to have to disagree with you here. The OP wrote (initially), |> The problem is that I cannot resolv any name belonging to domain2 [...] S/he then went on to suggest a number of reasons, which led to the (correct) technical statements about nslookup - and indeed the entire resolver subsystem - not working in the way that the OP wanted. David Schwartz continues: > Or, to put it more simply, the problem is that it's difficult for an > end station to be on two different networks at once because each > network has its own "view" and there is not always any good way to > synthesize those two views into one. In the general situation I'd agree with you on this point. But... > First, it should be fairly obvious that it's impossible to make this > "just work". If one network maps "foo.com" to 192.168.100.99 and the > other maps "foo.com" to 192.168.95.99, there is no automatic way to > know which is right. For the particular situations in which this kind of requirement often (usually? always??) exists, there is rarely a naming overlap with regard to forward DNS resolving. It's quite possible that there will be a numbering overlap (10.1.1.1 could easily exist in both networks), but the VPN configuration will determine which network "wins" for any routing requirement, and sadly rDNS appears to be a lost cause on many corporate networks. YMMV of course. > So the solution will have to involve creating a > new single network that contains the two (or more) networks you want > to compose. You have to set up your own name server (or comparable > service) that presents this integrated view to your computer. IMO this is pretty much want the OP wanted: for hosts in the domain(s) reachable via the VPN, use the nameservers presented via that connection; for hosts elsewhere use the original nameservers. Chris
From: David Schwartz on 8 Dec 2009 18:07 On Dec 8, 2:12 pm, Chris Davies <chris-use...(a)roaima.co.uk> wrote: > > First, it should be fairly obvious that it's impossible to make this > > "just work". If one network maps "foo.com" to 192.168.100.99 and the > > other maps "foo.com" to 192.168.95.99, there is no automatic way to > > know which is right. > For the particular situations in which this kind of requirement often > (usually? always??) exists, there is rarely a naming overlap with > regard to forward DNS resolving. But that's precisely what bit the OP. There was a naming overlap. Had there been no naming overlap, the OP would have had no problem. Perhaps you're missing that "foo.com" on network A and "bar.com" on network B *do* overlap. Each network has a different view of the "com" TLD, and the OP's computer has no way to know which he wants and no source from some third mapping. DS
From: pk on 8 Dec 2009 18:14 David Schwartz wrote: > On Dec 8, 2:12 pm, Chris Davies <chris-use...(a)roaima.co.uk> wrote: > >> > First, it should be fairly obvious that it's impossible to make this >> > "just work". If one network maps "foo.com" to 192.168.100.99 and the >> > other maps "foo.com" to 192.168.95.99, there is no automatic way to >> > know which is right. > >> For the particular situations in which this kind of requirement often >> (usually? always??) exists, there is rarely a naming overlap with >> regard to forward DNS resolving. > > But that's precisely what bit the OP. There was a naming overlap. Had > there been no naming overlap, the OP would have had no problem. > Perhaps you're missing that "foo.com" on network A and "bar.com" on > network B *do* overlap. Each network has a different view of the "com" > TLD, and the OP's computer has no way to know which he wants and no > source from some third mapping. I think what he means is that network A is using, say *.netac for its hosts, and network B is using, say, *.netb. There's no overlap. (sometimes suffixes like .internal, .local or similar are used, but this does not change the concepts). Since those are private domains, the respective DNS servers cannot be reached via referrals. As I understand it, the OP is on a host that is connected to both networks, and has network A's and network B's DNS servers in its resolv.conf (in some order). When it wants to resolve, for example, foo.netb, if it has network A's DNS listed first in resolv.conf, that will return NXDOMAIN and the DNS located in network B will not be queried, resulting in the host being unable to resolve names in network B (the dual if the order of the DNS servers in resolv.conf is the opposite). What could work is some intermediate software layer (like dnsmasq) that can peek into the queries and direct them to the DNS server that knows how to answer them; in the above example, it will see that the query is for a name ending in .netb, so it will send it to the DNS server located in network B, and the same for network A.
From: David Schwartz on 8 Dec 2009 20:49 On Dec 8, 3:14 pm, pk <p...(a)pk.invalid> wrote: > I think what he means is that network A is using, say *.netac for its hosts, > and network B is using, say, *.netb. There's no overlap. (sometimes > suffixes like .internal, .local or similar are used, but this does not > change the concepts). But there is overlap. In that case, network A has one view of '.' and network B has another view of '.'. The root domain is just much a domain as any other domain. > When it wants to resolve, for example, foo.netb, if it has network A's DNS > listed first in resolv.conf, that will return NXDOMAIN and the DNS located > in network B will not be queried, resulting in the host being unable to > resolve names in network B (the dual if the order of the DNS servers in > resolv.conf is the opposite). Exactly, because these two networks have a naming overlap. One has a '.' with 'netb' in it and one does not. This is two different views of the same domain with no way to tell which is right and which is wrong. It can't possibly "just work". > What could work is some intermediate software layer (like dnsmasq) that can > peek into the queries and direct them to the DNS server that knows how to > answer them; in the above example, it will see that the query is for a name > ending in .netb, so it will send it to the DNS server located in network B, > and the same for network A. That's one of the ways to do it. Which way is best depends upon the circumstances. If there are a lot of computers in the same location with this same issue, IMO, the best way to do it is to run one or two nameserver somewhere that present the desired view of the "fused networks" to those computers. This way, the configuration can be centrally managed. If it's just one computer, it may be difficult to justify the trouble. DS
From: Alessandro on 9 Dec 2009 03:39
-------- Original Message -------- Subject: Re: resolv.conf and first nameserver lookup failures From: ibuprofin(a)painkiller.example.tld (Moe Trin) To: Date: Sat Dec 05 2009 21:17:24 GMT+0100 (ora Solare Europa Occidentale) > On Fri, 04 Dec 2009, in the Usenet newsgroup comp.os.linux.networking, in > article <hfbi2m$i6d$1(a)nnrp.linuxfan.it>, Alessandro wrote: > >[...] > >> Bear in mind that "domain1" and "domain2" are local domains, for >> instance "mydomain1.loc" and "mydomain2.loc". And provided that in >> all domains I have DHCP+DNS working together (so to have DDNS) >> there is no way to add glue records to the first NS, unless I use >> some weird tricks. > > No - you don't understand what glue records are. Glue records are > pointers to the IP of the name server that is authoritative for a > range. If your name servers have dynamic IP addresses and like to > hide from everyone, the idiot who set up the networks needs to be > shot. Repeatedly. Uhuh I feel sick... ;) The glue records tell the name server to ask > a different (authoritative) name server for answer, so that it > can respond to the resolver making the original query. It's not the > job of the resolver to figure out which name server to ask or to > ask every name server it can find. You are right, I didn't understand this concept. I'll have a deeper look to this concept. I am reading "DNS and BIND 5th edition" by O'Reilly and probably my mind was absent when I was at page 211. > >> So why do we have many NS in resolv.conf and why can we set many >> search domains for the "search" option? > > You need to study the man page for resolver (man 5 resolver). Unless > you have tweaked /usr/include/resolv.h, you are limited to three > nameserver declarations. You also want to read the description of > the 'search' (and 'domain') keywords in that page. They are used to > help determine _what_ names to ask for, not _who_ to ask. For sure I'll follow your advice. Thanks for helping me in getting deeper sight of this awesome world. Sincerely. -- AF |