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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4970A127148 for <>; Fri, 24 Aug 2018 06:22:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 lkZ6_ICzTrOi for <>; Fri, 24 Aug 2018 06:22:14 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1D857129C6A for <>; Fri, 24 Aug 2018 06:22:14 -0700 (PDT)
Received: by with SMTP id t5-v6so10073531qtn.3 for <>; Fri, 24 Aug 2018 06:22:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=o6NinGD10Xu7/fLRjO7f74meYZwBG/PyPZKvWujyNC8=; b=p2iy4ni5ypBtbeRIuOTe24qJefZM3e7G9/SdMA60k2ymkMx7gqZjpqc8rSLmyzTvkU 4rwu4nM/LssJl1+1OjEqVzkIE9K1Y27kLS1heZkNLHTNsFCr+le2lgIFKks1HFx2yVXo TXniB9RuFhI5UVkVGYhEQZcvr+bNnMwR17lUVW1qtnCUKi/7BKaMtEXigNX7jl7Mrs5G DuKOaYgsUF+8MLUzCH1ElW+VOU5hOm8BaQ4azIbbHF/8TtMntbpqF13PLf7Uxr2Iteza oKQB2XE3I9YbiaAsHiLUgq6wqNPrLXn5g1mCfA8oDvT5B4FQMOj4dHWpdrurR5WILeD7 4n9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=o6NinGD10Xu7/fLRjO7f74meYZwBG/PyPZKvWujyNC8=; b=SDVII2q23Zdc963TXvN74Bli2XqJlR0CYfxjHk+jqruWM9efdv2F1gLBMn68Bbvq8r XkI4/v5AHyZ10COAIriRhb2XP5pcR4fovRxK3aKV4dJDUT/b7blyMU5gdXDkhutjBIMx roFD4iUsYTXOF9XI3ZgP8ms2Po6+dXTPBbYAS03LJd2JlJ0AORkkA1S55GvZd4kJp9Z6 fBbmiOizoCYM7awI02TU5zIj2xKu2jSzlqQWgh0Di947t57ST1qIti4LCocHU+xatxe8 kU4g2c3PzV8mFyNCbpw2GUul4Qv7vUKT0/AKw6d1NK/AV0oRf3QKxdosPmFrQgKGdcKU P9fA==
X-Gm-Message-State: APzg51CWKvApR8P5qiws0RZuCH3GccgPerJps9qCVYxRbQykvLE4CVNo sSmfr1wXMe04gE/5GYf10gZW6pF4SZQ=
X-Google-Smtp-Source: ANB0Vda3QKG3pVvJ/bO/81xCjCjYpWXL+kTSTKEq2IsevLllRMSq5OoMcB6R09LCydy4JXAFtePH5g==
X-Received: by 2002:ac8:2974:: with SMTP id z49-v6mr1632711qtz.149.1535116933104; Fri, 24 Aug 2018 06:22:13 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id f53-v6sm4999613qtk.40.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Aug 2018 06:22:12 -0700 (PDT)
From: Ted Lemon <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_198E6BD0-07D5-4B9D-BD16-62FD0C58DB2B"
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.38\))
Date: Fri, 24 Aug 2018 09:22:11 -0400
In-Reply-To: <>
Cc: Tom Pusateri <>, Tim Wattenberg <>, dnsop WG <>
To: Paul Vixie <>
References: <> <> <>
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:22:16 -0000

On Aug 23, 2018, at 9:23 PM, Paul Vixie <> wrote:
> <>
> the IETF DNSIND WG rejected this draft on the basis of its complexity. the idea of a zone having timers inside it, for self-modification, was just a bridge too far at that time. given what is now called "the camel" i think pendulum has swung _well_ away from that point of view, but is now in the process of swinging back. if i had hope, i would submit DEFUPD again, exactly as it was in 1996, because it still deftly threads the needle posed by UPDATE. your needs may differ.

I think that defupd is the core of a good idea, but it's more complicated than it needs to be.   Another way to accomplish the same thing would be to have an RR that just contains an update and a time when the update is to be done, hanging off of the name to be updated.   This could be included in the DNS update that creates the record, or created automatically by the server based on the update lease EDNS(0) option.

IOW I don't think there's any need for a new DEFUPD opcode, but the idea otherwise ought to be considered alongside Tom's proposal to see which one we think is easier to specify and implement.