Bug 81454 - resolver search list only allows 6 domains
resolver search list only allows 6 domains
Product: Red Hat Public Beta
Classification: Retired
Component: glibc (Show other bugs)
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2003-01-09 12:19 EST by Panu Matilainen
Modified: 2007-04-18 12:49 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-01-20 11:02:19 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 Panu Matilainen 2003-01-09 12:19:45 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.7 (X11; Linux i686; U;) Gecko/20021216

Description of problem:
The search list of /etc/resolv.conf is limited to six domains which, while
probably sufficient for most users, is oddly/needlessly low and is constantly
causing problems here. The cause of this showing up is actually our windows
users who are used to not using FQDN because *they* don't need it, which then
causes various intranet pages/links to appear broken etc but those I can't fix
... and unfortunately there are over six subdomains in the intra :(

Could you please up the limit (both the nr of domain & the total length of the
search list) to some "enough for everyone" value, something like 32 for the nr
of domains and 1024 for total length?

Oh and it would be nice if this was changed for possible future glibc-errata
releases for earlier distros too..

Version-Release number of selected component (if applicable): every glibc up to date

How reproducible:

Steps to Reproduce:
1. Add seven domains to /etc/resolv.conf search list
2. Try to ping a host in the last domain of the list

Actual Results:  Host is not found.

Expected Results:  Host should be found :)

Additional info:
Comment 1 Jakub Jelinek 2003-01-20 11:02:19 EST
Given that char    *dnsrch[MAXDNSRCH+1]; is part of _res variable which
applications may access directly, this really cannot be changed. Sorry.
Comment 2 Panu Matilainen 2003-01-20 11:22:51 EST
Oh well :( Would you reconsider this for RHL 9.0 (or whatever the next major
release happens to be) where binary compatibility potentially breaks anyway?
Just wondering would it be worth it to remind you later...
Comment 3 Jakub Jelinek 2003-01-20 11:25:58 EST
No. glibc maintains binary (althout not bug) compatibility all the way back.
Furthermore, this structure is a per-thread thing, and allocating more memory
per-thread for it when 99.9% users don't need it would be wasting.
I'd suggest adding CNAMEs to your DNS.
Comment 4 Panu Matilainen 2003-01-20 11:34:41 EST
Ok. CNAME's aren't going to help, the environment is far, far too big to be
cured by those, but thanks for the reply anyway. I guess it's time to start
bugging those web authors causing the mess then...

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