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 :)


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

Reply via email to