Feature request: Support for DNS-over-TLS

[saradickinson]

There is growing interest in operating public DNS privacy servers using the recently developed IETF Standards, I was recently at RIPE any many people expressed an interest in using dnsdist as a front end to such a service. Therefore this is a feature request to support DNS-over-TLS (RFC7858) and also consider supporting features such as

• Improved TCP connection management as described in section 10 of RFC7766
• EDNS0 TCP Keepalive (RFC7828)
• TCP Fast Open (RFC7413)
• From draft-ietf-dprive-dtls-and-tls-profiles: The TLS Profile specified in section 11 and the Traffic Analysis counter measures specified in section 13.1

It has additionally been pointed out that support for DNS-over-TLS would allow inter-op with DNS-Trigger clients.

Many thanks

Sara Dickinson (sara@sinodun.com)

[johnhtodd]

Knot resolver now has TLS support, and I'm hoping to avoid having to fork my TLS queries to Yet Another Resolver. A big "plus one" for us here.

[Habbie]

@johnhtodd we hear the +1, but can you clarify what you mean by 'fork' and 'Yet Another Resolver'?

[johnhtodd]

To clarify: We currently have multiple recursive resolvers answering queries, not because we don't love PowerDNS but because we must have no single-codebase fragility. What I don't want to have to do is implement another recursive resolver (knot) that supports TLS, or bolt on a front-end TLS protocol converter (nginx, stunnel) which makes metrics collection very difficult or impossible, as well as adding another layer of complexity to break, be maintained, etc. Ideally, having TLS supported either directly in PowerDNS recursive libraries (and auth, for that matter!) would be ideal. Having it work in dnsdist, recursor, and authoritative servers would be a big win. I'd be happy with dnsdist as a first step though.

[johnhtodd]

Update: We have DNS over TLS operating via a proxy "front-end" and passing to dnsdist. However, this method is far from clean. We lose our single metrics platform (dnsdist) because data is now stripped at the proxy layer. We also have issues with packet filtering and blocking, and now have two pipelines of DDoS management instead of one. Our fragility is increased, and monitoring/measuring has added complexity. Getting dnsdist to work natively with DNS-over-TLS would be ideal. We could potentially support development on this.

[dmccombs]

DNS over TLS support within dnsdist would certainly be nice to have.

[shane-kerr]

Perhaps this issue should be broken up into separate tickets. I think even a very simple implementation would be a great start, better than what we have now (which is... nothing).

Conceptually the naive implementation is not too difficult - we basically just need a way to configure dnsdist to listen on port 853 (or whatever) and provide it a certificate, then convert sockets to TLS sockets using whatever voodoo the underlying TLS library requires.

From my point of view it doesn't matter what TLS library is used, although probably mbed should be used since it is Dutch. ;-) If crypto-agility is desired then a simple class to abstract away the differences should be possible.

I'm happy to review or even work on this, if it seems likely to be merged into dnsdist itself.

[johnhtodd]

This gains more interest with every week, it would seem (here, at least.) We're still prepared to offer euros, dollars, beer, etc. for an implementation into dnsdist, since this would eliminate haproxy front-ending. The knobs to manage "high volume" load conditions would have to be significant, at least as powerful as what we get with haproxy (details to be worked out.)

[mikedamm]

+1 I would also love to see DNS/TLS in dnsdist.