Closed
Bug 223861
Opened 21 years ago
Closed 21 years ago
default value of network.dnsCacheExpiration should be reduced
Categories
(Core :: Networking, defect)
Core
Networking
Tracking
()
VERIFIED
FIXED
mozilla1.6beta
People
(Reporter: darin.moz, Assigned: darin.moz)
Details
Attachments
(1 file)
2.92 KB,
patch
|
dougt
:
review+
brendan
:
superreview+
|
Details | Diff | Splinter Review |
default value of network.dnsCacheExpiration should be reduced.
see bug 162871 comment #83.
Assignee | ||
Updated•21 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.6beta
Comment 1•21 years ago
|
||
Unless we include our own gethostbyname implementation, I don't see how we can
respect the actual TTL stored in the DNS for a given A record.
What's the state of the art gethostbyname on Linux? Does it have any secret
APIs we could use? How about Windows and Mac?
/be
Comment 2•21 years ago
|
||
Back when I hacked kernel and networking code for SGI, we had the same problem
Mozilla has: how to avoid terrible DNS performance by caching results briefly in
a client program that uses gethostbyname. We chose a small fixed
client-cache-ttl, around a minute if memory serves. This number was wired into
the gethostbyname implementation.
I just took a look at glibc-2.2.93/resolv/ sources, and I see no use of TTL sent
from the DNS in response to a query. Am I missing anything?
/be
Assignee | ||
Comment 3•21 years ago
|
||
>Unless we include our own gethostbyname implementation, I don't see how we can
>respect the actual TTL stored in the DNS for a given A record.
agreed.
>What's the state of the art gethostbyname on Linux? Does it have any secret
>APIs we could use? How about Windows and Mac?
not that i know of. as far as i know, the BIND API (res_*) doesn't provide it.
anyways, the fundamental difficulty in all of this is that we don't actually
know if we are using DNS to resolve hostnames. sure, in the vast majority of
cases that is happening, but with a few quick changes to /etc/nsswitch.conf i
can configure my linux box to use WINBINDD or NIS instead of DNS. we don't want
to be in the game of parsing /etc/nsswitch.conf and friends.
i think 60 seconds is a reasonable DNS timeout for mozilla.
Assignee | ||
Comment 4•21 years ago
|
||
this patch does the following:
1) reduce cache timeout to 60 seconds
2) increase DNS thread lifetime from 5 seconds to 60 seconds
3) fix enumeration bug in DEBUG dump of cached host records
Assignee | ||
Updated•21 years ago
|
Attachment #134586 -
Flags: superreview?(brendan)
Attachment #134586 -
Flags: review?(dougt)
Comment 5•21 years ago
|
||
Attachment #134586 -
Flags: superreview?(brendan) → superreview+
Updated•21 years ago
|
Attachment #134586 -
Flags: review?(dougt) → review+
Assignee | ||
Comment 6•21 years ago
|
||
fixed-on-trunk
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Comment 7•21 years ago
|
||
Hmmm ... What if someone wanted to use an even lower value ? Not that I find
that useful, but the guy in bug 162871 comment 83 who prompted this change,
wanted to use 30 seconds.
The problem is that kPrefDnsCacheExpiration is specified in seconds, but
converted to minutes, and the value will be truncated. The current default (1
minute) is also the minimum. See bug 205726 comment 69.
Assignee | ||
Comment 8•21 years ago
|
||
Jo: yup, that is a known limitation. the plan is to move to storing the
expiration time in seconds. that'll be done along with caching failed lookups
(for only a few brief seconds to help with performance when many images are
broken... possibly due to the use of an ad blocking /etc/hosts file).
see bug 208312
VERIFIED:
doc'd in http://www.mozilla.org/quality/networking/docs/netprefs.html.
Any short interval should be okay, because DNS entries should not turn over
minute-by-minute.
The benefits to people who have a long-pole to their DNS server are too great.
So many people are probably happy now that we both cache and timeout entries
sensibly.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•