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

#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?

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.

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

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

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).

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

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...

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

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!

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

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.

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.

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.

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/

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.

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.

@hslabbert

@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.

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?

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 :)

@treysis

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

@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.

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

@koxu1996

@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...

@agowa

@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.

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!

Hooray!

@agowa

@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 🎉

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

Navigation Menu

Repository navigation

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

10 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

kenpowers-signal commented on Apr 2, 2020

huaracheguarache commented on Sep 26, 2021

indutny-signal commented on Sep 27, 2021

treysis commented on Oct 21, 2021

optimismus commented on Jun 30, 2022

kubrickfr commented on Nov 2, 2022

KemalSoysal commented on Nov 16, 2022

pavel-odintsov commented on Dec 31, 2022

treysis commented on Jan 2, 2023

alexhaydock commented on Jan 2, 2023

pavel-odintsov commented on Jan 3, 2023

alexhaydock commented on Jan 3, 2023

pavel-odintsov commented on Jan 3, 2023

10 remaining items

hslabbert commented on Jan 26, 2023

maurice-w commented on Jan 26, 2023

treysis commented on Jan 26, 2023

treysis commented on Jan 27, 2023

treysis commented on Jan 27, 2023

agowa commented on Apr 17, 2023

treysis commented on Apr 17, 2023

koxu1996 commented on Jun 22, 2023

agowa commented on Jul 10, 2023

indutny-signal commented on Jul 10, 2023

maurice-w commented on Jul 10, 2023

indutny-signal commented on Jul 10, 2023

koxu1996 commented on Jul 10, 2023

pavel-odintsov commented on Jul 29, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions