Signal desktop app does not work in IPv6-only environment.

[mdavids]

#2327 still seems an open issue.

I have an IPv6-only system (with IPv4 disabled on my interface) and a NAT64/DNS64 setup to reach the IPv4-world. I can see the Signal desktop app is attempting A and AAAA queries for 'textsecure-service.whispersystems.org' (among other things, like 'cdn.signal.org' and 'updates2.signal.org') and then trying to prefer the A-record over the AAAA record, even though there is no IPv4-connectivity possible. This obviously fails. The AAAA answer is not used.

When I reconfigure my DNS64 resolver in such a way that an A-query gives a NODATA result, so that AAAA is the only reply returned, everything works. However, I can only do that in my own environment, not in other similar IPv6-only environments, maintained by others.

It seems to me that Signal (or Electron, or NodeJS for that matter) has no, or a dysfunctional 'Happy Eyeballs'-implementation. Could be NodeJS: nodejs/node#6307

Is this something that can be fixed?

[kenpowers-signal]

I can see a PR for node referenced in that issue: nodejs/node#31567

Once a fix reaches Node and then eventually Electron this issue should work itself out after we update to that version of Electron. I don't think there's much else we can do on our end though.

[huaracheguarache]

Looks like the IPv6 fix has been merged: nodejs/node#39987

And a new version with the fix is on the way: nodejs/node#40119

[indutny-signal]

We should get with an Electron update eventually. Great stuff!

[treysis]

It's more or less a NodeJS thing that is solved in v17. Although still no happy eyeballs. However, electron will only support that after the NodeJS fix makes it into v18 (LTS) and electron switching over to v18, and then Signal switching to the latest electron release after that. I don't expect that to happen well into 2022, maybe even 2023.

NodeJS generally gives the option to override the reordering of DNS results in favor of IPv4. Not sure if electron has the option to pass this on. In that case it could be 'fixed' by Signal itself. There's also some option in the latest NodeJS v16.x release to override the DNS reordering. Don't remember if this can ne set by a config file or only via cmdline (aside from passing the option in code after importing the module).

[optimismus]

This seems to be still open/unfixed. Signal App works great, Signal Desktop doesn't work. As far as I could see chat.signal.org which is used by Signal Desktop is IPv4-only:

Name:    chat.signal.org
Addresses:  76.223.92.165
          13.248.212.111

while Signal App uses update2.signal.org, which has dualstack:

Name:    updates2.signal.org.cdn.cloudflare.net
Addresses:  2606:4700:4400::ac40:91e4
          2606:4700:4400::6812:2a1c
          172.64.145.228
          104.18.42.28
Aliases:  updates2.signal.org

Is it still a software problem?

Regards
Axel

[kubrickfr]

This has some real-life implications. I went to a google office recently, and their guest network is IPv6 only (with NAT64 and DNS64), and it's impossible to use signal-desktop from there...

[KemalSoysal]

I have the same issue, is any help needed for resolving this issue?

[pavel-odintsov]

Hello!

I just finished deployment of IPv6 only network for my home office and noticed that Signal Desktop on Linux is not working well with NAT64 and native IPv6. Majority of apps work fine and it's clearly blocker for migration to IPv6.

Many engineers use Signal and ability to use it in IPv6 only environment is crucial for migration of Internet to IPv6 in coming decades.

Any chance to get more attention to this issue? Can I help in any way?

It's not actually very clear why it fails as I can see IPv6 addresses for signal.org and site itself works fine for me.

Thank you!

[treysis]

Electron framework still uses old NodeJS version which always prefers IPv4.

[alexhaydock]

I can confirm this is still an issue as of today on Windows 11 and the recent #6170 issue suggests it still affects Linux desktops as well.

Really this is not best practice, and as others have noted, this likely requires an upstream rebase of the NodeJS version that the Electron framework uses, but if you're on a v6-only network and you just need a way to make Signal Desktop work, then you can add these lines to your hosts file to make things work:

2600:9000:a61f:527c:d5eb:a431:5239:3232 chat.signal.org
2600:9000:a507:ab6d:4ce3:2f58:25d7:9cbf chat.signal.org

2a00:1450:4009:822::2013 storage.signal.org

# There's no actual AAAA records for cdsi.signal.org. See note below.
2001:8b0:6464:0:66:0:1409:e67 cdsi.signal.org

