XMPP Service Operators - 2026-02-25

Hi all, given that the .im is somewhat popular with people like us, it's a bit annoying that the registry does not provide DNSSEC. Did anyone else here run into this problem as well, and can share some experience other than "it just not possible" ? I found this from 10 years ago https://op-co.de/blog/posts/yax_im_dnssec is my assessment correct that nothing changed since then ?

> Hi all, given that the .im is somewhat popular with people like us, it's a bit annoying that the registry does not provide DNSSEC. > Did anyone else here run into this problem as well, and can share some experience other than "it just not possible" ? > I found this from 10 years ago https://op-co.de/blog/posts/yax_im_dnssec is my assessment correct that nothing changed since then ? Yes, my server is on a .im domain so it's quite annoying. I partially mitigated this by pointing my SRV record to another domain with DNSSEC. ↺

The .im registry simply doesn't bother with implementing DNSSEC or many other new registry features, I've contacted nic.im and the company that operates it a couple of times already

Yeah when I was trying to figure it out I found their amzingly quaint website :)

By "partial mitigation" do you mean that the lookup against the records returned from SRV are signed, but after that you're still not able to do DANE ? ✏

I believe servers look for the TLSA records at the SRV target

So if the target is xmpp.example.com, it should be looking at `_port._tcp.xmpp.example.com`

So I can have working DANE, I just haven't added the TLSA records yet

Telepath admin: no that won't help in any way, the .im records returned can't be trusted so dane can't be done

the .im only returns the SRV records, the important stuff like TLSA records are on the signed domain

but the SRV record cannot be trusted indeed

still better than nothing, I guess

> the .im only returns the SRV records, the important stuff like TLSA records are on the signed domain yes but nothing will fetch and use them because that would be a security vuln ↺

That mitigation afaik is only signing the authoritative records, its still possible to spoof the TLD lookup and serve fake records.

haven't really read it all, but I believe it was what it was getting at?

there's no mitigation, if you pick .im you can do nothing with DNSSEC/DANE/TLSA

> I believe servers look for the TLSA records at the SRV target servers look for the TLSA at the JID domain, not the SRV target, since thats the domain certs they are trying to verify against similarly SRV targets are untrusted and is only used to guide IP/port resolution ✏ ↺

I dare say SRVs should also be DNSSEC-checked too but i don't think any software does that

not exactly, TLSA is fetched for SRV targets but only if all domains involved are signed with dnssec

huh, why would TLSA be fetched for SRV targets? what benefit does that give if said target hostname isn't even used in establishing the connection?

> servers look for the TLSA at the JID domain, not the SRV target, since thats the domain certs they are trying to verify against > > similarly SRV targets are untrusted and is only used to guide IP/port resolution Prosody docs suggest otherwise ↺

there is also RFC 7673

the target hostname is used if the srv records are signed with dnssec

I like this DNSSEC explanation best https://wiki.xmpp.org/web/The_Knight

> there's no mitigation, if you pick .im you can do nothing with DNSSEC/DANE/TLSA moparisthebest, the article above... ↺

ah I misunderstood,

I have read the article more, still far from perfect solution

> the target hostname is used if the srv records are signed with dnssec did I catch this correctly: "target hostname" here refers *NOT* to the hostname in the jid (i.e. test@example.com) *but* to the hostname returned *inside* the SRV record response ? And "used" means that it's the name that is compared against the one that the server sends in it's certificate ? I.e. the verification logic is different between a full-DNSSEC and non-DNSSEC scenario ? ↺

kmq: correct

s2s only or c2s as well ? Because that would mean it's possible to host an xmpp service at xmpp.customer234.myhostingservice.example.com for a user myname@vanitydomain.com without having to share certificates for vanitydomain.com no ? (if all DNSSEC)

if the JID is bob@a.com and a.com returns dnssec signed srv pointing to b.com then the cert is trusted if it's valid for *either* a.com or b.com, both c2s and s2s

