Re: [DNSOP] Genart last call review of draft-ietf-dnsop-serve-stale-07

Puneet Sood <> Wed, 18 September 2019 16:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A0356120AD7 for <>; Wed, 18 Sep 2019 09:20:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NWP1Si2Inu4m for <>; Wed, 18 Sep 2019 09:20:28 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::e33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D673B120B0B for <>; Wed, 18 Sep 2019 09:20:25 -0700 (PDT)
Received: by with SMTP id p13so238380vso.0 for <>; Wed, 18 Sep 2019 09:20:25 -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=s2mmRsr3GXW9HRdo8ZLAP15lpKAm9vA5270QoiQUmoo=; b=ksFduIrfhIueRwnrLOFu0F5s+yiaO0fYynJc1MG3PLKcporuEKHmpj8S9pn9/6glI3 CSaS+JvowDIYJAgXzy6COodp37rHxxz5eMXgF85urxOORF9i+tMu3DlqXPqVct1nCEpY bgVXi7RzcSW5YizXNkt2VKVE2cBt1LHOKLXAL84RKcvW8VOaeE7SUEn3c29U+slGiDZM 2v7vS8hYhxBd/2p+g6a8ErOy+N7LZtnM3gyU8jnTOFjOYb10JBGn77Az4MzP7vl4aNqB 6cEy6AYJbxJf47Zh+qJkzrXIzXV8hoY0kGiWTl1YoZV/r1MQht9yy/IRxn6oXarXpwwO BCHg==
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=s2mmRsr3GXW9HRdo8ZLAP15lpKAm9vA5270QoiQUmoo=; b=Z9CcyGCFJv0LwRr4Fpn8yyl1yYvplbZUOaJL9FbVy40h/V7d7stxXbEZaDokIO8Tcw OLSytUTo2hYFlqZqwcxGcpqP8O+La4F1RE/hZ7AE9XSB7jo/qPWoA4xPzS+uXcNDZ2vw 4dCM+iKQ7Qs0KA4r1ca+1SlPCHbxrv0mF5CxZxHbuja2lF7RvYOZipdoQcYqdSJMAbqD Me+/p1oJyIunc0g+XW/5HtkCiv/xOGm0cVOS7poT/fHfrFvG3jV0Y3bowldUBfR3RLs2 jG00NC7kJ7ca7WFK96rkWzMiaSLIsJTg/tqgYu8FmWdLKBnuUOl43DiWJ6IdmJIVGW6g nOUw==
X-Gm-Message-State: APjAAAXtUfHwAPRJgyc48flxfT+wElIF/0NQvZA1yrlFtVZflhjxw28Y p3b0LpxNaEPU2ijYBrGQuS3SoM9jwujQyqVAUrgYzg==
X-Google-Smtp-Source: APXvYqxRhsn4l3BFApQ0vWtVaX5LoHAromfjufba1n+hw6EO/su3jRFBHCKfYATSWuK9vCzlg8Y298Kf+wz6Nfe9Dzk=
X-Received: by 2002:a67:1043:: with SMTP id 64mr2744983vsq.114.1568823624509; Wed, 18 Sep 2019 09:20:24 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Puneet Sood <>
Date: Wed, 18 Sep 2019 12:20:12 -0400
Message-ID: <>
To: Brian Carpenter <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [DNSOP] Genart last call review of draft-ietf-dnsop-serve-stale-07
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: Wed, 18 Sep 2019 16:20:38 -0000

NOTE: Responding to the TTL concerns raised in multiple threads
(thanks Viktor Dukhovni, Tony Finch) here since it seems to cover all
the lists.

On Mon, Sep 16, 2019 at 10:24 PM Brian Carpenter via Datatracker
<> wrote:
> Reviewer: Brian Carpenter
> Review result: Ready with Issues
> Gen-ART Last Call review of draft-ietf-dnsop-serve-stale-07
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> For more information, please see the FAQ at
> <>.
> Document: draft-ietf-dnsop-serve-stale-07.txt
> Reviewer: Brian Carpenter
> Review Date: 2019-09-17
> IETF LC End Date: 2019-09-25
> IESG Telechat date:
> Summary: Ready with issue
> --------
> Major issues:
> -------------
> "(It [RFC2181] also has the curious suggestion that a value in the
> range 2147483648 to 4294967295 should be treated as zero.)"
> I don't see why that is "curious". That is the range of unsigned
> 32-bit integers that would be negative if treated as signed 32-bit
> integers. And in any case, the statement seems unfair to the authors
> of RFC2181, which actually says this:
> "It is
> hereby specified that a TTL value is an unsigned number, with a
> minimum value of 0, and a maximum value of 2147483647... this value
> shall be encoded in the less significant 31 bits..."
> It's not a "suggestion"; since the RFC does not use RFC2119 keywords,
> it's a requirement. It's unambiguous, and obviously motivated by
> resilience to coding errors around signed vs unsigned integers. That
> was a legitimate concern in 1997. As best as I can tell, in 1997
> standard C did not include uint32; you needed to use unsigned long int
> and hope it was mapped to 32 bits.
> So the current draft overrides this choice made in RFC2181. Since that
> choice had an obvious (but unstated) motivation, how do we know that
> allowing TTLs above 2147483647 will not trigger long-standing coding
> bugs?
> There's an alarm bell later in the draft:
> "Regarding the TTL to set on stale records in the response,
> historically TTLs of zero seconds have been problematic for some
> implementations, and negative values can't effectively be
> communicated to existing software."
> You bet. If the TTL is specified as an unsigned 32 bit integer, and
> stored in a uint32, negative values are impossible. But if the coding
> is sloppy and used long int, "if ttl > 0" could go horribly wrong.
> Maybe it's all OK and there is no old resolver code out there with coding
> errors for values above 2147483647. Did the WG discuss this? I think the
> "curious suggestion" text above should be replaced by a brief discussion
> of why RFC2181 made the change that it did, and why it's now safe to
> reverse it.

The primary concern is around treating TTL values with the high bit
set as positive numbers resulting in really long TTL value either
intentionally (someone added that to a zone configuration) or
unintentionally (e.g. software incorrectly decrementing a zero value
or small positive value). The responses from Tony and Brian clarify
why the wording in RFC 2181 is written the way it is. My co-authors
have more context on the changes for TTL interpretation. I will follow
up and we will come back with a response.

I will also address the editorial comments around the TTL text with tat.