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?
IPv6 is disabled on all interfaces but local.
We do not use IPv6 and do want to have anything to do with it. 100% of our infrastructure is on IPv4, so we do not touch any IPv6 related settings in any software.
The confusion with the SRV records continues. I am very slowly making progress on this.
Our hosting company installed a tool on our servers called Magnawall. It helped visualize the issue with firewall rules. They were open on the DNS port to a wrong EXE of which I had asked but got no answers in another thread.
Now that I opened the DNS port to the correct EXE, I got further on the DNS SRV record verification page.
It now shows the following:
and says:
To compose the information on this page, a DNS SRV query has been made, using the value of domain.com, which is the XMPP domain name that is configured for Openfire. Any resulting records are inspected for a match against the value of mail.domain.com, which is the fully qualified domain name of the server that is running Openfire, as configured here.
When I click on the link “configured here” it shows mail.domain.com and that is the valid destination for the SRV records:
C:\>nslookup -type=srv _xmpp-client._tcp.domain.com
Server: UnKnown
Address: 192.168.27.1
_xmpp-client._tcp.domain.com SRV service location:
priority = 0
weight = 5
port = 5222
svr hostname = 192.168.27.2
domain.com nameserver = 192.168.27.1
But then the 3 tables below show the IP address 192.168.27.2 as the Host for port ## 5222, 5223, and 5270, instead of mail.domain.com.
I do not see any of the 3 tables on the screenshots attached to the marked solution, so not sure what is going on here.