default value of network.dnsCacheExpiration should be reduced. see bug 162871 comment #83.
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.
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
Comment on attachment 134586 [details] [diff] [review] v1 patch firstname.lastname@example.org. /be
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.