Re: [DNSOP] raising the bar: requiring implementations

Suzanne Woolf <> Thu, 29 March 2018 19:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BC9B11242EA for <>; Thu, 29 Mar 2018 12:18:50 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sje08OEUCmjS for <>; Thu, 29 Mar 2018 12:18:49 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 18C071201F2 for <>; Thu, 29 Mar 2018 12:18:49 -0700 (PDT)
Received: by with SMTP id d206so7123447qkb.0 for <>; Thu, 29 Mar 2018 12:18:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dokZloSighExn+4cUUoC4c1igUPZ1mVeEnrgcCm0/dw=; b=NU0BbF8gbiyuRB4hU0iSkQ6Gx+vCLV9VAJzS5xh5a1K0bY7Gc6icJgRr/+QLspcSym jEWoLbVnbhj/2e55pYKb+pCth345f2CAIgpzHNep471MhUeWeaX/Q9dUFCdXBcdkfa/5 LQhEYKI8zqPYCheR+14iHB8PGZuLndsJH1RV9NPkEusOpKiCnOqS4tfw8WzVH5r5Ga6d Wwoo9n7TiK89Nz1F9zvVqVnRDjD2OHnVL+CFCWMuQhov05lsHX1PV4FMgnoIocnNx6vS YVyAHisEo9ATBymnWKHdB9+QMmsWpCawC2BNHT2CwB8/WL+7y7JjJFcD/Lb/Vlg2BKeP Owkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dokZloSighExn+4cUUoC4c1igUPZ1mVeEnrgcCm0/dw=; b=K/f5coKUFjA2V3+o7SRyWbkk79E13DC43cUKsIxwUhjVFdDm1/mdyKEcNL49NEEqyF ZWpnWfVWfJlCnrMFNtLyVgTiXY9vLcdx4wK63ZKlB5Mqiz4EgTxAg1FDrvtlv+m5F7pj nQtpiejjM6koBnV8LQSlqgJfZwkGdEV5+FQjrV2xaCAVYZkHv+POSNQq5d15P3UntEyf 0sDfPtuySUzCjSqo0s/yXKwItR6bqwIIedD8m1gEuOXXCnMYFCPO0LeF7ldB3uavl+jO h2lt5FElzcHb7E7DDZfupnTJgYrF+lrjwMLx4XYLXcavEhG8KBjC7k3Za/8eq48VaxNa PoUw==
X-Gm-Message-State: ALQs6tCIMYCUyYKX3L23CEvhqY7gzkWKdURe7kxX4cDm3H4A02Sfo2ra wcj03Wd8ni/EXSVw5D41jaCQCw==
X-Google-Smtp-Source: AIpwx48hAMuybyKUcZ7M4qX2q7M9gGIpiKOovtKMlndQS+NZsMrSFN7tWzSCbkp9Ox804madUCRPHg==
X-Received: by with SMTP id m6mr13064327qkc.28.1522351128096; Thu, 29 Mar 2018 12:18:48 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id q25sm5290047qkj.71.2018. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 29 Mar 2018 12:18:47 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Suzanne Woolf <>
In-Reply-To: <20180328151939.GA19504@jurassic>
Date: Thu, 29 Mar 2018 15:18:45 -0400
Cc: tjw ietf <>, dnsop <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <20180328151939.GA19504@jurassic>
To: Mukund Sivaraman <>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <>
Subject: Re: [DNSOP] raising the bar: requiring implementations
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: Thu, 29 Mar 2018 19:18:51 -0000

On Mar 28, 2018, at 11:19 AM, Mukund Sivaraman <>; wrote:

> On Wed, Mar 28, 2018 at 10:55:13AM -0400, tjw ietf wrote:
>> I would say that most things we have adopted in the past few years do have
>> some implementations to reference.
>> Not when drafts are adopted, but generally before we head to WGLC I've
>> always wanted to see someone
>> who implemented the option in some manner.
>> But yes, agree.
> I'd raise the bar even higher, to see complete implementation in a major
> open source DNS implementation when it applies. Sometimes implementation
> problems are very revealing (client-subnet should have gone through
> this).

This is actually quite a good example of another problem: Client-subnet was documented for Informational purposes; it was already in wide use in the public internet and had an EDNS opt code codepoint allocated from the IANA registry.

Nothing that happened in DNSOP or the IETF changed that, and I strongly suspect nothing that happened in DNSOP or the IETF could have changed it.

Other documents we’ve considered on features or modifications to the protocol include refuse-any and, I believe, serve-stale, and the stated purpose of the localhost draft is to clarify the existing documentation on the reserved name “localhost”.

Should we refuse to document such things because they’re not in well-known open source codebases, or have otherwise not passed tests of goodness?

It’s not a rhetorical question. Given that people are extending the protocol outside of the IETF or any other formal process, in order to solve their own technical and business problems, it makes sense to ask ourselves periodically whether we should be encouraging them, trying to stop them, or something in between.