Hi Joe, > On 30 Jan 2024, at 12:57, Joe Abley <jab...@strandkip.nl> wrote: > > Hi all, > > I have read draft-dnsop-deleg-00 and have some comments. It seems premature > to offer actual text as well as commentary but I can definitely do that if > the authors would like. I am fully enthusiastic about updating delegations > and referral responses, and anything negative below should not be > accidentally interpreted as some kind of objection, because far from it. > > I wrote a vaguely similar draft to this one a while back (except not as good, > and it's expired, and nobody got particularly excited about it, which was > surely entirely fair). That draft contains a number of problem statements > that might be reusable here. The privacy motivation in particular seems > pertinent, but maybe the others too. > > https://datatracker.ietf.org/doc/html/draft-jabley-dnsop-refer-00 > > I understand the motivation for the text relating to the DNS operator not > being part of the Registry/Registrar/Registrant gang (clearly it's because > the DNS operator does not start with R, for a start) but I think the text > that is there is inadequate to cover the full breadth of that idea. There's a > neat shortcut there to put nameserver configuration in the hands of DNS > operators, but there's more to that story. I think this deserves more > thought, if it is to be mentioned in the base draft. Perhaps this means it > doesn't belong in the base draft. > > The question of whether DNSSEC might be necessary in the use case where a > delegation involves a secure transport is perhaps best thought about as a > potential downgrade attack. A secure delegation coupled with validation of > the DELEG response when it arrives is a protection against that attack. While > it seems very sensible to warn about the attack and to suggest a mitigation, > I don't think it's useful to require that DNSSEC be used. That seems like a > sure fire way to make sure DELEG is not used, for a lot of people. 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. 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. > The document is not very vocal on the question of whether a parent should > install both NS and DELEG RRSets above the zone cut, or whether there is an > opportunity for nameservers to use a DELEG if present to synthesise a > conventional referral with NSes. If DELEG doesn't mask NSes then there's the > question of what to do when the instructions in both delegations are > different. The draft says DELEG should be preferred, but to me this is just > taking an existing problem of parental and child NS sets being irritatingly > different in the wild and making the problem worse. 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. Happy to have implementors build features that do this though. > 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. Roy _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
