Open peterthomassen opened 1 year ago
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!
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.
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?
@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 recordsns1.example.net
,ns2.example.org
, andns3.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.)"
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):
Some or all of Step 1 may already be done.
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:
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:
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.