Why doesn't ISP provide the DNS ?

Since the days of slak-3 I don't remember having any problems with
'can't resolve URL' errors.
I'm slowly 'installing' a 2.6*kernel [Debian-Lenny-2009] and every
new app. is problematic. "Just do A, B, C" is a crappy explanation,
simlar to read the `cat man * | ws -l` = 3427 line manual.

I want to better understand what's actually happening.
If I can get out on ppp, to my ISP, then why doesn't the ISP
handle the DNS ? Not directly, but it would know where the
nearest/best DNS is ?

When you debug something, it's best to understand the
stages that the process goes through, so that you can test at these
critical stages.

Let me take a wild guess: when I `wget <URL>`:
1. some utility must searchy some file to decide which DNS to use;
I'd like to see a 'trace' of that file being read.

2. and then I'd like to see a trace of the next stage.

Can someone help me to understand what happens 'under the hood''?

== TIA.

On Mon, 11 Oct 2010 17:12:50 +0000 (UTC), (E-Mail Removed) wrote:
> Since the days of slak-3 I don't remember having any problems with
> 'can't resolve URL' errors.

Usenet guidelines suggest putting your question in the body of the
post instead of making anyone wanting to reply having to copy it into
their reply so they can respond to the problem.

> Subject: Re: Why doesn't ISP provide the DNS ?
First you have to prove is the ISP with the problem or if it is your problem.

> I'm slowly 'installing' a 2.6*kernel [Debian-Lenny-2009] and every
> new app. is problematic. "Just do A, B, C" is a crappy explanation,
> simlar to read the `cat man * | ws -l` = 3427 line manual.

Well there is a start, we now know the distribution. Bitching about
installing new app not required for your problem and invites flames.

> I want to better understand what's actually happening.

I find it helpful to look through the start up scripts to figure out
what is going on without going the full route and looking at source
code for applications.

> If I can get out on ppp, to my ISP, then why doesn't the ISP
> handle the DNS ?

Hmm, not sure what you mean by "get out". To me doing a successful
ping -c 1 72.30.2.43
proves I have connectivity all the way to yahoo.com, but a failure doing
ping -c 1 yahoo.com
proves some resolver or my system is at fault.

First prove it is ISP, not your setup. Off hand, it is user setup,
problem, dhcp client problem, ISP problem. Pretty much in that order.

> Not directly, but it would know where the nearest/best DNS is ?

Nope, just is not going to work that way. Each dns resolver in the
looks locally for name.whatever and if can not
figure it out, passed the resolution to next link in the Internet chain.

> When you debug something, it's best to understand the
> stages that the process goes through, so that you can test at these
> critical stages.

True, or at least learn how to troubleshoot the problem so you know
where to look.

> Let me take a wild guess: when I `wget <URL>`:
> 1. some utility must searchy some file to decide which DNS to use;
> I'd like to see a 'trace' of that file being read.
>
> 2. and then I'd like to see a trace of the next stage.

Seems your normal. The human mind reduces the problem to its most
complex form.

> Can someone help me to understand what happens 'under the hood''?

You can only run your 'trace' on apps on your system. You want to
watch code run, you either get the source and run it with a debugger.
Too much work there, then there is "strace".

You want to see which dns server is at fault, you use
dig @(each resolver in the path) some.name.

I know very little about Debian-Lenny. On my install, dns resolution
info/order is controlled by contents of

$ grep order /etc/host.conf
order hosts,bind

$ grep host /etc/nsswitch.conf
hosts: files dns

$ grep -m 1 nameserver /etc/resolv.conf
nameserver 127.0.0.1


Here you can see I had no use for mdns or nis doing resolution for me.
$ diff /etc/nsswitch.conf /etc/nsswitch.conf_vorig
< hosts: files dns
---
> hosts: mdns4_minimal files nis dns mdns4

Since I am running named as my DNS resolver, it will look in files on
my system, then go elsewhere. In my case I told it to use opendsn servers.

/etc/resolv.conf has the nameserver'S ip address of the first DNS
resolver in the chain to do your conversions.

It gets into /etc/resolv.conf by you putting it there via interface
setup, editor, script, dhcp client, or in your case, your pppd
application.

In the case of dhcp client, you do a man on that client and you should
be able to look through the lease file to compare against /etc/resolv.conf
For pppd, you can look around in system logs to see what was received.
Example command to try
grep -i ppp /var/log/messages

For extra points there is the command
man pppd

