Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-extended-error

Donald Eastlake <> Sat, 24 November 2018 04:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9DE5F130EE3 for <>; Fri, 23 Nov 2018 20:57:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 kcRXbF6tM32w for <>; Fri, 23 Nov 2018 20:57:40 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 213F4130EE2 for <>; Fri, 23 Nov 2018 20:57:40 -0800 (PST)
Received: by with SMTP id g85so21014602ita.3 for <>; Fri, 23 Nov 2018 20:57:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SaYuB6/ogVzSPB2hnWk8kWnxm73KQYOoFivhDQRNmuo=; b=VHGlJkmif+8kmvIJyt51w8iw8R55WiDqWfmNqDhDbDaBPFFhGfhD2pH7Da4quxepSs Oh7guPe0lZ/Lx8eialYsYV7MI/vW50n0gME2lt9tYE4iSVZ1sT9bUYI5SXENWH7wzcOp xz0mlkWAYSBo+oUMHRr94Uv+n3YsQjx29nZV0yRzCTcOeKenTZda3ncuoXwpHcbyd/Ll xSKPZ1LBnkVe4VwpccxNoqgfivOHAmojXpbF4qLYyRoJrxQjFQXA2rqSZHl6gLEsGohL M54erWyHLolU2islSOYLh3vELOL8ZZPXgAgZLdYimhDvAYK9uFFqUcyGSZlBTtpoEJU4 Xuwg==
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; bh=SaYuB6/ogVzSPB2hnWk8kWnxm73KQYOoFivhDQRNmuo=; b=jRnWLbi7zrWLiVWC74TSkkhhJtmvJvki3XdJuSI3T0gErQorlwVBZchFLVbAGNxlS7 gNd1sa1scYyW2UYBDq+Bey4anucKtmQx6TGQX5DG3cQzO4QhJ/q1xjikdC1dT9FOe6KS myM00JRd964wRrUh4EG2FzTRWo7tXiRxb7zFQr4EyvkvMmAQB5Y+Ovv6PdDr/+DzmYfd G+9MghSGTA3KbF1X3NXnwyEGyydFAJoMf7JZLEBsgNElpQ40uOWLCDoZ/ikgXtDPZ9p9 9iIaw+sBhd5v63E5GerlfLSTYvYhxgWBZAmO6KKjnK4L6Tt9F6tiuLA4oiA60fsXbZWL suqg==
X-Gm-Message-State: AGRZ1gLbQ9bThvjgnCcJgm2rXVOICjOKBdMc9B25H4/9AqAoO4otPC7P euPXcfRd0FdA0EJuSDr+AznAyFAj4mTANks8cOfX3Q==
X-Google-Smtp-Source: AFSGD/Uru74ssDxBd+Jygvog99vLcbxm9tPjG0TTzVHM8OQZt3eFML8YzLh8EggfxZebqcYZNhrlu0km63kNXcjHD10=
X-Received: by 2002:a24:ac02:: with SMTP id s2-v6mr14882063ite.105.1543035459174; Fri, 23 Nov 2018 20:57:39 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Donald Eastlake <>
Date: Fri, 23 Nov 2018 23:57:27 -0500
Message-ID: <>
To: "<>" <>
Cc: Ray Bellis <>, Paul Vixie <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-extended-error
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: Sat, 24 Nov 2018 04:57:42 -0000

I like the Extended Error Code using EDNS idea. This was effectively
what was done with TSIG and TKEY that have an expanded Error field
inside the RR. However:

 >> I don't see any reason for the complex two-dimensional table to
new error codes. Given that 16 bits is available for "INFO-CODE"
(which I think, to follow the DNS nomenclature used in TSIG and TKEY,
should just be called "Error"), I don't see why these extended error
codes, which provide more detail beyond the top level Error code
value, can't be from the single unified DNS error code table. That
way, wherever you get a DNS Error code (from RCODE or the EDNS
extended error field or the TSIG or TKEY error fields or wherever,
there is just one table to look it up in. For example, you could
Reserve 4096 through 8191 for this purpose, which is probably enough
values :-)

 >> Since RCODEs are 4 bits, I don't see why a 16-bit RESPONSE-CODE
field is required. Even if you want to be able to provide additional
information for the 12-bit error codes of RCODE as extended by base
EDNS, there is still enough room in the previous 16-bit word which has
15 unused bits in it. Just move the RESPONSE-CODE up into the previous

 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA

On Tue, Oct 30, 2018 at 1:42 PM Paul Vixie <> wrote:
> Ray Bellis wrote:
> ....
> > FWIW, I really wish in retrospect that EDNS(0) had defined the extra
> > rcode bits as being for a _sub-type_ of the primary RCODE, i.e. SERVFAIL
> > is always "2" in those four bits in the main header, with the extended
> > field in the EDNS response allowing for more detail (c.f. this draft).
> >
> > Unfortunately with the newer RCODEs just being assigned contigiously
> > from 16 onwards that's no longer possible :(
> it was never possible -- we needed more rcodes, even though we now know
> we also need more detail on existing rcodes.
> --
> P Vixie
> _______________________________________________
> DNSOP mailing list