Re: [DNSOP] New draft on delegation revalidation

Daniel Migault <mglt.ietf@gmail.com> Mon, 04 May 2020 12:44 UTC

Return-Path: <mglt.ietf@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 989B53A0848 for <dnsop@ietfa.amsl.com>; Mon, 4 May 2020 05:44:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kqLMoiVlDJA for <dnsop@ietfa.amsl.com>; Mon, 4 May 2020 05:44:10 -0700 (PDT)
Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B35E93A0845 for <DNSOP@ietf.org>; Mon, 4 May 2020 05:44:10 -0700 (PDT)
Received: by mail-vs1-xe29.google.com with SMTP id g2so10971937vsb.4 for <DNSOP@ietf.org>; Mon, 04 May 2020 05:44:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3GcCue49r7zCWEOiGH76c4mzuyvmv8ZnsldF5U8/t9c=; b=Vk8dsNkrv0O7rrIEafoAe5hpg92W4dq2E3PcRWxNIhCUsp4JVYK9tH80qv/l2d1nqB KYkWVUeMLk+a+L0ke72J6rFnc4ybgzhAYruxnF4L93CmDQ9CdNqpzmLh6DynwoCJEQnS Rf/uOPsp6dQ9sVpjSaAaiJ9nHEQrluRRQI5bbf9qf/yuNncmtNL24dDKl4LewYHkp4bm MPHt+wG9uVRO7qBpvx2nCvesWkAm06J/VqkILb0MCPkVzF3qhkCn+MQaHKjZIUqZ3JS1 iAa3C8eoc61shs1BqcS/EL4u2xEFnngLT5lZ+W0k/a1X4KcLoYWJRGxqAQaisxO8HhG6 GQ4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3GcCue49r7zCWEOiGH76c4mzuyvmv8ZnsldF5U8/t9c=; b=EwynUi3qUOBgLf41iLdnozZ4kKvwEXOBlILG9yDY8Wf1kY6QnXz03Sg0MId76I8RAe +O29MnKVpOveMMtAgZErPEEmuR3gIZ5onIB6tABkywbx6rgoxiuwZSI66s0KNj92OQnD hIoMfZ3h0562TlrDHq0BQ28zXAQCYmgzIOu4DnFLVwDuZFm2VTsEhsqHN4I3M/aSijrg MVkntxSpanpweVD/4ncPpAIKipuZBC+hFk1J1+ejLgkAMDKFxnqE1xNXzG7LE8zvBw20 o0V3OI/1owzDjN8GOJtp61/prVl0MdPQTo7PHzLFZ2aaVWz+RWy4KBfumoWDLj12CTt9 DGtQ==
X-Gm-Message-State: AGi0PuZdlOwUa70TqqDlaWrFShCcdiGjoLs9EOVfU7EKW7DL1w4zStKa /xPpjGO/mgND6cy1SlqbYjHcibS1dzqRLxVvMRo=
X-Google-Smtp-Source: APiQypIcZghIs43kMHIZ4vWL3UCoNuZ9NX0rLamtD1IEX3W/oiRg0Lc5pDBBW53pWQDJMTCBea8lmklF3rywPg02Mto=
X-Received: by 2002:a05:6102:208f:: with SMTP id h15mr12352997vsr.69.1588596249714; Mon, 04 May 2020 05:44:09 -0700 (PDT)
MIME-Version: 1.0
References: <CAHPuVdV9eSCLQOqMF0cq8fHcuSZs7nCgjhHMfMoaV5H=ekbtSA@mail.gmail.com> <4feca627-79d6-374e-402d-f50d49e03469@sidn.nl> <CAHPuVdVkTbV6o5sVCZzOcE4y0yEFUa3rmtcsWooxQK0nO_eMvw@mail.gmail.com> <058d760a-7400-e407-4d12-c744d949538e@sidn.nl> <CAHPuVdWR6MTsWK0xBBnRj3JkgncORUWptt=VYZW+R-cDO4G1ig@mail.gmail.com> <CADZyTkm2t9-bL478dtMShkQQKW-Y1_H8nh0xmAwQHOZEnREcnQ@mail.gmail.com> <CAHPuVdUcBdVVWXp2oRKNwa7vHYEc1QOybvDmcdouxChO8rkgRg@mail.gmail.com>
In-Reply-To: <CAHPuVdUcBdVVWXp2oRKNwa7vHYEc1QOybvDmcdouxChO8rkgRg@mail.gmail.com>
From: Daniel Migault <mglt.ietf@gmail.com>
Date: Mon, 4 May 2020 08:43:58 -0400
Message-ID: <CADZyTkmQCZWSxtDFj08s1XR0vq2FGTn2EFCcesRHm2kjqjpcnA@mail.gmail.com>
To: Shumon Huque <shuque@gmail.com>
Cc: IETF DNSOP WG <DNSOP@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000027e24405a4d1e38d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/0_jFG8ysrDh-Gpcvi5bJD8sCSDU>
Subject: Re: [DNSOP] New draft on delegation revalidation
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 May 2020 12:44:13 -0000

Thanks, that will be appreciated. I will make sure the two documents are
synchronised.
Yours,
Daniel

On Mon, May 4, 2020 at 8:20 AM Shumon Huque <shuque@gmail.com> wrote:

> On Wed, Apr 29, 2020 at 11:57 AM Daniel Migault <mglt.ietf@gmail.com>
> 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.
>
> Shumon.
>
>

-- 
Daniel Migault
Ericsson