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?

On Sat, 28 Nov 2009, in the Usenet newsgroup comp.os.linux.networking, in
article <bf7fd417-b219-4970-846d-20aa6766fb87@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

Moe Trin wrote:

> On Sat, 28 Nov 2009, in the Usenet newsgroup comp.os.linux.networking,
> in article
> <bf7fd417-b219-4970-846d-20aa6766fb87@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

On Nov 28, 7:04=A0am, Alessandro <fag...@gmail.com> wrote:

> $ nslookup box2.domain2
> Server: =A0 =A0 =A0 =A0 192.168.7.1
> Address: =A0 =A0 =A0 =A0192.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: =A0 =A0 =A0 =A0 192.168.50.6
> Address: =A0 =A0 =A0 =A0192.168.50.6#53
>
> Name: =A0 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?

How do you know the first couldn't give an authoritative answer? It
didn't fail, it returned 'NXDOMAIN'.

It looks like the resolver is doing the right thing. It tried the
first resolver first, and the first resolver told it "that domain
definitely does not exist". Now you claim the second nameserver would
have said it did exist. Well, one or the other must be wrong.

The resolver cannot work correctly if a nameserver that returns wrong
data is anywhere in its list of nameservers to try. And even if it did
try both and get two different answers, how would it know which one
was correct?

DS

> On Sat, 28 Nov 2009, in the Usenet newsgroup comp.os.linux.networking, in
> article <bf7fd417-b219-4970-846d-20aa6766fb87@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@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

-------- Original Message  --------
Subject: Re: resolv.conf and first nameserver lookup failures
From: David Schwartz <davids@webmaster.com>
To:
Date: Mon Nov 30 2009 04:51:37 GMT+0100 (ora Solare Europa Occidentale)

> On Nov 28, 7:04 am, Alessandro <fag...@gmail.com> wrote:
>  
> How do you know the first couldn't give an authoritative answer? It
> didn't fail, it returned 'NXDOMAIN'.
> 
> It looks like the resolver is doing the right thing. It tried the
> first resolver first, and the first resolver told it "that domain
> definitely does not exist". Now you claim the second nameserver would
> have said it did exist. Well, one or the other must be wrong.
> 
> The resolver cannot work correctly if a nameserver that returns wrong
> data is anywhere in its list of nameservers to try. And even if it did
> try both and get two different answers, how would it know which one
> was correct?
> 
> DS

Thanks for your answer. What is stunning me is that Windows XP resolver 
is working flawlessy, and even if I have several tunnels on it manages 
(I don't know how) to contact the right DNS server (the one belonging to 
the VPN subnet I am querying) and have the query resolved. Maybe I have 
to make some test with a sniffer to see what's going on, but I hardly 
believe that Windows is doing something smarter than the penguin.

AF

On Dec 4, 2:12=A0am, Alessandro <fag...@gmail.com> wrote:

> Thanks for your answer. What is stunning me is that Windows XP resolver
> is working flawlessy, and even if I have several tunnels on it manages
> (I don't know how) to contact the right DNS server (the one belonging to
> the VPN subnet I am querying) and have the query resolved. Maybe I have
> to make some test with a sniffer to see what's going on, but I hardly
> believe that Windows is doing something smarter than the penguin.

Linux is providing you an accurate view of the global DNS from the
server you asked it to provide you information from. Windows is not.

The 'nslookup' command is clearly documented to query Internet name
servers and tell you what they report. It would be horribly broken if
it did something other than that. (And we would just need some other
tool to do that.)

You don't say what your outer problem is. I'm pretty sure "nslookup is
working as advertised" is not it. But likely there's a simple
solution, probably involving changing 'nsswitch.conf' to make the
system use NMB or WINS after the hosts file but before the resolvers.

DS

David Schwartz ha scritto:
> On Nov 28, 7:04 am, Alessandro <fag...@gmail.com> wrote:
> 
>> $ 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?
> 
> How do you know the first couldn't give an authoritative answer? It
> didn't fail, it returned 'NXDOMAIN'.
> 
> It looks like the resolver is doing the right thing. It tried the
> first resolver first, and the first resolver told it "that domain
> definitely does not exist". Now you claim the second nameserver would
> have said it did exist. Well, one or the other must be wrong.

