Bug 206604 - Named as caching-nameserver for NetwotkManager fails to resolve hostnames
Named as caching-nameserver for NetwotkManager fails to resolve hostnames
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dan Williams
bzcl34nup
:
: 196962 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-09-15 04:11 EDT by Tadej Janež
Modified: 2008-05-06 20:50 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 20:50:50 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)
namedGetForwarders after boot (41 bytes, text/plain)
2006-09-19 10:05 EDT, Tadej Janež
no flags Details
namedGetForwarders after named restart (41 bytes, text/plain)
2006-09-19 10:06 EDT, Tadej Janež
no flags Details
messages file including info about named start and restart (20.56 KB, text/plain)
2006-09-19 10:07 EDT, Tadej Janež
no flags Details
named.conf (1.28 KB, text/plain)
2006-09-20 05:22 EDT, Tadej Janež
no flags Details
named.caching-nameserver.conf (1.06 KB, application/x-extension-conf)
2006-09-20 05:23 EDT, Tadej Janež
no flags Details
named.rfc1912.zones (948 bytes, text/plain)
2006-09-20 05:24 EDT, Tadej Janež
no flags Details
a proposed patch (4.99 KB, patch)
2006-10-13 08:15 EDT, Martin Stransky
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 381897 None None None Never

  None (edit)
Description Tadej Janež 2006-09-15 04:11:33 EDT
Description of problem:
After upgrading to bind-9.3.2-33.fc5 and caching-nameserver-9.3.2-33.fc5,
hostnames fail to resolve until I manually restart named.

Version-Release number of selected component (if applicable):
bind-9.3.2-33.fc5
caching-nameserver-9.3.2-33.fc5
NetworkManager-0.6.4-1.fc5

How reproducible:
Start the computer normally

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Looking at the messages log file I see the following difference between the 2
named startups:

- First startup:
Sep 15 08:36:24 localhost named[1732]: starting BIND 9.3.2 -u named -D
Sep 15 08:36:24 localhost named[1732]: found 1 CPU, using 1 worker thread
Sep 15 08:36:25 localhost named[1732]: loading configuration from '/etc/named.conf'
Sep 15 08:36:26 localhost named[1732]: not listening on any interfaces
Sep 15 08:36:27 localhost named[1732]: command channel listening on 127.0.0.1#953
Sep 15 08:36:27 localhost named[1732]: zone 0.in-addr.arpa/IN: loaded serial 42
Sep 15 08:36:28 localhost named[1732]: zone 0.0.127.in-addr.arpa/IN: loaded
serial 1997022700
Sep 15 08:36:29 localhost named[1732]: zone 255.in-addr.arpa/IN: loaded serial 42
Sep 15 08:36:29 localhost named[1732]: zone
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN:
loaded serial 1997022700
Sep 15 08:36:30 localhost named[1732]: zone localdomain/IN: loaded serial 42
Sep 15 08:36:31 localhost named[1732]: zone localhost/IN: loaded serial 42
Sep 15 08:36:32 localhost named[1732]: D-BUS dhcdbd subscription enabled.
Sep 15 08:36:32 localhost named[1732]: D-BUS service enabled.
Sep 15 08:36:33 localhost named[1732]: running
Sep 15 08:36:40 localhost named[1732]: D-BUS: dhclient for interface eth0
acquired new lease - creating forwarders.

Restart of named/second startup:
Sep 15 08:57:04 localhost named[1732]: rejected command channel message from
127.0.0.1#42932
Sep 15 08:57:04 localhost named[1732]: shutting down
Sep 15 08:57:04 localhost named[1732]: stopping command channel on 127.0.0.1#953
Sep 15 08:57:04 localhost named[1732]: exiting
Sep 15 08:57:07 localhost named[2209]: starting BIND 9.3.2 -u named -D
Sep 15 08:57:07 localhost named[2209]: found 1 CPU, using 1 worker thread
Sep 15 08:57:07 localhost named[2209]: loading configuration from '/etc/named.conf'
Sep 15 08:57:07 localhost named[2209]: listening on IPv4 interface lo, 127.0.0.1#53
Sep 15 08:57:07 localhost named[2209]: listening on IPv4 interface eth0,
172.28.9.245#53
Sep 15 08:57:07 localhost named[2209]: command channel listening on 127.0.0.1#953
Sep 15 08:57:07 localhost named[2209]: zone 0.in-addr.arpa/IN: loaded serial 42
Sep 15 08:57:07 localhost named[2209]: zone 0.0.127.in-addr.arpa/IN: loaded
serial 1997022700
Sep 15 08:57:07 localhost named[2209]: zone 255.in-addr.arpa/IN: loaded serial 42
Sep 15 08:57:07 localhost named[2209]: zone
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN:
loaded serial 1997022700
Sep 15 08:57:07 localhost named[2209]: zone localdomain/IN: loaded serial 42
Sep 15 08:57:07 localhost named[2209]: zone localhost/IN: loaded serial 42
Sep 15 08:57:07 localhost named[2209]: D-BUS dhcdbd subscription enabled.
Sep 15 08:57:07 localhost named[2209]: D-BUS service enabled.
Sep 15 08:57:07 localhost named[2209]: running
Sep 15 08:57:32 localhost NetworkManager: <WARNING>	 add_ip4_config_to_named ():
Could not set forwarders for zone '.'.  Error: 'No reply within specified time'. 

Is there a problem with 'not listening on any interfaces' because NetworkManager
hasn't initialised the interfaces yet and named isn't informed properly about
the running interfaces via D-Bus later on?
I saw similar comments in bug
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196962 but no resolution yet.
Note: I don't have SELinux packages installed.
Comment 1 Martin Stransky 2006-09-15 04:19:34 EDT
(In reply to comment #0)
> Is there a problem with 'not listening on any interfaces' because NetworkManager
> hasn't initialised the interfaces yet and named isn't informed properly about
> the running interfaces via D-Bus later on?

I guess this is the problem, thanks for the report.
Comment 2 Martin Stransky 2006-09-19 08:41:16 EDT
how many network interfaces (and which) do you use? Are they up when named is
starting? Do you use NM-VPN plug-in?

Please run /usr/sbin/namedGetForwarders after boor and after named restart and
attach the outputs here.
Comment 3 Tadej Janež 2006-09-19 10:03:23 EDT
I'm only using one network interface: eth0 (and loopback lo), but I also have an
external PCMCIA prism54 wireless card which is not attached at the moment.
#ifconfig
eth0      Link encap:Ethernet  HWaddr 00:08:02:69:86:D5
          inet addr:172.28.9.245  Bcast:172.28.255.255  Mask:255.255.0.0
          inet6 addr: fe80::208:2ff:fe69:86d5/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:556 errors:0 dropped:0 overruns:0 frame:0
          TX packets:485 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:314263 (306.8 KiB)  TX bytes:41411 (40.4 KiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:59 errors:0 dropped:0 overruns:0 frame:0
          TX packets:59 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:5274 (5.1 KiB)  TX bytes:5274 (5.1 KiB)

I'm using NetworkManager to manage my connections:
#chkconfig --list network
network         0:off   1:off   2:off   3:off   4:off   5:off   6:off
# chkconfig --list NetworkManager
NetworkManager  0:off   1:off   2:on    3:on    4:on    5:on    6:off
#chkconfig --list dhcdbd
dhcdbd          0:off   1:off   2:off   3:on    4:on    5:on    6:off
# chkconfig --list named
named           0:off   1:off   2:off   3:off   4:off   5:off   6:off

I think named is started before NetworkManger initializes eth0 interface,
however, this is somewhat strange because chkconfig says it is 'off'.
For details see messages attachment.

No, I don't use NM-VPN plug-in.
Comment 4 Tadej Janež 2006-09-19 10:05:23 EDT
Created attachment 136639 [details]
namedGetForwarders after boot
Comment 5 Tadej Janež 2006-09-19 10:06:05 EDT
Created attachment 136640 [details]
namedGetForwarders after named restart
Comment 6 Tadej Janež 2006-09-19 10:07:16 EDT
Created attachment 136641 [details]
messages file including info about named start and restart
Comment 7 Martin Stransky 2006-09-20 04:21:25 EDT
Could you please enable named (#chkconfig named on), reboot your box and check it?

What do you have in your /etc/named.conf?
Comment 8 Tadej Janež 2006-09-20 05:20:50 EDT
I enabled named service with chkconfig, rebooted the machine and it still
doesn't work.

I'll create new attachments for conf files.
Comment 9 Tadej Janež 2006-09-20 05:22:34 EDT
Created attachment 136720 [details]
named.conf
Comment 10 Tadej Janež 2006-09-20 05:23:01 EDT
Created attachment 136721 [details]
named.caching-nameserver.conf
Comment 11 Tadej Janež 2006-09-20 05:24:00 EDT
Created attachment 136722 [details]
named.rfc1912.zones
Comment 12 Martin Stransky 2006-09-20 08:25:11 EDT
Hm, strange. And are these forwarders (e.g. DNS servers) correct?

172.28.9.29
172.28.9.1
Comment 13 Tadej Janež 2006-09-20 09:14:03 EDT
Yes, they are corrent.
First one is a Win2k machine acting as a DNS and Exchange server and
the second one is a Borderware FreeBSD firewall acting as a secondary DNS server.
Comment 14 Martin Stransky 2006-10-13 08:11:58 EDT
*** Bug 196962 has been marked as a duplicate of this bug. ***
Comment 15 Martin Stransky 2006-10-13 08:15:48 EDT
Created attachment 138421 [details]
a proposed patch

We need to reload named when Network Manager adds a new network interface and
named is supposed to listen on it.
Comment 16 Dan Williams 2006-12-03 14:23:07 EST
Does named need to be restarted so that it knows about new network interfaces to
send out DNS queries and listen for replies on?  Is that the issue here?
Comment 17 Martin Stransky 2006-12-04 04:54:53 EST
(In reply to comment #16)
> Does named need to be restarted so that it knows about new network interfaces to
> send out DNS queries and listen for replies on?  Is that the issue here?

Yep, this is the problem.
Comment 18 Bug Zapper 2008-04-03 14:13:27 EDT
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Comment 19 Bug Zapper 2008-05-06 20:50:48 EDT
This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.

If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

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