_devalias

From this same thread, I found the Prefs > Advanced > GPU renderer redraws at least this often setting, which defaulted to 0.5sec; and changing it to 5sec (and then 3600sec to effectively disable it) seemed to drop my CPU usage from ~8-9% down to 1-2%; and I think also caused WindowServer to have way less CPU usage as well.

https://gitlab.com/gnachman/iterm2/-/issues/8640#note_3015813030

Ah true; that sucks :(

No worries, hopefully it can, and hopefully you get your situation figured!

Curious, are you pinning the SPKI fingerprint at all? I just ran into a similar sounding issue (though potentially different software setup, through ASUS router with DNS-over-TLS Profile set to Strict)

In my case, I had this old hash pinned:

SPfg6FluPIlUc6a5h313BDCxQYNGX+THTy7ig5X3+VA=

Which after a little digging / learning, I found out that that certificate seems to expire in ~8 days:

• https://crt.sh/?id=16251294730

And so it is probably in the process of being switched out; and may even be in a 'brown out' phase (which might explain why every now and then you're getting failures from it)

Using kdig I checked what the current certificate I was receiving was:

⇒ kdig -d .0.0.1 +tls-ca +tls-host=cloudflare-dns.com example.com
;; DEBUG: Querying for owner(example.com.), class(1), type(1), server(1.0.0.1), port(853), protocol(TCP)
;; DEBUG: TLS, imported 148 system certificates
;; DEBUG: TLS, received certificate hierarchy:
;; DEBUG:  #1, CN=cloudflare-dns.com,O=Cloudflare\, Inc.,L=San Francisco,ST=California,C=US
;; DEBUG:      SHA-256 PIN: ltQ6aXy3tqpNZKJdnevMD7oR+IsI5rNWbOssFDrl+Ew=
;; DEBUG:  #2, CN=SSL.com SSL Intermediate CA ECC R2,O=SSL Corp,L=Houston,ST=Texas,C=US
;; DEBUG:      SHA-256 PIN: zGgA4OU4DjJdvpRYUqbi5Vh2g9W5Oc/PgKihy9mkLsE=
;; DEBUG:  #3, CN=SSL.com Root Certification Authority ECC,O=SSL Corporation,L=Houston,ST=Texas,C=US
;; DEBUG:      SHA-256 PIN: oyD01TTXvpfBro3QSZc1vIlcMjrdLTiL/M9mLCPX+Zo=
..snip..  

Which had the following SPKI hash:

ltQ6aXy3tqpNZKJdnevMD7oR+IsI5rNWbOssFDrl+Ew=

Checking the certificate transparency logs for one.one.one.one, I saw there were a few newer certificates:

• https://crt.sh/?q=one.one.one.one

And after downloading them and calculating the SPKI hash, I found that this one seemed to match what I was receiving:

• https://crt.sh/?id=23481945460

I calculated the hash like so:

⇒ openssl x509 -in 23481945460.crt -pubkey -noout \
  | openssl pkey -pubin -outform DER \
  | openssl dgst -sha256 -binary \
  | openssl base64

ltQ6aXy3tqpNZKJdnevMD7oR+IsI5rNWbOssFDrl+Ew=

After updating my router settings to include that new SPKI fingerprint, everything seemed to work properly again, and DNS started resolving consistently as expected.

Edit: I wrote up the full debugging process I followed in a gist here, in case that's of use to anyone: https://gist.github.com/0xdevalias/e5430349a3e6e5feb347f8a373877f4e#dns-over-tls-dot-spki-fingerprint-pinning-issue-debugging

If you use BetterTouchTool, you can directly set a keyboard shortcut for Shift+Esc, and have that trigger a 'Trigger Menu Bar Menu-Item' with the command path set to: Window;Task Manager.

For anyone stumbling upon this into the future; I believe riot:// was for Beeper v3; and while I haven't tested to confirm, I assume it may no longer work in Beeper v4.

In Beeper v4+, the URL prefix is beeper:// , and then I detailed the extra paths and specifics in my comments on this other post where I deep dove into discovering them all the other day:

https://www.reddit.com/r/beeper/comments/1hnjphq/comment/nfwke8h/