The fact is that the second nameserver is authoritative for "domain2" 
domain, so if the first nameserver is not authoritative (because it is 
asked for a box in domain2 and it does not know about that domain, ie is 
not authoritative) the query should be passed to the next NS. 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.

> 
> The resolver cannot work correctly if a nameserver that returns wrong
> data is anywhere in its list of nameservers to try. And even if it did
> try both and get two different answers, how would it know which one
> was correct?

So why do we have many NS in resolv.conf and why can we set many search 
domains for the "search" option?

Maybe I'm missing something...

AF

On Fri, 04 Dec 2009 12:49:09 -0500, Alessandro <faglia@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.)

Alessandro wrote:
> -------- Original Message  --------
> Subject: Re: resolv.conf and first nameserver lookup failures
> From: David Schwartz <davids@webmaster.com>
> To:
> Date: Mon Nov 30 2009 04:51:37 GMT+0100 (ora Solare Europa Occidentale)
> 
>> On Nov 28, 7:04 am, Alessandro <fag...@gmail.com> wrote:
>>  
>> How do you know the first couldn't give an authoritative answer? It
>> didn't fail, it returned 'NXDOMAIN'.
>>
>> It looks like the resolver is doing the right thing. It tried the
>> first resolver first, and the first resolver told it "that domain
>> definitely does not exist". Now you claim the second nameserver would
>> have said it did exist. Well, one or the other must be wrong.
>>
>> The resolver cannot work correctly if a nameserver that returns wrong
>> data is anywhere in its list of nameservers to try. And even if it did
>> try both and get two different answers, how would it know which one
>> was correct?
>>
>> DS
> 
> Thanks for your answer. What is stunning me is that Windows XP resolver 
> is working flawlessy, and even if I have several tunnels on it manages 
> (I don't know how) to contact the right DNS server (the one belonging to 
> the VPN subnet I am querying) and have the query resolved. Maybe I have 
> to make some test with a sniffer to see what's going on, but I hardly 
> believe that Windows is doing something smarter than the penguin.
> 
> AF

The Linux resolver is doing the "correct" job - it asks the first DNS 
server, and if that replies with NXDOMAIN then it is accepted.  For 
better or worse, that's the way DNS works.

On Windows, things are a little more complicated.  First off, SMB 
broadcasts and WINS are also used to look up names.  Windows also seems 
to track DNS settings for each interface individually, and it's possible 
that it will try the (primary) DNS servers for each interface if it is 
getting NXDOMAIN.  To my knowledge, this is contrary to the way DNS is 
supposed to work - but it suits your requirements well in this case.

I have almost the same problem as you - I want to use the dnsmasq 
DHCP/DNS server on my home network to resolve local names here, and I 
want to use the dnsmasq DHCP/DNS server on the office network to resolve 
office network names when I'm connected by OpenVPN.  On my windows 
machine, there is no problem - local names are found by SMB broadcast 
(the linux servers have samba), and office names are found by the office 
DNS server.  On my Linux machines, I've just used a hosts file - there 
are not that many machines to track.  But for a more complete solution, 
I'd use a local dnsmasq server and specify different DNS servers for 
different domains.

David Brown <david.brown@hesbynett.removethisbit.no> wrote:
> Windows also seems to track DNS settings for each interface
> individually, and it's possible that it will try the (primary) DNS
> servers for each interface if it is getting NXDOMAIN.

Empirically, I would tend to agree with you. I'm not sure about the
NXDOMAIN, though: I'm pretty sure that Windows uses a particular DNS
server for any given connection/domain.


> I'd use a local dnsmasq server and specify different DNS servers for 
> different domains.

This works really well.
Chris

On Fri, 04 Dec 2009, in the Usenet newsgroup comp.os.linux.networking, in
article <hfbi2m$i6d$1@nnrp.linuxfan.it>, Alessandro wrote:

>David Schwartz ha scritto:

>> It looks like the resolver is doing the right thing. It tried the
>> first resolver first, and the first resolver told it "that domain
>> definitely does not exist". Now you claim the second nameserver
>> would have said it did exist. Well, one or the other must be wrong.

