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

Ted Lemon <> Wed, 20 February 2019 14:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 831C5130F19 for <>; Wed, 20 Feb 2019 06:44:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 Kp1QAbKTP0hm for <>; Wed, 20 Feb 2019 06:44:02 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::441]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C278A130EA8 for <>; Wed, 20 Feb 2019 06:44:02 -0800 (PST)
Received: by with SMTP id h1so12011291pfo.7 for <>; Wed, 20 Feb 2019 06:44:02 -0800 (PST)
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=LrkMZ4EMjbQI57xmXvECFPSHauaU7M/eFMlNpy8GVYQ=; b=mAJ5uD4IOZGSsdx30kVFrkVFbajbGCKcZDazv6/qyTiBdbO37/i5ou8wNhMX1h9216 ILpI8GuI6yTIZM1GU2k+dK5O6tbGCAJSRsE7YpGGDZTIo0aM9pihqarHXwmBq8uSOrGG 2wg1aFzvJjZLN4qcZcbVS4sbzBRAn5fnzpzhncqfEXnhnMgFJBcfyCjK7aCRLg0B3qDY u4hBIWFr0306CcIaieCu/jPRgDsXpjCUTxW7cQZuGa823/N+8j2q1Qjrwh+gYonDpRw3 XUnD5PsyZ6bZp+ox4jeNGES/lbRaUV/4uDJsykFO1WOl4bb626hhUTeZZB4vRcR4TaxF WCJw==
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=LrkMZ4EMjbQI57xmXvECFPSHauaU7M/eFMlNpy8GVYQ=; b=Krr2U05BjOAb1sTs/7sOFSG7Xy1SOzzX7sVOKjIlwCM+dfWmAQWRLzM+5vCSPULVjY VJ2YjYgHbV0QyPoZ5YGORIysGXQDPZrCoNyauyNYsQOcIfk4KudgYpT9fArz9VGuIx78 KHWOiTvQxIae057I2J6UH6HAmO/kvr/BUV5BhRWtMYvpMPyQ67Vd/2a0WdoR0rdi75L1 FHLx3q1eRHCpCwAM7QTJHJBAfsBu4lWWDLJEneIb/QJ+TJYryB1m3fo/zUexESw0jtXS eCZk3KtaQK6pqwUY7YnYa7TGeiVXzpXZlJP/GnR+7kZHadQ6Bg2hDFflll3IrESEEzTU mbNA==
X-Gm-Message-State: AHQUAuZlrJU+3kxqyOcRjAc698y0DnK3g48Gy/zHeE5vSZnOP/KK+VOD skYlmwPKS4HBtM+4G6R4sULSrYQfZObKog==
X-Google-Smtp-Source: AHgI3Ialicj9XA/dsQEG4XxiBKksaodOKzcDA7o7oXOBkEmzSwApyfuYxE3jw7jEPNrjIyfcSWISDQ==
X-Received: by 2002:a63:1266:: with SMTP id 38mr20195868pgs.388.1550673842029; Wed, 20 Feb 2019 06:44:02 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id u127sm25484583pfu.165.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Feb 2019 06:44:01 -0800 (PST)
From: Ted Lemon <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_42A49C31-3476-4F52-92F1-30CC0FD92690"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.2\))
Date: Wed, 20 Feb 2019 06:44:00 -0800
In-Reply-To: <>
Cc: Paul Wouters <>, dnsop <>
To: Joe Abley <>
References: <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.104.2)
Archived-At: <>
Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pusateri-dnsop-update-timeout-01.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 20 Feb 2019 14:44:11 -0000

On Feb 20, 2019, at 4:51 AM, Joe Abley <> wrote:
> The crux of the use case seems to be that it is commonplace for names in the DNS to exist for short periods of time and that for some applications a name that overstays its welcome can cause an operational problem.
> While I can understand the philosophical desire to complete the UPDATE specification so that it is possible to engineer around this scenario, I don't see the practical application. The existence of the requirement in the first place seems unproven (at least there are no obvious examples given); the scenario in which the purported operational problem arises seems likely to be rare; workarounds surely exist and, really, the damage in the event that the stars align and a temporary name does persist seems very low.
> If the goal is to try this out and have no impact on existing implementations (e.g. there is some side code that is imagined that will poll a transferred zone for TIMEOUT records and do local UPDATEs in order to remove RRSets that should not be there) then all that is really needed here is a code point for the TIMEOUT RR. The existence of the draft is nice since documentation is good, but I think "experimental" would be a better target than "standards track". It's surely possible that this mechanism will solve some as-yet unnoticed, large-scale problem and will one day be considered essential functionality, but I don't think we're there today. There be camels.

The goal of this is to automate name publication for situations where this is desirable.   You’re probably not going to use this for your public servers.   See <> (expired, but we’ll be submitting an update soon).

I say this not to specfically support this proposal, which I think has problems, but simply to point out that there is an itch here to scratch.   I don’t think this is something that we need in every different kind of DNS server, but something like this could definitely be useful in some operational situations.   Of course it can be done out of band, but there’s something to be said for keeping all the state in one place.   I don’t have enough operational experience with this yet to have formed a preference.