I’ve introduced the potential flaws of regular DNS queries and responses protocol and a practical solution to address it, which is called ‘DNS-over-TLS protocol’, in the most recent post: DNS-over-TLS Introduction and Implementation. However, since messages are transmitting through an uncommon port 853, public DNS servers implementing ‘DNS-over-TLS protocol’ are likely to be detected and restricted by controlling TCP traffics on that port.
Thus, introduced in RFC 8484, another protocol called ‘DNS-over-HTTPS’ was designed by researchers, which runs on common port 443. By implementing this protocol, all DNS messages are transmitted through regular HTTP requests and encrypted with SSL.
Traditional DNS queries and responses are sent over UDP and TCP without any encryption. Thus, this protocol is vulnerable to privacy tracking and DNS spoofing. Almost all traditional DNS queries are monitored and falsified during transmission in specific countries including China to block websites and injecting advertisements.
According to the image above, the ‘A’ record of ‘reddit.com’ is altered to a wrong IP address which belongs to services of Facebook.
To solve these problems, researchers designed DNS-over-TLS protocol which provides DNS resolutions over TLS-encrypted TCP connection delineated in RFC7858. DNS-over-TLS protocol improves privacy and security between client and servers since TLS is invulnerable to ‘Man-in-the-middle attack’ and cannot be deciphered easily.
In order to reduce latency and resource cost, website maintainers usually deploy their web service on servers located in separate geographic areas. However, since it’s a relatively inconvenient task for users to manually decide which server they should connect to, developers might desire a solution which could automatically allocate users according to their location.
Recently, as the developer of Encrypted-DNS project, I’m using Azure Traffic Manager to address the concern I mentioned above because the latency of DNS queries plays an essential role in users’ experiences. For instance, my DNS service is currently running on two separate computing engines provided by Google Cloud Platform, which locate in both the United States and Taiwan. Therefore, for users located in Asia, all of their DNS queries will be directed to the server in Taiwan; for users in other areas, their queries will be sent to the server in the United States.