<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jan 22, 2020, at 11:16 PM, Paul Vixie <<a href="mailto:paul@redbarn.org" class="">paul@redbarn.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On Thursday, 23 January 2020 02:51:28 UTC Warren Kumari wrote:<br class=""><blockquote type="cite" class="">...<br class=""><br class="">If the parent makes the DS for me from my DNSKEY, well, then the DS<br class="">suddently "feels" like it belongs more to the parent than the child,<br class="">but this is starting to get into the "I no longer know why I believe<br class="">what I believe" territory (and is internally inconsistent), so I'll<br class="">just stop thinking about this and go shopping instead :-)<br class=""></blockquote><br class="">as you see, the DS RRset is authoritative in the parent, in spite of its name <br class="">being the delegation point, which is otherwise authoritative only in the <br class="">child. so, DS really is "owned by" the delegating zone, unlike, say, NS.<br class=""><br class="">historians please note: we should have put the DS RRset at $child._dnssec.<br class="">$parent, so that there was no exception to the rule whereby the delegation <br class="">point belongs to the child. this was an unforced error; we were just careless. <br class="">so, example._<a href="http://dnssec.com" class="">dnssec.com</a> rather than <a href="http://example.com" class="">example.com</a>.<br class=""><br class="">-- <br class="">Paul<br class=""><br class=""></div></div></blockquote><div><br class=""></div>Paul, </div><div>If start talking about history and looking back with hindsight </div><div><br class=""></div><div>IMHO the second biggest mistake in DNS design was to have the same type in both parent and child zone </div><div>If RFC1035 had specified DEL record in parent and NS in child or the other way around it would have been obvious to </div><div>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.</div><div>…… </div><div>If we had the DEL record then that could also have provided the glue hints and no need for additional processing, </div><div><br class=""></div><div>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 <span style="font-size: 13.333333015441895px;" class="">Mockapetris </span>came up with </div><div>“Parent is authoritative for the existence of NS record, Child is authoritative for the contents” </div><div><br class=""></div><div><br class=""></div><div>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.</div><div><br class=""></div><div>But this is all hindsight based on 30 years of coding and operational difficulties.</div><div><br class=""></div><div>Regards, </div><div>Ólafur</div><br class=""></body></html>