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]
…
- [::] is the IPv6 version of 0.0.0.0
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?