Re: [Gen-art] [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-09.txt

Brian E Carpenter <> Mon, 02 December 2019 21:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2358512008C; Mon, 2 Dec 2019 13:02:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id p-vLtv79XWd7; Mon, 2 Dec 2019 13:02:24 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::1032]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C24A7120018; Mon, 2 Dec 2019 13:02:24 -0800 (PST)
Received: by with SMTP id l4so325673pjt.5; Mon, 02 Dec 2019 13:02:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=hWUdAyHH6z9MYNkZdb2Xdt8Jplv5ltdNNK9f/k/hjAQ=; b=SRjothvD0hoATCyT13dm75vlHqPekXft3mDyK3peUTmxSbxiZVggTrGJExf9+TAm2n 4YDYPXpTIH2Pdg5K7zwQVUxuwXqqmcLMHm6/qYHT81zHiX+Nl62kRmzR7yjY+r8mcqLr dqMux/Dt2xBize046XLIbhMoP5OacRA7alLgbQ7qcimQHRUNYtTXzAlux9Rci7+YN52d XVpOAyU48gOIaaCnHerPosmGq78LkbS/PZlrecY025iRmTHkK7Tfi/ZDDoK2Nlf5JU/c t69HYeZOObMwbowJap2KRJebO6Va4vmH9xj8NvUyB02rzTh1wtZlgKOHrmTUaU7aHhWq xrKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=hWUdAyHH6z9MYNkZdb2Xdt8Jplv5ltdNNK9f/k/hjAQ=; b=k3uU1io949YwfD3tFlWxviGVmCgV29wqxH8K0wIS1wQfTWp0AhIepmtme7vtyJWnZN T7Sz7CI7XjMn78XvWs2CEtL5HkxmmqnR684cxBQ7c9m12nFG3jXH7zV5rhkQ955MC5HM rhsJ5W9+3mqF2T5aJy07qJzM1pKP8YLrPikOdVHETUS3RqLc0oEJ/+X7QT1EnZ7XNAXd qd49xwmEow0AhX0wRlMDtYL3SeZ6o3evWMnlWl3FlTwBJF7WaDM21GwZ+dA2lmkgBsFN PRh0dKOAZaNs/79sOWc0PGBXAe/QlelzOjEVhgyFvQBCqFFzIV+PXoGXsukYxRqAoM6T nkEw==
X-Gm-Message-State: APjAAAVX1F859/eX8BCGOmDkxFHlNHrGKzseuB4eURcEPFWZ9vYiLemO LKo9UqpoBlliqlfQ1PcwqH2vphX6SSw=
X-Google-Smtp-Source: APXvYqxBNZbD8QhykyR0xdyZLjH9pR0cZc1IojpRxGqldeJpGCrSqd/PjDUWiOCniVVpBMcHhXSsAg==
X-Received: by 2002:a17:902:904c:: with SMTP id w12mr1261625plz.144.1575320543613; Mon, 02 Dec 2019 13:02:23 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id s27sm401859pfd.88.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Dec 2019 13:02:22 -0800 (PST)
To: Benjamin Kaduk <>
Cc: Dave Lawrence <>,,
References: <> <> <> <>
From: Brian E Carpenter <>
Message-ID: <>
Date: Tue, 03 Dec 2019 10:02:18 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Gen-art] [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-09.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 02 Dec 2019 21:02:27 -0000


It's certainly a judgment call, but it really does seem that uint_32t has been around so long now that surviving implementations that misuse int for this surely have many other problems too. We'd be talking about resolver code that hasn't been refurbished since 1997 *and* a DNS record with an absurdly large TTL.

I think DNSOP participants are better placed than me to comment.

   Brian Carpenter

On 03-Dec-19 08:33, Benjamin Kaduk wrote:
> Hi Brian,
> I agree that this updated text provides more clarity about why the
> change is being made, but I am not sure that it fully addresses all of
> the concerns you raised, and would appreciate your thoughts.
> Specifically, you had raised the possibility of existing, fielded,
> implementations that would behave poorly when presented with input that
> has the sign bit set.  The DNS-OARC data that indicates such packets have
> not been seen in the wild serves only to amplify this uncertainty, since
> we have no reason to believe that such a codepath would have been triggered
> already and diagnosed.  Isn't there still some latent risk of such
> fielded implementations that would be incompatible with this change if it
> ever did show up on the wire?
> Thanks,
> Ben
> On Fri, Oct 25, 2019 at 11:23:42AM +1300, Brian E Carpenter wrote:
>> Hi Dave,
>> Thanks. I think that covers it. I still suspect that the original reason
>> was concern about int versus uint confusion, but the new text is fine.
>> Regards
>>    Brian Carpenter
>> On 25-Oct-19 08:35, Dave Lawrence wrote:
>>> writes:
>>>> A diff from the previous version is available at:
>>> This revision addressed the one remaining outstanding issue that Brian
>>> Carpenter raised in the Gen-ART Last Call Review.  The following text
>>> was added to explain why a TTL with the high-order bit set is now
>>> handles as a large positive number (then capped down) rather than a
>>> negative number (and treated as zero).
>>>     As for the change to treat a TTL with the high-order bit set as
>>>     positive and then clamping it, as opposed to [RFC2181] treating it as
>>>     zero, the rationale here is basically one of engineering simplicity
>>>     versus an inconsequential operational history.  Negative TTLs had no
>>>     rational intentional meaning that wouldn't have been satisfied by just
>>>     sending 0 instead, and similarly there was realistically no practical
>>>     purpose for sending TTLs of 2^25 seconds (1 year) or more.  There's
>>>     also no record of TTLs in the wild having the most significant bit set
>>>     in DNS-OARC's "Day in the Life" samples.  With no apparent reason for
>>>     operators to use them intentionally, that leaves either errors or
>>>     non-standard experiments as explanations as to why such TTLs might be
>>>     encountered, with neither providing an obviously compelling reason as
>>>     to why having the leading bit set should be treated differently from
>>>     having any of the next eleven bits set and then capped per Section 4.
>>> I also removed the phrasing about 2181's handling of this issue as a
>>> "curious suggestion".  I recognize it could have an unintended
>>> negative connotation against the original authors, though when I wrote
>>> the sentence originally I meant it only with its neutral denotation.
>>> It was curious to me only because no rationale was provided as to why
>>> that particular choice had been made, despite the current assertion
>>> that it was obvious as to why.