Firefox fails to resolve AAAA only hostnames when using dnscrypt #1899

claverm · 2021-09-24T23:49:48Z

claverm
Sep 24, 2021

In Firefox, when a domain has only an IPv6 address and is resolved in browser with dnscrypt, it fails to load its page, and only reloading the page one or more times the page loads.

I tested in Chromium and this doesn't happens with it.

An example is when accessing http://v6.testmyipv6.com/ which has only AAAA IPs:

# host v6.testmyipv6.com
v6.testmyipv6.com has IPv6 address 2620:12e:1000::a00:f

I recorded a Screencast showing the problem:

Screencast.zip

Can this behavior in Firefox be solved by fixing something in dnscrypt?

claverm · 2021-09-25T18:57:29Z

claverm
Sep 25, 2021
Author

I'm using dnscrypt 2.1.0 and Debian testing 64 bits.

This is my configuration, I think it's OK: https://pastebin.com/A2FVRZ7q

0 replies

vp1981 · 2021-09-26T00:45:51Z

vp1981
Sep 26, 2021

Hello claverm.

Could you make a clearer test suite?

I use dnscrypt-proxy with dnsmasq for system and DoH for firefox and almost every time first attempt to open a website takes too long, and sometimes I have to reopen the website. I assume this has to do with the way dnscrypt-proxy works: it sends a request to a "provider" (HTTPS -> TCP), waits for a response and only then returns reponse to dnsmasq or firefox. But these are my thoughts, I haven't done any tests to check that and measure the time.

P.S. Your first sentence obviously contradicts the title. Besides, the phrase

resolved in browser with dnscrypt

seems too... confident, as if you are really tracing what firefox is doing. I would check trr setting on about:config page and check the domain in question on about:networking page.

Moreover, it might depend on the order in which you do the test: either first in Firefox, then in Chromium, or another way. You could measure response time in terminal using ping or dig/drill tools.

IMO, judging only by browser behavior is useless because you don't really know how exactly they resolve names.

0 replies

claverm · 2021-09-26T01:59:43Z

claverm
Sep 26, 2021
Author

@vp1981

I found what was wrong in Firefox. When it resolves a AAAA only domain, it "thinks" the resolved address is IPv4.

This is a bug of Firefox.

I solved by turning network.http.fast-fallback-to-IPv4 in about:config to "false".

Sorry about my English, it's not very good.

Thank you.

1 reply

vp1981 Sep 26, 2021

Hello @claverm.

I found what was wrong in Firefox

I'm glad you found out what was wrong with your configuration.

When it resolves a AAAA only domain, it "thinks" the resolved address is IPv4.

Firefox in contrast to Chromium/Chrome/Brave/Microsoft Edge/... is very advanced and has many configuration options. That's why I didn't tell anything about what to check in Firefox configuration.

This is a bug of Firefox.

That is NOT a bug, it is Firefox feature.

I solved by turning network.http.fast-fallback-to-IPv4 in about:config to "false".

I have this option set to true, but in DNS Lookup (see your screenshot) I could resolve v6.testmyipv6.com to IPv6. Nevertheless, I see similar behavior: just started Firefox doesn't open the address http://v6.testmyipv6.com/, but when I refresh the page it loads.

Sorry about my English, it's not very good.