yes exactly

what ? that's amazing. This has been bothering me for so long :) time to test it out !

the problem you'll run into is most clients and servers today don't do dnssec at all and therefore just won't trust the cert

. ✏

> if the JID is bob@a.com and a.com returns dnssec signed srv pointing to b.com then the cert is trusted if it's valid for *either* a.com or b.com, both c2s and s2s this is how you delegate to another domain name in xmpp-land? ↺

are there actually servers that would accept (and serve) b.com certs, while hosting an a.com xmpp service?

> are there actually servers that would accept (and serve) b.com certs, while hosting an a.com xmpp service? and even if they exist, then how can I, as a hoster, tell sending clients/servers to *only* accept a.com certs from an IP address derived from a b.com SRV target? The only way I can see is to specifically unsign the SRV RRSET, which is a questionable thing to do ↺

why would you want to do that

>> if the JID is bob@a.com and a.com returns dnssec signed srv pointing to b.com then the cert is trusted if it's valid for *either* a.com or b.com, both c2s and s2s > > this is how you delegate to another domain name in xmpp-land? It's one of at least 3 ways I know of yes lol ↺

> why would you want to do that if my server ingress depends on a CDN/dynamic DNS thingy, i'd rather use their domain ✏ ↺

still not seeing the reason? it just allows more certs doesn't break if the cert is only for a.com

but i want the certs to specifically be a.com? so the CDN isn't gonna put their certs + TLSA in?

you are saying you delegate to a domain you don't trust? just don't do that

>> >> this is how you delegate to another domain name in xmpp-land? > > It's one of at least 3 ways I know of yes lol what are the other ways? this is the only one I know of that doesn't require a cert on a.com, which is interesting ↺

> you are saying you delegate to a domain you don't trust? just don't do that i'm saying that if I need to delegate to a domain solely for its IP function, then this approach does not work. Perhaps I can delegate a.com to xmpp.a.com, and CNAME xmpp.a.com to cdn.b.com. Then that _might_ work? But that does look like a workaround more than anything ↺

all of them allow for that, the other ways are POSH and https://xmpp.org/extensions/xep-0487.html

the concept is called "secure delegation" and exists outside XMPP too

>> you are saying you delegate to a domain you don't trust? just don't do that > > i'm saying that if I need to delegate to a domain solely for its IP function, then this approach does not work. > > Perhaps I can delegate a.com to xmpp.a.com, and CNAME xmpp.a.com to cdn.b.com. Then that _might_ work? But that does look like a workaround more than anything if the CNAMEs are all dnssec signed then secure delegation allows this cert to be valid for cdn.b.com too ↺

you shouldn't securely delegate to domains you don't trust 🤷

>> >> i'm saying that if I need to delegate to a domain solely for its IP function, then this approach does not work. >> >> Perhaps I can delegate a.com to xmpp.a.com, and CNAME xmpp.a.com to cdn.b.com. Then that _might_ work? But that does look like a workaround more than anything > > if the CNAMEs are all dnssec signed then secure delegation allows this cert to be valid for cdn.b.com too is this from reading the rfc? ↺

yes

Hi everyone, I've written a small bot based on SlixMPP. :) BanBot is an XMPP bot for managing bans and temporary bans in multiple MUC (Multi-User Chat) rooms. It allows centralized administration from a designated admin room and protects multiple chat rooms from unwanted users. REPO: https://git.envs.net/envs/muc_banbot

https://upload.envs.net/file_share/019c95b7-e56c-7905-9b97-901ab85b0749/8049bde3-5832-4737-acaa-e91e7a919052.png

nice! you might also be interested in joining xmpp:bots-dev@muc.loqi.im?join

REPO is also MIRRORED TO: https://github.com/envs-net/muc_banbot

thanks for sharing

> REPO is also MIRRORED TO: https://github.com/envs-net/muc_banbot Yeah I was uhhh writing my own, so this saves like, a month or more of work lol ↺

Thanks man