default value of network.dnsCacheExpiration should be reduced

VERIFIED FIXED in mozilla1.6beta

Status

()

Core
Networking
--
minor
VERIFIED FIXED
14 years ago
14 years ago

People

(Reporter: Darin Fisher, Assigned: Darin Fisher)

Tracking

Trunk
mozilla1.6beta
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

14 years ago
default value of network.dnsCacheExpiration should be reduced.

see bug 162871 comment #83.
(Assignee)

Updated

14 years ago
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
(Assignee)

Comment 3

14 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

14 years ago
Created attachment 134586 [details] [diff] [review]
v1 patch

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

14 years ago
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+

Updated

14 years ago
Attachment #134586 - Flags: review?(dougt) → review+
(Assignee)

Comment 6

14 years ago
fixed-on-trunk
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED

Comment 7

14 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

14 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

Comment 9

14 years ago
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.