Open Bug 511839 Opened 15 years ago Updated 2 years ago

DNS prefetch peppers DNS server with queries for the same FQDN

Categories

(Core :: Networking, defect, P3)

x86
Linux
defect

Tracking

()

UNCONFIRMED

People

(Reporter: timo.ruiter, Unassigned)

Details

(Whiteboard: [necko-backlog])

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2 DNS prefetching queries the DNS server for each URL found in a page, unless it is already in the prefetch cache. When the FQDN is not found in the DNS (e.g. viewing a webpage of a commercial product running on a local server which has a link to the manufacturers website, on a PC without Internet connection) FireFox will repeat the query 3 times without any delay between them for as many times that FQDN is found in URLs on that page (it is not uncommon to have multiple links to the same website on one page). If the page is reloaded the same barrage of DNS queries is repeated, all of which will result in a NXDOMAIN or NXRRSET reply of the DNS server. Reproducible: Always Steps to Reproduce: 1. Open a webpage which references a website which FQDN does not exist in the DNS you query (either totally non-existent when you query Internet DNS servers, or just non-existent in your own DNS server). 2. 3. Actual Results: FQDNs from the URLs are queried 3 times after another on the same DNS server, which is repeated for as many times that same FQDN is present in ULRs on the page (each resulting in three queries). Expected Results: A negative response from a DNS server should be honored and the same server should not queried again. This would mean that each FQDN should be queried once per page. When you use multiple search domains in /etc/resolv.conf the FQDN is first queried by itself but if that is unsuccessful the FQDN is augmented with each domain you have in /etc/resolv.conf and then queried again (all of which come up empty for apparent reasons). If IPv6 is on as well the number of queries is doubled, leading to a true bombardment of DNS queries.
Firefox is using the OS services - what you describe (2 retries, apparently not remembering NXDOMAIN, etc ...) is due to the resolver stack. Not Firefox. And negative responses are often not cached (or not for a very long time at least). That doesn't mean that the behavior can be improved. For instance, I don't really understand why there's no cap on the number of prefetch queries (let's say, only do the first 10 links). But don't forget that they effectively happen in parallel, so that you can't really benefit from the knowledge on a negative response. Maybe we should only launch a few prefetch queries at the same time, and do the rest on a timer ? What you call the prefetch cache, is really the normal DNS cache in Firefox, controlled by network.dnsCacheExpiration (default 3 min) and network.dnsCacheEntries (default 400). That's on top of whatever the OS is doing. In Unix, I'm using a local caching nameserver for instance.
Jo, When I use wireshark to monitor the behaviour of my Fedora 8 Linux system when I query the name 'www.doesnotexist.aaa' with host(1) it is my resolver stack that tries the FQDN and 'FQDN.lan' (because 'lan' is in my resolv.conf). Each of the names are nonexistent which the DNS tells my resolver stack. Because of the fact that there is an answer, each name is queried exactly once, and I am not running nscd. This all makes perfect sense to me. I am not convinced that the triple questions where one should suffice is originating in my Linux system. You mention to cap the number of prefetch queries, but that is not what I mean. In fact, FireFox should prefetch ALL hostnames from URLs in a page, but before it does that SORT all hostnames and DISCARD duplicates. Timo
Tom: zoals ik al geschreven heb, de queries gebeuren in parrallel - er is geen specieke sortering van de requests. Ze worden uitgezonden als ze geparsed worden, zelfs als de hoofdpagina nog niet volledig geladen is. (and in English) There's no specific sorting of the DNS requests - they're issued as they're encountered during parsing. Possible while the main page is still loading. Possible all in parallel. And I'm only describing the current behavior, not what can be improved. But if you want to wait until the main page is loaded (to weed out the duplicates), then you're introducing a delay. What we need to do is to avoid queries which are already being sent (I'm not seeing that on Windows, it could be because the resolver is blocking that, or because of timing issues). Or maybe a cap on the number of queries (simultaneous or in total), but that's another issue. As a side note, since I'm involved with big-ass routers in my daytime job, I'm not particular concerned about the number of DNS queries - I often see millions of queries on the same moment, without a problem. Caching of negative response is much more important for all parties involved. And most DNS resolvers (Linux included) are not particularly smart.
I am aware that nameservers can take quite a beating when it comes to queries per second. And in itself, querying something you just have asked 1 millisecond ago (and got answer to) cannot be considered wrong. But it is stupid. Considering a situation where dozens of FireFox clients on a company network, without Internet connectivity for security reasons, a three-fold load of bogus DNS queries (for unresolvable hosts) constitutes a significant network load. What I see happening is that loading a website with a single URL results in three consecutive queries for that URL, not just one. This could mean that FireFox is querying its DNS cache three times for each URL (whether existent or not) which is degrading performance, but this is just speculation. I cannot repeat this behaviour using another tool, so I still suspect FireFox to be responsible. And although most DNS resolvers are not particularly smart (as you say) I don't think they would send out three queries _by themselves_ for every hostname they get a request for.
Component: General → Networking
Product: Firefox → Core
QA Contact: general → networking
> Possible while the main page is still loading. I don't believe this is true, actually. We buffer up the prefetches until end of load, then prefetch them, last I checked. Timo, all we do is call gethostbyname, last I checked. We should be doing that once per link, and I don't believe we retry ourselves.
Assignee: nobody → sjhworkman
Assignee: sworkman → nobody
Whiteboard: [necko-backlog]
Priority: -- → P1
Priority: P1 → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.