Hi there, I don't have much opinion about this one :) And I did not meet anybody needing such solution for now. >From an implementation point of view, as far as I understand, the idea is to write/read a DNS payload to/from an HTTP request. We already have the primitives to do this. The "most" complicated part would be to be able to to link the resolver scheduler to a backend. (maybe we could use this trick to do DNS over TCP too...)
I will follow the thread on the github and may jump in if anybody wants to implement it :) Baptiste On Mon, Feb 4, 2019 at 10:46 PM Aleksandar Lazic <al-hapr...@none.at> wrote: > 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 >
