Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Add dnsdist rules for DoT and DoH connections to detect the DNS server name #7210
For DoT and DoH it would be very useful to differenciate between different services based on the DNS servers domain name. With TLS based connections a DNS client can add the Server Name Indication (SNI) in the Client Hello message. The idea is to store the SNI for the whole session context and make it available via a dnsdist rule. For DoH the server name can be extracted from the request URI.
For DoH it can be extracted from the request URI:
For DoT and DoH it can be extracted from the SNI in the Client Hello:
Example rules in dnsdist:
If there would be a possibility to detect the DNS server name with dnsdist rules, there are countless possibilities. Here two examples:
Enable or disable options based on the DNS server name:
Send query to special downstream servers that offer different services (e.g. adblock, family-shield, safesearch for popular search engines, DNSSEC, etc.)
It seems that DoT and DoH are becoming more and more popular and the number of (native) client implemenations is increasing. For those two DNS transports it is normally possible to set a domain name or a URL (just DoH) in the DNS resolver setting. Also https://dnscrypt.info/stamps-specifications is saying the hostname will "be used as a SNI name" for DoT and DoH.
Here some interesting DoT/DoH implementations:
In the past the only possibility to differenciate between different services was to have multiple different IPs on the same DNS Resolver or different ports (might be very hard to configure for most DNS clients). Another options is to make use of the source IP address. But this is sometimes very hard because you need to know the current IP address in realtime and especially for mobile devices the IP changes all the time because of different networks (RAN, WiFi, etc.). The DNS server domain name will not change and is independent of IP addresses, NAT scenarios and transport networks. Making use it to offer different services for DoT and DoH connections can be very useful for a lot of applications.
An experiment, just for testing SNI extraction with OpenSSL (Debian Buster, version 1.1.1b-2) and (Debian Buster, libgnutls30 3.6.6-2): https://gist.github.com/Habbie/31a5a6a6dc15d1ba727fe3f1d23a968c
'Now we just have to type it in'.
Similar 'just get the SNI out' hack for DoH. https://gist.github.com/Habbie/0ab650579120ac01dd3578b9a1a4215f
Note that this one wouldn't even know where to store the name.
After discussion with @pieterlexis and @rgacogne we realise that addXLocal is not the best interface to begin with, and that the list of paths in addDOHLocal really overstretches the concept. Ideally we'd rearchitect some of this. When we do that, we can also support separate certs for separate SNIs.
This would also be difficult especially with wildcard certificates or similar... My idea was to use a multidomain or a wildcard TLS certificate (e.g. *.example.com) and the different SNI names can be dynamically used with the dnsdist rule functions:
And if possible, make the SNI available in the DNSQuestion object (e.g.