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

Reply via email to