Re: [DNSOP] new DNS classes

Nico Williams <nico@cryptonector.com> Thu, 06 July 2017 15:40 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 632371317C4; Thu, 6 Jul 2017 08:40:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBDm5KSYDChC; Thu, 6 Jul 2017 08:40:01 -0700 (PDT)
Received: from homiemail-a35.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DF561317C8; Thu, 6 Jul 2017 08:40:01 -0700 (PDT)
Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id A136FC0028BB; Thu, 6 Jul 2017 08:40:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=kYjLJSqN5bcVCU gZEYpNGC9mLIQ=; b=ylF7B86MeUvSNOgJk/QiEoJfbmIKcCO5KwIYhZd9mwweAD e4IbWAncThxaKJgWUzUrWxMuOMQLRlBdeUAj6RXVP2GL7NWpZRYsbwwvJpvRHn0F w0Ap/PR9F9To3sFKqUoGYAQj+5Zq46H7g2RJeWa+8/HPRNcb8LOkxCoz4nyog=
Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id 24CEBC0028BA; Thu, 6 Jul 2017 08:40:00 -0700 (PDT)
Date: Thu, 6 Jul 2017 10:39:56 -0500
From: Nico Williams <nico@cryptonector.com>
To: John C Klensin <john-ietf@jck.com>
Cc: Phillip Hallam-Baker <phill@hallambaker.com>, Paul Vixie <paul@redbarn.org>, dnsop <dnsop@ietf.org>, IETF Rinse Repeat <ietf@ietf.org>
Message-ID: <20170706153955.GB3393@localhost>
References: <m2podgxq97.wl-randy@psg.com> <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> <CACfw2hhx+-Z=7ZnnaOkToc+Bd7aKDpBFt+nFUxkt9sKqLn4D8Q@mail.gmail.com> <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> <595BD53E.60701@redbarn.org> <E739C1CB-E60E-4B4B-99CF-1E6C68CB6926@rfc1035.com> <7DCA3DAF1993A2E66915D0DD@JcK-HP5.jck.com> <595BE0D5.5000106@redbarn.org> <CAMm+Lwjd6xVp-EDp=doevx=AP8qws_Mv++aL733yHEyUF72EMA@mail.gmail.com> <562EC659F89FA92A09CAC4DB@PSB>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <562EC659F89FA92A09CAC4DB@PSB>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/fzlzGmnsaZgzlb7ghcBAO68JvKE>
Subject: Re: [DNSOP] new DNS classes
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Jul 2017 15:40:02 -0000

On Thu, Jul 06, 2017 at 11:15:34AM -0400, John C Klensin wrote:
> --On Thursday, July 6, 2017 00:36 -0400 Phillip Hallam-Baker
> <phill@hallambaker.com>; wrote:
> > The X.500 and UDDI models were broken because there is no
> > point in putting information into a directory if the service
> > can return it in a service handshake.
> 
> The X.500 and UDDI approaches failed because... sorry, I lost
> count of the reasons :-(

The complexity and general ugliness of x.400/x.500 naming (indeed, the
inability to correctly and canonically represent such names in TEXT!)
are all the reason anyone ever should have needed.  (See what I did
there?)  And yet some bits of that horrible thing are still with us
(PKIX, LDAP), though of course with various adaptations (eg, SANs) to
make them suck less and more Internet-like.

DNS is not a directory, but when your only off-the-shelf choices are DNS
or LDAP...

I'll contribute this extension to your earlier argument about root
sharing/non-sharing.  I think new classes will only ever be feasible
provided that a) they share roots with IN, or b) are like a local HS not
really meant to federate at all (thus root sharing / alt. roots would be
moot).  (a) classes would basically be an RR type extension field for
IN.  (b) is probably not worth considering -- the lack of security in HS
was a big reason for not using it, and so DNSSEC (or something like it)
would be a requirement in order to use an HS-like class, but if you'll
want DNSSEC then you'll want delegation hierarchy anyways and thus
you'll want shared roots, making any HS-like classes just IN-class RR
type extension fields.  It's easier to develop a new protocol for (b)
than to shove whatever it is into DNS.

So new classes will only be useful to extend the IN-class RR type
namespace.  We won't get there.  New RR types can be very difficult to
deploy due to lack of interest by registrars and domain hosting
services.  TXT RRs forever.  :(

Cheers,

Nico
--