chromium snap from focal fails DNS lookups, or delays them (ipv6)

[Matthias Klose]

When working with the chromium snap included in focal, it sometimes takes a few seconds to lookup an URL, sometimes it cannot resolve the hostname of the URL at all.

Doing the same browsing using firefox doesn't show such behavior, no timeouts, no failed lookups, no delays.

Any way how to debug that? That is using IPv6 only.

[Maciej Borzecki (maciek-borzecki)]

Probably needs more intricate knowledge of Chromium.

Just for the record, do you see any AppArmor denials when that happens?

[Matthias Klose (doko)]

I don't see any.

There are warnings like
Apr 30 16:29:25 x1e thunderbird.desktop[1796452]: ERROR: ld.so: object '/snap/chromium/1119/lib/bindtextdomain.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.

Apr 30 16:29:30 x1e quasselclient.desktop[1796455]: ERROR: ld.so: object '/snap/chromium/1119/lib/bindtextdomain.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.

but these seem to be unrelated.

Please could you be more specific, when you are requesting additional information?

[Paweł Stołowski (stolowski)]

It seems to be ipv6-related but I'm not using ipv6 so couldn't verify. FWTW I played with chromium snap on focal with ipv4 and couldn't spot any DNS lookup slowness, it was super fast. I've updated the title of the bug report accordingly.

[Claudio Matsuoka (cmatsuoka)]

I tested the chromium snap (1165) on a focal machine with IPv6 and couldn't reproduce DNS lookup problems. I did, however, find a difference between this chromium and unconfined chrome when handling IPv6 large packets (unconfined chrome works as expects and chromium times out).

Unconfined chrome output:

Test with IPv4 DNS record ok (0.032s) using ipv4
Test with IPv6 DNS record ok (0.034s) using ipv6
Test with Dual Stack DNS record ok (0.039s) using ipv6
Test for Dual Stack DNS and large packet ok (0.043s) using ipv6
Test IPv4 without DNS ok (0.033s) using ipv4
Test IPv6 without DNS ok (0.048s) using ipv6
Test IPv6 large packet ok (0.046s) using ipv6
Test if your ISP's DNS server uses IPv6 ok (0.052s) using ipv6
Find IPv4 Service Provider ok (0.447s) using ipv4 ASN 14868
Find IPv6 Service Provider ok (0.398s) using ipv6 ASN 14868

Chromium from snap:

Test with IPv4 DNS record ok (0.140s) using ipv4
Test with IPv6 DNS record ok (0.142s) using ipv6
Test with Dual Stack DNS record ok (0.159s) using ipv6
Test for Dual Stack DNS and large packet ok (0.094s) using ipv6
Test IPv4 without DNS skipped (0.087s)
Test IPv6 without DNS skipped (0.155s)
Test IPv6 large packet timeout (15.011s)
Test if your ISP's DNS server uses IPv6 ok (0.194s) using ipv6
Find IPv4 Service Provider ok (0.222s) using ipv4 ASN 14868
Find IPv6 Service Provider ok (0.208s) using ipv6 ASN 14868

Test IPv6 large packet description:
Validates that IPv6 requests with large packets work. If this test times out, but other IPv6 tests work, it suggests that there may be PMTUD issues; possibly involving IP tunnels. Double check to make sure that ICMPv6 Type 2 ("Packet Too Big") messages are not filtered by your firewall.

Test us from https://test-ipv6.com/

[Zygmunt Krynicki (zyga)]

I'm marking this as medium as we should handle ipv6 better and this may help to determine if there's a broad issue in the base snaps, either on the configuration side or in the set of packages contained.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Jan Vlug (z-j)]

Resolving hosts in Chromium stopped working after applying the changes as described in: https://bugs.launchpad.net/ubuntu/+source/network-manager-strongswan/+bug/1864256/comments/3

Firefox and Chrome still could resolve host names.