Firefox slow to start due to waiting for systemd-resolved

Problem

After starting Firefox I’m missing any feedback for a starting application. After 2 minutes or more the browser appears and seems to be working just fine.

Analysis so far

The issue seems to be related to systemd-resolved. I’ve watched Firefox syscalls:

$ strace firefox
[…]
socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 15
connect(15, {sa_family=AF_UNIX, sun_path="/run/systemd/resolve/io.systemd.Resolve"}, 42) = 0
sendto(15, "{\"method\":\"io.systemd.Resolve.Re"..., 100, MSG_DONTWAIT|MSG_NOSIGNAL, NULL, 0) = 100
recvfrom(15, 0x7f26d5544000, 131072, MSG_DONTWAIT, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable)
ppoll([{fd=15, events=POLLIN}], 1, {tv_sec=119, tv_nsec=999945000}, NULL, 8

this ppoll does take long until the browser does continue.

As you’ll have questions regarding systemd-resolved:

$ resolvectl
Global
         Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub

Link 2 (wlp0s20f3)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: +DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 10.87.77.1
       DNS Servers: 10.87.77.1 fd00::2e91:abff:fe8c:e9c0
        DNS Domain: fritz.box

During the startup time the following logs are being generated by systemd-resolved:

Jun 30 10:35:52 hamlet systemd-resolved[6207]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server fd00::2e91:abff:fe8c:e9c0.

But in my history I do find different yet similar messages:

Jun 30 10:01:03 hamlet systemd-resolved[6207]: Using degraded feature set UDP instead of TCP for DNS server fd00::2e91:abff:fe8c:e9c0.
Jun 30 10:01:34 hamlet systemd-resolved[6207]: Using degraded feature set TCP instead of UDP for DNS server fd00::2e91:abff:fe8c:e9c0.
Jun 30 10:02:21 hamlet systemd-resolved[6207]: Using degraded feature set UDP instead of TCP for DNS server fd00::2e91:abff:fe8c:e9c0.
Jun 30 10:02:53 hamlet systemd-resolved[6207]: Using degraded feature set TCP instead of UDP for DNS server fd00::2e91:abff:fe8c:e9c0.
Jun 30 10:03:39 hamlet systemd-resolved[6207]: Using degraded feature set UDP instead of TCP for DNS server fd00::2e91:abff:fe8c:e9c0.
Jun 30 10:04:11 hamlet systemd-resolved[6207]: Using degraded feature set TCP instead of UDP for DNS server fd00::2e91:abff:fe8c:e9c0.
Jun 30 10:24:41 hamlet systemd-resolved[6207]: Using degraded feature set UDP instead of TCP for DNS server fd00::2e91:abff:fe8c:e9c0.
Jun 30 10:25:13 hamlet systemd-resolved[6207]: Using degraded feature set TCP instead of UDP for DNS server fd00::2e91:abff:fe8c:e9c0.
Jun 30 10:25:38 hamlet systemd-resolved[6207]: Using degraded feature set UDP instead of TCP for DNS server fd00::2e91:abff:fe8c:e9c0.
Jun 30 10:30:50 hamlet systemd-resolved[6207]: Grace period over, resuming full feature set (UDP+EDNS0) for DNS server fd00::2e91:abff:fe8c:e9c0.

Workaround

I would love to help in th underlying general issue and will attempt to workaround the issue short term by disabling systemd-resolved according to Changes/systemd-resolved:

If you do not wish to use systemd-resolved, then manual intervention will be required to disable it:

  • Disable and stop systemd-resolved.service.
  • Delete /etc/resolv.conf
  • Restart the NetworkManager service. NetworkManager will then create a traditional /etc/resolv.conf. (If you are not using NetworkManager, you may create your own /etc/resolv.conf and configure it to your liking.)
1 Like

Can you reproduce the issue when using Google DNS or Cloudflare DNS exclusively?

Thank you, I missed checking that. I used my NetworkManager connection to enforce 1.1.1.1 as exclusive DNS and I cannot reproduce the issue.

$ resolvectl 
Global
         Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: foreign
Current DNS Server: 1.1.1.1
       DNS Servers: 1.1.1.1

Link 2 (wlp0s20f3)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: +DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 1.1.1.1
       DNS Servers: 1.1.1.1

My local DNS server is provided by a fritz.box, really common router in german housholds and the issue occured first today. I am providing this additional info to communicate that I would consider setting another DNS server to be another workaround, not a solution.

There are various issues caused by fritz.box behaviour. I don’t follow the details, but search systemd upstream.

1 Like

This indicates the issue is not so common, and most likely specific to some router’s firmware, so it’s problematic to reproduce, and a workaround might be your best option.

If found multiple bug reports that could be related to my issue - given the combination that the the DNS query done by Firefox during startup is added to the mix.

And there might be more - but I realized that I would not be able to help here due to me being stuck at the 90s state of DNS.

So I do agree that the best way currently is to just set an external DNS server like Cloudflare or Google in such connections. Currently I did pin the DNS server for my Fritzbox Wifi connection only.

I just ran into this problem because I wanted to use DNSOverTLS.

I don’t quite understand why Firefox takes so long to start even though the dns is super fast. As soon as firefox is running, all calls are also extremely fast. Only about:config causes the browser to freeze again for 2 minutes.

1 Like

thanks, seems to have helped

1 Like

I did this to enable systemd-resolved, and then set manual DNS on IPv4/6 to 127.0.0.1/::1 through NetworkManager (Workstation/GNOME) distros:fedora_workstation_gnome [RoE | Wiki]

I didn’t time Firefox, but it didn’t seem like it started up any slower than without systemd-resolved and upstream DNS.

There’s a problem in your instruction.
systemd-resolved is configured in mandatory DoT mode.
NetworkManager pushes its resolvers to systemd-resolved.
systemd-resolved rejects resolvers pushed by NetworkManager.
Those resolvers are redundant, non-DoT, and non-responsive.

1 Like