>The fact is that the second nameserver is authoritative for "domain2"
>domain, so if the first nameserver is not authoritative (because it
>is asked for a box in domain2 and it does not know about that domain,
>ie is not authoritative) the query should be passed to the next NS.

Does your name server know all of the hostnames of all of the systems
on the Internet?   How then does it resolve the names?  The name
server has been configured to refer to (or ask directly) the name
server that is authoritative.  This is not the job of the resolver.

>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.   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.

>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.

        Old guy

Moe Trin <ibuprofin@painkiller.example.tld> wrote:
> 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.

The problem that the OP has described is a real world one, however. And
as has been pointed out there is no easy way for a Linux client to cope
with it.

Chris

Chris Davies wrote:

> Moe Trin <ibuprofin@painkiller.example.tld> wrote:
>> 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.
> 
> The problem that the OP has described is a real world one, however. And
> as has been pointed out there is no easy way for a Linux client to cope
> with it.

As other have said, dnsmasq can do that. I agree that it requires extra 
software and it's not something a linux client can do easily by default (or 
can do at all).

pk wrote:

> Chris Davies wrote:
> 
>> The problem that the OP has described is a real world one, however. And
>> as has been pointed out there is no easy way for a Linux client to cope
>> with it.
> 
> As other have said, dnsmasq can do that. I agree that it requires extra
> software and it's not something a linux client can do easily by default
> (or can do at all).

Ops, I hadn't seen your other reply, sorry.

On Sat, 05 Dec 2009, in the Usenet newsgroup comp.os.linux.networking, in
article <eo1ru6xagq.ln2@news.roaima.co.uk>, Chris Davies wrote:

>Moe Trin <ibuprofin@painkiller.example.tld> wrote:

>> 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.

>The problem that the OP has described is a real world one, however.

It's a problem for most *nix, and _can_ be a problem for windoze as
well.  That's the nature of the way DNS works. See RFC2308

  2308 Negative Caching of DNS Queries (DNS NCACHE). M. Andrews.
       March 1998. (Format: TXT=41428 bytes) (Updates RFC1034,
       RFC1035) (Updated by RFC4035, RFC4033, RFC4034) (Status:
       PROPOSED STANDARD)

which proposes a pseudo-answer "NODATA" (coded as "NOERROR" with
empty data fields) and RFC4074

  4074 Common Misbehavior Against DNS Queries for IPv6 Addresses.
       Y. Morishita, T. Jinmei. May 2005. (Format: TXT=13073 bytes)
       (Status: INFORMATIONAL)

which recommends that result to cure the hang when looking up IPv6
data on a server not configured for IPv6.

>And as has been pointed out there is no easy way for a Linux client
>to cope with it.

I don't believe it's the _clients_ job to cope with this.  We've got
the Multicast DNS (Apple's version of the security hole as provided
by the Avahi service adopted by many Linux distributions) which can
resolve local names IF the other hosts are also running that service,
as well as Samba resolving windoze names.  But for that matter, we
don't have a daemon to handle the intentionally incompatible microsoft
version of Multicast DNS

  4795 Link-local Multicast Name Resolution (LLMNR). B. Aboba, D.
       Thaler, L. Esibov. January 2007. (Format: TXT=71969 bytes)
       (Status: INFORMATIONAL)

The case in this thread is a mis-configured server, and the cure is to
either run a local name server (with glue records pointing at the name
servers for those other domains), or to fix the mis-configured servers
such that they have the appropriate glue records and can therefore
resolve the names through referral.

        Old guy

On Dec 4, 9:49=A0am, Alessandro <fag...@gmail.com> wrote:

> Bear in
> mind that "domain1" and "domain2" are local domains, for instance
> "mydomain1.loc" and "mydomain2.loc".

Wow, you are confused. Step back for a second.

Both "domain1" and "domain2" are subdomains of the "loc" domain. If
the first nameserver is not authoritative for "loc", why should we
trust its information about "domain1.loc" at all? And if the first
nameserver is authoritative for "loc", why shouldn't we trust it when
it tells us "domain2.loc" does not exist?

