Re: [DNSOP] The DNSOP WG has placed draft-salgado-dnsop-rrserial in state "Call For Adoption By WG Issued"

Peter Thomassen <peter@desec.io> Fri, 28 May 2021 21:03 UTC

Return-Path: <peter@desec.io>
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 4C9553A35A6 for <dnsop@ietfa.amsl.com>; Fri, 28 May 2021 14:03:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=a4a.de
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 agVnnt7xaQ4j for <dnsop@ietfa.amsl.com>; Fri, 28 May 2021 14:03:04 -0700 (PDT)
Received: from mail.a4a.de (mail.a4a.de [IPv6:2a01:4f8:10a:1d5c:8000::8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C0363A35A5 for <dnsop@ietf.org>; Fri, 28 May 2021 14:03:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=a4a.de; s=20170825; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=2uIsQvHcQmOa4VWCNmST2PUi5BbnKzo59KIWfCDniTI=; b=cwow1g5wgiW9RnHJ/I1vbbjKeK /ShU4cnm/tlueiwLmKxCtsJ15g4moijRcy9VDdsdiVuHAvlqBeV/nzvy9Jktj38TycMKdZbj3YlWM 59vKcYdqpamGThiUwRx9YsXTbPKKgEYTlow/sM6iyMYVGFShOjZs8apQqdMHsbHwXfa3d+1LmkxxT wmTK7ceu0FuFyMZbv3yYGT9RdnVRZFfBV1le6dbkezIRdp0N49ikTbai1HUMeiEHWKD6Tamn4Wrwb B3l+v8HSZHzqzpMuhQafd83boKuRzFksy1uwCbrFnW7EOAwg7c8PjUwj5LiZVFPmrquV9Z/zEEohI NdcpEhHA==;
Received: from ip5f5aec6d.dynamic.kabel-deutschland.de ([95.90.236.109] helo=[192.168.1.171]) by mail.a4a.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from <peter@desec.io>) id 1lmjdB-0007gj-9l for dnsop@ietf.org; Fri, 28 May 2021 23:02:57 +0200
To: dnsop@ietf.org
References: <162221199604.5432.8913611760873877465@ietfa.amsl.com> <c8beea2f-90b6-f005-f137-df47b8dead4d@desec.io>
From: Peter Thomassen <peter@desec.io>
Message-ID: <eb0e25f8-1432-5055-a004-0ec14311a300@desec.io>
Date: Fri, 28 May 2021 23:02:52 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1
MIME-Version: 1.0
In-Reply-To: <c8beea2f-90b6-f005-f137-df47b8dead4d@desec.io>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="IQh88D5ecjhciYcBeafrSoKWuogBFwq8d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/TteIcXrCVOQ_j7IZCRRJ1G2wacg>
Subject: Re: [DNSOP] The DNSOP WG has placed draft-salgado-dnsop-rrserial in state "Call For Adoption By WG Issued"
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: Fri, 28 May 2021 21:03:09 -0000

I just discovered the related thread that started in January (when I was not yet on the list) and discusses most of this. Apologies for the noise.

On 5/28/21 9:27 PM, Peter Thomassen wrote:
> Hi,
> 
> I like the idea of having a way to add provenance information to responses. However, as with all new proposals, I think what's needed is a careful analysis of alternative ways to achieve the same goal, then an assessment of what's the best approach (which may very well turn out to be RRSERIAL).
> 
> 
> Some thoughts on this (some may be new, others not):
> 
> 
> 1.) multi-qtype
> ---------------
> With the proposed extension, we get a response for one and a half queries (whatever was asked, plus a piece from the SOA record).
> 
> The same thing could be achieved with some generic multi-qtype query method. Ray wrote a draft for this a while ago: https://datatracker.ietf.org/doc/draft-bellis-dnsext-multi-qtypes/
> 
> This would facilitate
> - the debugging use case,
> - other use cases (as explained in Ray's draft),
> - enable DNSSEC validation (if requested; note that this is regardless of whether DNSSEC is useful for the debugging use case).
> 
> If we now introduce RRSERIAL and then end up introducing multi-qtype one day, we'd have two methods for this. This would not be a desirable state (unless there is some extra advantage through RRSERIAL).
> 
> On a related note, multi-qtype would also allow you to use the same method for other kinds of debugging in the future. For example, you may want to look at the response together with a ZONEMD record, or whatever else may help you debug.
> 
> 
> 2.) NSID option
> ---------------
> The draft says, RRSERIAL helps "recognize the origin of an answer" (supposedly when secondaries are out of sync).
> 
> There already is a way to do that, using the NSID option (RFC 5001). It works as a part of another query, so no separate query is necessary (dig +nsid ...).
> 
> The question here would be why another method for discovering the origin should be introduced.
> 
> 
> 3.) Versioning
> --------------
> The draft says that RRSERIAL is useful for "associating this answer with a respective zone version".
> 
> We (deSEC) ran into problems several times because we relied on the serial as a version indicator.
> 
> One of the issue was the following: when customers created a zone, made a change or two, then deleted the zone, and created it again. As we don't keep deleted states, the serial for the recreated zone started counting from its default value, and then often ended up lower or equal to the serial of the old zone last seen on secondaries. If this sequence happens quickly enough that the secondary didn't see the deletion, weird things happen.
> 
> So, using the serial as a version indicator may be misleading. That's not to say that it is not useful; my point is rather to ask whether it is wise to introduce more of it. I would expect that once it is there, automation tools will start using it, and edge cases will be forgotten.
> 
> 
> Thinking about multi-qtype again: Ray's draft has it such that multiple qtypes can be queried for the same owner name only. That means that SOA could only be queried in an apex query. The RRSERIAL method does not have this issue, which is certainly favorable.
> 
> 
> Cheers,
> Peter
> 
> 
> On 5/28/21 4:26 PM, IETF Secretariat wrote:
>>
>> The DNSOP WG has placed draft-salgado-dnsop-rrserial in state
>> Call For Adoption By WG Issued (entered by Tim Wicinski)
>>
>> The document is available at
>> https://datatracker.ietf.org/doc/draft-salgado-dnsop-rrserial/
>>
>>
>> _______________________________________________
>> 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
> 

-- 
Like our community service? 💛
Please consider donating at

https://desec.io/

deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525