Subject: Re: usepeerdns
To: Manuel Bouyer <bouyer@antioche.lip6.fr>
From: Steven M. Bellovin <smb@research.att.com>
List: netbsd-users
Date: 05/17/2001 08:04:32
In message <20010517102712.A6346@antioche.lip6.fr>, Manuel Bouyer writes:
>On Wed, May 16, 2001 at 05:37:56PM -0400, Steven M. Bellovin wrote:
>> In message <20010516231623.A590@antioche.eu.org>, Manuel Bouyer writes:
>> >On Wed, May 16, 2001 at 06:19:02PM +0100, Georges Heinesch wrote:
>> >> Hi.
>> >>
>> >> The usepeerdns option queries the remote peer during dialup if there
>> >> are any DNS servers. Until now, I thought, that if the remote peer
>> >> gives out the DNS servers, that those are used automatically.
>> >>
>> >> Tests revealed that this is apparantly not the case. The problem comes
>> >> when using multiple providers.
>> >>
>> >> How can I tell pppd to use the DNS Servers which are negiciated during
>> >> initial dialup (provided the peer gives out the DNS servers, which is
>> >> not always the case)?
>> >
>> >Not easy;I don't think our pppd can get this info.
>> >However; I use xisp as front-end to pppd, and it can automatically add/remo
>ve
>> >entries from /etc/resolv.conf, based on the isp you're using.
>>
>> The man page (on 1.5.1beta1) says that it should automatically do the
>> right thing, but it hasn't worked for me in my (very limited) tests:
>>
>> usepeerdns
>> Ask the peer for up to 2 DNS server addresses. The
>> addresses supplied by the peer (if any) are passed
>> to the /etc/ppp/ip-up script in the environment
>> variables DNS1 and DNS2. In addition, pppd will
>> create an /etc/ppp/resolv.conf file containing one
>> or two nameserver lines with the address(es) sup-
>> plied by the peer.
>
>Did you try to write a ip-up script which prints to /dev/console content
>if DNS1 and DNS2 ?
I haven't, because until I cut-and-pasted that text yesterday I had
misread the text to say that it was creating /etc/resolv.conf, not /etc/
ppp/resolv.conf. I'm dialed up right now (!@#$%^ cable modem
provider), and I've confirmed that the latter file is indeed correct
for what it would have received from the POP. I'll write something to
put that data in a more useful spot -- but the answer seems to be that
yes, it's doing the right thing. (This, btw, is 1.5.1b1.)
--Steve Bellovin, http://www.research.att.com/~smb