> > The resolver cannot work correctly if a nameserver that returns wrong
> > data is anywhere in its list of nameservers to try. And even if it did
> > try both and get two different answers, how would it know which one
> > was correct?

> So why do we have many NS in resolv.conf and why can we set many search
> domains for the "search" option?

For failover. And, for resolvers that can support, to select the
fastest nameserver.

> Maybe I'm missing something...

Yes, you're missing that the root domain (".") is just as much a
domain as any other domain.

DS

On Dec 5, 2:00=A0pm, Chris Davies <chris-use...@roaima.co.uk> wrote:

> The problem that the OP has described is a real world one, however. And
> as has been pointed out there is no easy way for a Linux client to cope
> with it.

The OP has not pointed out a problem. The "nslookup" command is
performing its documented function. If it did something else, we'd
just need a new command to do what "nslookup" does.

If he has some actual problem, he hasn't explained what it is. How is
this causing him a problem?

DS

Chris Davies wrote:
> David Brown <david.brown@hesbynett.removethisbit.no> wrote:
>> Windows also seems to track DNS settings for each interface
>> individually, and it's possible that it will try the (primary) DNS
>> servers for each interface if it is getting NXDOMAIN.
> 
> Empirically, I would tend to agree with you. I'm not sure about the
> NXDOMAIN, though: I'm pretty sure that Windows uses a particular DNS
> server for any given connection/domain.
> 

I'm not sure of the details of how Windows picks which DNS server to 
use, but that sounds likely to me.

> 
>> I'd use a local dnsmasq server and specify different DNS servers for 
>> different domains.
> 
> This works really well.
> Chris

David Schwartz <davids@webmaster.com> wrote:
> If he has some actual problem, he hasn't explained what it is. How is
> this causing him a problem?

It seems to me that it was well described in the OP's first post. (On
the other hand, it may be that I recognised it because I have a similar
problem.)

Let me try to restate it:

Consider two distinct but interconnected networks, both of which use DNS,
but neither of which provides that (internal) name service to the outside
world. This could be the case for a corporate network that wants its
external DNS to show publicly reachable systems, but does not want its
internals exposed for all to see.

Now further consider the situation where a user on one network uses VPN
to connect to services on the other network, and where the VPN client
is configured to route only necessary traffic across the VPN.

In order to obtain nameservice for nodes on the local network, the user
has to reference the local name servers. In order to obtain nameservice
for nodes on the remote network, this same user has to use the remote name
servers. (Remember, neither network provides full DNS to the Internet,
and by implication to each other, so there is no DNS referal process
available.)

Chris

On Dec 7, 2:33=A0pm, Chris Davies <chris-use...@roaima.co.uk> wrote:

> David Schwartz <dav...@webmaster.com> wrote:

> > If he has some actual problem, he hasn't explained what it is. How is
> > this causing him a problem?

> It seems to me that it was well described in the OP's first post. (On
> the other hand, it may be that I recognised it because I have a similar
> problem.)

It seemed to me that the OP's "problem" was that the "nslookup"
command was performing its intended function.

> Let me try to restate it:

> Consider two distinct but interconnected networks, both of which use DNS,
> but neither of which provides that (internal) name service to the outside
> world. This could be the case for a corporate network that wants its
> external DNS to show publicly reachable systems, but does not want its
> internals exposed for all to see.

> Now further consider the situation where a user on one network uses VPN
> to connect to services on the other network, and where the VPN client
> is configured to route only necessary traffic across the VPN.

> In order to obtain nameservice for nodes on the local network, the user
> has to reference the local name servers. In order to obtain nameservice
> for nodes on the remote network, this same user has to use the remote nam=
e
> servers. (Remember, neither network provides full DNS to the Internet,
> and by implication to each other, so there is no DNS referal process
> available.)

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.

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. 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.

This can be a huge pain. The alternative, of course, is flipping a
switch. (And not being on both networks at once.)

DS

David Schwartz <davids@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

On Dec 8, 2:12=A0pm, Chris Davies <chris-use...@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

David Schwartz wrote:

> On Dec 8, 2:12 pm, Chris Davies <chris-use...@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.

