Prev: setting up multi uplink net
Next: News server "goes away"
From: Moe Trin on 5 Dec 2009 21:03
On Sat, 05 Dec 2009, in the Usenet newsgroup comp.os.linux.networking, in
article <eo1ru6xagq.ln2(a)news.roaima.co.uk>, Chris Davies wrote:

>Moe Trin <ibuprofin(a)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
From: David Schwartz on 6 Dec 2009 04:07
On Dec 5, 2:00 pm, Chris Davies <chris-use...(a)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
From: David Brown on 6 Dec 2009 04:57
Chris Davies wrote:
> David Brown <david.brown(a)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
From: Chris Davies on 7 Dec 2009 17:33
David Schwartz <davids(a)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
From: David Schwartz on 8 Dec 2009 10:21
On Dec 7, 2:33 pm, Chris Davies <chris-use...(a)roaima.co.uk> wrote:

> David Schwartz <dav...(a)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 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.)

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
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6
Prev: setting up multi uplink net
Next: News server "goes away"