It is not about language (I'm not a native speaker), but about the words:

fails to resolve AAAA

but the first sentence

it fails to load its page, and only reloading the page one or more times the page loads.

These two phrases are not the same: "fails to resolve" and "fails to load".

The next part:

it fails to load its page, and only reloading the page one or more times the page loads.

means that Firefox has successfully resolved the domain to IPv6.

claverm · 2021-09-26T23:56:58Z

claverm
Sep 26, 2021
Author

I tested Stubby: https://github.com/getdnsapi/stubby

and direct DNS:

# cat /etc/resolv.conf 
nameserver 1.1.1.1
nameserver 2606:4700:4700::1111

With them, Firefox loads AAAA sites normally.

This is specific to DNSCrypt and should be fixed in some way.

1 reply

vp1981 Sep 27, 2021

Hello claverm.

I'm not a network programmer or expert, but I know a bit about TCP and UDP, see, e.g. https://www.diffen.com/difference/TCP_vs_UDP, so below is just my guessing.

Cloudflare DNS (IPv4 or IPv6) works fine as DNS because local resolver uses UDP by default. Even without caching, you get results very quickly. You could try to use other DNS server to find out response time (use dig or drill tool) and compare these servers.

AFAIU, dnscrypt-proxy establishes a connection to a DoH provider using TCP, so first query maybe too long. But if cache is enabled, at subsequent resolve request would give almost instant response.

If my understanding is correct, there is nothing to "fix" here. Besides, dnscrypt-proxy measures response time before to use particular DoH and chooses one with "lowest latency".

If you feel there is room for improvement, you may give us a hint how to measure response time. Otherwise, it is rather difficult to figure out what is going on on your side.

P.S. I think because of all these "latencies" dnscrypt-proxy has its cache feature.

claverm · 2021-09-27T19:26:16Z

claverm
Sep 27, 2021
Author

I'm not using DoH, but anonymized DNSCrypt.

For Stubby (DNS over TLS) I get this timing:

# time dig youtube.com &>/dev/null
real	0m1.338s
user	0m0.007s
sys	0m0.005s

And for Anonymized DNSCrypt:


# time dig youtube.com &>/dev/null

real	0m0.257s
user	0m0.007s
sys	0m0.002s

DNSCrypt is faster than DNS over TLS, but causes that error in Firefox, DoT that is slower, works fine.

I tested in my Windoze PC, the same error persists in Firefox.

1 reply

vp1981 Sep 28, 2021

I'm not using DoH, but anonymized DNSCrypt.

I don't use that feature, so I can't comment.

For Stubby (DNS over TLS) I get this timing:

I think you measure wrong time. I meant time returned by dig, for example:

$ dig youtube.com @1.1.1.1

; <<>> DiG 9.16.21 <<>> youtube.com @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61182
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;youtube.com.                   IN      A

;; ANSWER SECTION:
youtube.com.            280     IN      A       142.250.150.136
youtube.com.            280     IN      A       142.250.150.93
youtube.com.            280     IN      A       142.250.150.91
youtube.com.            280     IN      A       142.250.150.190

;; Query time: 71 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Tue Sep 28 09:53:51 +08 2021
;; MSG SIZE  rcvd: 104

$ dig youtube.com @169.53.182.120

; <<>> DiG 9.16.21 <<>> youtube.com @169.53.182.120
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10286
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1024
;; QUESTION SECTION:
;youtube.com.                   IN      A

;; ANSWER SECTION:
youtube.com.            256     IN      A       142.251.32.78

;; Query time: 183 msec
;; SERVER: 169.53.182.120#53(169.53.182.120)
;; WHEN: Tue Sep 28 09:54:04 +08 2021
;; MSG SIZE  rcvd: 56

Here dig shows not only IPv4, but gives also additional information such as Query time.

claverm · 2021-09-27T21:23:15Z

claverm
Sep 27, 2021
Author

@jedisct1

My DNSCrypt is set on address 127.0.0.1:53 and also the other DNS program, Stubby.

I captured in Wireshark the DNS queries being made by Firefox using DNSCrypt and Stubby.

DNSCrypt is giving errors to Firefox when loading AAAA hostnames, Stubby not.

pcap.zip

0 replies

lifenjoiner · 2021-09-28T08:29:08Z

lifenjoiner
Sep 28, 2021
Maintainer

IMHO (I don't have IPv6):

By your Wireshark captures, to both of them, AAAA record are queried (record 2) and answered correctly (record 3). If the browser didn't work with this answer, there would be some issue.
By default, dnscrypt-proxy uses the top 2 of a bunch of dynamically estimated servers as upstream. They are operated by different providers. Here as you specified, the top 2 of server_names = ['dnscrypt.eu-nl', 'dnscrypt.eu-nl-ipv6', 'dns.watch', 'dns.watch-ipv6', 'ffmuc.net', 'ffmuc.net-v6']. The top 2 could change on the fly corresponding to the response delay.
And according to your screen-cast, it seemed that the first 1 or 2 AAAA query failed, causing the average latency of the used upstream servers increased and their ranking down, and then, new top 2 appeared which solved the AAAA query succeeded.
Stubby uses the only one upstream_recursive_servers (There is also an failure as record 13). These are 2 different strategies.

Maybe AAAA query is less used and costs more time for the upstream server to do a recursive lookup for the first time, which may cause timeout, and then the ranking in dnscrypt-proxy downs, and dnscrypt-proxy moves to a new upstream.
While in contrast, to a solid upstream server, the cache shows the advantage immediately on a retry of rare queries.
So, what you should work on is to find out which upstream server is used, and pick some one new that can solve AAAA queries better. Then the first query on a domain could be mitigated.

4 replies

claverm Sep 28, 2021
Author

I tried cloudflare DoH: https://pastebin.com/2nsKEXw1

The same problem persists in Firefox.

jedisct1 Sep 28, 2021
Maintainer

What are you seeing in the query log?

claverm Sep 29, 2021
Author

[2021-09-28 21:19:50] [NOTICE] dnscrypt-proxy 2.1.1
[2021-09-28 21:19:50] [NOTICE] Now listening to 127.0.0.1:53 [UDP]
[2021-09-28 21:19:50] [NOTICE] Now listening to 127.0.0.1:53 [TCP]
[2021-09-28 21:19:50] [NOTICE] Now listening to [::1]:53 [UDP]
[2021-09-28 21:19:50] [NOTICE] Now listening to [::1]:53 [TCP]
[2021-09-28 21:19:50] [NOTICE] Source [relays] loaded
[2021-09-28 21:19:50] [NOTICE] Source [opennic] loaded
[2021-09-28 21:19:50] [NOTICE] Source [quad9-resolvers] loaded
[2021-09-28 21:19:50] [NOTICE] Source [onion-services] loaded
[2021-09-28 21:19:50] [NOTICE] Source [odoh-servers] loaded
[2021-09-28 21:19:50] [NOTICE] Source [odoh-relays] loaded
[2021-09-28 21:19:50] [NOTICE] Source [public-resolvers] loaded
[2021-09-28 21:19:50] [NOTICE] Anonymized DNS: routing [dnscrypt.eu-nl-ipv6] via [anon-acsacsar-ams-ipv6]
[2021-09-28 21:19:50] [NOTICE] Anonymized DNS: routing [dns.watch] via [anon-acsacsar-ams-ipv4]
[2021-09-28 21:19:50] [NOTICE] Anonymized DNS: routing [ffmuc.net] via [anon-acsacsar-ams-ipv4]
[2021-09-28 21:19:50] [NOTICE] Anonymized DNS: routing [dns.watch-ipv6] via [anon-acsacsar-ams-ipv6]
[2021-09-28 21:19:50] [NOTICE] Anonymized DNS: routing [dnscrypt.eu-nl] via [anon-acsacsar-ams-ipv4]
[2021-09-28 21:19:50] [NOTICE] Anonymized DNS: routing [ffmuc.net-v6] via [anon-acsacsar-ams-ipv6]
[2021-09-28 21:19:50] [NOTICE] Firefox workaround initialized
[2021-09-28 21:19:50] [NOTICE] Anonymizing queries for [ffmuc.net-v6] via [anon-acsacsar-ams-ipv6]
[2021-09-28 21:20:00] [INFO] Unable to get the public key for [ffmuc.net-v6] via relay [2001:bc8:1824:738::1], retrying over a direct connection
[2021-09-28 21:20:01] [INFO] [ffmuc.net-v6] the key validity period for this server is excessively long (1311 days), significantly reducing reliability and forward security.
[2021-09-28 21:20:01] [NOTICE] [ffmuc.net-v6] OK (DNSCrypt) - rtt: 429ms
[2021-09-28 21:20:01] [NOTICE] Anonymizing queries for [dns.watch-ipv6] via [anon-acsacsar-ams-ipv6]
[2021-09-28 21:20:11] [INFO] Unable to get the public key for [dns.watch-ipv6] via relay [2001:bc8:1824:738::1], retrying over a direct connection
[2021-09-28 21:20:11] [NOTICE] [dns.watch-ipv6] OK (DNSCrypt) - rtt: 446ms
[2021-09-28 21:20:11] [NOTICE] Anonymizing queries for [ffmuc.net] via [anon-acsacsar-ams-ipv4]
[2021-09-28 21:20:11] [INFO] [ffmuc.net] the key validity period for this server is excessively long (1311 days), significantly reducing reliability and forward security.
[2021-09-28 21:20:11] [NOTICE] [ffmuc.net] OK (DNSCrypt) - rtt: 360ms
[2021-09-28 21:20:11] [NOTICE] Anonymizing queries for [dns.watch] via [anon-acsacsar-ams-ipv4]
[2021-09-28 21:20:12] [NOTICE] [dns.watch] OK (DNSCrypt) - rtt: 367ms
[2021-09-28 21:20:12] [NOTICE] Anonymizing queries for [dnscrypt.eu-nl] via [anon-acsacsar-ams-ipv4]
[2021-09-28 21:20:12] [NOTICE] [dnscrypt.eu-nl] OK (DNSCrypt) - rtt: 325ms
[2021-09-28 21:20:12] [NOTICE] Anonymizing queries for [dnscrypt.eu-nl-ipv6] via [anon-acsacsar-ams-ipv6]
[2021-09-28 21:20:22] [INFO] Unable to get the public key for [dnscrypt.eu-nl-ipv6] via relay [2001:bc8:1824:738::1], retrying over a direct connection
[2021-09-28 21:20:22] [NOTICE] [dnscrypt.eu-nl-ipv6] OK (DNSCrypt) - rtt: 280ms
[2021-09-28 21:20:22] [NOTICE] Sorted latencies:
[2021-09-28 21:20:22] [NOTICE] - 280ms dnscrypt.eu-nl-ipv6
[2021-09-28 21:20:22] [NOTICE] - 325ms dnscrypt.eu-nl
[2021-09-28 21:20:22] [NOTICE] - 360ms ffmuc.net
[2021-09-28 21:20:22] [NOTICE] - 367ms dns.watch
[2021-09-28 21:20:22] [NOTICE] - 429ms ffmuc.net-v6
[2021-09-28 21:20:22] [NOTICE] - 446ms dns.watch-ipv6
[2021-09-28 21:20:22] [NOTICE] Server with the lowest initial latency: dnscrypt.eu-nl-ipv6 (rtt: 280ms)
[2021-09-28 21:20:22] [NOTICE] dnscrypt-proxy is ready - live servers: 6
[2021-09-28 21:21:52] [NOTICE] Stopped.

===================================

I see the anon-acsacsar-ams-ipv6 is giving problems, I changed to anon-scaleway-ams-ipv6, but the same problem persists in Firefox.

lifenjoiner Sep 29, 2021
Maintainer

And the query log of v6.testmyipv6.com by Firefox?

jedisct1 · 2021-09-29T06:06:02Z

jedisct1
Sep 29, 2021
Maintainer

So, what are you seeing in the query log?

1 reply

claverm Sep 29, 2021
Author

claverm · 2021-09-29T18:59:14Z

claverm
Sep 29, 2021
Author

I tested this program: https://github.com/nadoo/glider

# glider -verbose -dns=[::]:53 -dnsserver=1.1.1.1:53
2021/09/29 15:54:58 server.go:60: [dns] listening UDP on [::]:53
2021/09/29 15:54:58 server.go:104: [dns-tcp] listening TCP on [::]:53
2021/09/29 15:54:58 group.go:186: [group] only 1 forwarder found, disable health checking
2021/09/29 15:55:09 client.go:123: [dns] 127.0.0.1:34682 <-> 1.1.1.1:53(udp) via DIRECT, v6.testmyipv6.com/1: , ttl: 1800s
2021/09/29 15:55:09 client.go:123: [dns] 127.0.0.1:34682 <-> 1.1.1.1:53(udp) via DIRECT, v6.testmyipv6.com/28: 2620:12e:1000::a00:f, ttl: 1800s
2021/09/29 15:55:16 client.go:123: [dns] 127.0.0.1:48994 <-> 1.1.1.1:53(udp) via DIRECT, www.worldipv6launch.org/1: 23.54.20.88,23.54.20.89, ttl: 20s
2021/09/29 15:55:17 client.go:123: [dns] 127.0.0.1:48994 <-> 1.1.1.1:53(udp) via DIRECT, www.worldipv6launch.org/28: 2600:1419:b400::173f:1c9a,2600:1419:b400::173f:1c9b, ttl: 20s

It's causing the same probem of DNSCrypt. It's made in Go as DNSCrypt is, perhaps these two use the same component in Go that could be the cause of this problem.

0 replies

lifenjoiner · 2021-09-30T01:15:10Z

lifenjoiner
Sep 30, 2021
Maintainer

Query log: those following the init log.

First, we'd like to know what dnscrypt-proxy did, if it did that right, and then, decide where to go ...

5 replies

claverm Sep 30, 2021
Author

Do you mean...

# /opt/dnscrypt-proxy/dnscrypt-proxy -config /opt/dnscrypt-proxy/dnscrypt-proxy.toml -logfile /dev/shm/log -loglevel 0

???

It only shows this: https://pastebin.com/HLajRair

There is no logs of queries.

vp1981 Sep 30, 2021

I think guys mean this

dnscrypt-proxy/dnscrypt-proxy/example-dnscrypt-proxy.toml

Line 447 in fc0ff3b

# Query logging #

section in configuration.

lifenjoiner Sep 30, 2021
Maintainer

To make your command work, in the query_log section of dnscrypt-proxy.toml, add:

  file = '/dev/stdout'

Or specify a log file as the example saying.

claverm Sep 30, 2021
Author

I added log_level = 0 and log_file = '/dev/stdout'

It only shows this: https://pastebin.com/KPdy2Zge

No query logs are showed in it.

jedisct1 Oct 1, 2021
Maintainer

It has to be in this section:

###############################
#        Query logging        #
###############################

## Log client queries to a file

[query_log]

claverm · 2021-10-01T23:29:44Z

claverm
Oct 1, 2021
Author

# /opt/dnscrypt-proxy/dnscrypt-proxy -config /opt/dnscrypt-proxy/dnscrypt-proxy.toml 
[2021-10-02 19:26:25] [NOTICE] dnscrypt-proxy 2.1.1
[2021-10-02 19:26:25] [NOTICE] Now listening to 127.0.0.1:53 [UDP]
[2021-10-02 19:26:25] [NOTICE] Now listening to 127.0.0.1:53 [TCP]
[2021-10-02 19:26:25] [NOTICE] Now listening to [::1]:53 [UDP]
[2021-10-02 19:26:25] [NOTICE] Now listening to [::1]:53 [TCP]
[2021-10-02 19:26:25] [NOTICE] Source [odoh-servers] loaded
[2021-10-02 19:26:25] [NOTICE] Source [odoh-relays] loaded
[2021-10-02 19:26:25] [NOTICE] Source [public-resolvers] loaded
[2021-10-02 19:26:25] [NOTICE] Source [relays] loaded
[2021-10-02 19:26:25] [NOTICE] Source [opennic] loaded
[2021-10-02 19:26:25] [NOTICE] Source [quad9-resolvers] loaded
[2021-10-02 19:26:25] [NOTICE] Source [onion-services] loaded
[2021-10-02 19:26:25] [NOTICE] Anonymized DNS: routing [dnscrypt.eu-nl] via [anon-meganerd]
[2021-10-02 19:26:25] [NOTICE] Anonymized DNS: routing [ffmuc.net-v6] via [anon-meganerd-ipv6]
[2021-10-02 19:26:25] [NOTICE] Anonymized DNS: routing [dns.watch-ipv6] via [anon-meganerd-ipv6]
[2021-10-02 19:26:25] [NOTICE] Anonymized DNS: routing [ffmuc.net] via [anon-meganerd]
[2021-10-02 19:26:25] [NOTICE] Anonymized DNS: routing [dnscrypt.eu-nl-ipv6] via [anon-meganerd-ipv6]
[2021-10-02 19:26:25] [NOTICE] Anonymized DNS: routing [dns.watch] via [anon-meganerd]
[2021-10-02 19:26:25] [NOTICE] Firefox workaround initialized
[2021-10-02 19:26:25] [NOTICE] Anonymizing queries for [ffmuc.net-v6] via [anon-meganerd-ipv6]
[2021-10-02 19:26:26] [NOTICE] [ffmuc.net-v6] OK (DNSCrypt) - rtt: 399ms
[2021-10-02 19:26:26] [NOTICE] Anonymizing queries for [dns.watch-ipv6] via [anon-meganerd-ipv6]
[2021-10-02 19:26:26] [NOTICE] Anonymizing queries for [dnscrypt.eu-nl-ipv6] via [anon-meganerd-ipv6]
[2021-10-02 19:26:27] [NOTICE] Anonymizing queries for [dns.watch] via [anon-meganerd]
[2021-10-02 19:26:27] [NOTICE] Anonymizing queries for [ffmuc.net] via [anon-meganerd]
[2021-10-02 19:26:27] [NOTICE] [ffmuc.net] OK (DNSCrypt) - rtt: 288ms
[2021-10-02 19:26:27] [NOTICE] Anonymizing queries for [dnscrypt.eu-nl] via [anon-meganerd]
[2021-10-02 19:26:27] [NOTICE] Sorted latencies:
[2021-10-02 19:26:27] [NOTICE] -   288ms ffmuc.net
[2021-10-02 19:26:27] [NOTICE] -   399ms ffmuc.net-v6
[2021-10-02 19:26:27] [NOTICE] Server with the lowest initial latency: ffmuc.net (rtt: 288ms)
[2021-10-02 19:26:27] [NOTICE] dnscrypt-proxy is ready - live servers: 2
[2021-10-02 19:26:30]	127.0.0.1	collector-hpn.ghostery.net	AAAA	PASS	264ms	ffmuc.net
[2021-10-02 19:26:30]	127.0.0.1	collector-hpn.ghostery.net	A	PASS	287ms	ffmuc.net
[2021-10-02 19:26:31]	127.0.0.1	ocsp.sca1b.amazontrust.com	AAAA	PASS	378ms	ffmuc.net-v6
[2021-10-02 19:26:31]	127.0.0.1	ocsp.sca1b.amazontrust.com	A	PASS	394ms	ffmuc.net-v6
[2021-10-02 19:26:35]	127.0.0.1	push.services.mozilla.com	AAAA	PASS	405ms	ffmuc.net-v6
[2021-10-02 19:26:35]	127.0.0.1	push.services.mozilla.com	A	PASS	439ms	ffmuc.net-v6
[2021-10-02 19:26:35]	127.0.0.1	push.services.mozilla.com	AAAA	PASS	0ms	-
[2021-10-02 19:26:35]	127.0.0.1	push.services.mozilla.com	A	PASS	0ms	-
[2021-10-02 19:26:36]	127.0.0.1	push.services.mozilla.com	A	PASS	0ms	-
[2021-10-02 19:26:36]	127.0.0.1	v6.testmyipv6.com	A	PASS	242ms	ffmuc.net
[2021-10-02 19:26:36]	127.0.0.1	v6.testmyipv6.com	AAAA	PASS	409ms	ffmuc.net-v6
[2021-10-02 19:26:36]	127.0.0.1	v6.testmyipv6.com	A	PASS	0ms	-
[2021-10-02 19:26:36]	127.0.0.1	v6.testmyipv6.com	A	PASS	0ms	-
[2021-10-02 19:26:36]	127.0.0.1	ocsp.digicert.com	AAAA	PASS	254ms	ffmuc.net
[2021-10-02 19:26:36]	127.0.0.1	ocsp.digicert.com	A	PASS	386ms	ffmuc.net-v6
[2021-10-02 19:26:45]	127.0.0.1	v6.testmyipv6.com	AAAA	PASS	0ms	-
[2021-10-02 19:26:45]	127.0.0.1	v6.testmyipv6.com	A	PASS	0ms	-
[2021-10-02 19:26:45]	127.0.0.1	v6.testmyipv6.com	AAAA	PASS	0ms	-
[2021-10-02 19:26:45]	127.0.0.1	v6.testmyipv6.com	A	PASS	0ms	-
[2021-10-02 19:26:46]	127.0.0.1	v6.testmyipv6.com	AAAA	PASS	0ms	-
[2021-10-02 19:26:46]	127.0.0.1	v6.testmyipv6.com	A	PASS	0ms	-
[2021-10-02 19:26:46]	127.0.0.1	sb.adtidy.org	AAAA	PASS	244ms	ffmuc.net
[2021-10-02 19:26:46]	127.0.0.1	sb.adtidy.org	A	PASS	280ms	ffmuc.net
[2021-10-02 19:26:46]	127.0.0.1	www.worldipv6launch.org	A	PASS	272ms	ffmuc.net
[2021-10-02 19:26:46]	127.0.0.1	www.worldipv6launch.org	AAAA	PASS	442ms	ffmuc.net-v6
[2021-10-02 19:26:46]	127.0.0.1	www.worldipv6launch.org	AAAA	PASS	0ms	-
[2021-10-02 19:26:46]	127.0.0.1	www.worldipv6launch.org	A	PASS	0ms	-
[2021-10-02 19:26:47]	127.0.0.1	www.worldipv6launch.org	A	PASS	0ms	-
[2021-10-02 19:26:47]	127.0.0.1	www.worldipv6launch.org	AAAA	PASS	0ms	-
[2021-10-02 19:26:47]	127.0.0.1	www.worldipv6launch.org	A	PASS	0ms	-
[2021-10-02 19:26:47]	127.0.0.1	www.worldipv6launch.org	A	PASS	0ms	-
[2021-10-02 19:26:49]	127.0.0.1	firefox.settings.services.mozilla.com	A	PASS	252ms	ffmuc.net
[2021-10-02 19:26:49]	127.0.0.1	firefox.settings.services.mozilla.com	AAAA	PASS	401ms	ffmuc.net-v6
[2021-10-02 19:26:51]	127.0.0.1	content-signature-2.cdn.mozilla.net	A	PASS	418ms	ffmuc.net-v6
[2021-10-02 19:26:51]	127.0.0.1	content-signature-2.cdn.mozilla.net	AAAA	PASS	428ms	ffmuc.net-v6
^C[2021-10-02 19:26:57] [NOTICE] Stopped.

3 replies

ghost Oct 2, 2021

https://bugzilla.mozilla.org/show_bug.cgi?id=1594150

claverm Oct 4, 2021
Author

This issue is old. The problem is that some DNS servers as Stubby or direct DNS don't have this issue, only DNSCrypt.

ghost Oct 4, 2021

Old but unresolved.

Your query log shows that all queries were resolved correctly but slowly.
Also on 1st try A record is returned first and AAAA record over 150ms later. So it's likely for Firefox (maybe after 100ms or so) to fallback to ipv4 in this case and cause your problem.
On 2nd try queries are returned from cache and therefore immediately and also AAAA record first. So no problem here.

Stubby and direct DNS are probably just fast enough for Firefox to be able to always wait for the AAAA record without fallback to ipv4.

lifenjoiner · 2021-10-04T12:52:08Z

lifenjoiner
Oct 4, 2021
Maintainer

Try to do some research on Firefox side with -MOZ_LOG=timestamp,nsHostResolver:5 -MOZ_LOG_FILE=/tmp/ff_ipv6.txt
Ref: https://firefox-source-docs.mozilla.org/networking/http/logging.html

Better: dnscrypt-proxy query log, Wireshark capture and Firefox log at the same time.

1 reply

claverm Oct 6, 2021
Author

I switched of ISP, my new ISP doesn't have IPv6 connectivity anymore.

Sorry, I can no longer test DNSCrypt with websites using IPv6 only.

Firefox fails to resolve AAAA only hostnames when using dnscrypt #1899

Replies: 12 comments · 17 replies

claverm Sep 25, 2021 Author

claverm Sep 26, 2021 Author

claverm Sep 26, 2021 Author

claverm Sep 27, 2021 Author

claverm Sep 27, 2021 Author

lifenjoiner Sep 28, 2021 Maintainer

claverm Sep 28, 2021 Author

jedisct1 Sep 28, 2021 Maintainer

claverm Sep 29, 2021 Author

lifenjoiner Sep 29, 2021 Maintainer

jedisct1 Sep 29, 2021 Maintainer

claverm Sep 29, 2021 Author

claverm Sep 29, 2021 Author

lifenjoiner Sep 30, 2021 Maintainer

claverm Sep 30, 2021 Author

lifenjoiner Sep 30, 2021 Maintainer

claverm Sep 30, 2021 Author

jedisct1 Oct 1, 2021 Maintainer

claverm Oct 1, 2021 Author

claverm Oct 4, 2021 Author

lifenjoiner Oct 4, 2021 Maintainer

claverm Oct 6, 2021 Author

Replies: 12 comments 17 replies

claverm
Sep 25, 2021
Author

claverm
Sep 26, 2021
Author

claverm
Sep 26, 2021
Author

claverm
Sep 27, 2021
Author

claverm
Sep 27, 2021
Author

lifenjoiner
Sep 28, 2021
Maintainer

claverm Sep 28, 2021
Author

jedisct1 Sep 28, 2021
Maintainer

claverm Sep 29, 2021
Author

lifenjoiner Sep 29, 2021
Maintainer

jedisct1
Sep 29, 2021
Maintainer

claverm Sep 29, 2021
Author

claverm
Sep 29, 2021
Author

lifenjoiner
Sep 30, 2021
Maintainer

claverm Sep 30, 2021
Author

lifenjoiner Sep 30, 2021
Maintainer

claverm Sep 30, 2021
Author

jedisct1 Oct 1, 2021
Maintainer

claverm
Oct 1, 2021
Author

claverm Oct 4, 2021
Author

lifenjoiner
Oct 4, 2021
Maintainer

claverm Oct 6, 2021
Author