XMPP stream binding with external addresses

Objective:
Ejabberd over tor with simple password authentication. No TLS certificates as using tor service instead.

Current setup
Ejabberd on a Raspberry Pi, port 5222 on boundary router forwarded to Pi. I have a second computer which sends messages to myself via Pidgin XMPP client. This computer has host entries "jab-free" with the IPv4 address of Pi on local computer, and "russell.nz" set to the external ip address. When the user has "connect server" set to "jab-free" then I can send a message to myself however as soon as I set the server to "russell.nz" the ejabberd server correctly recieves the message but then fails with a message:

2022-09-17 15:05:35.960 [info] <0.735.0>@ejabberd_c2s:handle_auth_success:442 (tcp|<0.735.0>) Accepted c2s PLAIN authentication for tony@jab-free.russell.nz by mnesia bac
kend from ::ffff:127.0.0.1
2022-09-17 15:05:37.862 [info] <0.735.0>@ejabberd_c2s:bind:411 (tcp|<0.735.0>) Opened c2s session for tony@jab-free.russell.nz/41049815455288262451026
2022-09-17 15:07:20.319 [info] <0.737.0>@ejabberd_s2s_out:init:280 Outbound s2s connection started: jab-free.russell.nz -> jab-free.nz
2022-09-17 15:07:20.459 [warning] <0.737.0>@ejabberd_s2s_out:process_closed:160 Failed to establish outbound s2s connection jab-free.russell.nz -> jab-free.nz: DNS lookup
failed: non-existing domain; bouncing for 19 seconds

So instead of binding to the originating connection, it seems instead to be attempting an s2s connection instead.

Start with the ejabberd_c2s:bind and ejabberd_s2s_out:init log paths shown in the report, then review how the external address and authenticated session are interpreted. Reproduce the Tor or forwarded-address setup described in the issue and trace why the session leads to an outbound s2s lookup. Done means the reported external-address connection follows the intended binding behavior without the failed lookup.