Closed Bug 1779110 Opened 2 years ago Closed 2 years ago

Why does "DNS over HTTPS" chases CNAME answers for HTTPS records and NODATA responses?

Categories

(Core :: Networking: DNS, enhancement, P2)

Product:
Core
Component:
Networking: DNS
Version:
Firefox 102
Type:
enhancement

Tracking

()

Status:
RESOLVED FIXED
Milestone:
105 Branch
Tracking Flags:
Tracking Status
firefox105 --- fixed

People

(Reporter: fantasyfate, Assigned: valentin)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [necko-triaged])

Attachments

(2 files)

Bug 1779110 - Skip HTTPS AliasMode record if the RR type is not HTTPS r=#necko
48 bytes, text/x-phabricator-request
Details | Review
Bug 1779110 - Do not follow CNAME for NODATA records r=#necko
48 bytes, text/x-phabricator-request
Details | Review

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

Steps to reproduce:

Browsing "https://www.bbc.com/" and observing "about:networking#dns"
Browsing "https://cdn.jsdelivr.net/" and observing "about:networking#dns"

Actual results:

The CNAME of "www.bbc.com", "bbc.map.fastly.net", appears in the page of "about:networking#dns", because "www.bbc.com" does not have AAAA records.

The CNAME of "cdn.jsdelivr.net", "cdn.jsdelivr.net.cdn.cloudflare.net", appears in the page of "about:networking#dns", because "cdn.jsdelivr.net" has HTTPS records.

Expected results:

I could not figure out why Firefox chases CNAME answers for HTTPS records and NODATA responses. This behavior seems to be unnecessary and give latency penalty.

The Bugbug bot thinks this bug should belong to the 'Core::Networking: DNS' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Networking: DNS
Product: Firefox → Core

Hi fantasyfate, thanks for your question!

We need to chase down/look up cname records, because thats how CNAME records are defined. There is no other way to retrieve the necessary IP address. The server administrators are responsible to configure their DNS entries in a sane way. Luckily, all necessary requests are returned with the first request, so in the end we only make one DNS request:

> dig +noall +answer www.bbc.com
www.bbc.com.		16446	IN	CNAME	www.bbc.com.pri.bbc.com.
www.bbc.com.pri.bbc.com. 39	IN	CNAME	bbc.map.fastly.net.
bbc.map.fastly.net.	20	IN	A	151.101.112.81

So the servers are configured in a good way leading to only one DNS request.

Same for cdn.jsdelivr.net:

> dig +noall +answer cdn.jsdelivr.net
cdn.jsdelivr.net.	300	IN	CNAME	cdn.jsdelivr.net.cdn.cloudflare.net.
cdn.jsdelivr.net.cdn.cloudflare.net. 300 IN A	104.16.88.20
cdn.jsdelivr.net.cdn.cloudflare.net. 300 IN A	104.16.85.20
cdn.jsdelivr.net.cdn.cloudflare.net. 300 IN A	104.16.87.20
cdn.jsdelivr.net.cdn.cloudflare.net. 300 IN A	104.16.89.20
cdn.jsdelivr.net.cdn.cloudflare.net. 300 IN A	104.16.86.20

Does this answer your question?

Severity: -- → N/A
Status: UNCONFIRMED → RESOLVED
Type: defect → task
Closed: 2 years ago
Priority: -- → P3
Resolution: --- → INVALID

Under further consideration, this might be related to draft-ietf-dnsop-svcb-https-10? https://en.wikipedia.org/wiki/List_of_DNS_record_types

I still need to understand how that impacts performance of resolving the dns query.

Severity: N/A → S4
Status: RESOLVED → UNCONFIRMED
Flags: needinfo?(fantasyfate)
Resolution: INVALID → ---

Hello Manuel Bucher , appreciate your very useful supplements.
Originally, I would like to avoid third party tool to reproduce this issue, but it seems not to suffice.

  1. Start CoreDNS with following configuration, "cert.pem", and "key.pem" as the local DoH server
