Slow startup because of attempt to connect to nameservers

Assigned to



2 months ago
29 days ago


(Reporter: Tom Yan, Assigned: valentin)


55 Branch

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [necko-active])



2 months ago
User Agent: Mozilla/5.0 (Linux; Android 7.1.1; F5122 Build/34.3.A.0.217) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.125 Mobile Safari/537.36

Steps to reproduce:

Have a static /etc/resolv.conf (using systemd-networkd but not systemd-resolved) with something like:


and start Firefox.

Actual results:

Firefox is takes a long time to start. With strace I can see that the stalling is due to attempts to connect to the listed nameservers. The problem would be gone if I removed /etc/resolv.conf (but certainly that won't be the solution). It seems to go away if I am connected to some oversea VPN server. Doesn't seem to help if I change the nameservers to OpenDNS ones or the local ones (well not so local but some sort of public DNS in my country, namely "114" in China).

Expected results:

I am not sure why Firefox make such attempts upon startup anyway.


2 months ago
Component: Untriaged → Networking
Product: Firefox → Core
Assignee: nobody → valentin.gosu
Whiteboard: [necko-active]

Comment 1

a month ago
Thanks for reporting this.
I tried to reproduce it myself, but I've had no luck.
My connection to is pretty fast, and when I tried with a non-existent dns server, Firefox still started up really fast.

After searching for a bit I came across something like this:
<< 2. DNS servers are poisoned if you use UDP. Anyway, if you try to use TCP to access these DNS servers, the connections are deliberately slowed down (by dropping TCP packets randomly). (For example, Google's and >>

The problem would probably be with very slow DNS servers. I'll try to emulate that. If a very slow DNS request is slowing down startup, that's definitely something we should look into.

Just as a curiosity, how slow is your startup?
Can you see if that matches the time it takes to do a DNS request?
And how long does this command take? time dig @

Flags: needinfo?(tom.ty89)

Comment 2

a month ago
The startup time could range from 10s ~ 20s when the problem occurs. Without /etc/resolv.conf, or when I am connected to a VPN server, the startup time takes 1s ~ 2s.

`dig @` right after a fresh reboot takes ~0.3s, after that each attempt takes ~0.03s.
Flags: needinfo?(tom.ty89)


a month ago
Depends on: 1398646

Comment 3

a month ago
Is this bug same as bug 1122097, which doesn't occur if setting network.dns.disableIPv6=true?

Comment 4

a month ago
Sorry, was bug 1122907 in comment 3.
Bulk priority update:
Priority: -- → P1

Comment 6

a month ago
@Shian-Yow, network.dns.disableIPv6=true does not workaround the issue. Will see if the patch introduced in bug 1398646 fixes it.

Comment 7

a month ago
(In reply to Tom Yan from comment #6)
> @Shian-Yow, network.dns.disableIPv6=true does not workaround the issue. Will
> see if the patch introduced in bug 1398646 fixes it.

Thanks for letting us know. You can check out the fix right now if you want, in Firefox Nightly:
Priority: P1 → P2
You need to log in before you can comment on or make changes to this bug.