XMPP Service Operators - 2024-01-19

Hello

Stefan: yo, what brings you here?

Hi! It seems I have a problem with my server records. the thing is, gajim needs more than 15 seconds to connect. (psi+ connects immediately). and I could first not connect to this muc, said "not reachable" (second try worked then). I thought it could be a problem with ipv6 not available (had this with putty), but others said i should check my server records. I have a dynip setup with a myfritz domain.

compliance tester from inputmice didn't pass the server-records test formerly.

Stefan: what did it complain about?

Gajim logs say what? DNS SRV records are fine?

I don't remember exactly, and now it doesn't work anymore.

> DNS SRV records are fine? i don't know enough about it to be able to answer that. could i show you the records?

Maybe

https://chat.rxmpp.de:5443/upload/5680bcb646ac9f3fe800312b92506ad84e990a48/tRYepj1xok0ythz5qDuy/64dcb28a-7870-4419-8e6f-33827f74297c.png

I remember I saw failures in the ejabberd log too, somethin with certificates.

Which client sent a picture as link?

gajim?

1.8.4? Odd

Licaon_Kter, embeddings may be stripped here.

for reasons

Ah

yes, 1.8.4

Stefan, * CNAME is..... potentially causing issues

Good to know. jonas’: how? MUC server manipulates messages?

Licaon_Kter, yes.

Licaon_Kter, I suspect https://modules.prosody.im/mod_muc_restrict_media.html is loaded here

I changed settings on my router, so the daily disconnection doesn't take place anymore. I think of putting in the ip directly now. ip change every 180 days should be not too bad?

Stefan, the ****.de suffix on conference.chat.*****.de needs to be removed

I even read about some methods of automatically change dns settings, it was an article in c't

and try removing the `*` CNAME.

that may cause issues depending on the particular DNS software used.

jonas’, thank you!

so only "conference.chat" ist enough?

yes

(probably—the DNS provider will add that suffix on their own)

ok, I changed the settings. I will check later to see if there has been a change.

good luck!

if it still doesn't work, you can tell us the domain name and we can take a look---it's often easier to poke at these kind of things from the outside because in particular with CNAMEs there's a lot that can go wrong.

can't you see the domain name in my upload link?

oh :)

yeah

I didn't think of it when posting..;-)

ok so the first thing I notice is that the SRV records don't seem to be actually present?

ah, you didn't set them up correctly

but even the other ones don't show up

perhaps because of the change?

how do you lookup that?

I use `dig` on the commandline: `dig +short SRV _xmpp-server._tcp.chat.rxmpp.de` (empty)

perhaps it doesn't work with cname with my provider at all?

or it takes a while, I just changed them, so perhaps that is the reason. thank you very much !

no, even when asking their servers directly (`dig +short @ns01.1blu.de. SRV _xmpp-server._tcp.chat.rxmpp.de`) the SRV record does not show up, but the `*` CNAME is gone already.

ah..

but that shouldn't be an issue, actually, quite the opposite. The chat.rxmpp.de record exists and seems to work

and a server answers on that (looks like an ejabberd?)

yes.

so it should work

so maybe the stuff with the MUC component will sort itself out now that you fixed the CNAMEs

I'd delete the SRV records in your case, because (a) they do not work and (b) it's not correct to point an SRV at a CNAME

and (c) you don't need them because you have CNAMEs pointing at A records for your XMPP domains

ok. but I could change the cnames to my ip?

no need for that

i mean, remove the cnames, and use ip instead

yeah, no need for that

so what do you think is the reason for the delayed connection in gajim?

does it happen always? ✏

yes. but psi+ is faster, always.

15-20 seconds

i have only ipv4 enabled for my server.

weird

in that case one would probably have to look at network traces. the connection to your server is fast. maybe that's something to ask in the gajim room though, maybe there are debug logs you can look at before shooting with the big guns (wireshark) at the problem.

I asked there already, they said me I should check the server records ;-)

right, but Psi+ seems to work and your server records look ok now to me.

oh, something weird *is* going on

ohhhh

yeah

the problem is very similar to the one I had with ssh / putty, but with a different computer. switching from "auto" to "ipv4" in putty solved the problem and the connection was re-established without delay. the delay was also about 15-20 seconds.

Stefan, your myfritz domain publishes *both* IPv6 and IPv4 records

if your xmpp server only listens on IPv4, that's going to cause issues

you need to make your xmpp server listen on IPv6, or fix the myfritz to only show the IPv4 IP

hmm I already thought about changing the server settings to support ipv6 too. but I don't have any knowledge about ipv6, so I didn't do it yet.

first step i planned now was to not use the cname anymore but put the ip in there.

> Stefan, your myfritz domain publishes *both* IPv6 and IPv4 records great that you noticed that, thank you!

> Stefan, your myfritz domain publishes *both* IPv6 and IPv4 records it looks as if there is no way to change this behaviour of myfritz.

then you should enable IPv6 on your XMPP service :)

fun: https://github.com/berthubert/trifecta/issues/38

Random issues like this are a reason Snikket uses a subdomain for HTTP upload, as "defence in depth" ✏

if your http upload component doesn't already set a strict content security policy, yesterday was a good time to change that.

> and (b) it's not correct to point an SRV at a CNAME now I'm a bit desoriented what would be the best way for me. (not regarding the problem with ipv4/ipv6). point an SRV at a CNAME ist not correct - but what is better now? setting it to the ip(v4), or deleting the SRV as jonas´ suggested? It seems that everything works without these Records? why do I need them at all?

There is a good chance you don't

They are necessary if you have non-standard ports or need to balance connections over multiple servers

ah I see.

> fun: https://github.com/berthubert/trifecta/issues/38 Ah yes, I assume everyone remembers this moment in their life, I know I do: > I never knew that SVG could contain javascript which would run... ↺

Stefan, *if* you wanted to keep SRV records (which you probably don't need to), you could point the SRV directly at your myfritz domain