Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt

Joe Abley <> Tue, 05 March 2019 17:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A84D8130D7A for <>; Tue, 5 Mar 2019 09:50:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CSnORt_dMLHS for <>; Tue, 5 Mar 2019 09:50:46 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E8BBA130DD8 for <>; Tue, 5 Mar 2019 09:50:45 -0800 (PST)
Received: by with SMTP id m137so5392287ita.0 for <>; Tue, 05 Mar 2019 09:50:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Rjg5ZGOkTp21J9r9qrjA6UUJTGbSVEvi1+RapKkR6+0=; b=ZaYEgXqk7VYYAHB6BCu9i45WvOnux9GgbuHk3dMW4zWUr2Fuz7WZLaa20+d32FmgDb OBDACxa00QUOI66QgXiUZt0viNDYslwbHUPcMVMcoW2SqhLYak/BHUlZvUgXqkeaZiix ewI2sQo0U8fJ6/8D7ImfwjCsP4hqZmHH1hv1k=
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=Rjg5ZGOkTp21J9r9qrjA6UUJTGbSVEvi1+RapKkR6+0=; b=t8ckJoKoFeZZCYOOLok+hmS6vQ3Zu815bFQR+Rz+9tv6gUuYp9NWfIrujM0zynMYS/ FCP4zh7daeQStPdWwxFoxMvjyTwVgFU4BiGHZw2w56jvxS6Kf41yp4InA6rbChMStnGh Ld8sZTtQxA1MBD6LVykoXmMA6SexdGimdmgQAGdp91FlsLGRCYHXMtcDBHxfki8CGZmT W838RDxeM1smZ0fznt+NKxApaMUUdyevppsdl8oy3MsoMJgL+9z9D+4qA0EZH3mgfpYs WFuuk/ncEB9Rm76l2VZXfh40kb+2neXrYTxRyD8Cs1F6v2z8HIwlaU+FfbjToBPSslZP hXSA==
X-Gm-Message-State: APjAAAVSEiLXF6ryTnmoxRVYbY+kFJSbBezL7rGwuGv+dwJ7LcYmFzMz 9ne9rh11MiWNBiAoCKKfZ994sQ==
X-Google-Smtp-Source: APXvYqykFxNuKn5At+4ZtovecEutXn2PkpmUHgXYaiyZFCf7BlLArxU7Wm5dwSfEsLucOSo6JEmFlQ==
X-Received: by 2002:a24:6981:: with SMTP id e123mr3337053itc.106.1551808244835; Tue, 05 Mar 2019 09:50:44 -0800 (PST)
Received: from ?IPv6:2607:f2c0:e786:128f:7cf1:6dba:e88b:b0ec? ([2607:f2c0:e786:128f:7cf1:6dba:e88b:b0ec]) by with ESMTPSA id t68sm101367ita.4.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Mar 2019 09:50:43 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Joe Abley <>
In-Reply-To: <>
Date: Tue, 5 Mar 2019 12:50:42 -0500
Cc: Paul Wouters <>, dnsop <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <4253851.Zqd2zPpPcC@linux-9daj> <> <> <>
To: Christopher Morrow <>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <>
Subject: Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.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: Tue, 05 Mar 2019 17:50:48 -0000

On 4 Mar 2019, at 23:52, Christopher Morrow <> wrote:

> I don't know how long it takes to get ICANN to 'do something creative' for the root zone, but I'm guessing this isn't always feasible in normal timelines (hours to a day or so).

The IANA created an official, supported mechanism for emergency changes to the root zone back in 2010, as part of the project to deploy DNSSEC. The goal was to accommodate the needs of TLD managers to do quick changes to DS RRSets in the event that some bad signing thing happened. Even without that emergency provision, there were examples way back when of out-of-cycle changes were pushed through by the root zone maintainer (e.g. a third serial in a single day) because of some operational concern. When it comes down to it, all the people involved are operational and are good at what they do.

I think TLDs are a red herring here, though. The TTLs on referral responses from TLD servers tend to be long and there is no shortage of options for diversity and redundancy in the NS set of TLD zones. Developing TLDs that have not yet reached a level to be able to engineer in that kind of diversity tend not to be the TLDs that are relied upon at the scale of those that have (and, I would suggest, serve-stale is not going to save them out from outage anyway). Structural instability in such TLDs is probably better addressed by technical outreach, support and education than by protocol extensions.

Enterprise zones with low TTLs and with reduced options for authority server diversity due to the response-time tricks used to manage their traffic are far more likely to be interested in something like serve-stale, especially if their revenue is closely correlated with being reachable, and especially if they use lots of response-time tricks and want to understand what happens to client traffic when there's a DNS blip. From the other side, resolver operators for whom DNS non-reachability means a support burden have already implement these things. Describing how they work using outside voices seems like a good thing for everybody.