Bug 205783 - name resolution with caching nameserver approach is broken
name resolution with caching nameserver approach is broken
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dan Williams
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-09-08 10:39 EDT by Thomas M Steenholdt
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version: 0.6.5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-31 13:51:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Thomas M Steenholdt 2006-09-08 10:39:43 EDT
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.
Comment 1 Sergio Monteiro Basto 2006-09-19 15:39:18 EDT
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
Comment 2 Thomas M Steenholdt 2006-09-19 16:07:27 EDT
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.
Comment 3 Sergio Monteiro Basto 2006-09-24 20:46:59 EDT
how I can change NetworkManager to put in /etc/resolv.conf like was before or
with nameserver give by dhcpd 
Comment 4 Sergio Monteiro Basto 2006-10-07 21:24:56 EDT
I found the solution , chkconfig NetworkManager off
chkconfig network on
and forget about NetworkManager 
Comment 5 Sergio Monteiro Basto 2007-01-17 10:26:26 EST
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 
Comment 6 Sergio Monteiro Basto 2007-10-31 12:47:46 EDT
please close the bug ! 
since #5 (2007-01-17) , this is working , without any complain 
Comment 7 Dan Williams 2007-10-31 13:51:42 EDT
ok, thanks

Note You need to log in before you can comment on or make changes to this bug.