IETF Logo Mail Archive

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting

Roy Arends <roy@dnss.ec> Tue, 20 June 2023 21:20 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 3B51FC152577 for <dnsop@ietfa.amsl.com>; Tue, 20 Jun 2023 14:20:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.096
X-Spam-Level:
X-Spam-Status: No, score=-7.096 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8piFgjMOtSy4 for <dnsop@ietfa.amsl.com>; Tue, 20 Jun 2023 14:20:47 -0700 (PDT)
Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92029C14CE3F for <dnsop@ietf.org>; Tue, 20 Jun 2023 14:20:46 -0700 (PDT)
Received: by mail-qk1-x72e.google.com with SMTP id af79cd13be357-763aba07271so136773985a.2 for <dnsop@ietf.org>; Tue, 20 Jun 2023 14:20:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dnss.ec; s=google; t=1687296045; x=1689888045; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=yCksIo+z21EpTAr51BTgcs+oxlQem2/aPJjp9DtXJNw=; b=IwEKKDR4bHpRNr7Cu/r1QNWc9lEkpaNYSIJ78QSTVVB/x1fS1HcPyhhLtrcAfRJAU0 +CrtukRuDDkf5eCYyf9iqmXCW2A+O4nlJLSmtBYQABkd3dyQ3fo+oYFAN5Z0mh7wx0Yt KBJJHgT/p4LFT5Qvobz1/6Lxx0YaKnJ63JZq8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687296045; x=1689888045; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=yCksIo+z21EpTAr51BTgcs+oxlQem2/aPJjp9DtXJNw=; b=Okyiuy+vCWBw/x7lpoEoGnaFCmTskuBGmEAbcrYI2RQxdSIh8NuT10uSLIQVJr//n6 z6rKlA0h7Rs43IUn7q5xJ467ISHUQ56SqOrcPNLFxw/h6VgVDyZyzw9C7bPZ3SmrnBn1 Xj6LEV1Zr9yAPsyb8J1h/BaGdyvwY521tKVz4GI8lmvQjU5ryPzjGIWb03xYjF6xFFX7 b4Znk60e9BaWrSGWSq6wkZlPtSewQ8p8tbGGRc93skCGsxvEqGyPOujG4Tyt8XOLCXWc M/Ut8doWX9RYmSzlQaO33TMSya0YXRfkSY9aUzmJvV/PWMnnBBUh0yVl1fj1iiqEFNtL T2Vw==
X-Gm-Message-State: AC+VfDxd5MOvN04oSx0AmYYW2Mfiw11bg2lRIn4Yzu/1f6KRvsb1l5nZ 8vHbgkGTooKcED2PQZ+/Wyls8w==
X-Google-Smtp-Source: ACHHUZ64AW6lTcPWq4YcPqdX+YMmZIdYr7ASfLhEhRrelml77Dx6nNKCqb8v/B6p671ymWcJARiCUw==
X-Received: by 2002:a05:620a:2890:b0:75d:4145:154e with SMTP id j16-20020a05620a289000b0075d4145154emr14439663qkp.65.1687296044991; Tue, 20 Jun 2023 14:20:44 -0700 (PDT)
Received: from smtpclient.apple ([89.33.15.144]) by smtp.gmail.com with ESMTPSA id pc21-20020a05620a841500b0075ca4cd03d4sm1524726qkn.64.2023.06.20.14.20.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Jun 2023 14:20:44 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\))
From: Roy Arends <roy@dnss.ec>
In-Reply-To: <CAKW6Ri6BnA1xpmQLpwepBDCZa=G0FnD-QtBqqskLc9NaOn3n8w@mail.gmail.com>
Date: Tue, 20 Jun 2023 22:20:31 +0100
Cc: Willem Toorop <willem@nlnetlabs.nl>, Benno Overeinder <benno@nlnetlabs.nl>, DNSOP Working Group <dnsop@ietf.org>, DNSOP Chairs <dnsop-chairs@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <62DB4990-C49F-46C6-9A72-EBFACFB835B4@dnss.ec>
References: <fa6ec641-0eab-dec6-2267-3ca818402812@NLnetLabs.nl> <49112d32-e0c7-0ee0-9bdb-b1379fc8e7ce@nlnetlabs.nl> <395A2004-803E-43CA-945E-F9C1EDE86F21@dnss.ec> <CAKW6Ri6BnA1xpmQLpwepBDCZa=G0FnD-QtBqqskLc9NaOn3n8w@mail.gmail.com>
To: Dick Franks <rwfranks@gmail.com>
X-Mailer: Apple Mail (2.3731.600.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/6Lk2hvt2ODM8t6MUlaqtQDhPulg>
Subject: Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
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: Tue, 20 Jun 2023 21:20:52 -0000


> On 20 Jun 2023, at 21:39, Dick Franks <rwfranks@gmail.com> wrote:
> 
> On Tue, 20 Jun 2023 at 12:21, Roy Arends <roy@dnss.ec> wrote:
>> 8
> 
>>> On 20 Jun 2023, at 12:14, Willem Toorop <willem@nlnetlabs.nl> wrote:
>> 8
> 
>>> I have one nit.
>>> 
>>> In the Example in section 4.2., a request still "includes an empty ENDS0 report channel". The third paragraph of that same section states something similar: "As support for DNS error reporting was indicated by a empty EDNS0 report channel option in the request". But Section 6.1. Reporting Resolver Specification states: "The EDNS0 report channel option MUST NOT be included in queries."
>>> 
>>> I believe the text in the Example section is a left over from an earlier version and should be corrected.
>> 
>> Ah, yes, I will remove that sentence completely!
> 
> WGLC is supposed to be a review, nit-picking and clarification process.

That is correct.

> Deleting that one sentence changes the meaning of the proposal from

No!

The change was from -03 to -04 and discussed in the WG IIRC. The specific sentence your refer to was a lingering oversight in the changes from -03 to -04. I have consulted many developers on this, and so far I had no push back. 

> explicitly querying the authoritative server for the appropriate
> report channel to a dependence on authoritatives attaching an
> (unsolicited) EDNS0 report channel option to each and every query.

No.

An authoritative server includes the option if configured to do so AND if it has the a non-null domain name configured as the reporting channel. It will then reply to each query. This is IMHO better than having a resolver include the option each and every time. Note that resolvers will ignore options that are unknown to them. 

> That is a fundamental change to the document, and certainly not a nit-pick.

This was an older change, though. It was indeed fundamental, but there was a thought behind this.

> I withdraw my earlier statement that the document is almost ready.
> Now, clearly it is not.

I hear you. I do not agree though, and I hope you reconsider.

Roy

v2.23.0 | Report a Bug | By Email