Dnsmasq unfortunately does not support TLS, so to have secure dns i have to build an extra service with some proxy that support TLS to port all DNS requests. Not really neat in my opinion. Can other dns servers be considered that do support TLS, so i can just solve this with configuration?
Hey Jeanine,
Thanks for getting in touch! I’d be interest in learning why dnsmasq.service is not providing the functionality you require?
Many of our customers rely on the avahi.service (mDNS), or create a new mDNS service, for domain name resolution on the local network.
Is there something specific about TLS you require?
Hey Samuel,
Thanks for the quick reply!
FYI, we are working towards complying with the new EU cybersecurity act that will go into effect in steps the coming years., first step in january ‘26. We require TLS because the current setup exposes our devices to man in the middle attacks by sending unencrypted dns queries to 8.8.8.8 (or another of course). This can be solved by using TLS over port (853) or https (443), but both are not supported by dnsmasq. Your collegue on support channel advised to proxy via something like stubby or unbound, but als encouraged me to open a feature request 
Hello @Jeanine
Thanks for the given details, I’d like to take the chance to clarify more about your request.
Before diving into the technical details, can you describe how the EU Cybersecurity Act is directly affecting you and your product? We are currently planning for the EU Cyber Resilience Act (CRA) being a product regulation concerning the cybersecurity of our and our customers products.
For the Encrypted DNS I do agree that this is a risk mitigation for the threat of man-in-the-middle DNS attacks. Which other risks have you identified in your product that need to be mitigated with encrypted DNS?
Thanks for sharing more details.
Harald
Hi Harald,
Yes, I do mean the cyber resilience act, my mistake. To dive a little bit deeper: we must comply to IEC 62443-4-2:2019 standard eventually and we are preparing our devices to use a X.509 certificate based authentication mechanism. To validate and rotate these certificates we rely on system time, so we need encrypted communication with NTP/NTS servers (which is probably a different feature request: chrony on balenaOS does not support NTS). But NTP servers relies on DNS, so that needs to be encrypted as well. Any interception or alteration of this traffic through a man-in-the-middle attack could redirect the system to a malicious NTP/NTS server, enabling an attacker to manipulate the system time. This, in turn, compromises the integrity of the X.509 certificate-based authentication.
Till now DNS and NTP servers are the only OS related items we have identified. I can keep you updated if we find more.