Hi Lukas. Am 04.02.2019 um 21:39 schrieb Lukas Tribus: > Hello, > > On Mon, 4 Feb 2019 at 12:14, Aleksandar Lazic <al-hapr...@none.at> wrote: >> >> Hi. >> >> I have just opened a new Issue about DoH for resolving. >> >> https://github.com/haproxy/haproxy/issues/33 >> >> As I know that this is a major change in the Infrastructure I would like to >> here what you think about this suggestion. >> >> My opinion was at the beginning against this change as there was only some >> big provider but now there are some tutorials and other providers for DoH I >> think now it's a good Idea. > > Frankly I don't see a real use-case. DoH is interesting for clients > roaming around networks that don't have a local DNS resolver or with a > completely untrusted or compromised connectivity to their DNS server. > A haproxy instance on the other hand is usually something installed in > a stable datacenter, often with a local resolver, and it is resolving > names you configured with destination IP's that are visible to an > attacker anyway.
A possible use-case is: Let's say you have a hybrid cloud setup (on-prem, AWS, Azure, ...) and the networks are connected via a unsecured L2/L3 internet connectivity. The networks are routed and the HAProxy VM/Container must resolve an internal Backend via DNS but some regulations does not allow to send plain DNS via the internet. Internal APP <-> INTERNET <-> HAProxy Pub Cloud <-> Client | | Internal DNS <-> DoH <-> The Solution is to use a DoH on-prem which resolves the internal Backend via classic DNS internally and send the answer back to HAProxy via HTTPS. Such a Setup helps to keep some VPN/IPSec setups out of the game. I hope I have described the use-case in understandable words. > The DNS implementation is still lacking an important feature (TCP > mode), which Baptiste does not really have time to work on as far as I > can tell and would actually address a problem for certain huge > deployments. At the same time I'm not sure I can up with a *real* > use-case for DoH in haproxy - and there is always the possibility to > install a local UDP to DoH resolver. Also a lot of setups nowadays are > either systemd or docker managed, both of which ship their own > resolver anyway (providing a local UDP/TCP service). Ack. It's not a small part, imho. On this wiki are some DOH Tools which show how DoH could be implemented. https://github.com/curl/curl/wiki/DNS-over-HTTPS > I'm not sure what the complexity of DoH is. I assume it's non trivial > to do in a non-blocking way, without question more complicated than > TCP mode. I don't agree on this as I think there are more or less equal hard to implement. But I must say I'm only a "sometimes" Developer so I'm sure I miss all the detail which make the difference. > So I'm not a fan of pushing DoH into haproxy. Especially if the > use-case is unclear. But those are just my two cents. Thank you. > Also CC'ing Baptiste. > > > cheers, > lukas Regards aleks