Description of problem: The protocol standards dictate, that DHCP provided nameservers should be queried in order, so that the primary DNS is ALWAYS used and secondary DNS is only used in the event that the primary fails. When using NetworkManager using the caching nameserver approach however, the DNS servers are added as forwarders which does not work like this. These are queried interchangably using a round-robin method or whatever. The end result is that a mixed nameserver setup where you have an internal nameserver as primary and an external nameserver as secondary just doesn't work reliably. There appears to be no way to make sure the primary/secondary order is followed, meaning that as often as not, the external DNS is queried for local-only names (like *.domain.local or something) that can't be found and are then cached as negative results. This is no good. Perhaps we could hack named in place to follow the primary/secondary order in some way or perhaps we can base the caching nameserver on something other than bind, that already works this way? I've filed this bug against NetworkManager rather than bind, since bind really behaves as it should (AFAIK) and the problem lies in the way NetworkManager uses it. Feel free to correct me. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. have you dhcp server serve an internal DNS as primary and an external one as secondary 2. connect a NetworkManager (caching nameserver setup) enabled ws 3. start pinging local names and wait for failure Actual results: at some point name resolution will fail because the bind based caching nameserver does not follow the primary, secondary scheme that we expect but uses round robin or something similar to switch between forwarders. Expected results: our primary should always be queried first. secondary should only be queried if the primary fails.
yap, I got same problem, I have a laptop when arrive to office , I got sep 19 20:16:28 localhost NetworkManager: <information> nameserver 10.134.x.x Sep 19 20:16:28 localhost named[1796]: D-BUS: dhclient for interface eth0 acquired new lease - creating forwarders. Sep 19 20:16:28 localhost NetworkManager: <information> nameserver 10.134.x.x Sep 19 20:16:28 localhost NetworkManager: <information> nameserver 194.65.x.x but cat /etc/resolv.conf # generated by NetworkManager, do not edit! ; Use a local caching nameserver controlled by NetworkManager search blabla.local nameserver 127.0.0.1 now I have : /usr/sbin/namedGetForwarders . 10.134.x.x 10.134.x.x 194.65.x.x but in morning, local names got failure I just want the /etc/resolv.conf don't Use a local caching nameserver
Yeah - I installed NetworkManager-0.6.4-5, rebuilt locally from development repository. This one makes use of named caching nameserver optional which is both good and bad. The good thing is that resolve order is maintained correctly. The bad thing is that the most apps (limitation in glibs iirc) needs to be restarted to pick up new nameservers. the caching nameserver solution solves this issue. The ideal way to solve this is to make named obey the resolve order or make NetworkManager use a different caching nameserver that obeys the resolve order. I want to use the caching nameserver solution - but can't because of this issue.
how I can change NetworkManager to put in /etc/resolv.conf like was before or with nameserver give by dhcpd
I found the solution , chkconfig NetworkManager off chkconfig network on and forget about NetworkManager
ok I have caching-nameserver-9.3.3-0.1.rc3.fc6.i386.rpm and NetworkManager works for me . Thanks, Sorry for my other nasty comment. Now, I can chkconfig network off and chkconfig NetworkManager on without problems
please close the bug ! since #5 (2007-01-17) , this is working , without any complain
ok, thanks