False-positive warning regarding missing SRV records

This thread is a continuation of Login to admin web UI - #65 by speedy for this specific issue:
The main admin page shows warning

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.

Well from the list there you are missing _xmpp-server.

It would be useful for you to provide the domain so that its easier to help.

It would also be useful for you to mention the Openfire version this is occurring on.

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?

Still the same as in the linked thread.

Unless you give me the domain, I can’t really help here.

Also a screenshot might be useful, I have never seen this error.

Name resolution absolutely does not require an outbound packet to anywhere, since local methods exist, like hosts files and caches.

Was your lookup run from your Openfire host machine?

Why are you attempting to fix this? Is it an actual problem causing people real-world issues?

Have you followed all instructions as described in Wireshark/DNS?

  1. Type ipconfig /flushdns and press Enter to clear the DNS cache of the Windows OS.
  2. Type ipconfig /displaydns and press Enter to display the DNS cache.

Have you cleared DNS Records in Openfire?

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.

whats your xmpp domain. perhaps the records you created are not in the correct zone?

as you can see from my lab openfire. there are no issues with custom domain.

I am happy to respond in private if you don’t want to make the domain public, but it is difficult to help if you do not provide this information.

I am sure others here would allow the same as well… (ask however)

Copy-paste from the admin UI is hard to mess up. Do you presume that OF’s code base is infallible?

The domain won’t do you any good. Like I mentioned several times, it is not open to the Internet. So I am at a loss to understand why you ask for it.

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

Let’s try to focus on the way OF or its admin console know that SRV records are missing. How do they establish that for a fact?

DNS lookup, and compare it against what it should be.

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.

with record added

1 Like

This is something that I can work with.
Thanks a lot!

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.