[dns-operations] any registries require DNSKEY not DS?

[Olafur Gudmundsson]

> On Apr 17, 2020, at 4:45 PM, Brian Dickson <brian.peter.dickson at gmail.com> wrote:
> 
> 
> 
> On Fri, Apr 17, 2020 at 12:57 PM Olafur Gudmundsson <ogud at ogud.com <mailto:ogud at ogud.com>> wrote:
> 
> 
>> On Jan 22, 2020, at 11:16 PM, Paul Vixie <paul at redbarn.org <mailto:paul at 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 at lists.dns-oarc.net <mailto:dns-operations at 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 at lists.dns-oarc.net <mailto:dns-operations at lists.dns-oarc.net>
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations <https://lists.dns-oarc.net/mailman/listinfo/dns-operations>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20200421/c7337ded/attachment.html>