2600:9000:215b:6800:1d:4f32:50c0:93a1 cdn.signal.org
2600:9000:215b:e200:1d:4f32:50c0:93a1 cdn.signal.org
2600:9000:215b:9400:1d:4f32:50c0:93a1 cdn.signal.org
2600:9000:215b:9a00:1d:4f32:50c0:93a1 cdn.signal.org
2600:9000:215b:c600:1d:4f32:50c0:93a1 cdn.signal.org
2600:9000:215b:d600:1d:4f32:50c0:93a1 cdn.signal.org
2600:9000:215b:e000:1d:4f32:50c0:93a1 cdn.signal.org
2600:9000:215b:7200:1d:4f32:50c0:93a1 cdn.signal.org

2606:4700::6812:32b cdn2.signal.org
2606:4700::6812:22b cdn2.signal.org

2606:4700::6812:187e updates2.signal.org
2606:4700::6812:197e updates2.signal.org

I based this list mostly on the domains in this file rather than trying to capture DNS on the wire myself, so hopefully I haven't missed any addresses Signal relies on. It seems to work well for me with these domains though, including media sharing and checking for updates.

The obvious caution applies here in that some of these are CDN-provided addresses so this is liable to break if those addresses get cycled at any point. And since I looked them up from my home location these might not be the most optimal CDN endpoints to be using for anyone but me. But for now, this is a temporary client-side resolution to this issue until it gets fixed upstream for the small number of people who it affects.

Edit: It's been pointed out to me that there's no actual AAAA record for cdsi.signal.org, so the address above points to my NAT64 gateway and likely won't work for anyone else. I'm not sure what this domain is actually for, so I'm not sure whether not having it will impact Signal Desktop much.

[pavel-odintsov]

Thank you so much for sharing your findings. It saved lots of time for me.

I believe I addresses this issue for my network at cost of custom patch for my recursive DNS server Unbound: NLnetLabs/unbound#819

With this patch my DNS setup is quite neat and reliable:

local-zone: "chat.signal.org." block_a
local-zone: "cdn.signal.org."  block_a
local-zone: "cdn2.signal.org." block_a
local-zone: "cdsi.signal.org." block_a
local-zone: "storage.signal.org." block_a

I just block A queries and then Signal app works just fine.

I hope it will be accepted to upstream Unbound as it may be useful trick for other projects.

[alexhaydock]

I hope it will be accepted to upstream Unbound as it may be useful trick for other projects.

Nice work! I imagine that patch breaks DNSSEC for the domains in question so hopefully there'll still be appetite to accept it upstream because I can definitely see a few uses for it.

[pavel-odintsov]

Thank you! I think it may cause issues with DNSSEC only if client / stub resolver runs in full DNSSEC mode as we will have no NSEC records in that case but Signal does not bother with DNSSEC and I think in this case it may work fine: https://dnsviz.net/d/signal.org/dnssec/

[maurice-w]

Nice work @pavel-odintsov!
You can achieve similar results using existing Unbound features by involving the respip module. I added a feature to filter all A records to OPNsense a while ago; this didn't require patching Unbound: opnsense/core#5944 opnsense/core#5945
This has proven quite useful for broken apps and IoT things which only use IPv6 if there are no A records.

[treysis]

For cases like this I adapted the filter-aaaa module for bind9 as filter-a. It has made its way upstream, however I think it's currently broken. Whoever uses bind9 might give it a try!

[pavel-odintsov]

Thank you for sharing, it looks really good: https://manpages.debian.org/unstable/bind9/filter-a.8.en.html

[pavel-odintsov]

I got alternative solution idea from dnsdist team and it can be done this way:

addAction(QTypeRule(DNSQType.A), RCodeAction(DNSRCode.NOERROR)) 

[pavel-odintsov]

My patch for Unbound was accepted and it's part of Unbound now: NLnetLabs/unbound#819

[pavel-odintsov]

I've tried Signal 6.3.0 on Ubuntu 22.04 and I can confirm that it's still broken in IPv6 native environment.

[treysis]

Probably because the electron folks decided to override the default dns setting back to preferring IPv4 💩

electron/electron@75d2caf

[hslabbert]

This is beyond absurd. It's 2023 and nodejs still thinks it's acceptable to arbitrarily override resolution behaviour by default.
nodejs/node#40702

[treysis]

What do you mean? That NodeJS offers an option to override default DNS sorting behavior?

[hslabbert]

In the linked issue there is discussion about override options to control this reordering:
nodejs/node#40702 (comment)
nodejs/node#40702 (comment)