On Dec 8, 3:14=A0pm, pk <p...@pk.invalid> wrote:

> I think what he means is that network A is using, say *.netac for its hos=
ts,
> and network B is using, say, *.netb. =A0There'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 DN=
S
> listed first in resolv.conf, that will return NXDOMAIN and the DNS locate=
d
> 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 c=
an
> 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 na=
me
> 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

-------- Original Message  --------
Subject: Re: resolv.conf and first nameserver lookup failures
From: David Schwartz <davids@webmaster.com>
To:
Date: Sun Dec 06 2009 10:06:17 GMT+0100 (ora Solare Europa Occidentale)

> On Dec 4, 9:49 am, Alessandro <fag...@gmail.com> wrote:
> 
>> Bear in
>> mind that "domain1" and "domain2" are local domains, for instance
>> "mydomain1.loc" and "mydomain2.loc".
> 
> Wow, you are confused. Step back for a second.
> 
> Both "domain1" and "domain2" are subdomains of the "loc" domain. If
> the first nameserver is not authoritative for "loc", why should we
> trust its information about "domain1.loc" at all? And if the first
> nameserver is authoritative for "loc", why shouldn't we trust it when
> it tells us "domain2.loc" does not exist?

Err.. sorry, I made a mistake in my previous mail. I meant 
"mydomain1.loc1" and "mydomain2.loc2". Local domains are different for 
each site (ie branch office) I have. And for each local domain I have 
(on site) the authoritative NS, the one I'd like my resolver to contact 
for resolving names belonging to its domain.


--
AF

-------- Original Message  --------
Subject: Re: resolv.conf and first nameserver lookup failures
From: ibuprofin@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@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

On Dec 8, 11:58=A0pm, Alessandro <fag...@gmail.com> wrote:

> > Both "domain1" and "domain2" are subdomains of the "loc" domain. If
> > the first nameserver is not authoritative for "loc", why should we
> > trust its information about "domain1.loc" at all? And if the first
> > nameserver is authoritative for "loc", why shouldn't we trust it when
> > it tells us "domain2.loc" does not exist?

> Err.. sorry, I made a mistake in my previous mail. I meant
> "mydomain1.loc1" and "mydomain2.loc2". Local domains are different for
> each site (ie branch office) I have. And for each local domain I have
> (on site) the authoritative NS, the one I'd like my resolver to contact
> for resolving names belonging to its domain.

That doesn't change anything. You still have two different views of
the same domain, in this case ".". The root domain behaves more or
less like any other domain.

You must trust the first nameserver to tell you that 'loc1' is in the
root domain. So there is no reason not to trust it when it
definitively tells you that 'loc2' is not in the root domain.

There is no way to make this magically work. You have two different
network that have two different contents for the same domain. There is
no reason why we should trust the first nameserver when it tells us
'loc1' exists but not when it tells us 'loc2' does not except that
this is what you want. How can the computer know what you want if you
haven't told it?

DS

> 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.

But that overlap has an obvious resolution.  So while technically you
can view it as an overlap, it does not generate ambiguities.  So it
should be technically possible to provide both views at the same time
(e.g. by settgin up a local name-server that tries the two views and
returns whichever view doesn't return a failure).


        Stefan

On Dec 9, 7:51=A0am, Stefan Monnier <monn...@iro.umontreal.ca> wrote:

> > 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.

> But that overlap has an obvious resolution.

It has many obvious resolutions. But which is the right one? What if
the right view for this computer is that one of those domains should
not exist? There is simply no automated way to know -- it would have
to be manually configured. Unless you want a crap shoot.

>=A0So while technically you
> can view it as an overlap, it does not generate ambiguities. =A0So it
> should be technically possible to provide both views at the same time
> (e.g. by settgin up a local name-server that tries the two views and
> returns whichever view doesn't return a failure).

But neither returned a failure in this case. NXDOMAIN is not a
failure, it is a definitive success condition.

DS

On Wed, 09 Dec 2009, in the Usenet newsgroup comp.os.linux.networking, in
article <hfnnnn$brn$1@nnrp.linuxfan.it>, Alessandro wrote:

>ibuprofin@painkiller.example.tld (Moe Trin)

>> 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... ;)

Someone in another newsgroup has a .sig that fits that situation:

  "Some people are alive only because it is illegal to kill them."

I have seen some of the most bone-headed networking setups, and yet
the people who set them up can't see anything wrong other than the
fact that the networks don't work the way they imagine they should.
Really need to add more chlorine to the gene pool.   ;-)

>> 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.

It's a fairly common problem, especially with domains that have more
than one facility - perhaps even in different countries. Trying to
get all of the sub-domains to feed all of the latest changes to the
poor admin who's _trying_ to keep the main name server up to date is
a loosing battle. That's why child domains or sub-domains were created.

>I am reading "DNS and BIND 5th edition" by O'Reilly and probably my
>mind was absent when I was at page 211.

;-) That's a _great_ book, and probably has more appropriate details
than the ISC BIND manual.   My wife hates it when I get near a book
store that's selling O'Reilly books, because I _always_ find yet
another book I've got to have.

>Thanks for helping me in getting deeper sight of this awesome world.

Happy to be able to help!

        Old guy

>> > 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.
>> But that overlap has an obvious resolution.
> It has many obvious resolutions.

Only if you warp your mind.  If you're a normal user, there's only one.

>> �So while technically you can view it as an overlap, it does not
>> generate ambiguities. �So it should be technically possible to
>> provide both views at the same time (e.g. by settgin up a local
>> name-server that tries the two views and returns whichever view
>> doesn't return a failure).
> But neither returned a failure in this case.  NXDOMAIN is not a
> failure, it is a definitive success condition.

If you're a name-lookup-function, indeed.  If you're a normal user,
it's a failure (which normal users usually describe more precisely as
"my thing doesn't work").


        Stefan

On Dec 9, 1:28=A0pm, Stefan Monnier <monn...@iro.umontreal.ca> wrote:

> >> > But there is overlap. In that case, network A has one view of '.' an=
d
> >> > network B has another view of '.'. The root domain is just much a
> >> > domain as any other domain.

> >> But that overlap has an obvious resolution.
> > It has many obvious resolutions.

> Only if you warp your mind. =A0If you're a normal user, there's only one.

That's why normal users don't get to design networks. ;)

> >> =A0So while technically you can view it as an overlap, it does not
> >> generate ambiguities. =A0So it should be technically possible to
> >> provide both views at the same time (e.g. by settgin up a local
> >> name-server that tries the two views and returns whichever view
> >> doesn't return a failure).

> > But neither returned a failure in this case. =A0NXDOMAIN is not a
> > failure, it is a definitive success condition.

> If you're a name-lookup-function, indeed. =A0If you're a normal user,
> it's a failure (which normal users usually describe more precisely as
> "my thing doesn't work").

Right, but the point is that there's a good reason it doesn't work
that needs to be addressed in a non-trivial way. You either need to
flip a switch between networks or you need to design a consistent
"synthesis view" of the two networks and implement that view somehow.

There is no magic way to "just make it work" that won't break in
horrible ways in situations just slightly more complex than this one.

DS

-------- Original Message  --------
Subject: Re: resolv.conf and first nameserver lookup failures
From: ibuprofin@painkiller.example.tld (Moe Trin)
To:
Date: Wed Dec 09 2009 20:57:08 GMT+0100 (ora Solare Europa Occidentale)

> On Wed, 09 Dec 2009, in the Usenet newsgroup comp.os.linux.networking, in
> article <hfnnnn$brn$1@nnrp.linuxfan.it>, Alessandro wrote:
> 
>> ibuprofin@painkiller.example.tld (Moe Trin)
> 
> ;-) That's a _great_ book, and probably has more appropriate details
> than the ISC BIND manual.   My wife hates it when I get near a book
> store that's selling O'Reilly books, because I _always_ find yet
> another book I've got to have.

Ahah my wife too. The difference is that I buy them at Amazon. I think 
we are all in the same boat (as a saying in my country states).

--
AF

