> On Apr 17, 2020, at 4:45 PM, Brian Dickson <brian.peter.dick...@gmail.com> > wrote: > > > > On Fri, Apr 17, 2020 at 12:57 PM Olafur Gudmundsson <o...@ogud.com > <mailto:o...@ogud.com>> wrote: > > >> On Jan 22, 2020, at 11:16 PM, Paul Vixie <p...@redbarn.org >> <mailto:p...@redbarn.org>> wrote: >> >> On Thursday, 23 January 2020 02:51:28 UTC Warren Kumari wrote: >>> ... >>> >>> If the parent makes the DS for me from my DNSKEY, well, then the DS >>> suddently "feels" like it belongs more to the parent than the child, >>> but this is starting to get into the "I no longer know why I believe >>> what I believe" territory (and is internally inconsistent), so I'll >>> just stop thinking about this and go shopping instead :-) >> >> as you see, the DS RRset is authoritative in the parent, in spite of its >> name >> being the delegation point, which is otherwise authoritative only in the >> child. so, DS really is "owned by" the delegating zone, unlike, say, NS. >> >> historians please note: we should have put the DS RRset at $child._dnssec. >> $parent, so that there was no exception to the rule whereby the delegation >> point belongs to the child. this was an unforced error; we were just >> careless. >> so, example._dnssec.com <http://dnssec.com/> rather than example.com >> <http://example.com/>. >> >> -- >> Paul >> > > Paul, > If start talking about history and looking back with hindsight > > IMHO the second biggest mistake in DNS design was to have the same type in > both parent and child zone > If RFC1035 had specified DEL record in parent and NS in child or the other > way around it would have been obvious to > specify a range of records that were parent only (just like meta records) > thus all resolvers from the get go would have known that types in that range > only reside at the parent. > …… > If we had the DEL record then that could also have provided the glue hints > and no need for additional processing, > > Would the method have potentially been to have GLUEA and GLUEAAAA records > rather than effectively overloading the A/AAAA status (authoritative vs not)? > And then all of the new types that live only in the parent, could have been > signed. > I'm guessing it's way to late to start doing that now, without rev'ing all of > DNS to v2. > >
Assuming that GLUEx records were Parent side only that is possible, but I was thinking that DEL could be like a TXT foo. DEL "ns1.foo” “127.0.0.1” “1::dead:beef” and this would have been what was used to do the initial lookup into child zone. Yes this all will require DNSng and that is a ……. > Brian > > > > You may recall that in 1995 when you and I were trying to formalize for > DNSSEC what the the exact semantics of NS record were, then you and Paul > Mockapetris came up with > “Parent is authoritative for the existence of NS record, Child is > authoritative for the contents” > > > Just in case you are wondering what was the biggest mistake that is QR bit, > recursion should have been on a different port than Authoritative. > > But this is all hindsight based on 30 years of coding and operational > difficulties. > > Regards, > Ólafur > > _______________________________________________ > dns-operations mailing list > dns-operations@lists.dns-oarc.net <mailto:dns-operations@lists.dns-oarc.net> > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > <https://lists.dns-oarc.net/mailman/listinfo/dns-operations> > _______________________________________________ > dns-operations mailing list > dns-operations@lists.dns-oarc.net <mailto:dns-operations@lists.dns-oarc.net> > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > <https://lists.dns-oarc.net/mailman/listinfo/dns-operations>
_______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
