On Fri, Feb 12, 2021 at 11:08 AM Joe Abley <[email protected]> wrote:
> Hi all, > > I have discovered that without liberal access to bars and hallways at > in-person IETF meetings, I no longer know how to tell the difference > between ambition and insanity when it comes to technical proposals. I am > quite prepared to find out that in this case the needle is at the crazy end > of the scale. > > Happy Friday! > > > Joe > > Begin forwarded message: > > *From: *[email protected] > *Subject: **New Version Notification for draft-jabley-dnsop-refer-00.txt* > *Date: *12 February 2021 at 10:52:38 EST > *To: *"Joe Abley" <[email protected]> > > > A new version of I-D, draft-jabley-dnsop-refer-00.txt > has been successfully submitted by Joe Abley and posted to the > IETF repository. > > Name: draft-jabley-dnsop-refer > Revision: 00 > Title: REFER: A New Referral Mechanism for the DNS > Document date: 2021-02-12 > Group: Individual Submission > Pages: 14 > URL: > https://www.ietf.org/archive/id/draft-jabley-dnsop-refer-00.txt > Status: https://datatracker.ietf.org/doc/draft-jabley-dnsop-refer/ > Htmlized: > https://datatracker.ietf.org/doc/html/draft-jabley-dnsop-refer > Htmlized: https://tools.ietf.org/html/draft-jabley-dnsop-refer-00 > > > Abstract: > The Domain Name System (DNS) incorporates a namespace that is > comprised, in practice, of multiple so-called zones. Each zone is, > in principal, a finite tree structure which can be administered > autonomously, and is connected to exactly one parent zone and zero or > more child zones. These connection points are known as zone cuts; a > parent zone contains information that allows the servers responsible > for the child zone to be found. > > The current DNS specification encodes that information about child > zones using an "NS" resource record set in the parent zone, and a > corresponding "NS" resource record set in the child zone. These two > resource record sets have identical owner names, class, and resource > record type but can differ in other respects such as the time-to-live > (TTL) attribute, the resource record data associated with each set > and the availability of cryptographic signatures. This property of > being similar, related but potentially different has led to > operational complexity. > > This document proposes a change to how zone cuts are encoded in the > parent zone, allowing the resource records in the parent and the > child zone to be more clearly distinguished and protected separately > using cryptographic signatures. > > It is not at all clear that this is a good idea. To restate in > stronger terms, the goal of the experiment described in this document > is to determine just how bad an idea this is. > > > I like this. But don't we also need to sign the glue A and AAAA records if they are in the child zone? (I wonder if something like the SVCB record, to include the NS info, plus A and AAAA, might be better.) -- Bob Harold
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
