Re: [DNSOP] Fwd: New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

Ted Lemon <> Fri, 24 August 2018 13:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6AF9C130E2B for <>; Fri, 24 Aug 2018 06:11:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 d4H6Vt1vboX7 for <>; Fri, 24 Aug 2018 06:11:32 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4B1AA129C6A for <>; Fri, 24 Aug 2018 06:11:32 -0700 (PDT)
Received: by with SMTP id c1-v6so3446327ybq.5 for <>; Fri, 24 Aug 2018 06:11:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=J9AVavwJUtRSSMT+NIFeIsDSv4XaVTXz9kB/OzgiQv4=; b=HbNZMOix/1+DIdyWektAGONfFOzgFEH5VtR2pcm2be/1N6AFpABNBytyVvrpKotCqx VOU+wFWYz2loRowATDdgninerfKt9L3CafzN7X6oUJ/FG5wTKD3o4XJN3UZEu7EaqBi5 WPYP3HdYbs1SVxBZ2MSMQ07tNu06uYTTdtkv0BLsORxJkxz9ps4tPmopXEk6TAzz0EZK HK3jLLMKk0pmooYxHInCaAwFvvpcA/HH2hqtbf3tKPVgKJTYDUmMHPtsilhY9HKuBFYZ mghTIPYO+lYU81nkRG9G6a42qR5dudQnuBQzCd9hqf0uE09o/41IcK0VEQEOCbOL9S4G JxzA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=J9AVavwJUtRSSMT+NIFeIsDSv4XaVTXz9kB/OzgiQv4=; b=F0kPZs88fDGVkYRWnvyTxxvoE+YuxgdqS1JHw/NSHvbTjr1+MWC1fy550xEeMxjjpB K8NP8yC23oCsksGIiYsiUDB1PmYujpM7YlFO2bS6/IGhCRk1azfQi6DH7+wfXl1M4XUl JaA0DwkR8GIkcdBnUg9ZMIs3lC+9MugQdtgUyApedw4d7LDOAKbDfn0/6x/QF6YquOeN GoNvMkjnIdnX57mrW9+xYNuY7wKrQF148Xg+SmKbZ7snarAKudg0CKoKMY3Aa+vz0D33 CLOtI9hyBYtSlkSdpTi1o0e0GUM8C2ZB+dd77egVEfv2o50JPk7+/XHPfUsGM75rzbxf efvg==
X-Gm-Message-State: APzg51B+tF8sKqNrrWNiWWCoQgPqmDLqE7ElUCBjpJ+0NWsN81dNFdc4 jE9o+aE0vtoS+36pIspSKBbptQ==
X-Google-Smtp-Source: ANB0VdYJxN7ZXfLD4NJxba0NbLz+uwbGPWcpwUp89WIw614mm7zlv+z1B42dqdMAjn2jggmJizq2vQ==
X-Received: by 2002:a25:14c4:: with SMTP id 187-v6mr930323ybu.220.1535116290947; Fri, 24 Aug 2018 06:11:30 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id n187-v6sm6057319ywn.76.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Aug 2018 06:11:29 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.38\))
From: Ted Lemon <>
In-Reply-To: <>
Date: Fri, 24 Aug 2018 09:11:28 -0400
Cc: Paul Vixie <>, dnsop WG <>, Tim Wattenberg <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Tom Pusateri <>
X-Mailer: Apple Mail (2.3445.100.38)
Archived-At: <>
Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 24 Aug 2018 13:11:35 -0000

On Aug 23, 2018, at 11:44 PM, Tom Pusateri <> wrote:
> An RRset isn’t granular enough because the components of the set could come from different clients with different timeout values.
> Therefore, a unique identifier is needed for each record. The hash provides that unique identifier since it is calculated over the entire record including the unique RDATA.

The hash stuff seems like a premature optimization.   I can think of two other ways to do this: either just send the contents of the RR, or use an index into the RRset and define a sorting order.   Bearing in mind that there's no reason for any server to store this data internally as anything other than an additional tuple in the RR itself, hashes may be the least efficient way to implement this.   Remember that for zone transfers, either you transfer the whole zone, or you transfer the differences, and in either case the zone contents for any zone serial number should always be the same.

Another question to ask here is, what is the application for this?   If it's just for DNSSD Registration, then it might be better to implement it in a less general way.  It would be worth scoping this before saying that it has to be done this way.   When Stuart and I talked about this, we had a much simpler model in mind; your model is certainly more general, but who's the customer?   I'm not saying your model is wrong, just that we ought to discuss it explicitly.

If a zone is signed, are the TIMEOUT records signed?