-------- Original Message  --------
Subject: Re: resolv.conf and first nameserver lookup failures
From: Alessandro <faglia@gmail.com>
To:
Date: Wed Dec 09 2009 09:39:19 GMT+0100 (ora Solare Europa Occidentale)

>> 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.
> 

I tried to employ glue records but BIND get angry with my zone data.

This the head of db.domain1.loc1 file (under /var/cache/bind):

$ORIGIN .
$TTL 86400      ; 1 day
domain1.loc1     IN SOA  box1.domain1.loc1. root.domain1.it. (
                                20081136   ; serial
                                28800      ; refresh (8 hours)
                                14400      ; retry (4 hours)
                                2419200    ; expire (4 weeks)
                                604800     ; minimum (1 week)
                                )
                        NS      box1.domain1.loc1.
                        MX      10 box1.domain1.loc1.
; glue records
domain2.loc2.           NS      box2.domain2.loc2.
box2.domain2.loc2.      A       192.168.50.6
$ORIGIN domain1.loc1.
box1			A	192.168.7.1
[remaining of the zone]


When I restart the service BIND says (in syslog):
ignoring out-of-zone data (domain2.loc2)
ignoring out-of-zone data (box2.domain2.loc2)

I fear that glue records cannot be employed if domain2.loc2 is not a
subdomain of domain1.loc1 for which I am defining glue record. Is this true?

--
AF

On Fri, 11 Dec 2009, in the Usenet newsgroup comp.os.linux.networking, in
article <hftq6a$uce$1@nnrp.linuxfan.it>, Alessandro wrote:

>>> 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.

>>>    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.

>I tried to employ glue records but BIND get angry with my zone data.

>$ORIGIN .
>$TTL 86400      ; 1 day
>domain1.loc1     IN SOA  box1.domain1.loc1. root.domain1.it. (

>                        NS      box1.domain1.loc1.

> glue records
>domain2.loc2.           NS      box2.domain2.loc2.
>box2.domain2.loc2.      A       192.168.50.6

Yes, there is some confusion here.  Last Saturday, you wrote:

>>Bear in mind that "domain1" and "domain2" are local domains, for
>>instance "mydomain1.loc" and "mydomain2.loc".

and I understood that meant that they were in a common domain 'loc'.
The idea is that you would run a local server authoritative for this
common domain - even if it doesn't answer for requests about that
domain to anyone because it has no hosts at that level.  It's merely
a place-holder holding the two sub-domains.  Your clients ask about
`host.domain1.loc`, and the name server sees that the request is not
for the 'loc' domain, but a sub-domain within that domain.

>When I restart the service BIND says (in syslog):
>ignoring out-of-zone data (domain2.loc2)
>ignoring out-of-zone data (box2.domain2.loc2)

Yes

>I fear that glue records cannot be employed if domain2.loc2 is not a
>subdomain of domain1.loc1 for which I am defining glue record. Is
>this true?

Yes - you have to be authoritative for the domain above both remotes.

        Old guy

David Brown wrote:
> Chris Davies wrote:
>> David Brown <david.brown@hesbynett.removethisbit.no> wrote:
>>> Windows also seems to track DNS settings for each interface
>>> individually, and it's possible that it will try the (primary) DNS
>>> servers for each interface if it is getting NXDOMAIN.
>>
>> Empirically, I would tend to agree with you. I'm not sure about the
>> NXDOMAIN, though: I'm pretty sure that Windows uses a particular DNS
>> server for any given connection/domain.
>>
> 
> I'm not sure of the details of how Windows picks which DNS server to
> use, but that sounds likely to me.

I tried to sniff packets on my windows box while connected to several
branches via OpenVPN and doing several pings to different hosts.

What I found is that windows's ping tries for every VPN interface (it's
a tap-like device for every connection I fire up) all DNS servers it can
(a kind of union of all DNS server you have from "ipconfig /all") and if
all this fails it tries WINS. The advantage over Linux (for what I can
understand) is that it seeks for an answer even if previous servers says
NXDOMAIN (as it happens by issueing nslookup).

I think now the picture is clearer in that Linux (as said before)
behaves "politely" but fails while windos plays dirty (by using WINS)
but manages to have an answer.

Thanks for all your input.

--
AF