Re: [DNSOP] New draft on delegation revalidation

Shumon Huque <> Mon, 04 May 2020 12:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9F8F33A0841 for <>; Mon, 4 May 2020 05:20:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 MBhqJxSBHFLl for <>; Mon, 4 May 2020 05:20:12 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::633]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1355F3A0843 for <>; Mon, 4 May 2020 05:20:12 -0700 (PDT)
Received: by with SMTP id s3so13686700eji.6 for <>; Mon, 04 May 2020 05:20:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=j4OAneTeYF8rdlWRhXEj22zXXHof4NuOH9Chh2o8cdo=; b=Q5/qbo+d0ku81ULXFO7AlhBXc3Jn9NcixxrNb7gx1Q37bLJyugo6B9LCeesSKw0LhQ O//vsXCZ9ZabqFzbabnloAzwXJYFYZda3AOAInrrOOqj9nJtvfBwuP1Y8qgcPSRbykke MyBDI6hO7qIPXIclxJrPzXqF9HXSsBaEcyXZpCkRm5R5iIGYC+/neYPULOaxFQuFpb6J LCURtbD+qKJnZLa2fgWafsu59+t+YGt/Gr3qV2+b1gZIZqWr09UeLxDQ3D1jNmddCdWw IWz6jrNjM8Lqv5tNQXArrdknQbKRxxRE8w31C9JHmAR+JmZXaRgYWhPUpFAMfD7pl2Ox yhGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=j4OAneTeYF8rdlWRhXEj22zXXHof4NuOH9Chh2o8cdo=; b=NOr8BGC1lgZ494SF3uXT93zi2PAffCesBwnjY2wgR/ePdykOWO8sZx4k8Z6tSpT8f6 Oi9Iw68sR2hZ80Ov3bEiSQEJbxbhX0g8bHdxZ5BXF5U0W67Uizq9MxG0eYpJX1QPppwU HKr/8rDovcR/+/qh73B+lRf0vfGqgFRBA9LvNJ/vuTImry/B2+5Hq21NDOEIYhEPqRcu 68vg+dGh741CdUzxbTfuRdM3exysWicl2fVu27Y9kOeSivFi+vX8s64+ZmxwO+a01ILw L9oD7QAF8bZTGPfUGDMP3qHCdlbx+7PlimCCR/LTVv8jVc32ET0Pmf8+Y7qJhuCVf0qb t2Rw==
X-Gm-Message-State: AGi0PuaodstIPRSnsZEoAZFEataKJssrYn6riupgH6AeFxLLEuNdzko+ Z6kq5+vqzD5IaH1x17IYDfuOTiXabcmeMC+UQLw=
X-Google-Smtp-Source: APiQypJSLYn30wjtXxfjgtsJFv1j3mgSNEw+mYCN0lYauwjfqyQ5HVvGqS8tpico2xCyojcJxGGQ7xESm6uabdbE2ok=
X-Received: by 2002:a17:906:131b:: with SMTP id w27mr14581253ejb.230.1588594810457; Mon, 04 May 2020 05:20:10 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Shumon Huque <>
Date: Mon, 04 May 2020 08:19:57 -0400
Message-ID: <>
To: Daniel Migault <>
Content-Type: multipart/alternative; boundary="0000000000005e90fc05a4d18d1f"
Archived-At: <>
Subject: Re: [DNSOP] New draft on delegation revalidation
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: Mon, 04 May 2020 12:20:14 -0000

On Wed, Apr 29, 2020 at 11:57 AM Daniel Migault <> wrote:

> Hi,
> I discovered this draft during the interim meeting. We had similar
> thoughts in our "Recommendations for DNSSEC Resolvers Operators". Our
> motivation for supporting this work are that it  1) improves the
> reliability of the resolution as well as 2) removes the temptation to
> (inadvertently) break resolution by fixing in appearance a
> misconfiguration. In other words it eases the operation.

Thank you Daniel. Will read your draft shortly, but in the meantime ..

Your note reminded me of the question you asked during the interim
meeting about why we can't just use the DS TTL as the revalidation
interval. Our response was that the main impediment was that DNSSEC
deployment is far from ubiquitous, but also that there is no reason that it
could not be factor, when available.

Here's what the draft already says about DS:

   Technically, if both parent and child zone are DNSSEC [RFC4033]
   [RFC4034] [RFC4035] signed with a corresponding secure delegation
   between them, then expiration of the DS record will cause
   revalidation of the current child zone's DNSKEY set, so responses
   from the orphaned child nameservers would no longer be trusted.
   However, delegation revalidation is still necessary to locate the
   current nameserver addresses.

In practice, the DS and delegating NS TTL do not always match.
COM for example uses 2 day NS and 1 day DS TTL for all its
delegations. So where DS is lower, that could be used as the upper
bound. We'll queue up some text on this subject for the next revision
of the draft.