https://. {
    bind 127.0.0.1
    tls cert.pem key.pem
    forward . tls://1.1.1.1 {
       tls_servername cloudflare-dns.com
    }
    log
}

  1. Open the DoH server URL (https://127.0.0.1/dns-query) with Firefox. For the first time, Firefox will notice that the certificate is self-signed and complain about it. This is expected. Click "Advanced" and "I accept the risks".

  2. Set network.trr.uri to https://127.0.0.1/dns-query and set network.trr.mode to 3

So when browsing "www.bbc.com", the CoreDNS will show the DNS queries from Firefox (the order may differ):

A IN www.bbc.com.
AAAA IN www.bbc.com.
HTTPS IN www.bbc.com.
AAAA IN bbc.map.fastly.net.
HTTPS IN bbc.map.fastly.net.

When browsing "cdn.jsdelivr.net", something like this will display:

A IN cdn.jsdelivr.net.
AAAA IN cdn.jsdelivr.net.
HTTPS IN cdn.jsdelivr.net.
HTTPS IN cdn.jsdelivr.net.cdn.cloudflare.net.

To summarize, Firefox chases CNAME answers for HTTPS records and NODATA responses ("www.bbc.com" has no AAAA records but "cdn.jsdelivr.net" has).

Flags: needinfo?(fantasyfate)

Let's have a look what Cloudflare returns in answer to queries:

  1. A query:
$ dig @cloudflare-dns.com +https www.bbc.com A

; <<>> DiG 9.19.3-dev <<>> +timeout +retry @cloudflare-dns.com +https www.bbc.com A
; (4 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12099
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
www.bbc.com.		28769	IN	CNAME	www.bbc.com.pri.bbc.com.
www.bbc.com.pri.bbc.com. 269	IN	CNAME	bbc.map.fastly.net.
bbc.map.fastly.net.	27	IN	A	151.101.0.81
bbc.map.fastly.net.	27	IN	A	151.101.64.81
bbc.map.fastly.net.	27	IN	A	151.101.128.81
bbc.map.fastly.net.	27	IN	A	151.101.192.81

;; Query time: 16 msec
;; SERVER: 2606:4700::6810:f9f9#443(cloudflare-dns.com) (HTTPS)
;; WHEN: Mon Jul 18 12:20:34 CEST 2022
;; MSG SIZE  rcvd: 166

Conclusion: No need to chase, all data are returned directly by Cloudflare right in the ANSWER section.

  1. AAAA query:
$ dig @cloudflare-dns.com +https www.bbc.com AAAA

; <<>> DiG 9.19.3-dev <<>> +timeout +retry @cloudflare-dns.com +https www.bbc.com AAAA
; (4 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41153
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;www.bbc.com.			IN	AAAA

;; ANSWER SECTION:
www.bbc.com.		28740	IN	CNAME	www.bbc.com.pri.bbc.com.
www.bbc.com.pri.bbc.com. 240	IN	CNAME	bbc.map.fastly.net.

;; AUTHORITY SECTION:
fastly.net.		8	IN	SOA	ns1.fastly.net. hostmaster.fastly.com. 2017052201 3600 600 604800 30

;; Query time: 16 msec
;; SERVER: 2606:4700::6810:f8f9#443(cloudflare-dns.com) (HTTPS)
;; WHEN: Mon Jul 18 12:22:07 CEST 2022
;; MSG SIZE  rcvd: 160

Conclusion: No need to chase. The AUTHORITY section indicates that Cloudflare already did chase the answer to end of the chain and that it is not there. See RFC 2308 for more details about that.

  1. HTTPS query:
$ dig @cloudflare-dns.com +https www.bbc.com HTTPS

; <<>> DiG 9.19.3-dev <<>> +timeout +retry @cloudflare-dns.com +https www.bbc.com HTTPS
; (4 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45169
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;www.bbc.com.			IN	HTTPS

;; ANSWER SECTION:
www.bbc.com.		28356	IN	CNAME	www.bbc.com.pri.bbc.com.
www.bbc.com.pri.bbc.com. 259	IN	CNAME	bbc.map.fastly.net.

;; AUTHORITY SECTION:
fastly.net.		30	IN	SOA	ns1.fastly.net. hostmaster.fastly.com. 2017052201 3600 600 604800 30

;; Query time: 26 msec
;; SERVER: 2606:4700::6810:f9f9#443(cloudflare-dns.com) (HTTPS)
;; WHEN: Mon Jul 18 12:23:31 CEST 2022
;; MSG SIZE  rcvd: 160

Conclusion: Same as for #2. No need to chase. The AUTHORITY section indicates that Cloudflare already did chase the answer to end of the chain and that it is not there. See RFC 2308 for more details about that.

Moreover 1.1.1.1/cloudflare-dns.com is a resolver and by definition the resolver does all the chasing for client if Recursion Desired bit is set in queries sent by client - and it surely is because Cloudflare's resolver returns SERVFAIL without that bit being set. In other words, even if the authority and answer section was empty (except for CNAMEs/DNAMEs) there is no need to chase CNAMEs in the application because resolver already did that.

Thanks a lot for clarifying. I think I understand what this bug is about now. It looks like NODATA isn't inferred at all(?). At least for AAAA and HTTPS records with a CNAME involved. So this bug is about inferring NODATA as described in rfc2308 section 2.2.

Status: UNCONFIRMED → NEW
Type: task → enhancement
Ever confirmed: true
Priority: P3 → P2

Before it is confirmed as a bug, I more or less lean toward that it is a purposeful behavior. After all, the unbound chase CNAMEs in forward zone against the Kaminsky attack.

In addition, I have not found a case but highly skeptical about NODATA response of A record with CNAME. Besides NODATA response, Firefox chase CNAME for HTTPS records with whether positive response or negative response.

This bug could be circumvented by optional CNAME Flattening used in NextDNS, but CNAME Flattening will invalid (uncloaking canonical names of uBlock Origin)[https://github.com/gorhill/uBlock/wiki/Dashboard:-Settings#uncloak-canonical-names].

(In reply to fantasyfate from comment #7)

Before it is confirmed as a bug, I more or less lean toward that it is a purposeful behavior. After all, the unbound chase CNAMEs in forward zone against the Kaminsky attack.

Kershaw, do we resolve the CNAME on purpose or should we fix that?

Because the spec seems clear to me, that we don't need to resolve the CNAME:

NODATA is indicated by an answer with the RCODE set to NOERROR and no relevant answers in the answer section.
[...]
CNAME and SIG records may exist in the answer section.[1]

(In reply to fantasyfate from comment #7)

This bug could be circumvented by optional CNAME Flattening used in NextDNS, but CNAME Flattening will invalid (uncloaking canonical names of uBlock Origin)[https://github.com/gorhill/uBlock/wiki/Dashboard:-Settings#uncloak-canonical-names].

Yeah, breaking uncloaking from uBlock sounds like a bad idea. But we don't need to do that? We just need to recognize this response as NODATA?

Flags: needinfo?(kershaw)

(In reply to Manuel Bucher from comment #8)

(In reply to fantasyfate from comment #7)

Before it is confirmed as a bug, I more or less lean toward that it is a purposeful behavior. After all, the unbound chase CNAMEs in forward zone against the Kaminsky attack.

Kershaw, do we resolve the CNAME on purpose or should we fix that?

While I'm not Kershaw, I'm DNS resolver developer and can explain the difference between recursive resolver (Unbound) and client (also knows as stub resolver, e.g. Firefox):
The CNAME chasing is an inherent feature of recursive resolver - it's the purpose of the recursive resolver to find out the final answer. On the other hand the client application (or stub resolver) is meant to defer this functionality to the recursive resolver so it does not have to reimplement the resolver - you can see where this is going.

As for not/following CNAMEs as a layer of protection, the important bit is in this comment by Unbound developer Ralph:
https://github.com/NLnetLabs/unbound/issues/132#issuecomment-567438407
If I rephrase it, it is intended as protection from fake replies from authoritative servers, but the code is simply invoked on any response.

In case of Firefox, it does not make sense to scrub CNAMEs because Firefox is sending the queries to the same resolver again and again irrespective of domain name. In case of Unbound the situation is different: The CNAME target might potentially be served by a different authoritative servers on different addresses, so it does make sense to go and obtain fresh answer from the authoritative servers.

I'm happy to clarify this further if you ask specific questions.

See Also: → 1649417

(In reply to Manuel Bucher from comment #8)

(In reply to fantasyfate from comment #7)

Before it is confirmed as a bug, I more or less lean toward that it is a purposeful behavior. After all, the unbound chase CNAMEs in forward zone against the Kaminsky attack.

Kershaw, do we resolve the CNAME on purpose or should we fix that?

I can't find the reason why we follow CNAME here. It seems we had this behavior since TRR code has been introduced.
As comment #5 said, I think we don't have to chase CNAME in some cases.

Blocks: doh
Flags: needinfo?(kershaw)

DNS request needs to follow the CNAME chain in order to identify the final CNAME of the DNS request.
Following the CNAME chain happens without sending a separate request if the all the CNAMEs are include in the same response.
But I agree, if ra and rd flags are set, and no A/AAAA/HTTPS answers are present, it's probably not worth following the chain.

Assignee: nobody → valentin.gosu
Whiteboard: [necko-triaged]

According to https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https#section-2.4.2

Unlike CNAME, AliasMode
records do not affect the resolution of other RR types, and apply
only to a specific service, not an entire domain name.

As such, we should skip the AliasMode response if the RR type is not HTTPS.

Additionally, when an AliasMode record is present in the response, we must
ignore any ServiceMode records present in the response.

https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https#section-2.4.1

Within a SVCB RRSet, all RRs SHOULD have the same Mode. If an RRSet
contains a record in AliasMode, the recipient MUST ignore any
ServiceMode records in the set.

If the response has the RA flag set, that means the recursive
resolver has probably followed the CNAME chain already, so
issuing other requests would be pointless.

Depends on D153511

Pushed by valentin.gosu@gmail.com: https://hg.mozilla.org/integration/autoland/rev/6d95df4686fc Skip HTTPS AliasMode record if the RR type is not HTTPS r=necko-reviewers,kershaw https://hg.mozilla.org/integration/autoland/rev/f6a9dff98882 Do not follow CNAME for NODATA records r=necko-reviewers,kershaw

Backed out for causing xpcshell failures on test_trr_httpssvc_wrap.js.
So far, this failed on Linux 18.04 x64 WebRender debug and Linux 18.04 x64 WebRender asan opt.

Push with failures

Failure log

Backout link

[task 2022-08-09T12:47:26.465Z] 12:47:26     INFO -  TEST-START | netwerk/test/unit_ipc/test_trr_httpssvc_wrap.js
[task 2022-08-09T12:52:26.472Z] 12:52:26  WARNING -  TEST-UNEXPECTED-TIMEOUT | netwerk/test/unit_ipc/test_trr_httpssvc_wrap.js | Test timed out
[task 2022-08-09T12:52:26.472Z] 12:52:26     INFO -  TEST-INFO took 300001ms
[task 2022-08-09T12:52:26.473Z] 12:52:26     INFO -  >>>>>>>
[task 2022-08-09T12:52:26.473Z] 12:52:26     INFO -  PID 11473 | [Parent 11473, Main Thread] WARNING: Couldn't get the user appdata directory. Crash events may not be produced.: file /builds/worker/checkouts/gecko/toolkit/crashreporter/nsExceptionHandler.cpp:2914
[task 2022-08-09T12:52:26.474Z] 12:52:26     INFO -  TEST-PASS | netwerk/test/unit_ipc/test_trr_httpssvc_wrap.js | setup - [setup : 15] "42240" != null
[task 2022-08-09T12:52:26.474Z] 12:52:26     INFO -  TEST-PASS | netwerk/test/unit_ipc/test_trr_httpssvc_wrap.js | setup - [setup : 16] "42240" != ""
[task 2022-08-09T12:52:26.474Z] 12:52:26     INFO -  (xpcshell/head.js) | test MAIN run_test pending (1)
[task 2022-08-09T12:52:26.475Z] 12:52:26     INFO -  (xpcshell/head.js) | test pending (2)
[task 2022-08-09T12:52:26.475Z] 12:52:26     INFO -  (xpcshell/head.js) | test pending (3)
[task 2022-08-09T12:52:26.477Z] 12:52:26     INFO -  (xpcshell/head.js) | test pending (4)
[task 2022-08-09T12:52:26.477Z] 12:52:26     INFO -  PID 11473 | [Parent 11473, Main Thread] WARNING: Couldn't get the user appdata directory, crash dumps will go in an unusual location: file /builds/worker/checkouts/gecko/toolkit/crashreporter/nsExceptionHandler.cpp:2973
[task 2022-08-09T12:52:26.477Z] 12:52:26     INFO -  PID 11473 | [Child 11490, Main Thread] WARNING: could not set real-time limit in CubebUtils::InitLibrary: file /builds/worker/checkouts/gecko/dom/media/CubebUtils.cpp:707
[task 2022-08-09T12:52:26.477Z] 12:52:26     INFO -  PID 11473 | Couldn't convert chrome URL: chrome://branding/locale/brand.properties
[task 2022-08-09T12:52:26.478Z] 12:52:26     INFO -  PID 11473 | [Child 11490, Main Thread] WARNING: Could not get the program name for a cubeb stream.: 'NS_SUCCEEDED(rv)', file /builds/worker/checkouts/gecko/dom/media/CubebUtils.cpp:427
[task 2022-08-09T12:52:26.478Z] 12:52:26     INFO -  PID 11473 | [Parent 11473, Renderer] WARNING: Failed to create EGLContext with khr_rbab_attribs: file /builds/worker/checkouts/gecko/gfx/gl/GLContextProviderEGL.cpp:715
[task 2022-08-09T12:52:26.479Z] 12:52:26     INFO -  PID 11473 | [Parent 11473, Renderer] WARNING: Failed to create EGLContext with khr_robustness_attribs: file /builds/worker/checkouts/gecko/gfx/gl/GLContextProviderEGL.cpp:727
[task 2022-08-09T12:52:26.479Z] 12:52:26     INFO -  PID 11473 | Initializing context 0x7f62b4354350 surface (nil) on display 0x7f62b27dc100
[task 2022-08-09T12:52:26.480Z] 12:52:26     INFO -  PID 11473 | GL_VENDOR: VMware, Inc.
[task 2022-08-09T12:52:26.480Z] 12:52:26     INFO -  PID 11473 | mVendor: VMware, Inc.
[task 2022-08-09T12:52:26.480Z] 12:52:26     INFO -  PID 11473 | GL_RENDERER: llvmpipe (LLVM 10.0.0, 256 bits)
[task 2022-08-09T12:52:26.481Z] 12:52:26     INFO -  PID 11473 | mRenderer: Unknown
[task 2022-08-09T12:52:26.482Z] 12:52:26     INFO -  PID 11473 | mIsMesa: 1
[task 2022-08-09T12:52:26.482Z] 12:52:26     INFO -  PID 11473 | [Parent 11473, Renderer] WARNING: robust_buffer_access_behavior marked as unsupported: file /builds/worker/checkouts/gecko/gfx/gl/GLContextFeatures.cpp:632
[task 2022-08-09T12:52:26.483Z] 12:52:26     INFO -  PID 11473 | [Parent 11473, Renderer] WARNING: Robustness supported, strategy is not LOSE_CONTEXT_ON_RESET!: file /builds/worker/checkouts/gecko/gfx/gl/GLContext.cpp:995
[task 2022-08-09T12:52:26.483Z] 12:52:26     INFO -  PID 11473 | [Parent 11473, Renderer] WARNING: robustness marked as unsupported: file /builds/worker/checkouts/gecko/gfx/gl/GLContextFeatures.cpp:632
[task 2022-08-09T12:52:26.484Z] 12:52:26     INFO -  (xpcshell/head.js) | test run in child pending (5)
[task 2022-08-09T12:52:26.485Z] 12:52:26     INFO -  (xpcshell/head.js) | test MAIN run_test finished (5)
[task 2022-08-09T12:52:26.485Z] 12:52:26     INFO -  running event loop
[task 2022-08-09T12:52:26.486Z] 12:52:26     INFO -  PID 11473 | [Parent 11473, GMPThread] WARNING: Failed to delete GMP storage directory: file /builds/worker/checkouts/gecko/dom/media/gmp/GMPServiceParent.cpp:1754
[task 2022-08-09T12:52:26.486Z] 12:52:26     INFO -  PID 11473 | Couldn't convert chrome URL: chrome://branding/locale/brand.properties
[task 2022-08-09T12:52:26.486Z] 12:52:26     INFO -  PID 11473 | [Parent 11473, Main Thread] WARNING: Could not get the program name for a cubeb stream.: 'NS_SUCCEEDED(rv)', file /builds/worker/checkouts/gecko/dom/media/CubebUtils.cpp:427
[task 2022-08-09T12:52:26.488Z] 12:52:26     INFO -  "CONSOLE_MESSAGE: (info) No chrome package registered for chrome://branding/locale/brand.properties"
[task 2022-08-09T12:52:26.488Z] 12:52:26     INFO -  CHILD-TEST-STARTED
[task 2022-08-09T12:52:26.488Z] 12:52:26     INFO -  (xpcshell/head.js) | test MAIN run_test pending (1)
[task 2022-08-09T12:52:26.489Z] 12:52:26     INFO -  (xpcshell/head.js) | test run_next_test 0 pending (2)
[task 2022-08-09T12:52:26.489Z] 12:52:26     INFO -  (xpcshell/head.js) | test MAIN run_test finished (2)
[task 2022-08-09T12:52:26.489Z] 12:52:26     INFO -  running event loop
[task 2022-08-09T12:52:26.490Z] 12:52:26     INFO -  "CONSOLE_MESSAGE: (warn) [JavaScript Warning: "Use of nsIFile in content process is deprecated." {file: "/builds/worker/workspace/build/tests/xpcshell/head.js" line: 364}]"
[task 2022-08-09T12:52:26.490Z] 12:52:26     INFO -  "CONSOLE_MESSAGE: (warn) [JavaScript Warning: "Use of nsIFile in content process is deprecated." {file: "/builds/worker/workspace/build/tests/xpcshell/head.js" line: 364}]"
[task 2022-08-09T12:52:26.491Z] 12:52:26     INFO -  netwerk/test/unit_ipc/test_trr_httpssvc_wrap.js | Starting setup setup
[task 2022-08-09T12:52:26.491Z] 12:52:26     INFO -  (xpcshell/head.js) | test setup pending (2)
[task 2022-08-09T12:52:26.491Z] 12:52:26     INFO -  (xpcshell/head.js) | test run_next_test 0 finished (2)
[task 2022-08-09T12:52:26.492Z] 12:52:26     INFO -  (xpcshell/head.js) | test run_next_test 1 pending (2)
[task 2022-08-09T12:52:26.492Z] 12:52:26     INFO -  (xpcshell/head.js) | test setup finished (2)
[task 2022-08-09T12:52:26.492Z] 12:52:26     INFO -  netwerk/test/unit_ipc/test_trr_httpssvc_wrap.js | Starting testHTTPSSVC
[task 2022-08-09T12:52:26.493Z] 12:52:26     INFO -  (xpcshell/head.js) | test testHTTPSSVC pending (2)
[task 2022-08-09T12:52:26.493Z] 12:52:26     INFO -  TEST-PASS | netwerk/test/unit_ipc/test_trr_httpssvc_wrap.js | testHTTPSSVC - [testHTTPSSVC : 58] asyncResolve ok - true == true
[task 2022-08-09T12:52:26.493Z] 12:52:26     INFO -  (xpcshell/head.js) | test run_next_test 1 finished (2)
[task 2022-08-09T12:52:26.494Z] 12:52:26     INFO -  TEST-PASS | netwerk/test/unit_ipc/test_trr_httpssvc_wrap.js | testHTTPSSVC - [testHTTPSSVC : 0] Checking that this is the correct callback - true == true
<...>
[task 2022-08-09T12:52:26.506Z] 12:52:26     INFO -  TEST-PASS | netwerk/test/unit_ipc/test_trr_httpssvc_wrap.js | testHTTPSSVC - [testHTTPSSVC : 145] 0 == 0
[task 2022-08-09T12:52:26.506Z] 12:52:26     INFO -  (xpcshell/head.js) | test run_next_test 2 pending (2)
[task 2022-08-09T12:52:26.507Z] 12:52:26     INFO -  (xpcshell/head.js) | test testHTTPSSVC finished (2)
[task 2022-08-09T12:52:26.507Z] 12:52:26     INFO -  netwerk/test/unit_ipc/test_trr_httpssvc_wrap.js | Starting test_aliasform
[task 2022-08-09T12:52:26.507Z] 12:52:26     INFO -  (xpcshell/head.js) | test test_aliasform pending (2)
[task 2022-08-09T12:52:26.508Z] 12:52:26     INFO -  (xpcshell/head.js) | test run_next_test 2 finished (2)
[task 2022-08-09T12:52:26.508Z] 12:52:26     INFO -  PID 11473 | port = 37085
[task 2022-08-09T12:52:26.509Z] 12:52:26     INFO -  (xpcshell/head.js) | test pending (2)
[task 2022-08-09T12:52:26.510Z] 12:52:26     INFO -  (xpcshell/head.js) | test finished (4)
[task 2022-08-09T12:52:26.510Z] 12:52:26     INFO -  (xpcshell/head.js) | test finished (2)
[task 2022-08-09T12:52:26.511Z] 12:52:26     INFO -  TEST-PASS | netwerk/test/unit_ipc/test_trr_httpssvc_wrap.js | test_aliasform - [test_aliasform : 193] asyncResolve ok - true == true
[task 2022-08-09T12:52:26.511Z] 12:52:26     INFO -  TEST-PASS | netwerk/test/unit_ipc/test_trr_httpssvc_wrap.js | test_aliasform - [test_aliasform : 0] Checking that this is the correct callback - true == true
[task 2022-08-09T12:52:26.512Z] 12:52:26     INFO -  TEST-PASS | netwerk/test/unit_ipc/test_trr_httpssvc_wrap.js | test_aliasform - [test_aliasform : 196] 2152398878 should be an error code - true == true
[task 2022-08-09T12:52:26.512Z] 12:52:26     INFO -  Unexpected exception NS_ERROR_NOT_AVAILABLE: Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIDNSService.clearCache]
[task 2022-08-09T12:52:26.513Z] 12:52:26     INFO -  test_aliasform@/builds/worker/workspace/build/tests/xpcshell/tests/netwerk/test/unit/test_trr_httpssvc.js:201:7
[task 2022-08-09T12:52:26.514Z] 12:52:26     INFO -  _do_main@/builds/worker/workspace/build/tests/xpcshell/head.js:238:6
[task 2022-08-09T12:52:26.514Z] 12:52:26     INFO -  _execute_test@/builds/worker/workspace/build/tests/xpcshell/head.js:595:5
[task 2022-08-09T12:52:26.515Z] 12:52:26     INFO -  @typein:0:154
[task 2022-08-09T12:52:26.515Z] 12:52:26     INFO -  exiting test
[task 2022-08-09T12:52:26.515Z] 12:52:26     INFO -  CHILD-TEST-COMPLETED
[task 2022-08-09T12:52:26.516Z] 12:52:26     INFO -  (xpcshell/head.js) | test finished (3)
[task 2022-08-09T12:52:26.517Z] 12:52:26     INFO -  <<<<<<<
[task 2022-08-09T12:52:26.517Z] 12:52:26     INFO -  xpcshell return code: None
[task 2022-08-09T12:52:26.518Z] 12:52:26     INFO -  netwerk/test/unit_ipc/test_trr_httpssvc_wrap.js | Process still running after test!
[task 2022-08-09T12:52:26.531Z] 12:52:26     INFO -  TEST-START | xpcshell.ini:toolkit/components/extensions/test/xpcshell/test_ext_scripting_contentScripts_css.js
Flags: needinfo?(valentin.gosu)
Pushed by valentin.gosu@gmail.com: https://hg.mozilla.org/integration/autoland/rev/84a34327f1c1 Skip HTTPS AliasMode record if the RR type is not HTTPS r=necko-reviewers,kershaw https://hg.mozilla.org/integration/autoland/rev/f07f149db61e Do not follow CNAME for NODATA records r=necko-reviewers,kershaw

https://hg.mozilla.org/mozilla-central/rev/84a34327f1c1
https://hg.mozilla.org/mozilla-central/rev/f07f149db61e

Status: NEW → RESOLVED
Closed: 2 years ago → 2 years ago
status-firefox105: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 105 Branch
Flags: needinfo?(valentin.gosu)

Unfortunately at version 108, "DNS over HTTPS" chases CNAME answers if HTTPS records have valid answers.

Opening "https://dns.nextdns.io/", and the CoreDNS will display DNS queries from Firefox (the order may differ):

HTTPS IN dns.nextdns.io.
A IN dns.nextdns.io.
AAAA IN dns.nextdns.io.
A IN steering.nextdns.io.
AAAA IN steering.nextdns.io.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Blocks: 1810410

(In reply to fantasyfate from comment #18)

Unfortunately at version 108, "DNS over HTTPS" chases CNAME answers if HTTPS records have valid answers.

This bug has already landed. I have filed bug 1810410 to look at this.

Status: REOPENED → RESOLVED
Closed: 2 years ago → 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: