Re: [DNSOP] Fwd: New Version Notification for draft-jabley-dnsop-refer-00.txt

[Bob Harold <[e-mail]>]

On Fri, Feb 12, 2021 at 11:08 AM Joe Abley <[e-mail]> 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: *[e-mail]
> *Subject: **New Version Notification for draft-jabley-dnsop-refer-00.txt*
> *Date: *12 February 2021 at 10:52:38 EST
> *To: *"Joe Abley" <[e-mail]>
>
>
> 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