On 30 Jan 2024, at 15:57, Roy Arends <r...@dnss.ec> wrote: >> Unless we are certain that there is no benefit from DELEG without DNSSEC, >> perhaps DNSSEC should not be mandatory. > > DNSSEC is not mandatory, it is recommended.
I was responding to the FOR DISCUSSION in section 1.5, which I imagined referred to the overall question of what level of support for DNSSEC the document should specify. > One motivation behind DELEG is the ability to use “Aliasmode” to point to an > SVCB record elsewhere, which contains a DS record. This way, DS records in > various top level domains can be federated under a single operator. This > works solely if both the DELEG is signed and “elsewhere” is signed. Yep. But simply not overloading the same RRTYPE involved in delegation (the NS RRSet) also confers benefits, regardless of whether DNSSEC is involved or not. >> If an authority server is capable of loading a DELEG RRSet and generating >> referral responses accordingly, it's surely also possible of synthesising an >> unsigned NS set? > > I’m all in favour of synthesising NS/Glue records from DELEG, however, this > automation is a nice to have and its functionality should not be required to > implement in the draft. Yep, I'm suggesting otherwise, that perhaps it ought to be a hard requirement to synthesise NS RRs when DELEG is present, and perhaps also that it not be legal to include both NS and DELEG at the same owner name. >> Related, what to do when the ipv4hints are not the same as the corresponding >> A RRSet? > > IMHO, potential unsigned glue records from elsewhere are inferior to address > records in a signed DELEG record. If a validator supports DELEG, and has > information such as Nameserver names and name server addresses, it should > ignore glue and NS records. I think specifying rules about which to prefer is important. But I also think it's worth thinking more pessimistically around what kinds of failures will result when people get that wrong. We have already seen this with HTTPS, using precisely the same mechanism. Joe _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
