Bug 185 - dhcpd server causes nameserver query
dhcpd server causes nameserver query
Product: Red Hat Linux
Classification: Retired
Component: dhcpcd (Show other bugs)
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Erik Troan
Depends On:
  Show dependency treegraph
Reported: 1998-11-24 10:42 EST by Michael Meissner
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 1998-12-09 14:40:04 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Michael Meissner 1998-11-24 10:42:07 EST
Something changed in the way dhcpd operates that causes a
new nameserver query that 5.1 didn't do.  I run diald to
demand diald my internet connection on my home machine,
and also run dhcpd to allow a laptop to get configured for
the home environment (using a Netgear ethernet card for the
home network).  Under 5.1, if I put all hostnames mentioned
in the dhcpd.conf file in /etc/hosts, and set the query
to look at files before dns, it would not do an external
nameserver query when the dhcpd server started.  Now with
5.2, I see the following queries when dhcpd starts:

XX /
XX /

( is the IP address of the host dhcpd is
running on).  Obviously, I should set up reverse mapping
on my local nameserver for addresses it knows about, but it
is odd that dhcpd now does this query when it previously
didn't do it before.
Comment 1 Preston Brown 1998-12-07 15:26:59 EST
re-assigned to Erik, who owns this package. :)
Comment 2 Michael Meissner 1998-12-09 14:25:59 EST
Further debugging shows that its not the dhcpd server that seems
to be causing the network traffic, but the caching name server that
is (dhcpd just happens to be executing when the modem starts dialing).
I have worked around the problem by not bringing up the caching name
server until the modem is brought up the first time.
Comment 3 Erik Troan 1998-12-09 14:40:59 EST
The additional information on this implies that it's not a bug
in dhcpd after all, so I don't have to fix anything :->

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