Re: [DNSOP] new DNS classes

Phillip Hallam-Baker <phill@hallambaker.com> Sat, 08 July 2017 12:04 UTC

Return-Path: <hallam@gmail.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 A62A5126C22; Sat, 8 Jul 2017 05:04:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level:
X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 UsYJwoBMKpfq; Sat, 8 Jul 2017 05:04:30 -0700 (PDT)
Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1B851204DA; Sat, 8 Jul 2017 05:04:29 -0700 (PDT)
Received: by mail-lf0-x232.google.com with SMTP id h22so37418055lfk.3; Sat, 08 Jul 2017 05:04:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=O8lcg9dLU4jaXcF4DTGemkf5CGH0HBwgmJyc9urUY6U=; b=HrMjyE91hU8nLYEDv4Hb1h2/ymaf032aM/Cf88UZ7LJWdCQjR+I49MB6NV3r0Qisfz yROk2tc5Tf2DucrpmpVfVeQqVsyrr/Sz8y4376g8iR3BxK+78/f1AUWbqY+Z9DzIVm9x /LjZjMqms2s4RJwbcg6hzAI/tkgD0oYHL7P/DBLd2COst5vjPrXP44zNiXXW/EKIdBOa +PXset+3iibrltg2YGGKDSjNnAAksaasrWazEVPGZtP4D66KVKShdLHQf6qThat5HCkF unCGKa3j/TUHp6rF18WzWCyVvUfGxTlqxTQRtwwhIk/PsF0GQUdhiVIYbhj/iLemUqnW kAiA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=O8lcg9dLU4jaXcF4DTGemkf5CGH0HBwgmJyc9urUY6U=; b=cTDdwU1vq8l2Yq/Fzw7pNa7M+9y2AqQFL3V6Zt0kCzQEGWWvCGeqrRa42Q+GwB6P1F 6SzQzi1TvjgiBu14IXP3cGcP+5YAzuxaX+2MzR4ZqY1vwuqiX/pofJxQJr98rtpJN+uL +B/A/Z2WxpcIcmlUIk/IgI3yDRIGMpMcbeqA1mZGsO05BUcgM799X0jO5fB27VY5acHZ /Rl2LCd7VwW5k6K7D/ukbhBb15jYx0F0dkiSYGGvyHwrOkJPN0MlPNQsAMFolDKa32k7 D68nepZ/G1/E0WIE17L8glev4C7eIahd3INXMwuuHcpoRUJc8e3kEOBVh0Mr29Y3N/tG pFsA==
X-Gm-Message-State: AKS2vOxtHqSSb+Cha6dswINneIUF6ioeI2Hm1dnMcZstSEwgeWwePtsd lXjzVqrclg/iaj2flWUnm5xbjmYCIA==
X-Received: by 10.25.17.75 with SMTP id g72mr20381061lfi.122.1499515468193; Sat, 08 Jul 2017 05:04:28 -0700 (PDT)
MIME-Version: 1.0
Sender: hallam@gmail.com
Received: by 10.25.181.214 with HTTP; Sat, 8 Jul 2017 05:04:26 -0700 (PDT)
In-Reply-To: <562EC659F89FA92A09CAC4DB@PSB>
References: <CAHw9_iJQ31wqLavOhtMpPOBhGP4j6CLk45KHGdX5vOA+qj4nQA@mail.gmail.com> <m2a84kzm4y.wl-randy@psg.com> <F98FEA1C-3F3F-4344-8B07-996AAD899CC2@fugue.com> <m2shicxr0h.wl-randy@psg.com> <A70FD34B-000A-4748-B1B2-BF6DF66C7D6C@fugue.com> <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>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Sat, 8 Jul 2017 08:04:26 -0400
X-Google-Sender-Auth: -jEDFB7gIHtktcQi93hlUf9SJac
Message-ID: <CAMm+LwjXiAtozbH4DJwRfU2Q6NcVMg76kKzLd8poQZhakLQtmw@mail.gmail.com>
To: John C Klensin <john-ietf@jck.com>
Cc: Paul Vixie <paul@redbarn.org>, dnsop <dnsop@ietf.org>, IETF Rinse Repeat <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="001a11401a18d125470553cd265c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/lXb0p71m0JIgGe06sLb1mN5oAWE>
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: Sat, 08 Jul 2017 12:04:32 -0000

On Thu, Jul 6, 2017 at 11:15 AM, John C Klensin <john-ietf@jck.com>; wrote:

>
>
> --On Thursday, July 6, 2017 00:36 -0400 Phillip Hallam-Baker
> <phill@hallambaker.com>; wrote:
>
> > There are changes to the DNS that are practical and those that
> > are not. For better or worse, I can't see any way that
> > teaching DNS to use new classes makes any sense at this point.
> > The only point at which it would have made sense was when
> > internationalization happened. But the path chosen makes more
> > sense.
>
> As the author of the I-D that proposed using a Class to deal
> with internationalization, it would not have worked, and the two
> important reasons are perhaps worth understanding.   First, that
> approach included a transition strategy that permitted legacy
> clients and registrations to keep working in a way that users
> would see as normal.  But that strategy depends on CLASSes
> sharing the same root and hierarchy.  At Paul points out, that
> interpretation of 1034/1035 is not universally accepted and
> implemented.  Second, IIR, we intended that the different CLASS
> allow a different set of matching rule assumptions and
> conditions.  Because labels must generally be interpreted and
> compared before CLASS values are accessed and, perhaps more
> important, in optimization of databases, one probably needs
> label types to do that, not CLASSes.   And label types don't
> have a good history.


​My point was that all the reasons not to use class for
internationalization are likely general and apply to any attempt to use
class.

> It seems to me that if people want to do anything new with DNS
> > that they should use prefixes, new RRs or both as the
> > mechanism, not the class which is limited anyway.
> >
> > DNS is not a full service directory. Nor does it need to be. A
> > UDP packet is big enough for a link, a fingerprint and a
> > digital signature. That is all that you ever need.
>
> As I think you know, I just love "all you will ever need"
> statements about the Internet (and its predecessors) although my
> favorite remains "we will never need more than 8 bits of address
> space".


​The question that always comes up in a directory service is how much
service description information to put in the ​directory and whether the
service itself should provide some of the description.

DNS is irritatingly constraining when it comes to distributing information
like a digital certificate. But we have managed to live in those
constraints for the past 20 or so years after they started to be an issue.

What you need and what you might want are different things.


​If people find that they do need 'more than 8 bits', then ​I guess we end
up having to design DNS/2 protocol. But I think it unlikely we get there
anytime soon.