1701315 - Firefox does not do IPv6 AAAA record lookup for dual stack clients and IPv4-only remote access VPN virtual adapter

Status: UNCONFIRMED

(Core :: Networking: DNS, defect, P3)

Description

[Quang Le]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:87.0) Gecko/20100101 Firefox/87.0

Steps to reproduce:

In a dual stack, IPv4/IPv6, environment, when using a remote access VPN software, such as Cisco AnyConnect or Palo Alto GlobalProtect, and the VPN software is configured for split tunnel buts not configured for IPv6 (IPv4 only), Firefox sometimes does not query for IPv6 AAAA record, only IPv4 A records. With the VPN off (disconnected), Firefox reliably queries for both A and AAAA records.

Actual results:

When using a remote access VPN software that's configured for split tunnel, but only supports IPv4, Firefox does not query for the AAAA records of certain DNS names, such as ipv6.google.com or www.v6.facebook.com.

Expected results:

Firefox should query for both A and AAAA records for all DNS names. Please note that the typical remote access VPN configuration is for all DNS traffic to switch to using the provided DNS server when the VPN client is connected. Our DNS server is capable of answering AAAA records over the VPN tunnel.

Comment 1

[Quang Le]

Attachment: Firefox_DNS_No_VPN.png

Notice that when the VPN is off, Firefox queries for both A and AAAA records of the same DNS name.

Comment 2

[Quang Le]

Attachment: Firefox_DNS_Queries_With_VPN.png

With VPN enabled, Firefox does not query for the AAAA record of the name ipv6.google.com, just the A record.

Comment 3

[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 revert this change in case you think the bot is wrong.

Comment 4

[(inactive) Nihanth Subramanya [:nhnt11]]

Valentin, Kershaw, do either of you know what our intention is here?

Comment 5

[Valentin Gosu [:valentin] (he/him)]

I don't know if this is a Firefox issue or a Windows DNS issue.

@Quang Le, have you also tried with a curl or Chrome in the same conditions? Do other tools attempt to resolve IPv6 using the VPN?

Comment 6

[Quang Le]

Chrome exhibits the same symptom as Firefox, and somebody had already opened a similar bug case with Chromium (Issue 1158538) on December 14, 2020. I tried the nslookup utility in windows and it correctly asked the DNS server for both A and AAAA records of ipv6.google.com. Please see attached Wireshark screenshot on the next post.

Comment 7

[Quang Le]

Attachment: VPN_Troubleshooting_DNS_Queries_NSLOOKUP.png

Comment 8

[Valentin Gosu [:valentin] (he/him)]

I think what's happening is that we make AF_UNSPEC requests to getaddrinfo, but because the adapter only supports IPv4 it doesn't do the IPv6 DNS request.

@Quang Le - could you check one last thing? While your VPN is running, if you go into network adapter properties and turn on IPv6, does that change anything? Thanks!

Comment 9

[Quang Le]

Unfortunately, the VPN clients that I have access to, Palo Alto GlobalProtect and Cisco AnyConnect, take full control of the VPN virtual adapter and don't like it when I make changes to the adapter. However, I do have a VPN portal that serves out IPv6 address, and Firefox works fine when I connect to this portal (the VPN virtual adapter has an IPv6 address). I can get to ipv6.google.com when connecting to this VPN portal, but not when connecting to another VPN portal without IPv6 support (no IPv6 address assigned to the VPN virtual adapter by the VPN client software. Just an IPv4 address only). Please see screenshot on next post. You can see that Firefox makes two DNS queries, one for the A record and another for the AAAA record, to the DNS server when I connect to a VPN portal with IPv6 support.

Comment 10

[Quang Le]

Attachment: Firefox_DNS_Query_VPN_With_IPv6.png

Comment 11

[chrysn]

Have you observed whether network.trr.skip-AAAA-when-not-supported has any impact on this issue?

(I'm trying to track down what I think is Firefox assuming that IPv6 is not supported when it actually is, and if this issue only appears when skip-AAAA-when-not-supported=true (as is the default), then we might be on to the same issue).

Comment 12

[Valentin Gosu [:valentin] (he/him)]

This bug is unrelated to TRR (otherwise we wouldn't see the DNS requests in wireshark)

Based on comment 6 this seems to be a problem with the implementation of Windows's getaddrinfo that we have no control over.