You can prove it is not an ISP problem by
dig @(ISP's dns ip here) some.name_here
If that works it is your problem. If fails, open a problem report.

Quick solution, fix your system to use your favorite resolver. Example look
around at https://www.opendns.com and if you like their added features
use their public DNS ip addresses.

Other solution, install bind and run your own resolver.

(E-Mail Removed) writes:

> Since the days of slak-3 I don't remember having any problems with
> 'can't resolve URL' errors.
> I'm slowly 'installing' a 2.6*kernel [Debian-Lenny-2009] and every
> new app. is problematic. "Just do A, B, C" is a crappy explanation,
> simlar to read the `cat man * | ws -l` = 3427 line manual.
>
> I want to better understand what's actually happening.
> If I can get out on ppp, to my ISP, then why doesn't the ISP
> handle the DNS ? Not directly, but it would know where the
> nearest/best DNS is ?

Sounds like you want the usepeerdns option to ppp, but without any
information about how you've set things up, that's a guess.

> When you debug something, it's best to understand the
> stages that the process goes through, so that you can test at these
> critical stages.
>
> Let me take a wild guess: when I `wget <URL>`:
> 1. some utility must searchy some file to decide which DNS to use;
> I'd like to see a 'trace' of that file being read.

strace is your best bet here.

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

On 2010-10-11, (E-Mail Removed) <(E-Mail Removed)> wrote:
> Since the days of slak-3 I don't remember having any problems with
> 'can't resolve URL' errors.
> I'm slowly 'installing' a 2.6*kernel [Debian-Lenny-2009] and every
> new app. is problematic. "Just do A, B, C" is a crappy explanation,
> simlar to read the `cat man * | ws -l` = 3427 line manual.
>
> I want to better understand what's actually happening.
> If I can get out on ppp, to my ISP, then why doesn't the ISP
> handle the DNS ? Not directly, but it would know where the
> nearest/best DNS is ?
>
> When you debug something, it's best to understand the
> stages that the process goes through, so that you can test at these
> critical stages.
>
> Let me take a wild guess: when I `wget <URL>`:
> 1. some utility must searchy some file to decide which DNS to use;
> I'd like to see a 'trace' of that file being read.
>
> 2. and then I'd like to see a trace of the next stage.
>
> Can someone help me to understand what happens 'under the hood''?

Just like you have trouble figuring out what Linux does, we have trouble
figuring out what you want.

DNS uses /etc/resolv.conf to read of the IP addresses of the dns
servers. If the first one times out the second ( if there ) is used,
etc.

If you want more under the hood than that, there is the source code
(gethostbyname, gethostbyaddress, gethostname, ....) Read it

>
>== TIA.
>

(E-Mail Removed) wrote:

> Since the days of slak-3 I don't remember having any problems with
> 'can't resolve URL' errors.
> I'm slowly 'installing' a 2.6*kernel [Debian-Lenny-2009] and every
> new app. is problematic. "Just do A, B, C" is a crappy explanation,
> simlar to read the `cat man * | ws -l` = 3427 line manual.
>
> I want to better understand what's actually happening.
> If I can get out on ppp, to my ISP, then why doesn't the ISP
> handle the DNS ? Not directly, but it would know where the
> nearest/best DNS is ?
>
> When you debug something, it's best to understand the
> stages that the process goes through, so that you can test at these
> critical stages.
>
> Let me take a wild guess: when I `wget <URL>`:
> 1. some utility must searchy some file to decide which DNS to use;
> I'd like to see a 'trace' of that file being read.
>
> 2. and then I'd like to see a trace of the next stage.
>
> Can someone help me to understand what happens 'under the hood''?

It's likely that the ISP is sending you the information about DNS servers -
this is fairly much standard practice these days, however you don't have
pppd configured correctly to update /etc/resolv.conf, or pppd doesn't have
access to update that file.

DNS servers are negotiated during the PPP startup, using LCP (Link Control
Protocol). Your best bet to understanding this is to read the pppd readme
file and look at the debug options.

Turn on pppd debugging & set debug levels so that you can see the LCP
negotiation and you should see the ms-dns attribute sent to you from the
ISP. Look to see what pppd does with that; /var/log/daemon should have pppd
output.

It's always a good idea to look at the contents of the log files in /var/log
if you have problems with a system process.

Bruce

On 2010-10-13, Bruce Cook <bruce-(E-Mail Removed)> wrote:
> (E-Mail Removed) wrote:
>
>> Since the days of slak-3 I don't remember having any problems with
>> 'can't resolve URL' errors.
>> I'm slowly 'installing' a 2.6*kernel [Debian-Lenny-2009] and every
>> new app. is problematic. "Just do A, B, C" is a crappy explanation,
>> simlar to read the `cat man * | ws -l` = 3427 line manual.
>>
>> I want to better understand what's actually happening.
>> If I can get out on ppp, to my ISP, then why doesn't the ISP
>> handle the DNS ? Not directly, but it would know where the
>> nearest/best DNS is ?
>>
>> When you debug something, it's best to understand the
>> stages that the process goes through, so that you can test at these
>> critical stages.
>>
>> Let me take a wild guess: when I `wget <URL>`:
>> 1. some utility must searchy some file to decide which DNS to use;
>> I'd like to see a 'trace' of that file being read.
>>
>> 2. and then I'd like to see a trace of the next stage.
>>
>> Can someone help me to understand what happens 'under the hood''?
>
> It's likely that the ISP is sending you the information about DNS servers -
> this is fairly much standard practice these days, however you don't have
> pppd configured correctly to update /etc/resolv.conf, or pppd doesn't have
> access to update that file.

IF he is using ppp, then ppp puts the resolver stuff into
/etc/ppp/resolv.conf, not /etc/resolv.conf. It is up to you or your
scripts to then put the into into /etc/resolv.conf.
If he is not using ppp this is irrelevant.
>
> DNS servers are negotiated during the PPP startup, using LCP (Link Control
> Protocol). Your best bet to understanding this is to read the pppd readme
> file and look at the debug options.
>
> Turn on pppd debugging & set debug levels so that you can see the LCP
> negotiation and you should see the ms-dns attribute sent to you from the
> ISP. Look to see what pppd does with that; /var/log/daemon should have pppd
> output.
>
> It's always a good idea to look at the contents of the log files in /var/log
> if you have problems with a system process.
>
> Bruce
>
>

In article <(E-Mail Removed)>, Bruce Cook <bruce-(E-Mail Removed)> wrote:

> (E-Mail Removed) wrote:
>
> > Since the days of slak-3 I don't remember having any problems with
> > 'can't resolve URL' errors.
> > I'm slowly 'installing' a 2.6*kernel [Debian-Lenny-2009] and every
> > new app. is problematic. "Just do A, B, C" is a crappy explanation,
> > simlar to read the `cat man * | ws -l` = 3427 line manual.
> >
> > I want to better understand what's actually happening.
> > If I can get out on ppp, to my ISP, then why doesn't the ISP
> > handle the DNS ? Not directly, but it would know where the
> > nearest/best DNS is ?
> >
> > When you debug something, it's best to understand the
> > stages that the process goes through, so that you can test at these
> > critical stages.
> >
> > Let me take a wild guess: when I `wget <URL>`:
> > 1. some utility must searchy some file to decide which DNS to use;
> > I'd like to see a 'trace' of that file being read.
> >
> > 2. and then I'd like to see a trace of the next stage.
> >
> > Can someone help me to understand what happens 'under the hood''?
>
> It's likely that the ISP is sending you the information about DNS servers -
> this is fairly much standard practice these days, however you don't have
> pppd configured correctly to update /etc/resolv.conf, or pppd doesn't have
> access to update that file.
>
> DNS servers are negotiated during the PPP startup, using LCP (Link Control
> Protocol). Your best bet to understanding this is to read the pppd readme
> file and look at the debug options.
>
> Turn on pppd debugging & set debug levels so that you can see the LCP
> negotiation and you should see the ms-dns attribute sent to you from the
> ISP. Look to see what pppd does with that; /var/log/daemon should have pppd
> output.
man pppd | wc -l == 1827 > 30 pages of A4, thank you !!
== "debug Enables connection debugging facilities. If this option is
given, pppd will log the contents of all control packets sent or
received in a readable form. The packets are logged through
syslog with facility daemon and level debug. This information
can be directed to a file by setting up /etc/syslog.conf appro-
priately (see syslog.conf(5))."

Do I really want to decode the packets, when I started ppp-ing 15 years ago
with slak3 and several RH-family-type since then.

It seems that Debina is a big waste of time.
I should never have opened the can-o-worms!
Or more correctly, per my previous post:
"The forking of Linux distributions is disasterous".
--------
-> An OLD non-debian specific well proven script which also fails:-
pppd lcp-echo-interval 300 lcp-echo-failure 4 connect '
chat -v "" ATZ OK ATX OK ATM2DT0123070301 CONNECT "" TIMEOUT 99 ' \
/dev/ttyS0 115200 debug crtscts modem defaultroute : name "2nm4nx6x@za"
seems to be set for 'debug'

--> man syslog.conf == No manual entry for syslog.conf
==> exercise the dog and see if/what recent *log is created
= or just see some most recent /var/*og == ...
File: debug.1 == ...
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xc2769b7b> <pcomp> <accomp>]

rcvd [LCP ConfReq id=0x3d <asyncmap 0xa0000> <auth pap> <magic 0xb8786615> <pcomp> <accomp> <mrru 1524> <endpoint [local:69.73.64.6e.78.32]>]
sent [LCP ConfRej id=0x3d <mrru 1524>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xc2769b7b> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x3e <asyncmap 0xa0000> <auth pap> <magic 0xb8786615> <pcomp> <accomp> <mrru 1524> <endpoint [local:69.73.64.6e.78.32]>]
sent [LCP ConfRej id=0x3e <mrru 1524>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xc2769b7b> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x3f <asyncmap 0xa0000> <auth pap> <magic 0xb8786615> <pcomp> <accomp> <endpoint [local:69.73.64.6e.78.32]>]
sent [LCP ConfAck id=0x3f <asyncmap 0xa0000> <auth pap> <magic 0xb8786615> <pcomp> <accomp> <endpoint [local:69.73.64.6e.78.32]>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xc2769b7b> <pcomp> <accomp>]
sent [LCP EchoReq id=0x0 magic=0xc2769b7b]
sent [PAP AuthReq id=0x1 user="2nm4nx6x@za" password=<hidden>]
rcvd [LCP EchoRep id=0x0 magic=0xb8786615]
rcvd [PAP AuthAck id=0x1 ""]
sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 0.0.0.0>]
rcvd [LCP EchoReq id=0x1 magic=0xb8786615 c2 76 9b 7b]
sent [LCP EchoRep id=0x1 magic=0xc2769b7b c2 76 9b 7b]
rcvd [LCP ProtRej id=0x1 80 fd 01 01 00 0f 1a 04 78 00 18 04 78 00 15 03 2f]
Protocol-Reject for 'Compression Control Protocol' (0x80fd) received
rcvd [IPCP ConfReq id=0x1 <compress VJ 0f 00> <addr 196.38.72.130>]
sent [IPCP ConfAck id=0x1 <compress VJ 0f 00> <addr 196.38.72.130>]
rcvd [IPCP ConfReq id=0x2 <compress VJ 0f 00> <addr 196.38.72.130>]
sent [IPCP ConfAck id=0x2 <compress VJ 0f 00> <addr 196.38.72.130>]
rcvd [IPCP ConfReq id=0x3 <compress VJ 0f 00> <addr 196.38.72.130>]
sent [IPCP ConfAck id=0x3 <compress VJ 0f 00> <addr 196.38.72.130>]
rcvd [IPCP ConfNak id=0x1 <addr 196.208.67.94>]
sent [IPCP ConfReq id=0x2 <compress VJ 0f 01> <addr 196.208.67.94>]
rcvd [IPCP ConfAck id=0x2 <compress VJ 0f 01> <addr 196.208.67.94>]

-> whereis ping == ok
--> Connect via ppp & try:--
ping -c 1 72,30,2,43 == <ok> 1 received, 0% packet loss...
ping -c 1 yahoo.com == unknown host yahoo.com
lynx www.bbc.com == fail-crap!
----------
>
> It's always a good idea to look at the contents of the log files in /var/log
> if you have problems with a system process.
>
Yes that's how I know that ppp has authenticated & pap ...
> Bruce

unruh-physics.ubc.ca wrote:--
>If you want more under the hood than that, there is the source code
>(gethostbyname, gethostbyaddress, gethostname, ....) Read it

Yes, thanks that's good stuff to read.

== Chris Glur.

Hello,

(E-Mail Removed) a écrit :
>
> -> An OLD non-debian specific well proven script which also fails:-
> pppd lcp-echo-interval 300 lcp-echo-failure 4 connect '
> chat -v "" ATZ OK ATX OK ATM2DT0123070301 CONNECT "" TIMEOUT 99 ' \
> /dev/ttyS0 115200 debug crtscts modem defaultroute : name "2nm4nx6x@za"

The 'usepeerdns' option seems to be missing.