Under certain conditions, DNS name resolution does not work in the Prosody container. At the same time, the DEBUG logs show that Prosody attempts to resolve using the unbound LUA library, but fails with the error NXDomain (non-existent domain name) prosody[1337]: http debug Making HTTPS POST request '55e3a46e6e50' to https://scc-13.mydomain.test/api/v1/events/meeting/ended prosody[1337]: net.connect debug [pending connection QZfW1go0z8uj] Starting connection process prosody[1337]: net.connect debug [pending connection QZfW1go0z8uj] Checking for targets... prosody[1337]: unbound.queryLVqSOgGQS_rH debug Resolve scc-13.mydomain.test IN A prosody[1337]: unbound.queryIT0aoiuccVGK debug Resolve scc-13.mydomain.test IN AAAA prosody[1337]: unbound debug Processing queries for ub_ctx: 0x55e3a46585a8 prosody[1337]: unbound.query5Zvy3Zmv7vFr debug Results for scc-13.mydomain.test IN A: NXDomain (Insecure, 0.000357 sec) prosody[1337]: unbound.queryorO0X-Rf5VE9 debug Results for scc-13.mydomain.test IN AAAA: NXDomain (Insecure, 0.000312 sec) prosody[1337]: net.connect debug [pending connection is2WbWLKmRw6] No more connection targets to try [NXDomain in AAAA lookup] prosody[1337]: event-sync.meet-13.mydomain.test:lifecycle_alert_component debug POST https://scc-13.mydomain.test/api/v1/events/meeting/created returned code 0 prosody[1337]: unbound.queryIT0aoiuccVGK debug Results for scc-13.mydomain.test IN AAAA: NXDomain (Insecure, 0.000195 sec) prosody[1337]: unbound.queryLVqSOgGQS_rH debug Results for scc-13.mydomain.test IN A: NXDomain (Insecure, 0.000245 sec) prosody[1337]: net.connect debug [pending connection QZfW1go0z8uj] No more connection targets to try [NXDomain in A lookup] Although, the resolution system works correctly and scc-13.mydomain.test resolves to the correct IP address # dig +short scc-13.mydomain.test 10.1.186.29 At the same time, using the sniffer, the outgoing network request from the Prosody container is not visible at the time of the NXDomain error (the moment of an unsuccessful attempt to enter the conference), but the request is visible when manually executing dig +short scc-13.mydomain .test. That is, in fact, Prosody does not contact the DNS server to resolve the name. However, if I remove the unbound library in the container apt-get purge lua-unbound:amd64 Then Prosody begins to use alternative LUA libraries for resolution. In particular, in the DEBUG logs it is clear that the adns LUA library is starting to be used, and resolution is starting to work correctly together with conferences in general. prosody[1337]: adns debug Sending DNS query to 10.1.186.29 prosody[1337]: connJtYcoUBNuSv- debug Closing now prosody[1337]: adns debug Reply for scc-13.mydomain.test (thread: 0x55f362c08978) [false] prosody[1337]: net.connect debug [pending connection yi9w1o2ZLAJx] Next target to try is 10.1.186.29:prosody[1337]: conn7arUVyFrc8NC debug Client FD 17 (10.1.186.29, 443, 172.17.0.17, 50370) created prosody[1337]: conn7arUVyFrc8NC debug Prepared to start TLS prosody[1337]: conn7arUVyFrc8NC debug Starting TLS now prosody[1337]: conn7arUVyFrc8NC debug TLS handshake complete (TLSv1.2 with ECDHE-RSA-AES256-GCM-SHA384) prosody[1337]: conn7arUVyFrc8NC debug Connected (FD 17 (10.1.186.29, 443, 172.17.0.17, 50370)) prosody[1337]: net.connect debug [pending connection yi9w1o2ZLAJx] Successfully connected Reinstalling the lua-unbound:amd64 library does not solve the problem. Libraries version: ii lua-basexx 0.4.1-jitsi1 all baseXX encoding/decoding library for Lua ii lua-cjson:amd64 2.1.0.10-jitsi1 amd64 JSON parser/encoder for Lua ii lua-cyrussasl:amd64 1.1.0-2 amd64 Cyrus SASL library for the Lua language ii lua-expat:amd64 1.3.9-1lua54prosody~bullseye3 amd64 libexpat bindings for the Lua language ii lua-filesystem:amd64 1.8.0-1 amd64 luafilesystem library for the Lua language ii lua-inspect 3.1.1-2 all Lua table visualizer, ideal for debugging ii lua-ldap:amd64 1.2.5-1+b1 amd64 LDAP library for the Lua language ii lua-luaossl:amd64 20161214-3prosody~bullseye2 amd64 OpenSSL bindings for Lua ii lua-sec:amd64 1.0.2-1prosody~bullseye1 amd64 SSL socket library for the Lua language ii lua-socket:amd64 3.0~rc1+git+ac3201d-6prosody~bullseye1 amd64 TCP/UDP socket library for the Lua language ii lua5.4 5.4.2-2 amd64 Simple, extensible, embeddable programming language ii lua-unbound:amd64 0.5-2 amd64 Unbound bindings for the Lua language I use prosody from dockerhub official repo ii prosody 0.12.3-1~bullseye1 amd64 Lightweight Jabber/XMPP server

Thanks for the report Is scc-13.mydomain.test the actual name used? .test is a reserved top level domain, it does not exist in the real DNS tree. Where are the names defined?

• tags Status-NeedInfo

scc-13.mydomain.test - Its my local name I tried different version prosody 0.12.4-1~bullseye1 500 <----- not working, but if I remove unbund-lua then working 500 http://packages.prosody.im/debian bullseye/main amd64 Packages 0.12.3-1~bpo11+1 100 # <----- not working 100 http://ftp.debian.org/debian bullseye-backports/main amd64 Packages *** 0.11.9-2+deb11u2 500 # <--- works fine 500 http://deb.debian.org/debian bullseye/main amd64 Packages 500 http://deb.debian.org/debian-security bullseye-security/main amd64 Packages 100 /var/lib/dpkg/status

libunbound has a built-in definition of the .test TLD as per https://www.rfc-editor.org/rfc/rfc6761#section-6.2 and I can't find a way to override this from Prosody, it may need support in lua-unbound. Since using the legacy DNS stub library works for you, just use that.

• tags Status-Blocked

... as a workaround, for now.

Confirmed, if I for my installation use another domain dns resolving works fine. Also, if I remove lua-unbound library and use domain in .test zone Prosody fallback legacy library stub (adns). But what’s strange is that in version 0.11.9.2 it works correctly without removing the library.

libunbound was added in 0.12.0 <https://prosody.im/doc/release/0.12.0#other> so downgrading to 0.11.x has the same effect as uninstalling lua-unbound, reverting to the earlier stub resolver