Re: new RRTYPEs, was DNSSEC architecture vs reality

Phillip Hallam-Baker <phill@hallambaker.com> Wed, 14 April 2021 16:48 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 936583A16E4 for <ietf@ietfa.amsl.com>; Wed, 14 Apr 2021 09:48:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 pAatzJDsB3IK for <ietf@ietfa.amsl.com>; Wed, 14 Apr 2021 09:48:16 -0700 (PDT)
Received: from mail-yb1-f179.google.com (mail-yb1-f179.google.com [209.85.219.179]) (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 19A763A16E9 for <ietf@ietf.org>; Wed, 14 Apr 2021 09:48:15 -0700 (PDT)
Received: by mail-yb1-f179.google.com with SMTP id o10so22847880ybb.10 for <ietf@ietf.org>; Wed, 14 Apr 2021 09:48:15 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EESGIXYzhdJRzAzagzwFV9s5kgJ8ZCaPobybnaS+SiA=; b=Kf336Gc/GA3toBQM5uGNvUbexutjtjuy6JMVtC2zJRQkcvhhJGdWc3ajc+Qa5ELgBS UL7QLs44ca2/GaZlWULuwOPRFC3qrFexAW8PhgbyTH37n96Fdc7tDM4pJ9eLTfl/FdYh 3k563MhI6rEX8a4FtbcNW07FUyJMZG9mAwv2A/3uwMfHMT2AwdHrm7XTjAWngnlEFnEy czxd/5WDcGD4We3lUzjzj9gh+CX488wPCEU6VG2kqBdMJO+Is0GseLs+BXUADhJHnfIA esUCNa6VBFveFytGjZ6jamsEGwgF0qPbhSV7EUMaUPUUwPJ0uMOKan+adOi46YXlNrnU ZCew==
X-Gm-Message-State: AOAM5304uEqtphWP+yib2adh8pPbXQGVqnB4YQDI54MomNbYuNE/wa+y 4jLHjsbcOCpIIEPZ/mRJywWuCKTW1GqmR0arKn4=
X-Google-Smtp-Source: ABdhPJzVTOeXzEVAeWn2HUsCZuyzKCUJgg64/CjqaLjXyJn+IPqChfZiGJ5n1tQsDW0WsDBoOpehNmkCfvqNPYQhdQ8=
X-Received: by 2002:a25:7612:: with SMTP id r18mr28918940ybc.172.1618418894872; Wed, 14 Apr 2021 09:48:14 -0700 (PDT)
MIME-Version: 1.0
References: <20210413015000.9297272C47BA@ary.qy> <C8C39247-226E-4C78-88E8-3AC215F2FF21@isc.org> <1c90249a-a9ad-52dd-bbc5-5e4bc6e6bdf@taugh.com>
In-Reply-To: <1c90249a-a9ad-52dd-bbc5-5e4bc6e6bdf@taugh.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Wed, 14 Apr 2021 12:48:05 -0400
Message-ID: <CAMm+LwhEmiQOYtP807n2Gm2MKq7cGhMoCB_hkJxPZCQ9uatW8Q@mail.gmail.com>
Subject: Re: new RRTYPEs, was DNSSEC architecture vs reality
To: John R Levine <johnl@taugh.com>
Cc: Mark Andrews <marka@isc.org>, IETF general list <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000053a27b05bff183fb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/HH_7MEHSfCIBlEmbdHIQODnlwac>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Apr 2021 16:48:21 -0000

On Tue, Apr 13, 2021 at 11:28 AM John R Levine <johnl@taugh.com> wrote:

> On Tue, 13 Apr 2021, Mark Andrews wrote:
>
> > John,
> >       please show how this would be used to parse a HTTPS record
> > without extending the format?
>
> It doesn't.  If an RRTYPE uses a new field type, you need to write code.
> But if you look at the list of RRTYPEs in the library I wrote, only seven
> of them need unique field types and the rest use regular fields.
>
> Also keep in mind that typical provisioning crudware currently handles
> about six RRTYPEs, and this is a way to at least catch up with the past
> several decades.  It's not a panacea but it lessens the pain a lot.
>

Some people being surprised that there are gatekeepers that require a fee
seem to be unsurprised that their own employer charges a fee for access to
their
app store.

I did propose a TXT record that could be used for unstructured config and
the
DNS folk rejected it (as they always do). So I really don't care how upset
they
get about the uses their comment field is being put to.

If indeed there is a need for comments in DNS config files, the obvious way
to support that at this stage is to introduce a new RRTYPE for that purpose.
Call it the REM record type. Anyone who really needs comments in the DNS can
use REM. The rest of us can follow the use that has been made of TXT for
over 20+ years: providing config info.


Specification irredentism is not a good look. When the world takes a
different
path to the one you would have prefered, try to roll with it. That's what I
do. I don't spend my time saying people should undo past decisions they made
against their advice, I just spend the next 40 years reminding them they are
responsible for the goof.


As some of you are aware, I am currently working on a scheme that allows a
rather different approach to DNS. Its not exactly an alt.root and its not
exactly
name coin. Imagine what you would get if you removed the ideological
commitments from both...

The parts I don't like in DNS are the root and the need to rent your name
for
$10/yr. What if the cost was $0.10 for life?