default value of network.dnsCacheExpiration should be reduced

VERIFIED FIXED in mozilla1.6beta

Status

()

defect
--
minor
VERIFIED FIXED
16 years ago
16 years ago

People

(Reporter: darin.moz, Assigned: darin.moz)

Tracking

Trunk
mozilla1.6beta
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

default value of network.dnsCacheExpiration should be reduced.

see bug 162871 comment #83.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.6beta
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
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
>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.
Posted patch v1 patchSplinter Review
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
Attachment #134586 - Flags: superreview?(brendan)
Attachment #134586 - Flags: review?(dougt)
Comment on attachment 134586 [details] [diff] [review]
v1 patch

sr=brendan@mozilla.org.

/be
Attachment #134586 - Flags: superreview?(brendan) → superreview+
Attachment #134586 - Flags: review?(dougt) → review+
fixed-on-trunk
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
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.
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.