Add indication on DNSSEC capabilities, such as DNSSEC bootstrapping

[peterthomassen]

Generally, most domains don't have DNSSEC enabled. This may be because the domain's DNS zone isn't signed. But even if it is, enabling DNSSEC requires a second step: deploying DS records in the parent domain, so that the child domain's keys get "hooked" into the parent's DNSSEC chain of trust.

Without this second step, DNSSEC is disabled. Unfortunately, this step is often manual (and often, there's a lack of knowledge amongst domain owners that this needs to be done). Thus, automation is important.

The current DNSSEC display has, roughly:

1. DNSSEC status:
   • Whether the zone is signed (to first order, this requires checking for a DNSKEY record)
   • Whether the zone is securely delegated (this requires checking for a DS record)
   • If the domain is securely delegated, it would be nice to see if resolution works, or if the setup is broken. (To first order, you can use a validating resolver and query e.g. the NS record set. If you get a response with AD bit set, it's working.)

For cases where the domain is signed, but not yet securely delegated (DS records missing), I'd like to propose to improve this with more details on the DNS provider's DNSSEC capabilities, specifically:

2. DNS provider's capability for automatic transmission of DS information to the parent
   • Whether CDS or CDNSKEY records are present (RFC 8078). This allows automatic enrollment (but without authentication).
   • If CDS/CDNSKEY records are present: whether Authenticated DNSSEC Bootstrapping is supported. This requires one additional query per nameserver record.

There are two parts to DNSSEC enrollment automation: a) the DNS provider needs to publish DNSSEC information which b) the parent can discover. The above checks are for part (a). You can find a list of parent registries supporting "their side of it" here: https://github.com/oskar456/cds-updates

I'm a co-author of the authenticated DNSSEC bootstrapping protocol happy to provide further details if anything's unclear.

[mdavids]

Hi Peter,

Thank you for getting in touch.

With regard to the DNSSEC status of the internet.nl test suite; indeed we check if the domain name is signed and if the result is either insecure (for example when there is no chain of trust), secure or bogus (for example when signatures are expired).

Could you please elaborate a bit on why precisely you propose to extend the tests with a check for the existence of CDS/CDNSKEY records and a check for authenticated bootstrapping?

Who would benefit from such an enhancement and why?

Thanks!

[peterthomassen]

Could you please elaborate a bit on why precisely you propose to extend the tests with a check for the existence of CDS/CDNSKEY records and a check for authenticated bootstrapping?

A major obstacle to DNSSEC adoption is the fact that even when the DNS provider signs the zone, the domain owner (usually) has to get involved to inform the parent domain (registrar/registry) about the DS parameters. If the domain owner doesn't do that, the domain's keys won't get hooked into the DNSSEC chain of trust, so signatures can't be validated. The domain remains insecure.

This problem doesn't exist when automation is added: By publishing CDS/CDNSKEY records, the DNS provider can publicly annouce what the DNSSEC parameters are, and the parent (registry/registrar) can discover that. It does not require that the domain owner does anything manual.

The procedure, specified in RFC 8078, is supported by several DNS providers (e.g. desec.io, or Cloudflare, who publish these records) and by several TLDs, who discover these records and use them to enable DNSSEC. -- However, the mechanism is not authenticated. "Authenticated bootstrapping" solves this, and is also supported by Cloudflare/deSEC and some TLDs like .ch/.li.

This removes a significant barrier for DNSSEC adoption.

Who would benefit from such an enhancement and why?

If the user can see on the Internet.nl check that their provider does not support DNSSEC bootstrapping (with or without authentication), then the user knows that their domain won't get DNSSEC benefits automatically.

It's like informing them about a problem with the TLS configuration, such as HSTS. The impact is that the security status is better exposed, and user can then go to their DNS provider and say: "hey, why don't you support that?"

Without such a feature, domain owners often will not know that it would be possible to get DNSSEC automatically.

[mdavids]

Thanks.

One more clarification question, for now at least; what additional query per name server record should we perform to determine if the DNS provider indeed offers support for Authenticated DNSSEC bootstrapping?

[bwbroersma]

@peterthomassen pretty nice proposal! I remember seeing the referenced 2019 FOSDEM talk about RFC8078 and thinking it was a bit of Trust on first use (with the "Accept after Delay"), but this would fix it.

So it's doable to test and verify the _signal stuff, but how do you check if it's supported by a 'Parental Agent'*?

@mdavids see the example in section 3.1.1:

For the purposes of bootstrapping the Child zone example.co.uk with NS records ns1.example.net, ns2.example.org, and ns3.example.co.uk, the required Signaling Domains are _signal.ns1.example.net and _signal.ns2.example.org.

In the zones containing these domains, the Child DNS Operator authenticates the CDS/CDNSKEY records found at the Child's apex by co-publishing them at the names:

_dsboot.example.co.uk._signal.ns1.example.net
_dsboot.example.co.uk._signal.ns2.example.org

The records are accompanied by RRSIG records created using the key(s) of the respective Signaling Zone. Publication of Signaling Records under the in-bailiwick domain _signal.ns3.example.co.uk is not required.

* "The entity that has the authority to insert DS records into the Parent zone on behalf of the Child. (It could be the registry, registrar, a reseller, or some other authorized entity.)"

[peterthomassen]

So it's doable to test and verify the _signal stuff, but how do you check if it's supported by a 'Parental Agent'*?

You can't observe that directly (besides correlating the creation of a DS record with the signaling records). However, TLD operators and registrars are expected to announce whether they support DNSSEC bootstrapping.

An current overview of the various operators' policies is given here: https://github.com/oskar456/cds-updates

As the number of domains with support for DNSSEC bootstrapping increases demonstrably, it will be easier to push parental agents to support their side of the protocol. That's another benefit why that visibility is needed.

@mdavids see the example in section 3.1.1:

Yes, the queries to be done follow from that link. More explicitly (for domains that have not DS record):

1. Collect the domain's CDS and/or CDNSKEY records, and the parent-side NS RRset.
   • abort if there are no CDS/CDNSKEY records or if all NS names are in-bailiwick (= subdomains of the domain itself)
2. For each out-of-bailiwick NS hostname $ns, query CDS and/or CDNSKEY at _dsboot.$domain._signal.$ns
   • abort as soon as an unvalidated or error response is encountered, or if empty for both query types
3. Check that the CDS records provided at _dsboot.$child._signal.$ns match those collected from the apex in step 1. Ditto for CDNSKEY.

Some or all of Step 1 may already be done.