Re: [DNSOP] New draft on delegation revalidation

Ólafur Guðmundsson <olafur@cloudflare.com> Mon, 13 April 2020 20:36 UTC

Return-Path: <olafur@cloudflare.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 CD3DE3A1DC7 for <dnsop@ietfa.amsl.com>; Mon, 13 Apr 2020 13:36:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.255
X-Spam-Level:
X-Spam-Status: No, score=-2.255 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 aZe5dcy7tOSo for <dnsop@ietfa.amsl.com>; Mon, 13 Apr 2020 13:36:56 -0700 (PDT)
Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (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 D5F9E3A1DC5 for <dnsop@ietf.org>; Mon, 13 Apr 2020 13:36:56 -0700 (PDT)
Received: by mail-ot1-x330.google.com with SMTP id i22so1081768otp.12 for <dnsop@ietf.org>; Mon, 13 Apr 2020 13:36:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=i49EZnk6gK5JcU05Fb39V1XE+Uop5DT1xkbiP95eNTc=; b=bv/p7LEHmRlJoDCMurayqqnIRRtEOYJUCxZPcrnpUjQASX6jzqyv+/SIxIRqtCzEaE J0h1+tqnGDx20xPg6ZLTA6TWZsMVe8Vw0UEREfDs8Js4Q3O42nBJH9CdJvdufT2Z1pGQ RDCGHXHeTJ34n5OJRNh4AXsd2vFiQx7vMa4V0=
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=i49EZnk6gK5JcU05Fb39V1XE+Uop5DT1xkbiP95eNTc=; b=fsXZJowytOZN+mTGHf52x+tdTS1v4A3+85dVMHAu+4bodqWlLukaUZBcg1pvscsWIK /jhrScz7JvkGZp98zzbBm4M99A2hcCaYsJUg6Xfbqz4LJS9w/teRIj+l9TsArHMNLSpd VtiiG0p6bI+q2joTGJXiqwCgYA4NfnL9OVy1ss2PP9LfPx/JbYFY0o0j8iUBloIJ9F5z RSvTDUyG3dtHkBxGh56Uv22UB1gBGK9PZx458HGL6ZQmP0DJ0oXe9pTQWUMxMQe78TiS 5JQahIfkep0GJozVfyD00DGsMteI4zKD7s8K92PDw1gfgan61pipMZ2EzeE77m283zRN eaFg==
X-Gm-Message-State: AGi0PuaJIYyUcccD1R8bDWUHeAd/JHk59X1QMtQMLzngyZgBla58Srf+ AEn3XAecUISgJPut7AkodkWbq6+5IPbMgowOxXhYww==
X-Google-Smtp-Source: APiQypJksHPRD6ae4lTAqB3iRpsAwPtOAjbO0LhOOwoTm1LOjT574eFuQ9oAgOsxV6c9990zUpfXuc0TuZ/p7DpRfnA=
X-Received: by 2002:a4a:c28e:: with SMTP id b14mr15527703ooq.39.1586810215795; Mon, 13 Apr 2020 13:36:55 -0700 (PDT)
MIME-Version: 1.0
References: <CAHPuVdV9eSCLQOqMF0cq8fHcuSZs7nCgjhHMfMoaV5H=ekbtSA@mail.gmail.com>
In-Reply-To: <CAHPuVdV9eSCLQOqMF0cq8fHcuSZs7nCgjhHMfMoaV5H=ekbtSA@mail.gmail.com>
From: Ólafur Guðmundsson <olafur@cloudflare.com>
Date: Mon, 13 Apr 2020 16:36:44 -0400
Message-ID: <CAN6NTqwrdE-_jE5iMRp05vm1URtdRkYLU7Dk2wWd43PvA-F3MQ@mail.gmail.com>
To: Shumon Huque <shuque@gmail.com>
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003d3c5805a3320bd7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/hjrl0WBOaEJoRXtvgaKtZJfVkoM>
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, 13 Apr 2020 20:37:00 -0000

I read the draft and like it, this is a clear statement of the problem and
good way forward.
I agree with the idea that "all" NS are lame is a good signal to
revalidate,

One idea to throw out here triggered by the first two paragraphs in section
3
Should we recommend that Authoritative servers that are configured for
minimal-response overwrite that on DNSKEY query and include NS RRset if
there is space ?

Olafur



On Fri, Apr 10, 2020 at 9:46 AM Shumon Huque <shuque@gmail.com> wrote:

> Hi folks,
>
> Paul Vixie, Ralph Dolmans, and I have submitted this I-D for
> consideration:
>
>    https://tools.ietf.org/html/draft-huque-dnsop-ns-revalidation-01
>
> I mentioned it on the dns-operations@dns-oarc.net mailing
> list last week, where the topic came up in another thread,
> and there has already been some lively discussion about it
> there. So we recommend reading the thread there:
>
>
> https://lists.dns-oarc.net/pipermail/dns-operations/2020-April/020041.html
>
> There is a range of different behaviors in resolver implementations
> in this respect today, and it would be good if we could agree on
> more commonality.
>
> The main recommendations in the draft are to: (1) deterministically
> prefer the authoritative child NS set over the non-authoritative,
> unsigned, delegating NS set in the parent, (2) revalidate the parent
> delegation at the expiration of the parent NS set TTL, to promptly
> detect when the parent has re-delegated the zone elsewhere (or
> removed the delegation).
>
> These are not new ideas of course. They have been proposed in Vixie
> et. al.'s resimprove draft from 2010, and Wouter Wijngaard's resolver
> mitigations draft from 2009. The Unbound resolver already mostly
> implements this with the 'harden-referral-path' configuration option.
>
> Comments/discussion welcome.
>
> Shumon, Paul, and Ralph.
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>


-- 
Ólafur Gudmundsson | Engineering Director
www.cloudflare.com blog.cloudflare.com