Re: Opinions about DoH (=DNS over HTTPS) as resolver for HAProxy
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 wrote: > Hi Lukas. > Am 04.02.2019 um 21:39 schrieb Lukas Tribus: > > Hello, > > > > On Mon, 4 Feb 2019 at 12:14, Aleksandar Lazic > 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 >
Re: Opinions about DoH (=DNS over HTTPS) as resolver for HAProxy
Hi Lukas. Am 04.02.2019 um 21:39 schrieb Lukas Tribus: > Hello, > > On Mon, 4 Feb 2019 at 12:14, Aleksandar Lazic 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
Re: Opinions about DoH (=DNS over HTTPS) as resolver for HAProxy
Hello, On Mon, 4 Feb 2019 at 12:14, Aleksandar Lazic 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. 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). 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. 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. Also CC'ing Baptiste. cheers, lukas
Opinions about DoH (=DNS over HTTPS) as resolver for HAProxy
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. Best regards Aleks
