[DNSOP] Secdir last call review of draft-ietf-dnsop-serve-stale-08

Adam Montville via Datatracker <noreply@ietf.org> Mon, 23 September 2019 22:24 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: dnsop@ietf.org
Delivered-To: dnsop@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2007A1200DF; Mon, 23 Sep 2019 15:24:40 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Adam Montville via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: dnsop@ietf.org, ietf@ietf.org, draft-ietf-dnsop-serve-stale.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.102.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Adam Montville <adam.montville.sdo@gmail.com>
Message-ID: <156927748004.17176.13716791809578495002@ietfa.amsl.com>
Date: Mon, 23 Sep 2019 15:24:40 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/s28uMcs9Fa-D2rDXqVRukph3im4>
Subject: [DNSOP] Secdir last call review of draft-ietf-dnsop-serve-stale-08
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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, 23 Sep 2019 22:24:41 -0000

Reviewer: Adam Montville
Review result: Ready

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the security area directors. 
Document editors and WG chairs should treat these comments just like any other
last call comments.

At first I was confused about offering an option to allow use of stale DNS
data, but after reading the draft and realizing that the decision is still left
to the operator, this draft is OK.

The draft brings up-to-date the definition of TTL and offers additional
specification on interpreting specific TTL values.  Perhaps some expansion as
to the prevalence of bad actors using the caches and fraudulently issued,
domain-validated certificates in the Security Considerations section is
warranted.

Nevertheless, it appears that implementations have been fielded and in use
operationally for quite some time, presumably without a problem, and, as
previously stated, operators don't have to enable this functionality unless
they warrant availability of their services to be paramount.