DNSSEC Discussion

[captncraig]

Just started thinking about this and wanted to write down notes for the future.

One thing I think would be interesting for DNSControl to manage would be DNSSEC records. This really has two parts:

1. DNS Provider needs to implement it. This involves managing keys, generating RRSIG records and so forth.
2. Registrar needs to register the DS record(s) with the tld nameservers.

I would love for dnscontrol to be able to activate DNSSEC for a domain with minimal effort required.

A few issues I foresee:

• Provider support is fairly limited.

  Of the registrars we support, gandi has an api. name.com has functionality in the web ui, but no api. route53 as a registrar supports dnssec, but not as a dns provider.

  As far as DNS providers go, gcloud has alpha support, gandi appears to support it, cloudflare has some sort of support, and all others seem to not. We could certainly do it for the bind provider with some work.

• Multiple providers

  DNSSEC would definitely not work unless all providers for a zone support it. If they do, I believe they can all use a separate key, and we can add multiple DS records via the registrar.

  Most cloud providers provide only a "just turn it on" model where they maintain all the keys and just give you the DS info to give the registrar.

• Key management

Bind may or may not be worth implementing anything for. Maybe the keys live on the actual server, and part of the process of deploying zonefiles is using dnssec-signzone or something.

[aeden]

We have API support over at DNSimple for signing zones as well as managing DS records when zones are signed elsewhere. It's true that support is spotty at registrars, especially with API support, but if you want to try to support it at some point, you can use us as your guinea pig.

You definitely want to avoid key management if you can. Key rotation needs to be handled carefully to ensure you do not lose DNS resolution when rotating out old keys.

Happy to answer questions about it if you have them, as our implementation just came out recently so it is front and center in my mind.

[KaiSchwarz-cnic]

We (HEXONET) support DNSSEC for various TLDs through our Backend System API Read here. Feel free to let us know when you dive into working on DNSSEC support in dnscontrol - we can definitely support you here.

/UPDATE: just got notification that we support DNSSEC in direction to the appropriate TLD registry, but our DNSSystem itself is not yet ready, but WIP. So support is coming, but no timeline available up to now. I will keep you updated.

[captncraig]

DS record support is gonna be added in #469 when it merges. After that I should have all the pieces I need to do a more automatic dnssec setup process with dnscontrol. It will be fairly analogous to how we handle nameservers currently.

If dnssec is "enabled" for a domain, we will:

1. Make a preliminary pass over all providers for that domain (which will need to implement some interface to provide DS info), and collect the DS record(s) we need to submit.
2. Make sure we have all of the discovered DS records added to the domain, in addition to any manually specified DS records already in the config.
3. Process dns provider records as usual.
4. Process registrars as usual.
5. Call special method on registrar to set up DS delegation with all of the previously discovered DS records.

I have good test accounts with Cloudflare and Google Cloud which both support the provider side of things (so it appears), and it looks like name.com now has a registrar api to submit the ds records. So I should have everything I need to test and get this going.

[captncraig]

A few open questions I need to research:

1. How important is it that the dns provider's nameservers respond with the same set of correct DS records? If dns is hosted with providerA AND providerB, they will each generate their own signing keys, and I will have 2 DS records to register upstream. Do all nameservers need to respond with both DS records, or can each just serve their own? Is it mandatory to sync them like it is with NS records? I think we need to attempt to make everything as unified as possible, but I worry providers may support it to varying degrees.

[aeden]

How important is it that the dns provider's nameservers respond with the same set of correct DS records?

AFAIK, the only thing that needs to be consistent between the providers is the algorithm used. If providers use different algorithms then you may run into issues (this will need to be tested).

Many providers will not let you sign a zone with keys you control, thus proposing to have every provider sign with all of the keys will cut off a portion of the providers available.

[captncraig]

That makes sense. If I am reading things correctly from my testing, the providers themselves really never need to serve DS records at all for the root. That makes it easy. You only need to specify DS records if delegating subdomains or something. The happy path is really just "collect DS records and submit to registrar".

[peterthomassen]

When several DNS providers share the operational responsibility for a zone, they need to serve each other's DNSKEY records, otherwise resolvers may end up with broken validation paths. (Example: Resolver queries a record which is signed with provider A's key, but when fetching the key, the resolver talks to provider B. This is permissible. If provider B now only servers their key, validation will fail.)

Note that this scenario also occurs when transferring zone operation from provider A to provider B without going insecure: if resolution and validation should not be interrupted, a dual-signer transition period is unavoidable.

An informational RFC exists, detailing the different working modes of such "multi-signer" scenarios: https://datatracker.ietf.org/doc/html/rfc8901 There is also a draft about automation in this context: https://datatracker.ietf.org/doc/draft-wisser-dnssec-automation/

The automation requires conveying each DNS provider's DNSKEY records to the others (and, for key rollovers, potentially also CDS/CDNSKEY records, but let's leave that for later). I can image that to look like the following:

1. Configure provider credentials in creds.json

{
  "DESEC": {...},
  "CLOUDFLAREAPI": {...}
}

2. Coordinate key circulation in dnsconfig.js

   
   // Configuration
   const domain = 'example.com';
   const providers = ['DESEC', 'CLOUDFLAREAPI'];

// Preparation const instances = providers.map(type => { "type": type, "provider": NewDnsProvider(type, type), });

// Fetch DNSSEC paramters from each provider for (const instance of instances) { // QUESTION: Does something like fetchDNSSECParametersFromProvider() exist? instance.dnskey = instance.provider.fetchDNSSECParametersFromProvider('DNSKEY'); }

// Combine DNSKEY RRsets, removing duplicates const dnskeys = new Set(instances.reduce((acc, cur) => acc.concat(cur.dnskey), [])); const rrset_dnskey = Array.from(dnskeys).map(rr => DNSKEY('@', rr));

// Distribute DNSKEY to all for (const instance of instances) { D(domain, NewRegistrar('none', 'NONE'), instance.provider, NO_PURGE, rrset_dnskey); }

3. **Commit** by running `dnscontrol preview`, then `dnscontrol push`

As far as I can tell, the missing pieces here would be:
- the `.fetchDNSSECParametersFromProvider('DNSKEY')` call on each provider,
- support for the `DNSKEY` record type,
- (potentially similar support for record types related to key rollover, i.e. `CDS`/`CDNSKEY`).

Would you folks be interested in this kind of functionality?

(Some related work is also going on here: https://github.com/DNSSEC-Provisioning/Multi-signer)

[pierrehenrymuller]

Any update for the dnssec feature?

In a first implementation, maybe managing a non multi provider case would be a good start?

A simple usage with dnscontrol that generates bind zones or to a single provider and that would manage the generation / rotation of the keys as well as the declaration of the latter to the registry. That would be a good start, wouldn't it?

[tlimoncelli]

@pierrehenrymuller: There's currently no active development on DNSSEC features. To be totally transparent: it isn't a feature that my employer needs, therefore it is a feature that will have to come from the community.

Your proposal sounds good to me and I would be glad to coach a volunteer through implementing it.

[tlimoncelli]

Friendly ping?

[peterthomassen]

More protocol context: https://www.ietf.org/archive/id/draft-thomassen-dnsop-mske-00.html