[dnsdist] Dns over TLS, and certificates that expire

[Kai Storbeck]

Hi Remi,

On 07-06-18 15:46, Remi Gacogne wrote:
> Hi Kai,
> 
> On 06/07/2018 03:30 PM, Kai Storbeck wrote:
>> On 31-05-18 16:20, David wrote:
>>> On 2018-05-31 6:55 AM, Kai Storbeck wrote:
>>>> Hello all,
>>>>
>>>> It seems to work wonderfully, or at least, "kdig" thinks it works.
>>>> Getting it by default in my
>>>>
>>>> We will probably try to launch this soon, using a certificate from Lets
>>>> Encrypt. Those certificates live for 3 months, and I'd like to automate
>>>> the refreshing of this cert in dnsdist.
>>>>
>>>> Now, my point:
>>>>
>>>> As far as I know, hot reloading (or graceful reloading) is not supported
>>>> right now, or is it?
>>>
>>> This is not supported in dnsdist, but going by how quick it restarts
>>> fully is it really an issue?
>>
>> I don't know. (digging with dnsgram) ...
>>
>> About 490ms the dnsdist process is not answering. This will drop ~5k
>> questions on the floor in our current setup. I find that quite a lot.
> 
> Neither OpenSSL nor GnuTLS APIs make it easy to switch the certificate,
> but we could create a new TLSContext and switch to it at run-time. We
> would need to be careful to keep the current ticket keys around, and we
> would loose existing ticket-less TLS sessions but I don't see any major
> issue preventing us from implementing that feature.
> That's still quite some work so I wouldn't expect it before 1.4.0.

Thanks!

You mention tickets. You're referring to these:

> Session Tickets, specified in RFC 5077, are a technique to resume TLS sessions by storing key material encrypted on the clients. In TLS 1.2 they speed up the handshake from two to one round-trips.
> (from https://blog.filippo.io/we-need-to-talk-about-session-tickets/)

Do we (I) really need that? In our anycast setup that's already
breaking. I know it saves a roundtrip, but meh, if that means 1 extra
roundtrip fixes to fix it, it's not exactly bad. Especially if those
statements on that blog are true.

The key stays the same, only the certificate signature(?) changes, would
that invalidate any ssl tickets?

>> I tried this:
>>
>> dnsdist -c cannot update the TLS listener (addTLSLocal cannot be used at
>> runtime!).
>>
>> I've tried using a hot restarter wrapper around the daemon, but the
>> second instance gets these errors:
>>> jun 07 15:25:24 resolver-beta.xs4all.net hot-restarter.py[8561]: Unable to bind to control socket on 0.0.0.0:5199: binding socket to 0.0.0.0:5199: Address already in use
>>> jun 07 15:25:24 resolver-beta.xs4all.net hot-restarter.py[8561]: Unable to bind to webserver socket on 0.0.0.0:8083: binding socket to 0.0.0.0:8083: Address already in use
> 
> Right, we don't enable reuseport on the webserver and console socket so
> we can't listen on it if the other process is still running. You could
> enable the webserver later via the console, but it's more complicated
> for the console itself. One option would be to have two console ports,
> so the first process uses the first port, then the second one uses the
> second port and the third one can use the first one again since the
> first process should be long gone. It's not ideal but shouldn't be too
> hard to implement in a few lines of Lua.

I thought about swapping between 2 ports. But it's getting quite complex
now, so I'm going to wait, or deploy with a commercial key that lives 3
years :P.

The main issue sounds so simple.

Regards,
Kai

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.powerdns.com/pipermail/dnsdist/attachments/20180607/b85b4a21/attachment-0001.sig>