"Random" HTTPS issues, possibly related to DNS server

Question

Hi,

this is a rather strange problem and I'm stuck at this point.
Several users have issues with HTTPS connections not working or only working after multiple attempts. This may or may not only occur with certain applications and usually is not reproducible on other workstations.

Examples:
One user usually gets connection reset errors connecting to bing.com, everyone else can connect without problem

Another user cannot access stackoverflow or deepl unless refreshing multiple times. It will then at some point eventually load the page wihtout CSS, after a few more tries CSS will work too. Then it usually keeps working for the rest of the day or at least a longer period of time.

Our Jenkins server started having problems connecting to its (https) update servers, while the same URL can opened from a browser on the same machine without issues. Switching the update servers to HTTP will cause fetching update information to work, though the updates itself will work via https and thus fail. (Java error:SSLHandshakeException)

For me, Office 365 outlook decided to lose connection to exchange servers after a while, not being able to reconnect. Additionally, when I sign out of my Office 365 account from outlook (or any other office 365 app), It will fail to sign in again, simply closing the sign in dialog after entering the user name.
This behaviour started when the workstation was joined to the company domain and occurs with any user account, also local ones that didnt have a problem before.

The last issue does not appear when I switch to another network or change the DNS server from our domain controller to a publich one (1.1.1.1 used for reference). Changing DNS and then re-connecting (unplugging and re-plugging cable) to the network will allow me to sign in without issues, even if everything else is still configured via DHCP.

Changing DNS did not help in case of the Jenkins server, although re-connecting was not possible during my test and seemed to be required on my machine for the procedure to work.

I should also mention that many of the other users encountering issues are not yet domain members as it is currently in the process of being rolled out, so it doesnt appear to be (directly) connected to that. It should also rule out faulty GPOs as those workstations dont have any applied yet.

I initially suspected our sonicwall firewall, but it seems i can count it as ruled out (at least for the office365 problem) as cause of the issue.

DHCP config is very basic and just assigns IP, Netmask, Gateway, DNS and DNS Domain name.
DNS has three forward zones which havent changed for a while and were in use when everything still worked as expected.
DNS also has 1.1.1.1 and 8.8.8.8 set s forwarders for all requests that cannot be resolved locally. It is set up to use root hints if no forwarders are available, which shouldnt occur.

I really need to get this fixed soon as it is starting to affect production systems but I cant seem to pinpoint an actual cause.

Help is very appreciated.

Answer 1

Edit: The 192.168.100.1 DNS is actually not invalid, but its no DC. Removing it doesn't help either way though.

Kind of vague but either case I'd remove it from DHCP server scope config. Domain members must use domain DNS. May be more appropriate as a forwarder but just a wild guess at this point.

--please don't forget to Accept as answer if the reply is helpful--

Answer 2

I removed it, but as mentioned before, that didnt do the trick. Actually, the issues already occured before I added it.
Anything else that may indicate the source of my problems?

Answer 3

Might also try different public DNS for forwarders. The non-domain DNS added to DHCP scope is sure to cause issues.

--please don't forget to Accept as answer if the reply is helpful--

Answer 4

I have tried other DNS forwarders with the same result. Besides that, the current external DNS forwarders do work just fine if entered in the workstation adapter config as primary DNS.
I have already removed the second DNS from the DHCP scope, that did not do the trick.
I must also point out that while not a domain controller, the other (no longer included) DNS server is still a domain member and replicating the first DNS servers zones, acting as a backup. This was done as there currently is no secondary domain controller to perform this task.

I'd like to point out again that while it must be part of the problem, the DNS itself does work fine and name resolution works without issues. Both workstations with and without HTTPS issues can resolve any names fast and reliable. This is not a matter of name resolution, but of SSL certificates that are not loaded or accepted when using the internal DNS server, only happening for specific applications on certain computers with no recognizable pattern.

Answer 5

only happening for specific applications

The application developer may be your best resource to debug the process.

--please don't forget to Accept as answer if the reply is helpful--