Re: [DNSOP] [Ext] partial glue is not enough, I-D Action: draft-ietf-dnsop-glue-is-not-optional-00.txt

Brian Dickson <> Thu, 02 July 2020 17:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6DD903A0B81 for <>; Thu, 2 Jul 2020 10:17:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 j5Y2pX0szeQV for <>; Thu, 2 Jul 2020 10:17:01 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::92f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D81B83A0B0A for <>; Thu, 2 Jul 2020 10:17:00 -0700 (PDT)
Received: by with SMTP id g14so9153389ual.11 for <>; Thu, 02 Jul 2020 10:17:00 -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=8Vg5BEtgZEdkDRoEaaAUzW4OlPGfUdEf5+UGO3OvBEI=; b=SMytMPkSssMroGZ3yk+YXxJHFAJtw6FkJE26cLH4IwKtLEbjmqSqqdxRqQwhaCaiXz KIFLs/+1hd4t/6irm9dZQYgQojkuWtn7tLCjfKfBxYxfnbWIAw/v3eVmnpxJ9CwLCQTG DG1zJZ1I6bzY3p77RNxlrawj0lKZEYh8aZyRrkxNVS8bN+KtrSPGLnAoMgO1boAHVoGa 7UIsMImUEOBMtZ+A+dXCjjm58dOzVRWF0s4wi3hLeXxkMwDTNRa2lUxdOQN0zq+riJRC i7p39Y1EVkTGcpk7VCeKqwlmTYcUOduOA5HgcpWarN3I/M+MALMDfN+btmtL3VUmeAHk CYeA==
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=8Vg5BEtgZEdkDRoEaaAUzW4OlPGfUdEf5+UGO3OvBEI=; b=K40TjzLwWTfTCTov9bb9t/my+b9Guus5JM5UA+F7LBxnIhRdkoXtZCf2Nw/oSSCZUq rpZ0YC0461ZYM2BR1NefI/+GCOxeH6hHmbZ+5RgCytLKa3Q/7k7GRg1RkjY0O5R5RGp8 m3MFeXNLDR7rOS4z7foeyf+ZeLmz7UF+7+FUWvtl4c3yZjIugjijcOhkV/Oup90hb+TN T/krjL+rh15rbdhMrUoUhixo4Pk3zoWrw9u4sGp+5y2sdw7l+gwUJXqFsWpLsQJa29Ir GIqMh+kOoci1Z7Y5CDTlZIdPZsc7tbX6PCjcj2xcav1LCUvPBKt/yVx7wcBVb+Yl3t4v bEsw==
X-Gm-Message-State: AOAM531jd45mdH+qUO/3RKT8gE0qV/vRgxLwlB1VJ0RJ01zfgcpWZAsh Lpi0sXGxTRxtxd12cAQ73GnvjjJ6bCS9M3/PGpA=
X-Google-Smtp-Source: ABdhPJyn0p55y1iOV9H+/Raew2Uf4NIVcOO9K6cFzadfN45pcYLSCwFzDzlL52iJc1xy5wVHsTM7zdEVmDk5Svr33oY=
X-Received: by 2002:ab0:1052:: with SMTP id g18mr19835120uab.62.1593710219758; Thu, 02 Jul 2020 10:16:59 -0700 (PDT)
MIME-Version: 1.0
References: <20200702011816.D4B0D1C3CD10@ary.qy> <2843010.V8yvLItfke@linux-9daj> <alpine.OSX.2.22.407.2007020949360.96330@ary.qy> <6402649.6cnN7U4pX5@linux-9daj> <> <>
In-Reply-To: <>
From: Brian Dickson <>
Date: Thu, 2 Jul 2020 10:16:48 -0700
Message-ID: <>
To: Paul Hoffman <>
Cc: dnsop WG <>
Content-Type: multipart/alternative; boundary="00000000000086129905a9789394"
Archived-At: <>
Subject: Re: [DNSOP] [Ext] partial glue is not enough, I-D Action: draft-ietf-dnsop-glue-is-not-optional-00.txt
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: Thu, 02 Jul 2020 17:17:02 -0000

On Thu, Jul 2, 2020 at 9:14 AM Paul Hoffman <> wrote:

> The interpretation of whether a partial RRset is allowed by 1035/2181 made
> by JohnL, PaulV, and MukundS are all plausible and conflicting. RFC 1035
> and RFC 2181 are unclear about whether an RRset that is required in a reply
> can be partial.
> draft-ietf-dnsop-glue-is-not-optional as it stands is probably not the
> best place to update the understanding of the standards-level relationship
> between partial RRsets, the TC bit, and what parts of a response are
> required. Doing so is adventurous, time-consuming, and will almost
> certainly cause multiple current implementations to be out of compliance.
> It is probably still worth doing, albeit carefully. A bad outcome would be
> finishing the document due to exhaustion instead of consensus.

I agree with Paul H in this regard.

Here's how I see it: the update to 1035 is necessary, but not sufficient

Note that 1035 itself predates EDNS, so advice on TC alone is good, but for
the population of DNS implementations doing EDNS, perhaps we could take
advantage of its existence?

There are a whole bunch of unused bits in the core element of the OPT RR
(the place where the DO bit exists). That would be an excellent (IMHO)
place to signal the situation here (partial glue truncation).

Such a bit would hopefully disambiguate the cases where TC=1 is set,
allowing for graceful handling (try to use the available glue, prepare for
the failure case and retry over TCP if it does fail).