Re: [DNSOP] Fwd: New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

Joe Abley <> Sat, 24 March 2018 13:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C3E881243F3 for <>; Sat, 24 Mar 2018 06:48:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 43AogjwAN6an for <>; Sat, 24 Mar 2018 06:48:38 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 28C6C1201F2 for <>; Sat, 24 Mar 2018 06:48:38 -0700 (PDT)
Received: by with SMTP id c78-v6so17447699lfh.1 for <>; Sat, 24 Mar 2018 06:48:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=from:mime-version:references:in-reply-to:date:message-id:subject:to :cc; bh=EBUijXb+UuGhkQSeURDUjEoQ+5N6J21eWWAqpHIH3KE=; b=LrYXlSLr7RtgkSsVQmad2EesQLYPq7uKI5BH8pTN/S/PM3dLoMjGCFbmflyZ2sdNY+ jpT4V76sRoUtJiHj9SJs913jykMsE9IP2jvo5P6Gp7r46MpoYb9SCJqQfXwfCjNCZ3r/ 1+AI99LMz5JxSVSXchDq46ahUwv2F2kLhWbcE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:mime-version:references:in-reply-to:date :message-id:subject:to:cc; bh=EBUijXb+UuGhkQSeURDUjEoQ+5N6J21eWWAqpHIH3KE=; b=lqgV6aBelMkNy1Pwr+AOzhKGA8VM4abJvdv+vZ4qos0qWWhFyb8eHfo7ghqOi2t1iE Wb3UZYuGFW+kdd2ndh93ceUQPYrCVT8JHPP8IXJuebi551Ve6Dk0mpaM5LfWm6QWR8iH LdKq/yugBGop9KnLB9l0UpRW0cw5eUKvFGPC50a/PuCjTBu10bGwqy24Ek6rkB7GuAWt SzsDKrVnbMja8d9RQ99DdxaG/1l3HJ9G1w+VrRY1eoGeWJqi+/9XKGc8+P0jkBf46/Y8 4o839wfbbtOyKQlZz13yjchwrIO34I6tBLJoemGKsc8we9bwz5VD5FJn7PBdyx6LGJRl x6tg==
X-Gm-Message-State: AElRT7FChtV4lMn7oPFICFZYTphOAAn8hQMwf+a1jMJLIntfex1Co86m mzTVQ/GOFfyb3whras2dlxbTP+hOcXPmKAM7fof7kQ==
X-Google-Smtp-Source: AG47ELvF4Z1PJ1oRGNpAzkp22YAzSYpMmWA515nKaK86PE5GoW/oaxDkIK7QRy/B++ssln69Aw4+gsBn4ebYuhHbFtM=
X-Received: by with SMTP id x24mr7539176ljd.144.1521899316451; Sat, 24 Mar 2018 06:48:36 -0700 (PDT)
Received: from unknown named unknown by with HTTPREST; Sat, 24 Mar 2018 06:48:35 -0700
From: Joe Abley <>
Mime-Version: 1.0 (1.0)
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Date: Sat, 24 Mar 2018 06:48:35 -0700
Message-ID: <>
To: Jared Mauch <>
Cc: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <>, Bob Harold <>, dnsop <>, Paul Vixie <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [DNSOP] Fwd: New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 24 Mar 2018 13:48:40 -0000

On Mar 24, 2018, at 13:49, Jared Mauch <> wrote:

>    isc/bind can and perhaps should implement logging for these
> rrtypes that say they may be going away so folks can see the impact.

I'm actually surprised to see that support for rarely-used RRTypes is
really upsetting the camel.

A combinatorial explosion of annoying workarounds for the inability of
middleboxes or upstream authority servers to implement EDNS(0)
properly seems like a much more plausible camel irritant to me. I'm
sure there are many more like that.

I can see why you could strip out lines of code by eliminating the
need to parse the canonical formatting of WKS and friends, but I'm
surprised that it's a notable source of complexity. It is, after all,
complexity that I heard is causing the camel strain, not just lines of

If future-BIND stops parsing an archaic RRType that I happen to use,
I'm going to have to change whatever code or processes that depend on
it. Maybe someone (ISC, even) is going to publish a filter that will
turn all the old RRs in canonical syntax into TYPExxxx representation,
and back again. New RRTypes might then need to get implemented in both
BIND (because presumably they are camel-friendly) and also in the
filter or filters, because perhaps we are targeting multiple
nameserver implementations with our zone file.

This all sounds like we're just sharing the complexity around. It
doesn't sound any simpler. Maybe it's a silly example? I don't know.
Could be. But I think brushing the grains RRType parsing dust off the
camel is not going to do much for its posture.