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?
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
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.
I have demonstrated that this is not an Openfire issue, and that it is correctly report the dns queries.
Perhaps openfire is not a good fit for your unique use-case. I’m sorry that we were unable to further assist you with your issues.
OMG, you really did no have to try to end this this with a corporate-sounding spin.
Did I hurt you by asking these questions? I am sorry if I did. All I was trying to find out was why there is a long delay after a log in that was not there in the old version.
I won’t disturb you anymore, I promise.
no…you didn’t hurt me. I just don’t know how else I might be able to help. I believe that your setup/environment is unique. Everyone here thats helped has not been able to reproduce your issue. It appears that you are the only one reporting the issue. This further supports that its something unique to your setup/environment. Without deeper knowledge of your environment, use-case, and desired end result…I’m afraid the support offered by me and other volunteers will be limited.
I’m with @speedy and don’t know what else to recommend other than trying to find out what’s different/unique with your VM and network settings.
For example, in one of your netstat logs I noticed both; IPv4 and IPv6 addresses but protocol shows TCP for both (and not TCPv6 for the [::] address).
Proto Local Address Foreign Address State
TCP 0.0.0.0:5222 HOST1:0 LISTENING [openfire-service.exe]
…
TCP [::]:5222. HOST1:0 LISTENING [openfire-service.exe]
…
Windows Server 2008, and later versions of Windows implement RFC 3484 and use a prefix table to determine which address to use when multiple addresses are available for a Domain Name System (DNS) name. By default, Windows favours IPv6 global unicast addresses over IPv4 addresses.
If this is the case for the network adapter(s) on your VM, have you tried setting Prefer IPv4 over IPv6 in prefix policies or tried disabling IPv6?
Not sure if it helps if you add A, PTR and SRV records for the IPv6 address of your VM to the DNS as well?
