ip-up.d/0000usepeerdns shouldn't clobber /etc/resolv.conf (patch attached)

Bug #38917 reported by Gabriel Bauman
6
Affects Status Importance Assigned to Milestone
ppp (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

Hullo, I was using ppp over a VPN link when I noticed that /etc/ppp/ip-up.d/0000usepeerdns was clobbering my client machine's resolv.conf with the VPN's dynamic DNS servers when starting the connection.

This is bad because the VPN's DNS server only knows about internal domains, so I was unable to surf the net.

Here's a patch that causes the script to *add* the PPP link's dynamically-provided DNS servers to the system's resolv.conf rather than replacing them.

This might get hairy if clients have more than one active PPP connection, but the 0000usepeerdns script doesn't look like it ever took that into account anyway. A cursory glance at /etc/ppp/0_dnsup (provided by the pppconfig package) looks like it does practically the same thing as 0000usepeerdns in a more robust way.

Revision history for this message
Gabriel Bauman (gabrielbauman) wrote : Patch to fix clobber of /etc/resolv.conf nameservers

Causes ip-up.d/0000usepeerdns to concat /etc/resolv.conf and /etc/ppp/resolv.conf when a ppp link goes up, instead of replacing /etc/resolv.conf's DNS servers. Adds nice comments to /etc/resolv.conf.

Revision history for this message
Gabriel Bauman (gabrielbauman) wrote : FIXED patch

Whoops, looks like I screwed up the first patch - dynamic DNS names don't seem to resolve unless the ppp-supplied nameservers come first in /etc/resolv.conf. Try this patch instead.

Revision history for this message
Gabriel Bauman (gabrielbauman) wrote :

This problem appears to be fixed in Dapper.

Changed in ppp:
status: Unconfirmed → Fix Released
Revision history for this message
Gabriel Bauman (gabrielbauman) wrote :

Just did a fresh Dapper install and found that the problem still exists and is fixed by the attached patch.

Changed in ppp:
status: Fix Released → Confirmed
Revision history for this message
Daniel T Chen (crimsun) wrote :

Is this issue reproducible in 8.10 alpha?

Changed in ppp:
status: Confirmed → Incomplete
Revision history for this message
Gabriel Bauman (gabrielbauman) wrote :

Yes, this is still a minor issue (years later!)

When a new PPP link starts up and USEPEERDNS is set, the script /etc/ppp/ip-up.d/0000usepeerdns replaces all of the nameservers in /etc/resolv.conf.

If you're accessing a PPTP VPN with a private DNS server, name resolution is broken as soon as the PPP link comes up. You can only browse to domains that the private DNS server knows about.

My (admittedly simplistic) patch causes the script to *add* the VPN's nameservers to /etc/resolv.conf.

The thing is, /etc/ppp/ip-up.d/0dns-up seems to do the same thing in a much smarter way (plus it's aware of the resolvconf package). I'm not sure why the two scripts exist; it seems that 0000usepeerdns is redundant.

Revision history for this message
Gabriel Bauman (gabrielbauman) wrote :

Marking confirmed to avoid the Janitor

Changed in ppp:
status: Incomplete → Confirmed
Revision history for this message
Stéphane Graber (stgraber) wrote :

Hi,

We recently switched to using resolvconf (in 12.04) that should fix that issue by properly managing /etc/resolv.conf merging/appending name servers as needed.

Any chance you can test your setup on 12.04 and confirm that resolvconf fixes it?

Thanks

Changed in ppp (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Gabriel Bauman (gabrielbauman) wrote : Re: [Bug 38917] Re: ip-up.d/0000usepeerdns shouldn't clobber /etc/resolv.conf (patch attached)

Sorry, I no longer use Ubuntu and can't test for you. With that said resolvconf did fix the issue for me on Fedora.

Revision history for this message
Stéphane Graber (stgraber) wrote :

Thanks for your comment, marking this fix released as resolvconf should have fixed the problem in Ubuntu.

Changed in ppp (Ubuntu):
status: Incomplete → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.