Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-extended-error-14: (with DISCUSS and COMMENT)

Warren Kumari <> Thu, 23 April 2020 18:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 37DF73A0E17 for <>; Thu, 23 Apr 2020 11:15:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, 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 kktvXI0GOtJx for <>; Thu, 23 Apr 2020 11:15:06 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 464753A0E16 for <>; Thu, 23 Apr 2020 11:15:05 -0700 (PDT)
Received: by with SMTP id h6so5565843lfc.0 for <>; Thu, 23 Apr 2020 11:15:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=WUvpspByFKsmU1prRJYndqSmCXU0Z/zuJuUwxl8vKo8=; b=AHF7P/zkcFtQTQ6kd1MvXJFPKajrFGepwGEwjGyMt5XUCWVqWK82xznazEPsfoN1Wv YEYUCKYzD+CgMfiYDUyIuXRrntkMmHUWU+YoxJQJI1nRBJ6GBw3qx+q1jatXji/QaX+u 0+K3rckvF65e66zgAbWRL6MkkA5VYV7U+zxQS5QWXWaPrklelLz7pzBCHTpoPAoCQCOq 2ImbnJ1plk8mK75xfqx6+uhJvOm4HwJqyK0x9+qRbGM2uR+FWYl+NXagarR5eORG/jzh vn+ox7kj8t8PtCkFr7Or+52w504ugPxVjTwaSLpP1jwXJevTHChXemMWm1FcT2L6Tm3M aSrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=WUvpspByFKsmU1prRJYndqSmCXU0Z/zuJuUwxl8vKo8=; b=cYp9N1VGhrvRrd87fXyi6ijPpbcfgRe5OVwOPTMnjed74ilGdrWmVp1vWEWQVyxDAm G1BNuaKneolb+2tkm1gy9Ub/ebfGl1Zz7Vw8z+kpnjXnR9EBZZleh3QPt+xe52+w1j+4 Txl2hsJrfmZlmbdC3JkErk+dc1hakrz7RDHi43YcQymOwpRDk86OeuEAIPTDtYf9p8K2 XGlkUvNNwGNSdbEEsOJw68Mp5XGikYf36ZF7Nae3rMEmvoP5JFJUurYjh9QCRYnN1QD/ bZ+za0tKiWHzWtsM1w9hX7lmcPqQeYlkRP7h/PBgXm5Ut9+eaWgDHOZqwrhhKSqpS4b5 9GLQ==
X-Gm-Message-State: AGi0PuZ1x4eF5AJCimyj76+hdOuxwlk0TgSLOdLYNoQ7s5eBvVJtXqch I8HNRydMog57cScPw2j8BlHM2LMci/28BsE7E8KggA==
X-Google-Smtp-Source: APiQypJSu8ivVbbuQCqF2IiRWNWLlPnviXDs091+sKs0+mdacDdB5ZPix/kPslqkqO0nUNOP0Xme/NPr09A82y3011s=
X-Received: by 2002:a05:6512:74:: with SMTP id i20mr3177209lfo.104.1587665703867; Thu, 23 Apr 2020 11:15:03 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Warren Kumari <>
Date: Thu, 23 Apr 2020 14:14:26 -0400
Message-ID: <>
To: Vittorio Bertola <>
Cc: Benjamin Kaduk <>, Tim Wicinski <>, DNSOP-Chairs <>, dnsop <>,
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-extended-error-14: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 23 Apr 2020 18:15:10 -0000

On Thu, Apr 23, 2020 at 5:04 AM Vittorio Bertola
<> wrote:
> > Il 22/04/2020 19:15 Benjamin Kaduk via Datatracker <> ha scritto:
> >
> > ----------------------------------------------------------------------
> > ----------------------------------------------------------------------
> >
> > Sections 4.16 and 4.17 have some discussion that suggests that the
> > respective extended errors apply only to the current "local hop" of a DNS
> > query, and thus should not be propagated by a resolver/forwarder as part of
> > a response.  If so, this would be at odds with the discussion in Section 3
> > that leaves such bhavior as merely "implementation dependent" (giving some
> > MAY-level options).  I'm not sure what the intent is, here, so let's talk
> > about whether there's anything that should change.
> Indeed, thinking at the possible use case for those error codes, it would make sense for the forwarder to forward them to the final user. Perhaps we can fix the language to make this clear? E.g., instead or "the server being directly talked to", "the server actually resolving the queries" or something like that?

Hah! Wes and I spent some time yesterday trying to figure out how best
to answer this, and ended up with two ideas:
1: just remove the "being directly talked to":
"The server is unable to respond to the request because the domain is
blacklisted due to an internal security policy imposed by the operator
of the server being directly talked to." -> "The server is unable to
respond to the request because the domain isblacklisted due to an
internal security policy imposed by the operator of the server"
or 2: some very convoluted text...

In my view your proposed text is simple, clear, and addresses the issue...

Thank you!

> --
> Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
> Office @ Via Treviso 12, 10144 Torino, Italy

I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.