NetworkManager vs Cacheing nameserver
I installed bind and tried to use it as a basic cacheing nameserver,
which in principal just means running named and
pointing /etc/resolv.conf to 127.0.0.1. However resolv.conf keeps
getting overwritten by NetworkManager, and I notice an excessive number
of "Resolving foo ..." messages from Firefox and Chrome, i.e. no
cacheing is being done as far as I can tell. Note that I didn't touch
named.conf or any other config files.
How does one convince NM not to interfere with resolv.conf? (Please
don't tell me to uninstall NM, that's not going to happen).
poc
Similar Topics
| Topic | Started |
|---|---|
| How to pass two routers | 1 hour 22 min ago |
| libselinux 2.0.94-2 testing | 12 hours 3 min ago |
| https://koji.fedoraproject.org -> invalid certificate | 12 hours 40 min ago |
| oowriter won't execute as user | 14 hours 4 min ago |
| Creating an audio CD | 14 hours 10 min ago |
| GNOME PDF creator | 15 hours 21 min ago |
| Fwd: Undelivered Mail Returned to Sender | 15 hours 40 min ago |
| how to load a module | 17 hours 17 min ago |
| Adobe Flash Player 10 | 17 hours 18 min ago |
24 comments
Re: NetworkManager vs Cacheing nameserver
Are you able to configure your DHCP server? On my network, my DHCP
server tells all the clients to use my DNS server, because that's how
I've configured it, and everything is hunky dory.
If you're trying to ignore information from your DHCP server (because
you can't configure it), then you need to play with configuring your
DHCP client. That used to be by the /etc/dhclient.conf file, but I seem
to recall that you'd put a special copy of the options into some other
location, one read by Network Manager.
If the domains being resolved set silly zero-second (or similar) record
life data, then your caching name server is going to honour that. But
are you sure that those warnings are about the same records over and
over?
I've noticed that, at least in the past, Firefox will do some of its own
caching. i.e. The next time it needs a connection to example.com,
Firefox uses the same IP without consulting a DNS server. It's been
necessary to quit and restart Firefox to test changes to DNS records.
You might want to play with the dig tool and your name server.
Re: NetworkManager vs Cacheing nameserver
Not in general. This is a netbook and I'm moving around. On my home
desktop I have a wired connection and IIRC everything Just Works.
There is no dhclient.conf file anywhere in the system.
I haven't checked in detail but I'll make a note of that.
I'm using Chrome at the moment, as it's lighter weight on a netbook.
I've been using dig to check lookups.
poc
Re: NetworkManager vs Cacheing nameserver
System --> Preferences --> Network Connections
Pick the type of interface, and then the specific interface.
Highlight it and click on edit.
Under the IPv4 Settings, change the Method drop-down to "Automatic
(DHCP) address only". If you are using IPv6, then change that
drop-down to address only.
Mikkel
Re: NetworkManager vs Cacheing nameserver
That worked for a while, then reverted.
poc
Re: NetworkManager vs Cacheing nameserver
Patrick O'Callaghan:
Sounds like you have a bug to report, then. That appears to be the only
way to add DHCP client override options with NetworkManager.
Anything else would be a workaround. e.g. Run a DHCP server on the
laptop as a relay server, with local override options.
Re: NetworkManager vs Cacheing nameserver
Tim, the bug was in my head. As I mentioned in my last post to this
thread, I had neglected to fill in the DNS field in the NM panel. That's
what finally did the trick, after restarting NM. I subsequently rebooted
just to check, and the change is preserved.
Thanks for your help.
poc
Re: NetworkManager vs Cacheing nameserver
I may be stating the obvious or missed it that you tried this ...
But did you try this:
In the NM applet when editing config:
under IPV4 settings set
method -> Automatic (DHCP) addresses only
Then fill in the DNS servers you want to use (127.0.0.1)
And the search domains:
I do this and my resolv.conf is never touched.
gene/
Re: NetworkManager vs Cacheing nameserver
I had tried selecting the method but hadn't actually filled in the DNS
field. It worked for a while and was then overwritten. I'll try it as
you suggest.
poc
Re: NetworkManager vs Cacheing nameserver
There's a suggestion that a resolv.conf.save file will be copied to
resolv.conf each reboot. You could try that file as a reset to (your)
normal options for your configuration.
Re: NetworkManager vs Cacheing nameserver
Dumb question - do you have more then one NIC, or more then one
profile for one NIC?
I believe if you have more then one wireless profile, (Different
SSIDs) then you have to edit each one. I am not sure, but I suspect
that if one profile changes it, it does not get changed back.
Mikkel
Re: NetworkManager vs Cacheing nameserver
Nope. I only use the WiFi interface on this machine. It obviously has a
physical eth0 interface as well, but that's never used.
In theory that may be true (for roaming) but for now I'd be happy to get
just one working.
poc
Re: NetworkManager vs Cacheing nameserver
On Tue, 05 Jan 2010 00:39:26 +0000
Don't know for sure how to make interfaces managed by NM
stop doing it, but for my non-NM system I still have to
prevent resolv.conf from being scrogged by setting
PEERDNS=no
in my /etc/sysconfig/network-scripts/ifcfg-eth0 file.
Note that after you change this (if it works) you may still
have to fix the resolv.conf file two or three more times
after reboots because it has the old version of resolv.conf
stashed somewhere and keeps copying it back even after you
change the PEERDNS option.
The big hammer for preventing resolv.conf mods (and
other files as well) is:
chattr +i /etc/resolv.conf
not even root can change it after that (though root
can do a chattr -i to put it back the way it was).
Re: NetworkManager vs Cacheing nameserver
resolv.conf is overwritten by dhclient, whether the interface is is
NM-managed or not, so your "PEERDNS=no" solution will work for the OP.
Re: NetworkManager vs Cacheing nameserver
That seems to be working for the moment, but there's an element of magic
in it that makes me nervous. The default named.conf file is set up as a
simple cacheing nameserver for local queries, but where does named do
its recursive lookups if not from the DHCP service?
poc
Re: NetworkManager vs Cacheing nameserver
On Tue, 05 Jan 2010 14:30:02 +0000
If you want to add the name servers specified by DHCP to lookups,
then you don't want your resolv.conf file to be unmodified,
instead you want NM to modify it "correctly", like by
leaving 127.0.0.1 as one nameserver and adding additional
nameservers. <sarcasm> How to get NM to do this is no doubt described
fully in the extensive NetworkManager documentation. </sarcasm>
With bind configured as a cacheing server, there is usually
a "forwarders" section in named.conf that points to the DNS
servers it should look at. These aren't affected by NM
in any way I know of (though it might be nifty if there
was some way for NM to add and subtract forwarders dynamically).
Don't know if that is possible or not. I suppose it could
do something drastic like modify the named.conf file and
restart bind.
Re: NetworkManager vs Cacheing nameserver
On Tue, Jan 05, 2010 at 09:54:54 -0500,
I don't belive that is correct. I think the fallback servers are for
when a connection to a name server fails. If it returns nxdomain, other
dns servers aren't supposed to be checked.
If you want local A records, then you need a local dns server that returns
information for locally defined domains and does something else (either
forward to another dns server or do iterative lookups using the root zone
hints) for nonlocal domains.
Re: NetworkManager vs Cacheing nameserver
Quite.
There isn't. This is the default, unmodified named.conf.
I've now rebooted to check, and /etc/resolv.conf has again been
overwritten by NM, despite the PEERDNS=no line in the ifcfg file, i.e.
it has reverted to what it was. NM seems to be calling dhclient with its
own private config file, the whereabouts of which are non-obvious.
poc
Re: NetworkManager vs Cacheing nameserver
Strange. You might then need to set the DNS server through the NM GUI.
Re: NetworkManager vs Cacheing nameserver
You might want to take this question to the NetworkManager list at
gnome.org. The developers hang out there--if it's a bug, they'd
probably like to know about it. If it's by design, they can probably
explain it.
Re: NetworkManager vs Cacheing nameserver
I may do that. However I'm still not able to say it's a bug. I can't
believe that no-one has ever tried to do this before as it's so obvious,
so I was hoping simply to learn the Right Way To Do It.
poc
Re: NetworkManager vs Cacheing nameserver
On Tue, 05 Jan 2010 15:24:00 +0000
So that probably means you are simply talking directly
to the root DNS servers and should be able to lookup
any public addresses. The problem you'd have with only
using localhost for lookups would show up if you did
something like a VPN connection to a corporate network
and wanted to lookup names in that local network. If
you never do that, forcing resolv.conf to be immutable
with chattr might work OK.
Re: NetworkManager vs Cacheing nameserver
It might, in fact it probably would, but it's hard to believe that that
is the way you're supposed to do this.
poc
Re: NetworkManager vs Cacheing nameserver
On Wed, 06 Jan 2010 00:26:00 +0000
I'm sure it isn't, but it is easy and it works (except on opensuse
where the whole boot process comes to a screeching halt when it can't
write resolv.conf :-).
If they wanted people to know the right way to fix it, then instead
of just a comment saying "resolv.conf generated by NetworkManager"
they would actually put in a comment describing how to convince
NetworkManager to generate the correct resolv.conf file, (but that's
just what they'd expect us to do! :-).
Re: NetworkManager vs Cacheing nameserver
Following "Mail Lists"' suggestion I filled in the DNS field in the
nm-applet, after selecting the appropriate DHCP method. After restarting
NM I see that resolv.conf now says:
$ cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 127.0.0.1
which is encouraging. We'll see if it stays that way and isn't
overwritten.
poc