Only some IPs accessable?

"Chris Davies" <chris-(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>>> 3. Has your /etc/resolv.conf been updated with these DNS servers?
>
> NoHtmlMailsPlease <(E-Mail Removed)> wrote:
>> -> cat /etc/ppp/resolv.conf ==
>> nameserver 41.160.0.36
>> nameserver 41.164.0.11
>> ====> these are dynamically provided by this new/ISP2
>
> But what about /etc/resolv.conf (not /etc/ppp/resolv.conf)? It's *this*
> file that gets used by the system for name resolution.
>
> The /etc/ppp/resolv.conf file contains the values derived via ppp, which
> may or may not be relevant. So it's optional whether they get installed
> into the true resolv.conf. In my distro (Debian, not Slackware TBH),
> the ppp "up" script installs /etc/ppp/resolv.conf into /etc/resolv.conf.

Here:Slak13 `ls /etc/res* -l`
shows 3 OLD files. /etc/resolv.conf == 2 lines copied manually now
search neotel.co.za
nameserver 207.132.16.5

and /etc/ppp/resolv.conf is new/NOW with the DNSs of this problematic ISP.

>
> It may be that this scripting is broken or doesn't exist, or perhaps
> you could get away with a simple "ln -fs /etc/ppp/resolv.conf
> /etc/resolv.conf".
>
WOW!! Linking /etc/resolv.conf to /etc/ppp/resolv.conf
does it !!

Thanks man.
I've just fetched my email, which needed Slak's X.
I had been tearing my guts out trying to get it via
`chroot <the old proven installations>` via telnet.

I suspect that I skipped the <config inet/ppp step> during installing
Slak, because it seemed unlikely that ANY linux would connect to the
fixed-wireless-telephone's wireless, which is only specified to work with
Win. Since it uses the zeroCD method, whereby the PC's USB initially see
a simulated CD, which it downloads and runs to drive the modem;
the modem and driver could be a completely secret standard.
Ie. since the modem tells the Win-PC how to dance, it could be an
unknown protocol.

The wireless modem only connects to linux after it's been 'primed' by Win7.
The normal zeroCD protocol, is that the PC sends some byte/s to the
device, to make it switch over from a CD to a modem, once the PC has
d/l-ed the driver-software from the simulated CD.

Having climbed this big mountain with your help, I now need a rest,
and then I'd like to understand how/why/where linux puts the DNS-IPs
given by the ISP, and how they are then used.

Thanks,

== Chris Glur.

> Chris

PS. we note that I got no help from Slak-boys.

"NoHtmlMailsPlease" <(E-Mail Removed)> wrote:
> and then I'd like to understand how/why/where linux puts the DNS-IPs
> given by the ISP, and how they are then used.

The answer is really simple. The DNS servers used are those listed in
/etc/resolv.conf

How they are used might be a little bit more complicated. Having more than
one DNS server listed in /etc/resolv.conf might be good for redundancy,
but it might also slow things down. For some reason it seems as if the
system waits for all servers to answer even if the first server gives a
correct answer.

regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc123(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost

Henrik Carlqvist <(E-Mail Removed)> wrote:
>"NoHtmlMailsPlease" <(E-Mail Removed)> wrote:
>> and then I'd like to understand how/why/where linux puts the DNS-IPs
>> given by the ISP, and how they are then used.
>
>The answer is really simple. The DNS servers used are those listed in
>/etc/resolv.conf
>
>How they are used might be a little bit more complicated. Having more than
>one DNS server listed in /etc/resolv.conf might be good for redundancy,
>but it might also slow things down. For some reason it seems as if the
>system waits for all servers to answer even if the first server gives a
>correct answer.

That should not happen. This quote is from the
RESOLV.CONF(5) man page:

"On a normally configured system this file should not
be necessary. The only name server to be queried will
be on the local machine; the domain name is determined
from the hostname and the domain search path is
constructed from the domain name.

The different configuration options are:

nameserver Name server IP address
Internet address (in dot notation) of a name server
that the resolver should query. Up to MAXNS
(currently 3, see <resolv.h>) name servers may be
listed, one per keyword. If there are multiple
servers, the resolver library queries them in the
order listed. If no nameserver entries are
present, the default is to use the name server on
the local machine. (The algorithm used is to try a
name server, and if the query times out, try the
next, until out of name servers, then repeat trying
all the name servers until a maximum number of
retries are made.)"

The gist is that there is no point in listing more than
3 name servers. But in any event the first one is the
only one that will ever be queried if the first query is
successful, which also assumes that either there is no
local DNS server or that it has failed.

The reason for more than one server to be listed is so
that a single server need not have 100% availability for
DNS to be 100% available.

--
Floyd L. Davidson <http://www.apaflo.com/>
Ukpeagvik (Barrow, Alaska) (E-Mail Removed)

["Followup-To:" header set to comp.os.linux.networking.]
On Sat, 2011-10-15, Floyd L. Davidson wrote:
> Henrik Carlqvist <(E-Mail Removed)> wrote:
>>"NoHtmlMailsPlease" <(E-Mail Removed)> wrote:
>>> and then I'd like to understand how/why/where linux puts the DNS-IPs
>>> given by the ISP, and how they are then used.
>>
>>The answer is really simple. The DNS servers used are those listed in
>>/etc/resolv.conf
>>
>>How they are used might be a little bit more complicated. Having more than
>>one DNS server listed in /etc/resolv.conf might be good for redundancy,
>>but it might also slow things down. For some reason it seems as if the
>>system waits for all servers to answer even if the first server gives a
>>correct answer.
>
> That should not happen. This quote is from the
> RESOLV.CONF(5) man page:
....
> The gist is that there is no point in listing more than
> 3 name servers. But in any event the first one is the
> only one that will ever be queried if the first query is
> successful,

Where "successful" includes "you got a response, and it said there is
no such name in DNS".

> which also assumes that either there is no
> local DNS server or that it has failed.

What do you mean here? As far as I can tell, resolv.conf is used even
if there is a local name server running.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

Jorgen Grahn <grahn+(E-Mail Removed)> wrote:
>On Sat, 2011-10-15, Floyd L. Davidson wrote:
>>
>> That should not happen. This quote is from the
>> RESOLV.CONF(5) man page:
>...
>> The gist is that there is no point in listing more than
>> 3 name servers. But in any event the first one is the
>> only one that will ever be queried if the first query is
>> successful,
>
>Where "successful" includes "you got a response, and it said there is
>no such name in DNS".
>
>> which also assumes that either there is no
>> local DNS server or that it has failed.
>
>What do you mean here? As far as I can tell, resolv.conf is used even
>if there is a local name server running.

From the text of the man page as quoted in my previous article:

"On a normally configured system this file should not
be necessary. The only name server to be queried will
be on the local machine; [...]"

--
Floyd L. Davidson <http://www.apaflo.com/>
Ukpeagvik (Barrow, Alaska) (E-Mail Removed)

["Followup-To:" header set to comp.os.linux.networking.]
On Sat, 2011-10-15, Floyd L. Davidson wrote:
> Jorgen Grahn <grahn+(E-Mail Removed)> wrote:
>>On Sat, 2011-10-15, Floyd L. Davidson wrote:
>>>
>>> That should not happen. This quote is from the
>>> RESOLV.CONF(5) man page:
>>...
>>> The gist is that there is no point in listing more than
>>> 3 name servers. But in any event the first one is the
>>> only one that will ever be queried if the first query is
>>> successful,
>>
>>Where "successful" includes "you got a response, and it said there is
>>no such name in DNS".
>>
>>> which also assumes that either there is no
>>> local DNS server or that it has failed.
>>
>>What do you mean here? As far as I can tell, resolv.conf is used even
>>if there is a local name server running.
>
> From the text of the man page as quoted in my previous article:
>
> "On a normally configured system this file should not
> be necessary. The only name server to be queried will
> be on the local machine; [...]"

Yes, but that only means localhost is queried if the file doesn't exist,
not that the file is ignored if there's a nameserver on localhost.
Do you agree?

(I didn't know about that sane default, so I have a local DNS and a
resolv.conf which points to localhost.)

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

(E-Mail Removed) (Floyd L. Davidson) wrote:

> Henrik Carlqvist <(E-Mail Removed)> wrote:
>> For some reason it seems as if the system waits for all servers to
>> answer even if the first server gives a correct answer.

> But in any event the first one is the only one that will ever be queried
> if the first query is successful,

Thats what one might expect, but I have seen examples of when queries go
to all servers listed even though the first one gives a correct answer and
I have seen this slow down DNS queries when some DNS server is down even
if the first server is up.

It did come as a surpries to me when running strace to see that all
servers were queried even though the first server gave the right answer.

Now, when trying to recreate that I only got partial success. I have no
DNS server running on localhost:

-8<---------------------
bash-3.1# cat /etc/resolv.conf
# Generated by dhcpcd for interface wlan0
search Belkin
nameserver 192.168.30.254

bash-3.1# dig www.google.com @192.168.30.254

; <<>> DiG 9.4-ESV-R4-P1 <<>> www.google.com @192.168.30.254
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16474
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;www.google.com. IN A

;; ANSWER SECTION:
www.google.com. 86400 IN A 209.85.169.105

;; Query time: 98 msec
;; SERVER: 192.168.30.254#53(192.168.30.254)
;; WHEN: Sat Oct 15 19:39:55 2011
;; MSG SIZE rcvd: 48

bash-3.1# dig www.google.com @127.0.0.1

; <<>> DiG 9.4-ESV-R4-P1 <<>> www.google.com @127.0.0.1
;; global options: printcmd
;; connection timed out; no servers could be reached

bash-3.1# time nslookup www.google.com
Server: 192.168.30.254
Address: 192.168.30.254#53

Name: www.google.com
Address: 209.85.169.105


real 0m0.104s
user 0m0.004s
sys 0m0.004s
bash-3.1# emacs -nw /etc/resolv.conf
bash-3.1# cat /etc/resolv.conf
# Generated by dhcpcd for interface wlan0
search Belkin
nameserver 192.168.30.254
nameserver 127.0.0.1


bash-3.1# time nslookup www.google.com
;; Got recursion not available from 192.168.30.254, trying next server
;; connection timed out; no servers could be reached


real 0m15.113s
user 0m0.004s
sys 0m0.000s
-8<---------------------

In the example above "nslookup www.google.com" takes 0.1s with a single
working nameserver in resolv.conf. Adding a broken nameserver increases
that time to 15s and also gives no answer. This test was done on Slackware
12.2.

The above example does not behave exactly as I remembered the problem, but
at least it shows there is something fishy with nslookup.

regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc123(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost

Jorgen Grahn <grahn+(E-Mail Removed)> writes:
> On Sat, 2011-10-15, Floyd L. Davidson wrote:

>> From the text of the man page as quoted in my previous article:
>>
>> "On a normally configured system this file should not
>> be necessary. The only name server to be queried will
>> be on the local machine; [...]"
>
> Yes, but that only means localhost is queried if the file doesn't exist,
> not that the file is ignored if there's a nameserver on localhost.
> Do you agree?

That's correct. After reading /etc/resolv.conf if no name servers are
found to be configured, 127.0.0.1 is added to the list.

I don't know if that's "normally" configured - I suspect that
numerically at least, nonempty resolv.conf is the more frequent
configuration.

--
http://www.greenend.org.uk/rjk/

Henrik Carlqvist <(E-Mail Removed)> wrote:
>Now, when trying to recreate that I only got partial success. I have no
>DNS server running on localhost:
>
>-8<---------------------
>bash-3.1# cat /etc/resolv.conf
># Generated by dhcpcd for interface wlan0
>search Belkin
>nameserver 192.168.30.254

....

>bash-3.1# time nslookup www.google.com
>Server: 192.168.30.254
>Address: 192.168.30.254#53
>
>Name: www.google.com
>Address: 209.85.169.105
>
>real 0m0.104s
>user 0m0.004s
>sys 0m0.004s

That is as expected.

>bash-3.1# emacs -nw /etc/resolv.conf
>bash-3.1# cat /etc/resolv.conf
># Generated by dhcpcd for interface wlan0
>search Belkin
>nameserver 192.168.30.254
>nameserver 127.0.0.1
>
>bash-3.1# time nslookup www.google.com
>;; Got recursion not available from 192.168.30.254, trying next server
>;; connection timed out; no servers could be reached
>
>real 0m15.113s
>user 0m0.004s
>sys 0m0.000s
>-8<---------------------

On my system the same configuration results in exactly
the same time as with only a single valid nameserver
entry. If I put the invalid entry first it takes about
1 second longer. I only get the 15 second time out if
there are no valid entries.

>In the example above "nslookup www.google.com" takes 0.1s with a single
>working nameserver in resolv.conf. Adding a broken nameserver increases
>that time to 15s and also gives no answer. This test was done on Slackware
>12.2.

I'm using Slackware 13.37, but have never seen it any different.

>The above example does not behave exactly as I remembered the problem, but
>at least it shows there is something fishy with nslookup.

Yep, that's downright weird!

--
Floyd L. Davidson <http://www.apaflo.com/>
Ukpeagvik (Barrow, Alaska) (E-Mail Removed)

Floyd L. Davidson wrote:
> Henrik Carlqvist<(E-Mail Removed)> wrote:
[...]
>> The above example does not behave exactly as I remembered the problem, but
>> at least it shows there is something fishy with nslookup.
>
> Yep, that's downright weird!
>

Just 'dig' it :-)

-rasp