Re: [DNSOP] Status of draft-ietf-dnsop-dns-error-reporting

Manu Bretelle <> Fri, 12 November 2021 06:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E958F3A12D2; Thu, 11 Nov 2021 22:42:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 tn03GCnXuUm4; Thu, 11 Nov 2021 22:42:43 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EFC5F3A12D1; Thu, 11 Nov 2021 22:42:42 -0800 (PST)
Received: by with SMTP id x19-20020a9d7053000000b0055c8b39420bso12550486otj.1; Thu, 11 Nov 2021 22:42:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YGxTA7LZLOXNu0t3A81CRIuhvdoTm/0pJ/SheAwUsTI=; b=Jf1hhSOi1CDuUm3x2URDwQoitkZdULGls+NB76K8nY98SJksYuW1+cw8xVXNYV6GTV uegWLBg2LYO2OFFN3d/gWNgeGbtWKfWgkE3rTAagjhuU+/IwKxMjHUw5GFHsdaP9IcYE 9+8WD31LMWROal/oD50tXlxxq7xRrxH7DCH8l4+3XUf+8s4ChPZ+UZKvt5E6mPWwL8pT QwvwbwrzlsvkepRatKaEBQbSzxsSm5yDecNVqX3868OrSgJl+IbACAUv6v+MNH8ur+u5 6ytCUQws3DvQQZSqVR9mcvCUsqGX7VVCWsjBpNBW/mWNAYqxHneXmDWLN6r2ewgjJLJq 55Qw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YGxTA7LZLOXNu0t3A81CRIuhvdoTm/0pJ/SheAwUsTI=; b=5v7xz1VNhm3URT70zLxK8TugKuNl4bL2l/aKn5R0Rx6hLUN152iLcenfI4nmtDjBmL smFkbEk84nm94Ue7qcZ+gRQZtjmMLdUvypQa19mIXk66g3J//3lhxwb1al+6pr0kmXAw grjdOHpQiV1wv2IlOqw9Gv9g4J333cU6wnVhCGXecojj583bI6lWyLCbuuzVibyU3Tfo KEVrIzl1YeBjCFUaA3IIk2xTwA1g3d1KoWm5GB52CalfuqIfi8TiDfY8oMR/b1vLZt6J acTZQ5vj7KSRg2nHI6d714cGgniWOn07vYZ4F7X3Y9YjMNoH8xqXgMYSpEpkBUSOiCAe Vu8w==
X-Gm-Message-State: AOAM532Wb0DgtiWCJHPU1rqvqwI/jAt+ddMlaOE37jsDK6tnQOAuFXdD PUh7gm1lT5X26H2T0TgBoBcBuOjcvgPe2xsWLoU=
X-Google-Smtp-Source: ABdhPJxMakXEuzdLQjdcCO78s0EjhuF5pBvPdAz9heSLng5hmO1eGH1zfpwHOQsdFafb5Ai7wQCs1AxFNfOBAlo3Tzk=
X-Received: by 2002:a9d:67c1:: with SMTP id c1mr10808062otn.299.1636699360234; Thu, 11 Nov 2021 22:42:40 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Manu Bretelle <>
Date: Thu, 11 Nov 2021 22:42:29 -0800
Message-ID: <>
To: Roy Arends <>
Cc: Matt Larson <>, dnsop <>, dnsop-chairs <>
Content-Type: multipart/alternative; boundary="000000000000f88f9405d091c392"
Archived-At: <>
Subject: Re: [DNSOP] Status of draft-ietf-dnsop-dns-error-reporting
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: Fri, 12 Nov 2021 06:42:50 -0000

Hi Roy,

I like the idea of an out-of-band error reporting and therefore I like the
proposition of this draft.

One of the things I have a hard time visualizing though is how this could
be used for more than reporting DNSSEC specific errors. With the option not
being signed in the first place, it does not seem that DNSSEC is a
requirement to be able to leverage this functionality, hence it would be
great to think how we can make this work for more than DNSSEC-only errors.

As it is, the requirement for the EDNS0 option to be in the response, while
it does offer some properties such as controlling sampling rate…,
essentially will prevent any report of answers which are not properly
formatted in the first place, or never received like when a resolver is not
able to reach any authorities for a given name, when resolver start falling
back on staled data, and possibly in the future, failing to reach over an
advertised encrypted channel… There is likely value for an authoritative
resolver operator to be able to get report for those issues too.

The title of the draft: "DNS Error Reporting" would let one believe that it
is a somewhat generic mechanism, but I don't think it is as is. Actually,
while DNSSEC is not named in the title/abstract, the examples in the
abstract are DNSSEC specific, the wording in the rest of the document
refers for the most part to "validating resolvers". Should this be a
"DNSSEC Error Reporting" draft? or a "DNS Error Reporting" draft, but then
the function of "validating" itself should be less emphasized? While a
validating resolver can report more type of errors than a non-validating
resolvers, validation is not a requirement to be able to report.

On Tue, Nov 9, 2021 at 3:07 PM Roy Arends <> wrote:

> Dear WG,
> Change 3) There as a lot of descriptive text what implementations should
> and shouldn’t do, and what configurations should and shouldn’t do. This was
> found to be overly descriptive and pedantic, and has now been removed.

I see that the security consideration about not reporting errors from an
encrypted channel (over a supposedly unencrypted channel) has been removed.
Wouldn’t it make sense to leave it in order to avoid leaking traffic for
queries that were not previously visible on the network? Possibly requiring
than an encrypted channel (equal or stronger, for whatever definition that
may be) is used to send such reports if needed? This would also make sure
the mechanism is going to work once the ADo* mechanisms are ironed out.


> There was a request to put the markdown version of the document in GitHub.
> This has now been placed here:
> New version:
> Diffs:
> Warm regards,
> Roy Arends
> _______________________________________________
> DNSOP mailing list