1933356 - DNS timings in PerformanceNavigationTiming interface are implausible short

Status: UNCONFIRMED

(Core :: Networking: DNS, defect)

Description

[Philipp Bielefeld]

Attachment: Python script for reproducing bug and logs

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:132.0) Gecko/20100101 Firefox/132.0

Steps to reproduce:

I ran the attached Python script (run_measurement.py) to get the Performance Timings from a selenium controlled Firefox browser for the 100 most popular domains.
Please note following caches are disabled to ensure that the DNS server is actually queried:
"browser.cache.disk.enable":False
"browser.cache.memory.enable":False
"browser.cache.offline.enable":False
"network.http.use-cache":False

The test was also executed on a Ubuntu VM with Mozilla version 127.0.2 with similar results. The problem was already discovered by other users, but not reported in Bugzilla as far as I can see:
2016: https://www.reddit.com/r/javascript/comments/5qh9ro/how_is_it_possible_to_have_0_values_in_navigation/
2015: https://github.com/sitespeedio/sitespeed.io/issues/772

Actual results:

As can be seen in performance_navigation_timings.log the delta between domainLookupEnd and domainLookupStart is often in the single digit range and sometimes even 0ms

As reference:
the ping to the set DNS server, which needs 41ms on average
the response time of the DNS server which needs at least 145ms, which is plausible since DNS-over-HTTPS needs 3RTTs, which is roughly the case.

Please note:
The docs say, that if the page is cached or a persistent connection is used, fetchStart would be the same as domainLookupStart and domainLookupEnd, which is often not the case, so the request must have been actually executed
Also all known caches were disabled, since the times in the logs between cold cache entries and warm cache entries do not differ much, it seems like I did not miss any cache, otherwise the warm DNS times would be magnitudes smaller

Expected results:

The delta between domainLookupEnd and domainLookupStart should be at least 145ms in the example (local test). deltas with less than 5ms are implausible for DNS lookups over a network even in datacenter environments and if only one round trip is needed.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Networking: DNS' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.