[DNSOP] Fwd: Comments on draft-ietf-dnsop-root-loopback

Brian Dickson <brian.peter.dickson@gmail.com> Mon, 29 December 2014 22:23 UTC

Return-Path: <brian.peter.dickson@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2F201AC427 for <dnsop@ietfa.amsl.com>; Mon, 29 Dec 2014 14:23:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.1
X-Spam-Level:
X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 uKjxOQsJLnTz for <dnsop@ietfa.amsl.com>; Mon, 29 Dec 2014 14:23:49 -0800 (PST)
Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB71A1ACDF4 for <dnsop@ietf.org>; Mon, 29 Dec 2014 14:23:48 -0800 (PST)
Received: by mail-ig0-f176.google.com with SMTP id l13so12589230iga.3 for <dnsop@ietf.org>; Mon, 29 Dec 2014 14:23:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=ZSTuNvrgC6m+gFSJG7RnqTz0M/4QSnRRx1P7iONaurk=; b=AJ/uxjk7I2vYPA8Lc5lUiCSsw79NIExuiPJI8bjUEKoHsYCRFXBziPvPvCJm0F61ho PqmgS6oN7CMSJNhMwT7usWyEMmno84EbrskpQ0auMNTGAtWrsY6tkvA18/B9O3MUwN18 3pbDpMzOEJVvy6MYvshT8InmK5SOXkmYp/Hx4GRbIWc12Md5+UUHjpqmdRoFXuitvS7x VXC8Y4kScguiM2MJQxiW7MXhIRVSR+sg3bVc6os5uZy6AO8o4msa//Pfna7lL7Jo4NuO pJjfTUGIVNHg3aTEmbpRK0TnHbW9EAwKeCT+2ueoLkvlOJm9xHvhncxh9xuQQWMQsQUm iyKw==
MIME-Version: 1.0
X-Received: by 10.50.17.99 with SMTP id n3mr34652956igd.21.1419891824615; Mon, 29 Dec 2014 14:23:44 -0800 (PST)
Received: by 10.64.69.167 with HTTP; Mon, 29 Dec 2014 14:23:44 -0800 (PST)
In-Reply-To: <CAH1iCirLkTYcBZ7pfYSwdDQhOEUJyN2sjpTMSkTMdGn3ZkX3ZA@mail.gmail.com>
References: <CAH1iCirLkTYcBZ7pfYSwdDQhOEUJyN2sjpTMSkTMdGn3ZkX3ZA@mail.gmail.com>
Date: Mon, 29 Dec 2014 14:23:44 -0800
Message-ID: <CAH1iCiqBTh5NcD9LWjQ1BNVRFt0Bc-ROJYs+hG=vO8i_bwrD5A@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
To: "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="089e01228278d36aea050b62536c"
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/-HV-31tKcTRZyHgDyXkHEhq6tis
Subject: [DNSOP] Fwd: Comments on draft-ietf-dnsop-root-loopback
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 29 Dec 2014 22:23:52 -0000

I like the idea generally, and mostly have concerns about what can go
wrong, and possible missed opportunities in the operational realm.

These comments are meant to be constructive, and with the goal of improving
the draft quality and/or quality of the underlying protocol.

And, of course, I speak only for myself.

In no particular order:

- Given the unsigned nature of the glue in the zone, and the importance of
root glue, it might be the right time to also introduce a "zone signature"
RR, signed by the ZSK.

- Given the lack of the "big red button", this would be a good time to
introduce the ability to opt-in to a NOTIFY "registry", so that
appropriately validated notifications could be sent by a root-zone operator
(from whom the root-loopback operator does AXFRs)

- I'd also suggest adding something like a "sentinel" query for SOA Serial
Number be made at REFRESH intervals to randomly-selected root servers. If
the SOA Serial Number is stale for REFRESH + RETRY, it may be safer to go
SERVFAIL at that point rather than waiting for EXPIRE. (The stale zone
might still want to be used if all other root servers become unreachable,
so don't delete the zone, just prefer not to use it.)

Hope this is helpful. Feel free to ignore anything viewed as controversial
or unlikely to gain consensus.

Brian Dickson