Server Host Name (FQDN): mail.domain.com DNS configuration appears to be missing or incorrect.
Other members tried to convince me that something is wrong with ‘my setup’ whatever it is, but I established, through Wireshark packet capture, that neither OF server nor its admin UI make any DNS requests whatsoever; therefore, they cannot possibly know that the DNS configuration is missing.
If my Wireshark filter is flawed, feel free to correct me. I used dns filter. My method of confirming the validity of that filter was to copy-paste the records that are allegedly missing into command line and run nslookup -type=SRV on them. Wireshark immediately showed the queries to my DNS server and responsed from it. Besides them, only queries originating from the browser during the logging in to the admin UI got captured. Neither of them queried the three records claimed as missing by the admin UI:
_xmpp-client._tcp.domain.com. 86400 IN SRV 0 5 5222 mail.domain.com.
_xmpps-client._tcp.domain.com. 86400 IN SRV 0 5 5223 mail.domain.com.
_xmpps-server._tcp.domain.com. 86400 IN SRV 0 5 5270 mail.domain.com.
Since no queries can be captured since the start-up of the OF service and until after the ‘DNS SRV Record verification’ page finishes loading, this appears as a false-positive warning.
I am confused.
The OF admin UI displays a list of 3 missing SRV records. That list is above. Why should it matter that something else which is not on that list is missing, and why that extra item should concern me before the 3 items are addressed?
Not in this case. We control items that you mention.
Yes to 1 and 2.
Where do I find that UI?
Because it is a warning with an exclamation sign icon on it. ITIL dictates that such issues have to be looked after. As to whether that’s a problem or whether it causes “real-world” issues, I have no way of knowing because OF is a black box for me. It is this forum that can only provide me with any insight into that. Hoping for that.
One of the item that I can suspect is the long delay in logging into the admin UI that I had mentioned on the linked thread. Again, I have no way of knowing whether it is related or not. Only developers of this product can possibly offer troubleshooting steps. Hoping for that.
On the main page the warning appears as follows:
When I click on it, it takes me to another page that still has Server Information menu item showing as selected:
SRV records are related to XMPP clients discovering the XMPP server. They won’t be related to the Admin login time. Given the massive length of that thread, I’m sure you’ll understand if I won’t reread it all, but given it’s closed but you state it’s not solved, if you wanted to open a new thread about that (unrelated to SRV records) and summarise all of the findings so far, I’d be happy to read that.
I’d posit that the hypervisor could be what’s preventing you from detecting network lookups. Naturally there’s an element of indirection at the network layer.
You’ve spent a while saying “Openfire can’t have looked them up” but you haven’t said whether or not the records actually exist.
I forgot about this, that makes it a lot harder to configure.
Its still useful to know the domains, and see the outputs… you keep redacting it, its very difficult to help without the full story.
Its not that speedy believes the codebase is infallible, its the fact they can not reproduce your issue, if they can’t reproduce your issue then its hard to blame the codebase.
If you choose to continue here I need to see the FQDN and the domain name, the records Openfire is recommending you to add, and then all 4 outputs from a dns tool such as dig or nslookup.
internal or external accessibility is irrelevant. I’m unable to reproduce your issue using an internal domain space as well. this leads me to believe that your incorrectly setting your records in the incorrect dns zone. in this case, your internal dns
That is not happening, like I explained earlier. We are going in circles.
Neither OF or its admin console make any DNS queries but display the warning. How do they make the decision to display it?
Openfire will check DNS at the time of signing into the admin panel and using the DNS Check page.
I set up my internal domain with out setting the SRV records…as you can see, wireshark captured the request to my internal DNS and provided the accurate response.
I tested all of our clients. None of them is interested in the DNS SRV entries and only wants to resolve the XMPP server and STUN.
OF still makes no DNS queries. This is a dead end.
