Bug 128900 - resolver seems to give up too easily
resolver seems to give up too easily
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-07-30 18:33 EDT by Michal Jaegermann
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-30 05:04:33 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 Michal Jaegermann 2004-07-30 18:33:26 EDT
Description of problem:

When I am trying

$ host ftp.bz2.us.kernel.org

I see this:

;; Truncated, retrying in TCP mode.
;; Connection to 192.168.23.254#53(192.168.23.254) for
ftp.bz2.us.kernel.org failed: connection refused.

The catch is that /etc/resolv.conf was written by a dhcp client
and points to a "caching server" on a firewall "sealed box", from
some maker,  which also provides DHCP.  It is most likely not the
best server in the world but situations when a user does not have
much control over what and how provides DNS are not that unusual.

It is true that I can do

$ dig +ignore ftp.bz2.us.kernel.org

; <<>> DiG 9.2.4rc6 <<>> +ignore ftp.bz2.us.kernel.org
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22648
;; flags: qr tc rd ra; QUERY: 1, ANSWER: 29, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ftp.bz2.us.kernel.org.		IN	A

;; ANSWER SECTION:
ftp.bz2.us.kernel.org.	2892	IN	A	140.211.166.134
ftp.bz2.us.kernel.org.	2892	IN	A	140.221.9.138
ftp.bz2.us.kernel.org.	2892	IN	A	144.92.104.38
ftp.bz2.us.kernel.org.	2892	IN	A	144.174.32.40
ftp.bz2.us.kernel.org.	2892	IN	A	146.186.15.46
ftp.bz2.us.kernel.org.	2892	IN	A	155.98.64.81
ftp.bz2.us.kernel.org.	2892	IN	A	155.101.16.102
ftp.bz2.us.kernel.org.	2892	IN	A	204.157.9.31
ftp.bz2.us.kernel.org.	2892	IN	A	206.10.253.14
ftp.bz2.us.kernel.org.	2892	IN	A	206.253.222.50
ftp.bz2.us.kernel.org.	2892	IN	A	207.45.221.24
ftp.bz2.us.kernel.org.	2892	IN	A	207.250.4.12
ftp.bz2.us.kernel.org.	2892	IN	A	209.61.158.75
ftp.bz2.us.kernel.org.	2892	IN	A	209.140.211.22
ftp.bz2.us.kernel.org.	2892	IN	A	209.221.142.122
ftp.bz2.us.kernel.org.	2892	IN	A	216.17.145.149
ftp.bz2.us.kernel.org.	2892	IN	A	216.92.2.151
ftp.bz2.us.kernel.org.	2892	IN	A	216.176.132.235
ftp.bz2.us.kernel.org.	2892	IN	A	12.165.49.5
ftp.bz2.us.kernel.org.	2892	IN	A	18.24.10.100
ftp.bz2.us.kernel.org.	2892	IN	A	24.220.0.37
ftp.bz2.us.kernel.org.	2892	IN	A	64.186.240.117
ftp.bz2.us.kernel.org.	2892	IN	A	66.230.217.253
ftp.bz2.us.kernel.org.	2892	IN	A	69.31.98.210
ftp.bz2.us.kernel.org.	2892	IN	A	128.46.156.117
ftp.bz2.us.kernel.org.	2892	IN	A	128.105.103.12
ftp.bz2.us.kernel.org.	2892	IN	A	128.175.60.102
ftp.bz2.us.kernel.org.	2892	IN	A	128.223.162.20
ftp.bz2.us.kernel.org.	2892	IN	A	129.21.60.34

;; Query time: 31 msec
;; SERVER: 192.168.23.254#53(192.168.23.254)
;; WHEN: Fri Jul 30 16:23:55 2004
;; MSG SIZE  rcvd: 503

and everything is happy.  Well, not exactly:

$ ftp ftp.bz2.us.kernel.org
ftp: ftp.bz2.us.kernel.org: Name or service not known

Oops!  If I can add to /etc/resolv.conf some other DNS servers
which will answer the query without things like '+ignore' then
things are ok but, unfortunately, this is not always feasible.
Comment 1 Ulrich Drepper 2004-09-30 05:04:33 EDT
The values used are good defaults.  Users can change them by using

  options timeout:N attempts:M

in resolv.conf.  Just make sure dhcp does not destroy the file, but
keeps the options.  There will be noo glibc change.
Comment 2 Michal Jaegermann 2004-09-30 10:28:09 EDT
> Just make sure dhcp does not destroy the file ...

So how do you propose to do that, say, on a laptop which frequently
moves between different networks?  Effectively you tell "fire
up an editor on every change and modify /etc/resolv.conf one
way or another".  Besides the problem does not seem to be a timeout
or a number of attempts but that a name server got too many
hosts in a response.

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