Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt

神明達哉 <> Thu, 16 November 2017 19:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AF14B12717E for <>; Thu, 16 Nov 2017 11:10:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TxBk-ycI7HQ3 for <>; Thu, 16 Nov 2017 11:10:57 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c0c::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 21E3812009C for <>; Thu, 16 Nov 2017 11:10:57 -0800 (PST)
Received: by with SMTP id o14so48582wrf.9 for <>; Thu, 16 Nov 2017 11:10:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=SzNzNMybR6TPVx1igclfmIuTAwfZjiYg+RnIkHsMMHg=; b=HlGU+US+wh29SYSHspQaB7Q7fqeLsgDE+NHW4BmfbmQN8HFasqYTzNyk5/7MHBJybK PwYe53+KfQlFdOlDE0CT4l4TMjZt/FeXJvFp1SxA1e9gu572/mDKQZZqUD76eLLza+sy jOUKS4+fqwVtJPTnPddX3ujpm9pvFobYSWSzwEo7teXd98qU874O3s2AiAQ9pSVR44cu uEk8O9Q/fLRFE4bAU6Ie/pGRXaP0yongS/jvn9+IvJutGrJ8owJoF8z6abMCMpdrMzmg pVPfJC/Eua7yz9R/djTbBobIAWsRwxBMP8MmbTqMwzvSWvwPPCDzwx91l7kn29csO8nD tnyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=SzNzNMybR6TPVx1igclfmIuTAwfZjiYg+RnIkHsMMHg=; b=WCCETKChOPCAkMgK1pdMvnb2AqCU+/yHjjF2HKEBHh7LZ7Yxr7cxv5EUAp0lCxouop 2yg/EtnILR6bqzO/jvG7+ROPp4k50GcpgyyVOZH+0s4zFIOQj8dZauBdPpEJ3oraxEvy jvtVUZ0l/gBqjz7gaB9q9LBwBweKagIDUu2mE5vDEkzGFiS+PqQhZbuAQ2la1iL0m/hg DVgWN3/U8ewsX6Q6o9KdPVbP7IQXM5HuYCELV1TNm5LGuzfg4oy8vcMQhheS5KmQQePH +tDtURxeRTxE6ocuFQZ47DDvqDS4yly3jxAYTvsBk3J00jGfDK4ylgNHItFhGF87k/ym /ZsQ==
X-Gm-Message-State: AJaThX4JexHCY2sQDZcDn3J/hAFMIUEHOQB5/VLtrqvZbgrLwfpt+7r2 m2WWOvZBsTWJ1IopPKje00jDIPQ/37lLAGM3MZpopXTy
X-Google-Smtp-Source: AGs4zMZrzyjQugbMyz1dZ0OPzCzTJReezzd5Ge/CWu6SDjIVlgfqAs1LtxTKrAdqn2y6w7Pk+quUn2QTON6T4xWozrU=
X-Received: by with SMTP id i40mr2534464wrf.124.1510859455493; Thu, 16 Nov 2017 11:10:55 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 16 Nov 2017 11:10:54 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
From: 神明達哉 <>
Date: Thu, 16 Nov 2017 11:10:54 -0800
X-Google-Sender-Auth: ZaAfvuqwNtx8yx15mTUq34UQPkM
Message-ID: <>
To: P Vix <>
Cc: Dave Lawrence <>, IETF DNSOP WG <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-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: Thu, 16 Nov 2017 19:11:00 -0000

At Wed, 15 Nov 2017 05:41:04 +0000,
P Vix <> wrote:

> >1) when the request explicitly signals it is ok;
> >2) when the request groks EDNS but might or might not understand
> >   a staleness option; or
> >3) in all cases.
> >
> >My current understanding is that you and Paul are of position 1, while
> >I'm at 3.  At first glance 2 would appear to be pretty nearly the same
> >as 3 as far as its permissive toward unaware clients, but
> >significantly it does at least provide signal you could still access
> >via protocol debugging (dig, tcpdump, etc).
> I expect you to implement 3. I expect us to document 1.

Realistically, I expect virtually everyone will implement 3, given how
this kind of feature is sold in the marketing context.  Open-source
reference implementations may implement 1 if it actually becomes the
standard behavior, but I bet any serious large-scale user of those
implementations will make a custom change to disable that part.  I'd
be sad about that, but that's quite likely to be the reality.

I don't want the IETF to standardize a bad practice, and in that sense
I'd personally prefer option 1 (or something that shares its spirit).
But, as an engineering group, if there's basically no chance to deploy
it I don't see a point of bothering to standardize it.

So, if we choose to document option 1, I'd like to know the plan of
this group of its deployability.  Is it that we optimistically think
that nearly all stub resolvers eventually (in 5-10 years?) support the
signaling option and enable it by default, and then server
implementations will gradually start honoring the standard (and until
then we'll just grumble about the deployment of non-compliant

JINMEI, Tatuya