<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 17, 2020 at 12:57 PM Olafur Gudmundsson <<a href="mailto:ogud@ogud.com">ogud@ogud.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><br><div><br><blockquote type="cite"><div>On Jan 22, 2020, at 11:16 PM, Paul Vixie <<a href="mailto:paul@redbarn.org" target="_blank">paul@redbarn.org</a>> wrote:</div><br><div><div>On Thursday, 23 January 2020 02:51:28 UTC Warren Kumari wrote:<br><blockquote type="cite">...<br><br>If the parent makes the DS for me from my DNSKEY, well, then the DS<br>suddently "feels" like it belongs more to the parent than the child,<br>but this is starting to get into the "I no longer know why I believe<br>what I believe" territory (and is internally inconsistent), so I'll<br>just stop thinking about this and go shopping instead :-)<br></blockquote><br>as you see, the DS RRset is authoritative in the parent, in spite of its name <br>being the delegation point, which is otherwise authoritative only in the <br>child. so, DS really is "owned by" the delegating zone, unlike, say, NS.<br><br>historians please note: we should have put the DS RRset at $child._dnssec.<br>$parent, so that there was no exception to the rule whereby the delegation <br>point belongs to the child. this was an unforced error; we were just careless. <br>so, example._<a href="http://dnssec.com" target="_blank">dnssec.com</a> rather than <a href="http://example.com" target="_blank">example.com</a>.<br><br>-- <br>Paul<br><br></div></div></blockquote><div><br></div>Paul, </div><div>If start talking about history and looking back with hindsight </div><div><br></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></blockquote><div><br></div><div>Would the method have potentially been to have GLUEA and GLUEAAAA records rather than effectively overloading the A/AAAA status (authoritative vs not)?</div><div>And then all of the new types that live only in the parent, could have been signed.</div><div>I'm guessing it's way to late to start doing that now, without rev'ing all of DNS to v2.</div><div><br></div><div>Brian</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><br></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.3333px">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></div><div><br></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></div><div>But this is all hindsight based on 30 years of coding and operational difficulties.</div><div><br></div><div>Regards, </div><div>Ólafur</div><br></div>_______________________________________________<br>
dns-operations mailing list<br>
<a href="mailto:dns-operations@lists.dns-oarc.net" target="_blank">dns-operations@lists.dns-oarc.net</a><br>
<a href="https://lists.dns-oarc.net/mailman/listinfo/dns-operations" rel="noreferrer" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-operations</a><br>
</blockquote></div></div>