On 03/20/2018 07:44 AM, Paul Wouters wrote: > The goal of the document is to make such malicious changes visible. > > If the parent needs to replace NS/DS records, these are easily > auditable identically to Certificate Transparency (rfc 6962bis) > We only need to look (log) the DS/DNSKEY and we do not have > to monitor all TLSA and other security RRtypes. Without this flag, > we need to track and log every DNS RRtype that has public key material > in it. >
Forgive my ignorance on the subject, but I'm having trouble following how delegation_only flag actually helps in this specific case. Certificate Transparency works because specifically because the entire certificate is uploaded, and (assuming a valid cert) a SCT is generated which can be verified by cross-checking it against the log servers public key. Without the RRtypes logged, I'm not seeing how you're supposed to be able to audit them. In the case where a KSK is compromised, you could simply sign a new zone record, serve up fraudulent records and remain unaware. CT as it's implemented in the x509 world (combined with Expect-CT) specifically prevents unknown but validly signed certificates from being used. I'm likely missing something obvious, by only logging DS/NS, it would be impossible to determine if a private key is misused to serve fraudulent records which in my mind is a bigger and much more likely/common threat since one can simply attack a target domain and not try to compromise the root. Moving to the topic of the draft itself: >From a technical point of view, aren't there TLDs that as authoritative for second level domains as well? The specification likely needs a way to denote how many levels deep delegation can go. This also would be true in the case of delegation_only being used at a level above both the root and TLD zones. I know historically .name only allowed registration of third-level domains until 2009, and .uk up until 2014. I'm unsure if any of the TLDs still restrict and/or is authoritative for second-level domains as well. At a minimum though, the one case I know off hand of a TLD being authoritative for a second-level domain is that ICANN requires new gTLDs are required to publish a wildcard for 90 days when they're added to the root zone to help catch any name collisions. Michael _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop