Suggestion: Improve error handling for DNS-over-HTTPS functionality in case of port conflicts

[dittert]

Setting up Technitium, I dug my self a whole that resulted in the config interface being inaccessible. I would like to suggest to improve parameter validation to prevent that from happening to others.

Technitium is running as Docker container. These are the relevant configurations:

• Settings | Web Service | Web Service HTTP Port with value 80
• Settings | Web Service | Web Service HTTPS Port with value 443
• Settings | Web Service | HTTPS Options with Enable HTTPS and Enable HTTP to HTTPS Redirection checked
• Settings | Optional Protocols | Enable DNS-over-HTTPS checked
• Settings | Optional Protocols | DNS-over-HTTPS Port with value 443

The initial idea was to be able to access the Technitium admin interface through regular ports. Going back and forth, I later enabled DNS-over-HTTPS without realizing that this would lock me out of the admin interface. In my case, the lock out was also delayed until the container was restarted at a later time.

Basically the configuration above results in the admin interface and the DNS-over-HTTPS functionality both being mapped to the regular HTTPS port 443. The consequence was that the admin interface became inaccessible because DNS-over-TLS seems to "win" in that case. I did not see an easy fix for that as the config files all seem to be binary (i.e. you can't just a shell and change config files manually).

I would like to suggest that Enable DNS-over-HTTPS should check whether there is a conflict with the admin interface ports and you should not be able to enable that functionality if you would lock yourself out of the admin interface.

Another solution could be to include something like a "Click here if you're an admin" link on the DNS-over-TLS web page that is served by Technitium so that both could coexist on port 443.

[ShreyasZare]

Thanks for the feedback. Will get this fixed in the next update. The fix will prioritize web service and let DoH fail instead so that access is not lost due to port conflict. Right now in this situation, restarting the DNS server would restore access to the web service while DoH would fail to start.

[dittert]

Thank you!

[ShreyasZare]

You're welcome!