It's mentioned there as a means for folks to return to the broken reordering behaviour when the default was changed to correct behaviour, though I suppose it could be used to override the now-broken-yet-again default to actually leave things alone and respect resolver ordering.

I'm just really frustrated that it appears they tried to shift to correct (don't arbitrarily reorder) defaults, then caved and flipped it back.

[hslabbert]

Okay, I read things wrong. The default behaviour should be correct in node 17 with the arbitrary reordering removed by default.

Clearly I'm undercaffeinated.

[maurice-w]

Unfortunately, I have to confirm that Signal Desktop 6.4.0-beta.2 still doesn't work on a Windows 11 machine in an IPv6-only network (with DNS64 + NAT64). Filtering A records in DNS is still required to make it connect.

[treysis]

@hslabbert never mind :D however, everything happens exactly as I feared: people that are slowly transitioning to Node v18 (because v16 will fall out of support this autumn) and are suddenly experiencing problems. Instead of fixing the apps, they simply revert to the old DNS sorting. And we all know that this change will stay in their code for years to come. Future automated tests will also fail and thus this setting is engraved in stone.

I don't know any way out of this. I understand that the Node folks don't want to introduce such a breaking change with no way around it. But I think it's bad.

@maurice-w Since the ipv4first option seems to make its way even into the coming Electron v24, I don't think this will change in the near future. Maybe 2030? Fingers crossed 🤞 And well, probably 2030 there will be no more Signal. Maybe even no NodeJS. Maybe that's just the way it will be: every software of today won't become really IPv6 capable before its end of life.

[treysis]

Probably because the electron folks decided to override the default dns setting back to preferring IPv4 💩

I got something wrong: yes, Electron 24 (which hasn't been finally released) does indeed override the default DNS sorting behavior. So in theory there's a tiny chance to convince Electron folks to change that.

However, Signal 6.3.0 still uses Electron 22. Electron 22 still uses NodeJS 16.17.1 with the old DNS sorting. I'm not sure if it's possible for anything using Electron 22 (or 24 for that matter) to override the settings passed onto NodeJS?

[treysis]

It seems I missed some stuff that happened over the last weeks/months. It seems NodeJS now supports Happy Eyeballs 🤓!

I am not sure if it is enabled on v18, just wasn't able to figure this out. But eventually this will cause clients to try all addresses including IPv6, even with ipv4first being set. So maybe we won't have to wait till 2030 :)

[agowa]

I think I'm hitting the same issue. And I'm on v6.14.0 (from 5 days ago, Node 16.17.1, Electron 22.3.5), so sadly it's still not fixed in the latest version of Signal. so probably still some time to wait. @treysis, do you have some insight in the overall progress? Are there any roadmaps or issues available to track?

#v6.14.0

[treysis]

@agowa338 Signal is still based on Electron 22 with itself is based on the older Node v16.17. Unfortunately, I don't know of any roadmap. I am not affiliated in any way with the Signal project.

[koxu1996]

I have dual IPv4/IPv6 environment - with the latter as default - and Signal does not work for me as well.

I am using Arch Linux with netctl network manager; using unbound as DNS resolver helped in my case:

$ sudo pacman -S unbound expat
$ sudo systemctl enable --now unbound.service

$ cat /etc/resolvconf.conf
name_servers="::1 127.0.0.1"
resolv_conf_options="trust-ad"
$ sudo resolvconf -u

$ cat /etc/resolv.conf
# Generated by resolvconf
nameserver ::1
nameserver 127.0.0.1
options trust-ad

[agowa]

@koxu1996 you need a DNS server that filters all A-Records and only serves the AAAA ones. That's the only way signal currently works for me...

[indutny-signal]

@agowa are you on the latest version of Signal. I believe it should work even with mixed A/AAAA records now! Please let me know if it doesn't and if you could submit a debug log - I'd be happy to take a look.

[maurice-w]

I believe it should work even with mixed A/AAAA records now!

It does indeed! Works for me as of Signal Desktop 6.25.0-beta.1 (Windows). Yay, finally!

[indutny-signal]

Hooray!

[koxu1996]

@agowa Yeah, I used the rules from @pavel-odintsov:

local-zone: "chat.signal.org." block_a
local-zone: "cdn.signal.org." block_a
local-zone: "cdn2.signal.org." block_a
local-zone: "cdsi.signal.org." block_a
local-zone: "storage.signal.org." block_a

However, it works out of the box now - version 6.24.0 🎉

[pavel-odintsov]

Amazing, I can confirm that it works fine in IPv6 only NAT64 enabled network.