Custom DNS Over TLS/QUIC Endpoints: Feature Request
This article discusses a feature request for adding the ability to configure custom upstream DNS servers using DNS names for secure protocols like DNS-over-TLS (DoT) and DNS-over-QUIC (DoQ). This enhancement aims to provide greater flexibility and robustness in network configurations. This document explains why implementing this feature is crucial, detailing its benefits and proposing a configuration format.
Rationale: Why Custom DNS Endpoints are Essential
Flexibility in port usage is a key reason for this feature request. The current configurations often default to a specific port, such as 853 for DoT, or only allow the use of IP addresses. While standard ports exist for DoT (853) and DoQ (8853), allowing custom ports is essential when upstream servers operate on non-standard ports. This might occur due to various reasons, such as network policies, load balancing, or running multiple services on the same host. The ability to specify custom ports ensures that users can connect to DNS servers that do not adhere to the default port configurations, providing a more adaptable and versatile system.
DNS name resolution is another critical aspect driving this request. Using actual DNS names, such as cloudflare-dns.com or a custom hostname, makes the configuration more resilient to upstream server IP changes. In dynamic network environments, IP addresses can change frequently, leading to connectivity issues if the configuration relies solely on static IP addresses. By using DNS names, the system can automatically resolve the current IP address of the server, ensuring continuous service availability. This approach is particularly beneficial when the upstream server is part of a Content Delivery Network (CDN) or a load-balanced cluster, where IP addresses can change as part of the network's scaling and optimization processes. Therefore, DNS name resolution provides a more robust and maintainable solution compared to using static IP addresses.
TLS/QUIC certificate validation is also a significant factor. When connecting via DoT or DoQ, the client must validate the server's TLS certificate to ensure a secure connection. This validation typically uses the Server Name Indication (SNI) field, which requires the connection to be established using the actual DNS hostname for which the certificate was issued. If an IP address is used alone, certificate validation may fail unless the IP is explicitly listed as a Subject Alternative Name (SAN) in the certificate. This requirement underscores the importance of using DNS names to ensure successful certificate validation and a secure connection. By allowing configurations to use DNS names, this feature ensures that the necessary TLS/QUIC certificate validation processes can be completed correctly, maintaining the security and integrity of the DNS resolution process.
Proposed Implementation and Configuration Format
To facilitate clear and intuitive configuration, the proposed implementation uses a URI scheme to designate the protocol and endpoint. This approach provides a standardized way to specify the connection details, making it easier for users to understand and configure their systems. The URI scheme clearly indicates the protocol being used (either DNS-over-TLS or DNS-over-QUIC) and the endpoint, which includes the hostname or IP address and the port number. This format not only enhances clarity but also ensures consistency across different configurations and systems.
DNS-over-TLS (DoT)
The proposed format for DNS-over-TLS is tls://hostname_or_ip:port. For example, a configuration using Cloudflare's DNS service on the standard DoT port would look like this: tls://dns.provider.net:853. This format explicitly states that the connection should be established using the TLS protocol, followed by the hostname (or IP address) and the port number. The use of the tls:// prefix clearly identifies the protocol, while the hostname and port number specify the server to connect to. This standardization simplifies the configuration process and reduces the likelihood of errors, as the format is both explicit and easy to understand. Furthermore, it allows for easy integration with various configuration management tools and systems, as the URI scheme provides a consistent and predictable way to define DoT endpoints.
DNS-over-QUIC (DoQ)
Similarly, for DNS-over-QUIC, the proposed format is quic://hostname_or_ip:port. For example, a configuration using a DoQ server on its standard port would be: quic://dns.provider.net:8853. This format mirrors the DoT configuration but uses the quic:// prefix to indicate that the connection should use the QUIC protocol. QUIC, being a modern transport protocol, offers several advantages over traditional protocols like TCP, including improved performance and security. By explicitly specifying the use of QUIC in the configuration, users can take advantage of these benefits. The consistency in the URI scheme between DoT and DoQ simplifies the overall configuration process, allowing users to easily switch between protocols or configure multiple endpoints using different protocols. This flexibility is crucial for adapting to different network conditions and security requirements, making the system more versatile and robust.
Benefits of Implementing Custom Upstream Endpoints
Enhanced Flexibility
Enhanced flexibility in network configuration is a primary benefit of implementing custom upstream endpoints. By allowing users to specify DNS servers using a combination of DNS names and explicit port numbers, the system can accommodate a wider range of network setups. This flexibility is particularly important in complex network environments where standard configurations may not be sufficient. For instance, organizations may use non-standard ports for security reasons, load balancing, or to run multiple DNS services on the same host. Without the ability to specify custom ports, users would be restricted to the default port configurations, potentially leading to connectivity issues or suboptimal performance. The ability to use DNS names instead of static IP addresses further enhances flexibility by allowing the system to adapt to changes in the network infrastructure. This dynamic resolution ensures that the system can always connect to the correct server, even if the IP address changes. Therefore, enhanced flexibility translates to a more adaptable and resilient network configuration, capable of meeting the diverse needs of different environments.
Improved Maintainability
Improved maintainability is another significant advantage. Using DNS names instead of static IP addresses makes the configuration more resilient to changes in the upstream server's IP address. In dynamic network environments, IP addresses can change due to various reasons, such as server migrations, network upgrades, or failover events. If the configuration relies on static IP addresses, any change in the IP address would require manual updates to the configuration, which can be time-consuming and error-prone. By using DNS names, the system can automatically resolve the current IP address, eliminating the need for manual intervention. This feature is particularly beneficial in large-scale deployments where managing numerous static IP addresses can be a significant administrative burden. Furthermore, the proposed URI scheme provides a clear and consistent format for specifying DNS endpoints, making the configuration easier to understand and manage. This clarity reduces the likelihood of misconfigurations and simplifies troubleshooting, contributing to overall improved maintainability. Therefore, using DNS names and a standardized configuration format makes the system more manageable and reduces the operational overhead associated with maintaining DNS configurations.
Robust Security
Robust security is significantly enhanced by using DNS names with TLS/QUIC. When connecting via DoT or DoQ, the client validates the server's TLS certificate to ensure a secure connection. This validation process relies on the Server Name Indication (SNI) field, which requires the connection to be established using the DNS hostname for which the certificate was issued. If an IP address is used alone, certificate validation may fail, potentially exposing the system to man-in-the-middle attacks. By using DNS names, the system ensures that the certificate validation process is completed correctly, maintaining the integrity and confidentiality of the DNS resolution process. Additionally, the ability to specify custom ports allows organizations to use non-standard ports for added security, making it more difficult for attackers to discover and exploit vulnerabilities. The combination of DNS name resolution, TLS/QUIC certificate validation, and custom port usage provides a multi-layered security approach that significantly reduces the risk of DNS-related attacks. Therefore, implementing custom upstream endpoints with DNS names for TLS/QUIC strengthens the overall security posture of the system, protecting sensitive information and ensuring reliable DNS resolution.
Conclusion
In conclusion, implementing custom upstream endpoints with DNS names for TLS/QUIC offers significant benefits in terms of flexibility, maintainability, and security. The ability to specify DNS servers using DNS names and explicit port numbers enhances the adaptability of the system, allowing it to accommodate a wider range of network configurations. The use of DNS names instead of static IP addresses improves maintainability by making the configuration more resilient to changes in the network infrastructure. Furthermore, robust security is ensured through proper TLS/QUIC certificate validation and the option to use custom ports. The proposed URI scheme provides a clear and consistent format for configuring DNS endpoints, simplifying the overall management of the system. Therefore, this feature request addresses a critical need for modern network environments and would greatly enhance the functionality and reliability of DNS resolution. For more information on DNS security best practices, visit Internet Society Deploy360 Programme.
