Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-error-reporting-00.txt

Roy Arends <roy@dnss.ec> Mon, 25 October 2021 23:57 UTC

Return-Path: <roy@dnss.ec>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D59F3A0E9B for <dnsop@ietfa.amsl.com>; Mon, 25 Oct 2021 16:57:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dnss.ec
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BA6d8jhig_-d for <dnsop@ietfa.amsl.com>; Mon, 25 Oct 2021 16:56:59 -0700 (PDT)
Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 158F53A0E0E for <dnsop@ietf.org>; Mon, 25 Oct 2021 16:56:58 -0700 (PDT)
Received: by mail-qt1-x832.google.com with SMTP id z24so11910204qtv.9 for <dnsop@ietf.org>; Mon, 25 Oct 2021 16:56:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dnss.ec; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YdrKs+ECNwyqbr7Aoj1oBlhKnnPK33ZlhBGx/CNBV9U=; b=RVwjH73OMIAymcEO+7hON2y+9t/OVEEe7zM/t35u/W7yNnIW1qdM5Zw2itQliR2D3r qXGczrPLNc9TGiZIiwID32wXX5IHl8ixPI1yFZVvC82V3dXCfLzbA7KuU8RyiSB8p+vZ uIN6nYzQk0XINw58T9UQBmImDw/GOsambzHOU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YdrKs+ECNwyqbr7Aoj1oBlhKnnPK33ZlhBGx/CNBV9U=; b=A58VDBUQRkzb2sVxLg8TBFLhVrPwALRcvo8qf5q5uyX8TXe5Paf6KveBNh2/2kHvmq oHRN9cXSFNlHlQiqe84LUNyHBssUn4Ia22pvOg8MTE3xNagAykDRv3kivQ3eqqxI0oW6 V/DNRvIoT9tP7Qt7N9ZxB+T03+b2+Ntf6hUqibOv8vnMzERjfKZqKBO7UlhurMX4D6xx PJz2rz+8B3QJsqwKmxpWne/3kKqBUJK80sqdyUD6vpx48vsKybHqLW49Uag7cWBJV+hr JMjHM06whsV0XDB117wSb/enMRjxYRikbWV/SMoKAxxz90C3JG0sv+3AN5U/J7b0GXkT J1nA==
X-Gm-Message-State: AOAM531+20cRbObdHMYXmEWgMuCLjkBxDh1SwIMvRjKG9AOCoeYiPD5d ZNBTsAQ/5XHZ7ZldEsevi857PFUDNgkWjg==
X-Google-Smtp-Source: ABdhPJz4TBA/+YzC6f2P0peH0eFh512CHrHfONGwWcfBm8idagMQ+Bkwd+DQvlNu5Q23wYwf8TNoBQ==
X-Received: by 2002:a05:622a:13cc:: with SMTP id p12mr21313015qtk.227.1635206216218; Mon, 25 Oct 2021 16:56:56 -0700 (PDT)
Received: from smtpclient.apple ([88.81.139.247]) by smtp.gmail.com with ESMTPSA id c3sm4487139qkp.47.2021.10.25.16.56.55 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Oct 2021 16:56:55 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Roy Arends <roy@dnss.ec>
In-Reply-To: <f9f4dcfc-3bc4-3859-7aab-568c3f5d0a29@nic.cz>
Date: Tue, 26 Oct 2021 00:56:53 +0100
Cc: dnsop@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <367EA8BC-BD5E-4363-A3FC-D5F3AF41305E@dnss.ec>
References: <161953482575.7668.10479553059119648994@ietfa.amsl.com> <f9f4dcfc-3bc4-3859-7aab-568c3f5d0a29@nic.cz>
To: "libor.peltan" <libor.peltan@nic.cz>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/P7B6mD2dplMiUVh4Q-g21R7IvtU>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-error-reporting-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Oct 2021 23:57:10 -0000

> On 20 Oct 2021, at 14:14, libor.peltan <libor.peltan@nic.cz> wrote:
> 
> Hi all,
> 
> although for me, as an implementer of an auth server, it's not too important, I'd like to ask for clarification regarding the foreseen reporting domain(s) setup in the (usual) case of many secondary auth servers.
> 
> The draft says: "Each authoritative server SHOULD be configured with a unique reporting agent domain."
> 
> I see two possible error situations:
> 
> 1) the zone itself is wrongly signed, so all secondaries share the same error
> 2) some of the secondaries respond wrongly from correctly signed zone, so the error is slave-specific
> 
> IMHO the case (2) is far less common. And the case (1) doesn't require per-secondary reporting domain, just per-zone.
> 
> Is it really recommended (in capitals) that the zone operator prepares extra reporting domain for each secondary around the world (it can be hundreds)?

The domain owner may have contracts with more than one operator. The operator may operate many authoritative servers, which not all serve the same set of zones.

If the reporting agent domain is unique, the erroneous server can be pinpointed faster. If all auth servers for a domain have the same reporting agent domain, the reporting agent knows there is an error, just doesn’t know where.

> If so, it can cause a disclosure about which secondary the answer is comming from, dunno if some zone operators are not willing to conceal this.

In that case, the zone operator doesn’t have to deploy EDE reporting, right?

Roy

> 
> Thanks!
> 
> Libor
> 
> Dne 27. 04. 21 v 16:47 internet-drafts@ietf.org napsal(a):
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Domain Name System Operations WG of the IETF.
>> 
>>         Title           : DNS Error Reporting
>>         Authors         : Roy Arends
>>                           Matt Larson
>> 	Filename        : draft-ietf-dnsop-dns-error-reporting-00.txt
>> 	Pages           : 12
>> 	Date            : 2021-04-27
>> 
>> Abstract:
>>    DNS Error Reporting is a lightweight error reporting mechanism that
>>    provides the operator of an authoritative server with reports on DNS
>>    resource records that fail to resolve or validate, that a Domain
>>    Owner or DNS Hosting organization can use to improve domain hosting.
>>    The reports are based on Extended DNS Errors [RFC8914].
>> 
>>    When a domain name fails to resolve or validate due to a
>>    misconfiguration or an attack, the operator of the authoritative
>>    server may be unaware of this.  To mitigate this lack of feedback,
>>    this document describes a method for a validating recursive resolver
>>    to automatically signal an error to an agent specified by the
>>    authoritative server.  DNS Error Reporting uses the DNS to report
>>    errors.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting/
>> 
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-dnsop-dns-error-reporting-00
>> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-error-reporting-00
>> 
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> 
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop