Re: [DNSOP] Fwd: New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

Joe Abley <> Fri, 24 August 2018 14:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 99C9F127333 for <>; Fri, 24 Aug 2018 07:11:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mA65zUirnfdL for <>; Fri, 24 Aug 2018 07:11:39 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C887E127332 for <>; Fri, 24 Aug 2018 07:11:39 -0700 (PDT)
Received: by with SMTP id z4-v6so4374839pgv.2 for <>; Fri, 24 Aug 2018 07:11:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PfKXqgBhPanEiHRNRwcv4z6S0Y22Oa7hBRb27Hrw53Y=; b=OJ9xlg/pTV9op6C0dQ5vCX/mhfeA+0Ok4refR2vgQinfpcpQrFQREFV9lcjluxvU75 k2N9mBfNPpdLcv1218fJIj4NHdUY0ao6I5JfLsEKk57V3/Pa25hT0wyk/P6bDgYkYmD/ xaf61X9Gx7sghV0HyBMJXcLtsgWB45oh627lM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PfKXqgBhPanEiHRNRwcv4z6S0Y22Oa7hBRb27Hrw53Y=; b=QzpctikwCOvCyG9s4BwmUqBvHx3aseVbtTTE9zyAGKKvicB+UAt0FfjV/uIValQnYp 0OVfJfo7xkyEAIjh7RZr1G/qOJkByDVhkIdFu9HQmCFbrO2qTfhWO57vDuQLgHLDeazi 4LT790zEtmed1ZQkhfv2KBBYH6cWNvh4Ns0sctnNddJmjKWgFUq5kQmRbWoPrKqHGWVs hRO/OiPijhcHme7bHCxKO7+Id9p06zKZHD7Vene2417cnLBAn91uGnvnv7lKIXNCrVfz OSaqKGWcuNyRdJENQmAOL3TihYSJatjF6Zu+8vfkl8elhEWFgxABP+PXbam2DUgitWll JHqQ==
X-Gm-Message-State: APzg51Cjv79GGqw9PXzVdDlEdOv1JFWYZ9ZepCmCEr3p4JMzUDRK/blg d68Raxn2q0GH6wOsYWtZP8Hl6lKF1+i1/w==
X-Google-Smtp-Source: ANB0VdZX0W/IEPmrET2WiykPahGLEHstSxKQhltbGC5Lpf1USmO6HiQd2F0rO71pQ79x5Q7RoTM4MQ==
X-Received: by 2002:a62:a65a:: with SMTP id t87-v6mr2181564pfe.225.1535119899240; Fri, 24 Aug 2018 07:11:39 -0700 (PDT)
Received: from ?IPv6:2607:f2c0:101:3:e1ce:bcf3:c5be:4fc2? ([2607:f2c0:101:3:e1ce:bcf3:c5be:4fc2]) by with ESMTPSA id s27-v6sm11387806pfk.133.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Aug 2018 07:11:38 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
From: Joe Abley <>
X-Mailer: iPad Mail (15G77)
In-Reply-To: <>
Date: Fri, 24 Aug 2018 10:11:34 -0400
Cc: Ted Lemon <>, dnsop WG <>, Paul Vixie <>, Tim Wattenberg <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <>
To: Tom Pusateri <>
Archived-At: <>
Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 24 Aug 2018 14:11:42 -0000

Hi Tom,

> On Aug 24, 2018, at 09:52, Tom Pusateri <> wrote:
>> If a zone is signed, are the TIMEOUT records signed?
> No. The draft says they are skipped.

New RRTypes are supposed to be handled by old software that pre-dates them because they can be treated as opaque types. That's not the case if new RRTypes are encumbered with requirements for special handling at query or signing time (as described in your section 2).

This seems like a significant architectural change that in effect updates 1034 and 1035 as well as 3597. This would be a much more straightforward and uncontroversial proposal if it was simply a specification for use of a new RRType that made no changes at all to the rest of the protocol.

I have not read your draft in detail but I think you probably would also need to spend more time considering the cases of old, non-TIMEOUT authority servers that wind up serving zones that contain TIMEOUT RRSets (e.g. third-party hosting services). Client handling of rogue RRSIGs, RCODE=NOERROR with ANSWER sections containing TIMEOUT RRSets, etc.

This all seems a bit messy, to be honest.