Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #188193 > unrolled thread
| Started by | Roberto C. Sánchez <roberto@debian.org> |
|---|---|
| First post | 2017-10-23 04:20 +0200 |
| Last post | 2017-10-25 16:20 +0200 |
| Articles | 20 on this page of 138 — 29 participants |
Back to article view | Back to linux.debian.user
Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-23 04:20 +0200
Re: Why does resolv.conf keep changing? Joe <joe@jretrading.com> - 2017-10-23 11:00 +0200
Re: Why does resolv.conf keep changing? <tomas@tuxteam.de> - 2017-10-23 11:50 +0200
Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-24 01:40 +0200
Re: Why does resolv.conf keep changing? David Wright <deblis@lionunicorn.co.uk> - 2017-10-24 02:30 +0200
Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-24 05:10 +0200
Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-24 09:20 +0200
Re: Why does resolv.conf keep changing? Greg Wooledge <wooledg@eeg.ccf.org> - 2017-10-24 14:20 +0200
Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-24 14:30 +0200
Re: Why does resolv.conf keep changing? Curt <curty@free.fr> - 2017-10-24 19:10 +0200
Re: Why does resolv.conf keep changing? David Wright <deblis@lionunicorn.co.uk> - 2017-10-24 18:50 +0200
Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-25 15:30 +0200
Re: Why does resolv.conf keep changing? Gene Heskett <gheskett@shentel.net> - 2017-10-25 15:40 +0200
Re: Why does resolv.conf keep changing? David Wright <deblis@lionunicorn.co.uk> - 2017-10-25 20:50 +0200
Re: Why does resolv.conf keep changing? Roger Lynn <Roger@rilynn.me.uk> - 2017-10-25 00:30 +0200
Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-25 04:10 +0200
Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-23 13:00 +0200
Re: Why does resolv.conf keep changing? Greg Wooledge <wooledg@eeg.ccf.org> - 2017-10-23 18:10 +0200
Re: Why does resolv.conf keep changing? Jude DaShiell <jdashiel@panix.com> - 2017-10-23 18:10 +0200
Re: Why does resolv.conf keep changing? Gene Heskett <gheskett@shentel.net> - 2017-10-23 23:10 +0200
Re: Why does resolv.conf keep changing? Dan Ritter <dsr@randomstring.org> - 2017-10-24 00:00 +0200
Re: Why does resolv.conf keep changing? Gene Heskett <gheskett@shentel.net> - 2017-10-24 02:40 +0200
Re: Why does resolv.conf keep changing? Michael Stone <mstone@debian.org> - 2017-10-25 03:20 +0200
Re: Why does resolv.conf keep changing? Gene Heskett <gheskett@shentel.net> - 2017-10-25 05:00 +0200
Re: Why does resolv.conf keep changing? Michael Stone <mstone@debian.org> - 2017-10-25 05:10 +0200
Re: Why does resolv.conf keep changing? Gene Heskett <gheskett@shentel.net> - 2017-10-25 06:20 +0200
Re: Why does resolv.conf keep changing? Michael Stone <mstone@debian.org> - 2017-10-25 13:40 +0200
Re: Why does resolv.conf keep changing? Alberto Luaces <aluaces@udc.es> - 2017-10-25 14:10 +0200
Re: Why does resolv.conf keep changing? Michael Stone <mstone@debian.org> - 2017-10-25 15:30 +0200
Re: Why does resolv.conf keep changing? <tomas@tuxteam.de> - 2017-10-25 15:50 +0200
Re: Why does resolv.conf keep changing? Curt <curty@free.fr> - 2017-10-25 16:30 +0200
Re: Why does resolv.conf keep changing? Joe <joe@jretrading.com> - 2017-10-25 17:10 +0200
Re: Why does resolv.conf keep changing? <tomas@tuxteam.de> - 2017-10-25 17:30 +0200
Re: Why does resolv.conf keep changing? rhkramer@gmail.com - 2017-10-25 19:00 +0200
Re: Why does resolv.conf keep changing? <tomas@tuxteam.de> - 2017-10-25 19:10 +0200
Re: Why does resolv.conf keep changing? rhkramer@gmail.com - 2017-10-25 19:40 +0200
Re: Why does resolv.conf keep changing? Gene Heskett <gheskett@shentel.net> - 2017-10-25 14:20 +0200
Re: Why does resolv.conf keep changing? Felix Miata <mrmazda@earthlink.net> - 2017-10-25 05:50 +0200
Re: Why does resolv.conf keep changing? Gene Heskett <gheskett@shentel.net> - 2017-10-25 13:40 +0200
Re: Why does resolv.conf keep changing? <tomas@tuxteam.de> - 2017-10-25 14:00 +0200
Re: Why does resolv.conf keep changing? tomas@tuxteam.de - 2017-10-25 14:20 +0200
Re: Why does resolv.conf keep changing? Nicolas George <george@nsup.org> - 2017-10-25 14:50 +0200
Re: Why does resolv.conf keep changing? Joe <joe@jretrading.com> - 2017-10-25 14:10 +0200
Re: Why does resolv.conf keep changing? <tomas@tuxteam.de> - 2017-10-25 14:20 +0200
Re: Why does resolv.conf keep changing? Joe <joe@jretrading.com> - 2017-10-25 15:00 +0200
Re: Why does resolv.conf keep changing? Dan Ritter <dsr@randomstring.org> - 2017-10-25 17:10 +0200
Re: Why does resolv.conf keep changing? Gene Heskett <gheskett@shentel.net> - 2017-10-25 18:50 +0200
Re: Why does resolv.conf keep changing? Don Armstrong <don@debian.org> - 2017-10-25 21:30 +0200
Re: Why does resolv.conf keep changing? Michael Stone <mstone@debian.org> - 2017-10-25 13:40 +0200
Re: Why does resolv.conf keep changing? Glenn English <ghe2001@gmail.com> - 2017-10-26 17:40 +0200
Re: Why does resolv.conf keep changing? Greg Wooledge <wooledg@eeg.ccf.org> - 2017-10-26 17:50 +0200
Re: Why does resolv.conf keep changing? The Wanderer <wanderer@fastmail.fm> - 2017-10-26 18:00 +0200
Re: Why does resolv.conf keep changing? Nicholas Geovanis <nickgeovanis@gmail.com> - 2017-10-26 18:20 +0200
Re: Why does resolv.conf keep changing? Nicholas Geovanis <nickgeovanis@gmail.com> - 2017-10-26 18:40 +0200
Re: Why does resolv.conf keep changing? Gene Heskett <gheskett@shentel.net> - 2017-10-27 02:00 +0200
Re: Why does resolv.conf keep changing? Gene Heskett <gheskett@shentel.net> - 2017-10-27 02:00 +0200
Re: Why does resolv.conf keep changing? Jörg-Volker Peetz <jvpeetz@web.de> - 2017-10-23 12:10 +0200
Re: Why does resolv.conf keep changing? Stefan Monnier <monnier@iro.umontreal.ca> - 2017-10-25 05:50 +0200
Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-25 06:10 +0200
Re: Why does resolv.conf keep changing? Stefan Monnier <monnier@iro.umontreal.ca> - 2017-10-25 06:50 +0200
Re: Why does resolv.conf keep changing? Curt <curty@free.fr> - 2017-10-25 08:50 +0200
Re: Why does resolv.conf keep changing? Stefan Monnier <monnier@iro.umontreal.ca> - 2017-10-25 14:40 +0200
Re: Why does resolv.conf keep changing? <tomas@tuxteam.de> - 2017-10-25 14:50 +0200
Re: Why does resolv.conf keep changing? Stefan Monnier <monnier@iro.umontreal.ca> - 2017-10-25 15:00 +0200
Re: Why does resolv.conf keep changing? <tomas@tuxteam.de> - 2017-10-25 15:10 +0200
Re: Why does resolv.conf keep changing? Greg Wooledge <wooledg@eeg.ccf.org> - 2017-10-25 15:10 +0200
Re: Why does resolv.conf keep changing? <tomas@tuxteam.de> - 2017-10-25 15:10 +0200
Re: Why does resolv.conf keep changing? Michael Stone <mstone@debian.org> - 2017-10-25 15:30 +0200
Re: Why does resolv.conf keep changing? Gene Heskett <gheskett@shentel.net> - 2017-10-25 15:30 +0200
Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-25 16:10 +0200
Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-25 16:10 +0200
[SOLVED] Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-25 20:30 +0200
Re: [SOLVED] Re: Why does resolv.conf keep changing? Michael Stone <mstone@debian.org> - 2017-10-25 20:40 +0200
Re: [SOLVED] Re: Why does resolv.conf keep changing? Greg Wooledge <wooledg@eeg.ccf.org> - 2017-10-25 20:40 +0200
Re: [SOLVED] Re: Why does resolv.conf keep changing? Greg Wooledge <wooledg@eeg.ccf.org> - 2017-10-25 21:00 +0200
Re: [SOLVED] Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-25 21:00 +0200
Re: [SOLVED] Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-26 15:10 +0200
Re: [SOLVED] Re: Why does resolv.conf keep changing? Greg Wooledge <wooledg@eeg.ccf.org> - 2017-10-26 15:40 +0200
Re: [SOLVED] Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-26 16:00 +0200
Re: [SOLVED] Re: Why does resolv.conf keep changing? Don Armstrong <don@debian.org> - 2017-10-26 21:40 +0200
Re: [SOLVED] Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-26 21:40 +0200
Re: [SOLVED] Re: Why does resolv.conf keep changing? Nicholas Geovanis <nickgeovanis@gmail.com> - 2017-10-26 16:30 +0200
The new normal of logging Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2017-10-26 21:10 +0200
Re: The new normal of logging Nicholas Geovanis <nickgeovanis@gmail.com> - 2017-10-26 21:30 +0200
Re: The new normal of logging Gene Heskett <gheskett@shentel.net> - 2017-10-27 02:10 +0200
Re: The new normal of logging Ben Caradoc-Davies <ben@transient.nz> - 2017-10-27 03:30 +0200
Re: The new normal of logging Gene Heskett <gheskett@shentel.net> - 2017-10-27 07:00 +0200
Re: The new normal of logging Ben Caradoc-Davies <ben@transient.nz> - 2017-10-28 04:50 +0200
Re: The new normal of logging Gene Heskett <gheskett@shentel.net> - 2017-10-28 08:10 +0200
Re: The new normal of logging Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-10-27 04:10 +0200
Re: The new normal of logging Darac Marjal <mailinglist@darac.org.uk> - 2017-10-27 11:40 +0200
Plain text vs. binary (was Re: The new normal of logging) The Wanderer <wanderer@fastmail.fm> - 2017-10-27 14:40 +0200
Re: The new normal of logging Roberto C. Sánchez <roberto@debian.org> - 2017-10-26 21:30 +0200
Re: [SOLVED] Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-27 17:10 +0200
Re: [SOLVED] Re: Why does resolv.conf keep changing? Greg Wooledge <wooledg@eeg.ccf.org> - 2017-10-27 17:50 +0200
Re: [SOLVED] Re: Why does resolv.conf keep changing? Curt <curty@free.fr> - 2017-10-27 20:30 +0200
Re: [SOLVED] Re: Why does resolv.conf keep changing? Brian <ad44@cityscape.co.uk> - 2017-10-27 20:50 +0200
Re: [SOLVED] Re: Why does resolv.conf keep changing? Curt <curty@free.fr> - 2017-10-27 21:50 +0200
Re: [SOLVED] Re: Why does resolv.conf keep changing? Greg Wooledge <wooledg@eeg.ccf.org> - 2017-10-27 22:00 +0200
Re: [SOLVED] Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-28 18:30 +0200
Re: Why does resolv.conf keep changing? Stefan Monnier <monnier@iro.umontreal.ca> - 2017-10-26 05:40 +0200
Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-26 12:50 +0200
Re: Why does resolv.conf keep changing? Darac Marjal <mailinglist@darac.org.uk> - 2017-10-26 13:30 +0200
Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-26 13:50 +0200
Re: Why does resolv.conf keep changing? David Wright <deblis@lionunicorn.co.uk> - 2017-10-26 16:40 +0200
Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-26 17:00 +0200
Re: Why does resolv.conf keep changing? Mart van de Wege <mvdwege@gmail.com> - 2017-10-27 10:10 +0200
Re: Why does resolv.conf keep changing? Gene Heskett <gheskett@shentel.net> - 2017-10-27 13:50 +0200
Re: Why does resolv.conf keep changing? Darac Marjal <mailinglist@darac.org.uk> - 2017-10-27 14:20 +0200
Re: Why does resolv.conf keep changing? Greg Wooledge <wooledg@eeg.ccf.org> - 2017-10-27 14:40 +0200
Re: Why does resolv.conf keep changing? David Wright <deblis@lionunicorn.co.uk> - 2017-10-27 20:50 +0200
Re: Why does resolv.conf keep changing? David Wright <deblis@lionunicorn.co.uk> - 2017-10-27 20:50 +0200
Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-27 16:20 +0200
Re: Why does resolv.conf keep changing? Mart van de Wege <mvdwege@gmail.com> - 2017-10-28 00:10 +0200
Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-28 00:10 +0200
Re: Why does resolv.conf keep changing? David Wright <deblis@lionunicorn.co.uk> - 2017-10-28 02:00 +0200
Re: Why does resolv.conf keep changing? Mart van de Wege <mvdwege@gmail.com> - 2017-10-28 15:30 +0200
Re: Why does resolv.conf keep changing? Glenn English <ghe2001@gmail.com> - 2017-10-28 18:50 +0200
Re: Why does resolv.conf keep changing? Mart van de Wege <mvdwege@gmail.com> - 2017-10-28 15:40 +0200
Re: Why does resolv.conf keep changing? Stefan Monnier <monnier@iro.umontreal.ca> - 2017-10-27 16:40 +0200
Re: Why does resolv.conf keep changing? Mart van de Wege <mvdwege@gmail.com> - 2017-10-28 00:10 +0200
Re: Why does resolv.conf keep changing? Stefan Monnier <monnier@iro.umontreal.ca> - 2017-10-27 16:30 +0200
Re: Why does resolv.conf keep changing? Michael Stone <mstone@debian.org> - 2017-10-28 02:40 +0200
Re: Why does resolv.conf keep changing? Stefan Monnier <monnier@iro.umontreal.ca> - 2017-10-26 14:40 +0200
Re: Why does resolv.conf keep changing? Roger Lynn <Roger@rilynn.me.uk> - 2017-11-04 00:30 +0100
Re: Why does resolv.conf keep changing? <tomas@tuxteam.de> - 2017-11-04 08:50 +0100
Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-11-04 13:10 +0100
Re: Why does resolv.conf keep changing? Brian <ad44@cityscape.co.uk> - 2017-11-04 22:00 +0100
Re: Why does resolv.conf keep changing? <tomas@tuxteam.de> - 2017-11-04 22:10 +0100
Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-11-04 22:10 +0100
Re: Why does resolv.conf keep changing? Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-11-04 15:40 +0100
Re: Why does resolv.conf keep changing? Greg Wooledge <wooledg@eeg.ccf.org> - 2017-10-26 15:30 +0200
Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-25 15:30 +0200
Re: Why does resolv.conf keep changing? Gene Heskett <gheskett@shentel.net> - 2017-10-25 15:00 +0200
Re: Why does resolv.conf keep changing? Stefan Monnier <monnier@iro.umontreal.ca> - 2017-10-25 15:30 +0200
Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-25 15:10 +0200
Re: Why does resolv.conf keep changing? Stefan Monnier <monnier@iro.umontreal.ca> - 2017-10-25 15:30 +0200
Re: Why does resolv.conf keep changing? Roberto C. Sánchez <roberto@debian.org> - 2017-10-25 16:20 +0200
Page 1 of 7 [1] 2 3 4 5 6 7 Next page →
| From | Roberto C. Sánchez <roberto@debian.org> |
|---|---|
| Date | 2017-10-23 04:20 +0200 |
| Subject | Why does resolv.conf keep changing? |
| Message-ID | <uDAvn-89e-1@gated-at.bofh.it> |
So, I just upgraded my main router/firewall machine to Stretch.
Following the upgrade my /etc/resolv.conf settings appear to track the
DHCP options obtained by one of the two interfaces. No matter what I
try I can't get the /etc/resolv.conf settings to remain as I would like
them.
The machine has two network interfaces: one on the Internt side which
connects to my ISP-provided equipment and which obtains its address via
DHCP, another on the LAN side which is statically configured.
My /etc/network/interfaces looks like this (192.168.174.0/24 is my LAN
subnet):
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 192.168.174.1
netmask 255.255.255.0
broadcast 192.168.174.255
auto eth1
iface eth1 inet dhcp
My /etc/resolv.conf looks like this:
domain example.com
search example.com.
nameserver 127.0.0.1
The reason for "nameserver 127.0.0.1" is that I run my own instance of
bind which acts as a caching server and also serves my own internal
zones. Prior to the recent upgrade to Stretch everything worked
normally. That is, whatever I put in /etc/resolv.conf was left as I
configured it. Following my recent Stretch upgrade I found my
resolv.conf had been changed to just this (192.168.63.1/24 is the subnet
used by the ISP equipment):
nameserver 192.168.63.1
That has the effect of not allowing processes running on that machine
(the router/firewall) to properly resolve internal DNS addresses. Other
machines on my network are fine since they get their name servers set by
the internal DHCP server which is configured with the name server
address 192.168.174.1. This DHCP server is different from the embedded
DHCP server that runs on my ISP's device.
I have tried two different things. First, I added this directive to
/etc/network/interfaces under the eth0 stanza:
dns-nameservers 127.0.0.1
That did not appear to have any effect because taking eth0 and eth1 down
and then bringing them back up still results in resolv.conf pointing to
the ISP router as its name server. Additionally, after the interfaces
are up even if I manually change resolv.conf, something comes along
sometime later and undoes my changes.
The second thing I tried was adding to /etc/dhcp/dhclient.conf:
supersede domain-name example.com;
supersede domain-search example.com.;
supersede domain-name-servers 127.0.0.1;
This similarly has no lasting effect, which is really surprising to me.
I did find a page on the Debian wiki [0] which recommends setting the
immutable attribute on /etc/resolv.conf. However, that feels like an
ugly hack.
Can anyone point out what it is that I am missing here?
Regards,
-Roberto
[0] https://wiki.debian.org/resolv.conf
--
Roberto C. Sánchez
[toc] | [next] | [standalone]
| From | Joe <joe@jretrading.com> |
|---|---|
| Date | 2017-10-23 11:00 +0200 |
| Message-ID | <uDGKt-3zS-1@gated-at.bofh.it> |
| In reply to | #188193 |
On Sun, 22 Oct 2017 22:12:03 -0400 Roberto C. Sánchez <roberto@debian.org> wrote: > So, I just upgraded my main router/firewall machine to Stretch. > Following the upgrade my /etc/resolv.conf settings appear to track the > DHCP options obtained by one of the two interfaces. No matter what I > try I can't get the /etc/resolv.conf settings to remain as I would > like them. > > The machine has two network interfaces: one on the Internt side which > connects to my ISP-provided equipment and which obtains its address > via DHCP, another on the LAN side which is statically configured. > > My /etc/network/interfaces looks like this (192.168.174.0/24 is my LAN > subnet): > > auto lo > iface lo inet loopback > > auto eth0 > iface eth0 inet static > address 192.168.174.1 > netmask 255.255.255.0 > broadcast 192.168.174.255 > > auto eth1 > iface eth1 inet dhcp > > My /etc/resolv.conf looks like this: > > domain example.com > search example.com. > nameserver 127.0.0.1 > > The reason for "nameserver 127.0.0.1" is that I run my own instance of > bind which acts as a caching server and also serves my own internal > zones. Prior to the recent upgrade to Stretch everything worked > normally. That is, whatever I put in /etc/resolv.conf was left as I > configured it. Following my recent Stretch upgrade I found my > resolv.conf had been changed to just this (192.168.63.1/24 is the > subnet used by the ISP equipment): > > nameserver 192.168.63.1 > > That has the effect of not allowing processes running on that machine > (the router/firewall) to properly resolve internal DNS addresses. > Other machines on my network are fine since they get their name > servers set by the internal DHCP server which is configured with the > name server address 192.168.174.1. This DHCP server is different > from the embedded DHCP server that runs on my ISP's device. > > I have tried two different things. First, I added this directive to > /etc/network/interfaces under the eth0 stanza: > > dns-nameservers 127.0.0.1 > > That did not appear to have any effect because taking eth0 and eth1 > down and then bringing them back up still results in resolv.conf > pointing to the ISP router as its name server. Additionally, after > the interfaces are up even if I manually change resolv.conf, > something comes along sometime later and undoes my changes. > > The second thing I tried was adding to /etc/dhcp/dhclient.conf: > > supersede domain-name example.com; > supersede domain-search example.com.; > supersede domain-name-servers 127.0.0.1; > > This similarly has no lasting effect, which is really surprising to > me. > > I did find a page on the Debian wiki [0] which recommends setting the > immutable attribute on /etc/resolv.conf. However, that feels like an > ugly hack. > It most certainly is, and shouldn't be necessary in your case. > Can anyone point out what it is that I am missing here? Not 'missing', you probably have the package resolvconf installed, and with your network configuration, you don't need it. It's not certain, but it seems to be the culprit in most of these cases. There is undoubtedly a way to beat it into submission, but it's not widely known. There was another recent thread on this matter. If you're bringing up and taking down random interfaces, such as VPN tunnels and wifi, then you do want to keep shifting your DNS server, so resolvconf is appropriate on a laptop, but probably not on a fixed workstation. -- Joe
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2017-10-23 11:50 +0200 |
| Message-ID | <uDHwS-47Q-3@gated-at.bofh.it> |
| In reply to | #188197 |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, Oct 23, 2017 at 09:17:11AM +0100, Joe wrote: > On Sun, 22 Oct 2017 22:12:03 -0400 > Roberto C. Sánchez <roberto@debian.org> wrote: [...] > > I did find a page on the Debian wiki [0] which recommends setting the > > immutable attribute on /etc/resolv.conf. However, that feels like an > > ugly hack. > > > > It most certainly is, and shouldn't be necessary in your case. I've used that approach sometimes and regularly recommend it. That said, my main intention is to *debug* the problem, i.e. to provoke an error message in some log file or whatever, to learn which process is (undesirably?) mutating some file. Most of the time this leads to learning some config option to not do that mutation in the first place (or to some understanding on why that mutation is a Good Thing after all and to a better way of solving my real, underlying problem). Only in exceptional cases I had to "leave in" the immutable attribute as a permanent "solution". (as to the rest, yeah, resolvconf seems a worthy candidate). Cheers - -- tomás -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlnttXEACgkQBcgs9XrR2kbeIwCeJ1IyTwgJjRt/URyUIrhhFfyp +KwAn3HyMZ9UO1tGAaljQeD2zxTMU3p7 =JeQl -----END PGP SIGNATURE-----
[toc] | [prev] | [next] | [standalone]
| From | Roberto C. Sánchez <roberto@debian.org> |
|---|---|
| Date | 2017-10-24 01:40 +0200 |
| Message-ID | <uDUu5-3H8-1@gated-at.bofh.it> |
| In reply to | #188198 |
On Mon, Oct 23, 2017 at 11:25:05AM +0200, tomas@tuxteam.de wrote: > On Mon, Oct 23, 2017 at 09:17:11AM +0100, Joe wrote: > > On Sun, 22 Oct 2017 22:12:03 -0400 > > Roberto C. Sánchez <roberto@debian.org> wrote: > > [...] > > > > I did find a page on the Debian wiki [0] which recommends setting the > > > immutable attribute on /etc/resolv.conf. However, that feels like an > > > ugly hack. > > > > > > > It most certainly is, and shouldn't be necessary in your case. > > I've used that approach sometimes and regularly recommend it. > > That said, my main intention is to *debug* the problem, i.e. to > provoke an error message in some log file or whatever, to learn which > process is (undesirably?) mutating some file. Most of the time this > leads to learning some config option to not do that mutation in the > first place (or to some understanding on why that mutation is a Good > Thing after all and to a better way of solving my real, underlying > problem). > > Only in exceptional cases I had to "leave in" the immutable attribute > as a permanent "solution". > So, I edited resolv.conf to my preference and then made it immutable with `chattr +i /etc/resolv.conf`. Several hours later the name server was changed back to the ISP router's address. That is very odd. Yet even more odd is that this time the domain and search options were left untouched. Previously, the domain and search would get wiped (because the ISP router doesn't push those options). The plot thickens. Regards, -Roberto -- Roberto C. Sánchez
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2017-10-24 02:30 +0200 |
| Message-ID | <uDVgt-4bM-3@gated-at.bofh.it> |
| In reply to | #188225 |
On Mon 23 Oct 2017 at 19:33:01 (-0400), Roberto C. Sánchez wrote: > On Mon, Oct 23, 2017 at 11:25:05AM +0200, tomas@tuxteam.de wrote: > > On Mon, Oct 23, 2017 at 09:17:11AM +0100, Joe wrote: > > > On Sun, 22 Oct 2017 22:12:03 -0400 > > > Roberto C. Sánchez <roberto@debian.org> wrote: > > > > [...] > > > > > > I did find a page on the Debian wiki [0] which recommends setting the > > > > immutable attribute on /etc/resolv.conf. However, that feels like an > > > > ugly hack. > > > > > > > > > > It most certainly is, and shouldn't be necessary in your case. > > > > I've used that approach sometimes and regularly recommend it. > > > > That said, my main intention is to *debug* the problem, i.e. to > > provoke an error message in some log file or whatever, to learn which > > process is (undesirably?) mutating some file. Most of the time this > > leads to learning some config option to not do that mutation in the > > first place (or to some understanding on why that mutation is a Good > > Thing after all and to a better way of solving my real, underlying > > problem). > > > > Only in exceptional cases I had to "leave in" the immutable attribute > > as a permanent "solution". > > > > So, I edited resolv.conf to my preference and then made it immutable > with `chattr +i /etc/resolv.conf`. Several hours later the name server > was changed back to the ISP router's address. That is very odd. Yet > even more odd is that this time the domain and search options were left > untouched. Previously, the domain and search would get wiped (because > the ISP router doesn't push those options). So if you: $ ls -l --full-time /etc/resolv.conf and then look at what happened at that precise time in /var/log/syslog or wherever your logs are being written. What took place? Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | Roberto C. Sánchez <roberto@debian.org> |
|---|---|
| Date | 2017-10-24 05:10 +0200 |
| Message-ID | <uDXLj-5Rz-5@gated-at.bofh.it> |
| In reply to | #188227 |
On Mon, Oct 23, 2017 at 07:26:38PM -0500, David Wright wrote: > > So if you: > $ ls -l --full-time /etc/resolv.conf > and then look at what happened at that precise time in /var/log/syslog > or wherever your logs are being written. What took place? > Most recently the problem happened at 22:29:16.419070807. Looking in all of my logs (not just syslog), the only thing that happened near that time was that a host on my LAN sent a DHCPREQUEST at 22:29:07 (which the DHCP server answered with a DHCPACK) and then at 22:29:58 Shorewall dropped an attempt to connect to port 2433 from a host on the Internet. I have already changed resolv.conf back to my preferred configuration and I will check again for correlated log entries when it is changed again. Regards, -Roberto -- Roberto C. Sánchez
[toc] | [prev] | [next] | [standalone]
| From | Roberto C. Sánchez <roberto@debian.org> |
|---|---|
| Date | 2017-10-24 09:20 +0200 |
| Message-ID | <uE1Ff-8hv-3@gated-at.bofh.it> |
| In reply to | #188231 |
On Mon, Oct 23, 2017 at 11:05:03PM -0400, Roberto C. Sánchez wrote: > On Mon, Oct 23, 2017 at 07:26:38PM -0500, David Wright wrote: > > > > So if you: > > $ ls -l --full-time /etc/resolv.conf > > and then look at what happened at that precise time in /var/log/syslog > > or wherever your logs are being written. What took place? > > > Most recently the problem happened at 22:29:16.419070807. Looking in > all of my logs (not just syslog), the only thing that happened near that > time was that a host on my LAN sent a DHCPREQUEST at 22:29:07 (which the > DHCP server answered with a DHCPACK) and then at 22:29:58 Shorewall > dropped an attempt to connect to port 2433 from a host on the Internet. > > I have already changed resolv.conf back to my preferred configuration > and I will check again for correlated log entries when it is changed > again. > So, it happened again at 03:02:26 that resolv.conf was changed. I looked in the logs and found nothing that appeared to be a close correlation. There were several DHCPREQUEST/DHCPACK exchanges before and after, but my network has a near constant stream of such exchanges with no more than 3 or 4 minutes between exchanges. It seems unlikely to me that the DHCPREQUEST/DHCPACK exchange could be the cuplrit. I am fairly out of ideas at this point. Anyone? Regards, -Roberto -- Roberto C. Sánchez
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <wooledg@eeg.ccf.org> |
|---|---|
| Date | 2017-10-24 14:20 +0200 |
| Message-ID | <uE6lz-2Kc-11@gated-at.bofh.it> |
| In reply to | #188234 |
On Mon, Oct 23, 2017 at 07:33:01PM -0400, Roberto C. Sánchez wrote: > So, I edited resolv.conf to my preference and then made it immutable > with `chattr +i /etc/resolv.conf`. Several hours later the name server > was changed back to the ISP router's address. That is very odd. ls -ld /etc/resolv.conf On Tue, Oct 24, 2017 at 03:15:30AM -0400, Roberto C. Sánchez wrote: > > > So if you: > > > $ ls -l --full-time /etc/resolv.conf > > > and then look at what happened at that precise time in /var/log/syslog > > > or wherever your logs are being written. What took place? And what does the ls actually SHOW? > So, it happened again at 03:02:26 that resolv.conf was changed. ls -ld /etc/resolv.conf If it's a SYMLINK and you made the symlink immutable, well, that would explain a whole lot.
[toc] | [prev] | [next] | [standalone]
| From | Roberto C. Sánchez <roberto@debian.org> |
|---|---|
| Date | 2017-10-24 14:30 +0200 |
| Message-ID | <uE6vf-2Nk-1@gated-at.bofh.it> |
| In reply to | #188238 |
On Tue, Oct 24, 2017 at 08:12:20AM -0400, Greg Wooledge wrote: > On Mon, Oct 23, 2017 at 07:33:01PM -0400, Roberto C. Sánchez wrote: > > So, I edited resolv.conf to my preference and then made it immutable > > with `chattr +i /etc/resolv.conf`. Several hours later the name server > > was changed back to the ISP router's address. That is very odd. > > ls -ld /etc/resolv.conf > > > On Tue, Oct 24, 2017 at 03:15:30AM -0400, Roberto C. Sánchez wrote: > > > > So if you: > > > > $ ls -l --full-time /etc/resolv.conf > > > > and then look at what happened at that precise time in /var/log/syslog > > > > or wherever your logs are being written. What took place? > > And what does the ls actually SHOW? > > > So, it happened again at 03:02:26 that resolv.conf was changed. > > ls -ld /etc/resolv.conf > > If it's a SYMLINK and you made the symlink immutable, well, that would > explain a whole lot. > It is not a symlink: debian:/etc# ls -l --full-time /etc/resolv.conf -rw-r--r-- 1 root root 25 2017-10-24 07:07:54.513938427 -0400 /etc/resolv.conf debian:/etc# file /etc/resolv.conf /etc/resolv.conf: ASCII text Regards, -Roberto -- Roberto C. Sánchez
[toc] | [prev] | [next] | [standalone]
| From | Curt <curty@free.fr> |
|---|---|
| Date | 2017-10-24 19:10 +0200 |
| Message-ID | <uEaSe-5Aa-9@gated-at.bofh.it> |
| In reply to | #188239 |
On 2017-10-24, Roberto C Sánchez <roberto@debian.org> wrote: >> >> If it's a SYMLINK and you made the symlink immutable, well, that would >> explain a whole lot. > > It is not a symlink: > > debian:/etc# ls -l --full-time /etc/resolv.conf > -rw-r--r-- 1 root root 25 2017-10-24 07:07:54.513938427 -0400 /etc/resolv.conf > debian:/etc# file /etc/resolv.conf > /etc/resolv.conf: ASCII text Of course you're certain the file indeed has the immutable attribute (lsattr) set, in which case I wonder vaguely to myself how it could be possible for the file to have been subsequently modified. The plot sickens. > Regards, > > -Roberto > -- "A simpering Bambi narcissist and a thieving, fanatical Albanian dwarf." Christopher Hitchens, commenting shortly after the nearly concurrent deaths of Lady Diana and Mother Theresa.
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2017-10-24 18:50 +0200 |
| Message-ID | <uEayS-5ey-5@gated-at.bofh.it> |
| In reply to | #188234 |
On Tue 24 Oct 2017 at 03:15:30 (-0400), Roberto C. Sánchez wrote: > On Mon, Oct 23, 2017 at 11:05:03PM -0400, Roberto C. Sánchez wrote: > > On Mon, Oct 23, 2017 at 07:26:38PM -0500, David Wright wrote: > > > > > > So if you: > > > $ ls -l --full-time /etc/resolv.conf > > > and then look at what happened at that precise time in /var/log/syslog > > > or wherever your logs are being written. What took place? > > > > > Most recently the problem happened at 22:29:16.419070807. Looking in > > all of my logs (not just syslog), the only thing that happened near that > > time was that a host on my LAN sent a DHCPREQUEST at 22:29:07 (which the > > DHCP server answered with a DHCPACK) and then at 22:29:58 Shorewall > > dropped an attempt to connect to port 2433 from a host on the Internet. > > > > I have already changed resolv.conf back to my preferred configuration > > and I will check again for correlated log entries when it is changed > > again. > > > So, it happened again at 03:02:26 that resolv.conf was changed. I > looked in the logs and found nothing that appeared to be a close > correlation. There were several DHCPREQUEST/DHCPACK exchanges before > and after, but my network has a near constant stream of such exchanges > with no more than 3 or 4 minutes between exchanges. It seems unlikely > to me that the DHCPREQUEST/DHCPACK exchange could be the cuplrit. Here, with resolvconf installed, resolv.conf is updated to within one second of the DHCPREQUEST/DHCPACK exchange. I only get these exchanges every few minutes when this laptop is misbehaving (the wifi is flaky and the signal strength gets low). Normally it's ten or twelve hours which I assume is when the lease expires. > I am fairly out of ideas at this point. Anyone? Perhaps you could watch the file with inotifywait, and capture a ps and maybe even a lsof listing at that moment. Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | Roberto C. Sánchez <roberto@debian.org> |
|---|---|
| Date | 2017-10-25 15:30 +0200 |
| Message-ID | <uEtUS-ot-5@gated-at.bofh.it> |
| In reply to | #188244 |
On Tue, Oct 24, 2017 at 11:49:21AM -0500, David Wright wrote: > > Perhaps you could watch the file with inotifywait, and capture > a ps and maybe even a lsof listing at that moment. > I have both inotify-hookable and incrond watching the file and the output of `lsof /etc/resolv.conf` and `ps -ef` triggered by both of those for any access if resolv.conf (whether read or write) does not show anything related to resolv.conf at all, except for the incron and inotify-hookable processes watching the file. Regards, -Roberto -- Roberto C. Sánchez
[toc] | [prev] | [next] | [standalone]
| From | Gene Heskett <gheskett@shentel.net> |
|---|---|
| Date | 2017-10-25 15:40 +0200 |
| Message-ID | <uEu4x-rw-1@gated-at.bofh.it> |
| In reply to | #188288 |
On Wednesday 25 October 2017 09:19:04 Roberto C. Sánchez wrote: > On Tue, Oct 24, 2017 at 11:49:21AM -0500, David Wright wrote: > > Perhaps you could watch the file with inotifywait, and capture > > a ps and maybe even a lsof listing at that moment. > > I have both inotify-hookable and incrond watching the file and the > output of `lsof /etc/resolv.conf` and `ps -ef` triggered by both of > those for any access if resolv.conf (whether read or write) does not > show anything related to resolv.conf at all, except for the incron and > inotify-hookable processes watching the file. > > Regards, > > -Roberto And I have a thought. The immutable bit may be hiding the attempted access from inotifywait because it may be set to only report success at changing the file. I am not familiar with inotify-hookable. But inotifywait has several options so I'd study the man page to see if a different one may be more suitable to catch this perp. I use it here to tell kmail about incoming mail by triggering on the closing of the /var/spool/mail/name file(s) after procmail has delivered it. It has worked well for that for at least a decade now. But thats not germane to this, only that I am familiar with it to that extent. Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene>
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2017-10-25 20:50 +0200 |
| Message-ID | <uEyUx-3l2-3@gated-at.bofh.it> |
| In reply to | #188293 |
On Wed 25 Oct 2017 at 09:38:54 (-0400), Gene Heskett wrote: > On Wednesday 25 October 2017 09:19:04 Roberto C. Sánchez wrote: > > > On Tue, Oct 24, 2017 at 11:49:21AM -0500, David Wright wrote: > > > Perhaps you could watch the file with inotifywait, and capture > > > a ps and maybe even a lsof listing at that moment. > > > > I have both inotify-hookable and incrond watching the file and the > > output of `lsof /etc/resolv.conf` and `ps -ef` triggered by both of > > those for any access if resolv.conf (whether read or write) does not > > show anything related to resolv.conf at all, except for the incron and > > inotify-hookable processes watching the file. > > > > Regards, > > > > -Roberto > > And I have a thought. The immutable bit may be hiding the attempted > access from inotifywait because it may be set to only report success at > changing the file. I am not familiar with inotify-hookable. But > inotifywait has several options so I'd study the man page to see if a > different one may be more suitable to catch this perp. I use it here to > tell kmail about incoming mail by triggering on the closing of > the /var/spool/mail/name file(s) after procmail has delivered it. It > has worked well for that for at least a decade now. > > But thats not germane to this, only that I am familiar with it to that > extent. I think that is correct. I would assume that the immutable attribution bit is seen as soon as the directory entry is consulted, whereas the inode is the item actually being watched for change. But if the OP is going to unset the attribution, I hope they'll post the lsattr output first: we've had no evidence posted here that an immutable file has been modified. Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | Roger Lynn <Roger@rilynn.me.uk> |
|---|---|
| Date | 2017-10-25 00:30 +0200 |
| Message-ID | <uEfRU-ca-1@gated-at.bofh.it> |
| In reply to | #188234 |
On 24/10/17 08:20, Roberto C. Sánchez wrote: > So, it happened again at 03:02:26 that resolv.conf was changed. I > looked in the logs and found nothing that appeared to be a close > correlation. There were several DHCPREQUEST/DHCPACK exchanges before > and after, but my network has a near constant stream of such exchanges > with no more than 3 or 4 minutes between exchanges. It seems unlikely > to me that the DHCPREQUEST/DHCPACK exchange could be the cuplrit. > > I am fairly out of ideas at this point. Anyone? Did you remove the resolvconf package, which is responsible for updating resolv.conf in dynamic networking environments? Roger
[toc] | [prev] | [next] | [standalone]
| From | Roberto C. Sánchez <roberto@debian.org> |
|---|---|
| Date | 2017-10-25 04:10 +0200 |
| Message-ID | <uEjiN-2mJ-1@gated-at.bofh.it> |
| In reply to | #188253 |
On Tue, Oct 24, 2017 at 10:18:00PM +0100, Roger Lynn wrote: > On 24/10/17 08:20, Roberto C. Sánchez wrote: > > So, it happened again at 03:02:26 that resolv.conf was changed. I > > looked in the logs and found nothing that appeared to be a close > > correlation. There were several DHCPREQUEST/DHCPACK exchanges before > > and after, but my network has a near constant stream of such exchanges > > with no more than 3 or 4 minutes between exchanges. It seems unlikely > > to me that the DHCPREQUEST/DHCPACK exchange could be the cuplrit. > > > > I am fairly out of ideas at this point. Anyone? > > Did you remove the resolvconf package, which is responsible for updating > resolv.conf in dynamic networking environments? > https://lists.debian.org/debian-user/2017/10/msg00787.html -- Roberto C. Sánchez
[toc] | [prev] | [next] | [standalone]
| From | Roberto C. Sánchez <roberto@debian.org> |
|---|---|
| Date | 2017-10-23 13:00 +0200 |
| Message-ID | <uDICB-4Jk-5@gated-at.bofh.it> |
| In reply to | #188197 |
On Mon, Oct 23, 2017 at 09:17:11AM +0100, Joe wrote:
> Roberto C. Sánchez <roberto@debian.org> wrote:
>
>
> > Can anyone point out what it is that I am missing here?
>
> Not 'missing', you probably have the package resolvconf installed, and
> with your network configuration, you don't need it. It's not certain,
> but it seems to be the culprit in most of these cases. There is
> undoubtedly a way to beat it into submission, but it's not widely
> known. There was another recent thread on this matter.
>
Ah yes, I forgot to mention that. I do not have resolvconf installed:
debian:/etc# apt-cache policy resolvconf
resolvconf:
Installed: (none)
Candidate: 1.79
Version table:
1.79 500
500 http://ftp.us.debian.org:3142/debian stretch/main amd64 Packages
> If you're bringing up and taking down random interfaces, such as VPN
> tunnels and wifi, then you do want to keep shifting your DNS server, so
> resolvconf is appropriate on a laptop, but probably not on a fixed
> workstation.
>
I agree. I make sure to only install resolvconf on my laptops since
those are the only machines I have that move from one network to
another.
Regards,
-Roberto
--
Roberto C. Sánchez
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <wooledg@eeg.ccf.org> |
|---|---|
| Date | 2017-10-23 18:10 +0200 |
| Message-ID | <uDNsB-7Tv-3@gated-at.bofh.it> |
| In reply to | #188197 |
On Mon, Oct 23, 2017 at 11:48:36AM -0400, Jude DaShiell wrote: > If you've got dynamic ip addresses as many of us do, that file has to change > to keep your internet connection up. That's not true. The resolv.conf file does not necessarily have to change when your IP addresses change. The primary example of a non-changing resolv.conf would be someone running a local resolver listening on 127.0.0.1 -- exactly like the original poster's case.
[toc] | [prev] | [next] | [standalone]
| From | Jude DaShiell <jdashiel@panix.com> |
|---|---|
| Date | 2017-10-23 18:10 +0200 |
| Message-ID | <uDNsB-7Tv-5@gated-at.bofh.it> |
| In reply to | #188197 |
If you've got dynamic ip addresses as many of us do, that file has to change to keep your internet connection up. On Mon, 23 Oct 2017, Joe wrote: > Date: Mon, 23 Oct 2017 04:17:11 > From: Joe <joe@jretrading.com> > To: debian-user@lists.debian.org > Subject: Re: Why does resolv.conf keep changing? > Resent-Date: Mon, 23 Oct 2017 08:54:41 +0000 (UTC) > Resent-From: debian-user@lists.debian.org > > On Sun, 22 Oct 2017 22:12:03 -0400 > Roberto C. S?nchez <roberto@debian.org> wrote: > >> So, I just upgraded my main router/firewall machine to Stretch. >> Following the upgrade my /etc/resolv.conf settings appear to track the >> DHCP options obtained by one of the two interfaces. No matter what I >> try I can't get the /etc/resolv.conf settings to remain as I would >> like them. >> >> The machine has two network interfaces: one on the Internt side which >> connects to my ISP-provided equipment and which obtains its address >> via DHCP, another on the LAN side which is statically configured. >> >> My /etc/network/interfaces looks like this (192.168.174.0/24 is my LAN >> subnet): >> >> auto lo >> iface lo inet loopback >> >> auto eth0 >> iface eth0 inet static >> address 192.168.174.1 >> netmask 255.255.255.0 >> broadcast 192.168.174.255 >> >> auto eth1 >> iface eth1 inet dhcp >> >> My /etc/resolv.conf looks like this: >> >> domain example.com >> search example.com. >> nameserver 127.0.0.1 >> >> The reason for "nameserver 127.0.0.1" is that I run my own instance of >> bind which acts as a caching server and also serves my own internal >> zones. Prior to the recent upgrade to Stretch everything worked >> normally. That is, whatever I put in /etc/resolv.conf was left as I >> configured it. Following my recent Stretch upgrade I found my >> resolv.conf had been changed to just this (192.168.63.1/24 is the >> subnet used by the ISP equipment): >> >> nameserver 192.168.63.1 >> >> That has the effect of not allowing processes running on that machine >> (the router/firewall) to properly resolve internal DNS addresses. >> Other machines on my network are fine since they get their name >> servers set by the internal DHCP server which is configured with the >> name server address 192.168.174.1. This DHCP server is different >> from the embedded DHCP server that runs on my ISP's device. >> >> I have tried two different things. First, I added this directive to >> /etc/network/interfaces under the eth0 stanza: >> >> dns-nameservers 127.0.0.1 >> >> That did not appear to have any effect because taking eth0 and eth1 >> down and then bringing them back up still results in resolv.conf >> pointing to the ISP router as its name server. Additionally, after >> the interfaces are up even if I manually change resolv.conf, >> something comes along sometime later and undoes my changes. >> >> The second thing I tried was adding to /etc/dhcp/dhclient.conf: >> >> supersede domain-name example.com; >> supersede domain-search example.com.; >> supersede domain-name-servers 127.0.0.1; >> >> This similarly has no lasting effect, which is really surprising to >> me. >> >> I did find a page on the Debian wiki [0] which recommends setting the >> immutable attribute on /etc/resolv.conf. However, that feels like an >> ugly hack. >> > > It most certainly is, and shouldn't be necessary in your case. > >> Can anyone point out what it is that I am missing here? > > Not 'missing', you probably have the package resolvconf installed, and > with your network configuration, you don't need it. It's not certain, > but it seems to be the culprit in most of these cases. There is > undoubtedly a way to beat it into submission, but it's not widely > known. There was another recent thread on this matter. > > If you're bringing up and taking down random interfaces, such as VPN > tunnels and wifi, then you do want to keep shifting your DNS server, so > resolvconf is appropriate on a laptop, but probably not on a fixed > workstation. > > --
[toc] | [prev] | [next] | [standalone]
| From | Gene Heskett <gheskett@shentel.net> |
|---|---|
| Date | 2017-10-23 23:10 +0200 |
| Message-ID | <uDS8W-2p4-19@gated-at.bofh.it> |
| In reply to | #188210 |
On Monday 23 October 2017 11:48:36 Jude DaShiell wrote: > If you've got dynamic ip addresses as many of us do, that file has to > change to keep your internet connection up. > This true, but all the isp's I have dealt with over the last 23 years, have all assigned that dynamic address BASED on the MAC of the device doing the requesting. So while my router(s) do use dhcp to get its internet address, I can even swap routers as long as I clone the originals MAC address into the replacement. So my web page, (see the sig) which is on this machine, has for the most part just worked for much of a decade now. There hasn't been zero downtime of course, perhaps .01% of the time. > On Mon, 23 Oct 2017, Joe wrote: > > Date: Mon, 23 Oct 2017 04:17:11 > > From: Joe <joe@jretrading.com> > > To: debian-user@lists.debian.org > > Subject: Re: Why does resolv.conf keep changing? > > Resent-Date: Mon, 23 Oct 2017 08:54:41 +0000 (UTC) > > Resent-From: debian-user@lists.debian.org > > > > On Sun, 22 Oct 2017 22:12:03 -0400 > > > > Roberto C. S?nchez <roberto@debian.org> wrote: > >> So, I just upgraded my main router/firewall machine to Stretch. > >> Following the upgrade my /etc/resolv.conf settings appear to track > >> the DHCP options obtained by one of the two interfaces. No matter > >> what I try I can't get the /etc/resolv.conf settings to remain as I > >> would like them. > >> > >> The machine has two network interfaces: one on the Internt side > >> which connects to my ISP-provided equipment and which obtains its > >> address via DHCP, another on the LAN side which is statically > >> configured. > >> > >> My /etc/network/interfaces looks like this (192.168.174.0/24 is my > >> LAN subnet): > >> > >> auto lo > >> iface lo inet loopback > >> > >> auto eth0 > >> iface eth0 inet static > >> address 192.168.174.1 > >> netmask 255.255.255.0 > >> broadcast 192.168.174.255 > >> > >> auto eth1 > >> iface eth1 inet dhcp > >> > >> My /etc/resolv.conf looks like this: > >> > >> domain example.com > >> search example.com. > >> nameserver 127.0.0.1 > >> > >> The reason for "nameserver 127.0.0.1" is that I run my own instance > >> of bind which acts as a caching server and also serves my own > >> internal zones. Prior to the recent upgrade to Stretch everything > >> worked normally. That is, whatever I put in /etc/resolv.conf was > >> left as I configured it. Following my recent Stretch upgrade I > >> found my resolv.conf had been changed to just this (192.168.63.1/24 > >> is the subnet used by the ISP equipment): > >> > >> nameserver 192.168.63.1 > >> > >> That has the effect of not allowing processes running on that > >> machine (the router/firewall) to properly resolve internal DNS > >> addresses. Other machines on my network are fine since they get > >> their name servers set by the internal DHCP server which is > >> configured with the name server address 192.168.174.1. This DHCP > >> server is different from the embedded DHCP server that runs on my > >> ISP's device. > >> > >> I have tried two different things. First, I added this directive > >> to /etc/network/interfaces under the eth0 stanza: > >> > >> dns-nameservers 127.0.0.1 > >> > >> That did not appear to have any effect because taking eth0 and eth1 > >> down and then bringing them back up still results in resolv.conf > >> pointing to the ISP router as its name server. Additionally, after > >> the interfaces are up even if I manually change resolv.conf, > >> something comes along sometime later and undoes my changes. > >> > >> The second thing I tried was adding to /etc/dhcp/dhclient.conf: > >> > >> supersede domain-name example.com; > >> supersede domain-search example.com.; > >> supersede domain-name-servers 127.0.0.1; > >> > >> This similarly has no lasting effect, which is really surprising to > >> me. > >> > >> I did find a page on the Debian wiki [0] which recommends setting > >> the immutable attribute on /etc/resolv.conf. However, that feels > >> like an ugly hack. > > > > It most certainly is, and shouldn't be necessary in your case. > > > >> Can anyone point out what it is that I am missing here? > > > > Not 'missing', you probably have the package resolvconf installed, > > and with your network configuration, you don't need it. It's not > > certain, but it seems to be the culprit in most of these cases. > > There is undoubtedly a way to beat it into submission, but it's not > > widely known. There was another recent thread on this matter. > > > > If you're bringing up and taking down random interfaces, such as VPN > > tunnels and wifi, then you do want to keep shifting your DNS server, > > so resolvconf is appropriate on a laptop, but probably not on a > > fixed workstation. Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene>
[toc] | [prev] | [next] | [standalone]
Page 1 of 7 [1] 2 3 4 5 6 7 Next page →
Back to top | Article view | linux.debian.user
csiph-web