Re: [DNSOP] Consensus suggestion for EDE and the TC bit

Michael StJohns <> Wed, 04 December 2019 06:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 89EF71200B2 for <>; Tue, 3 Dec 2019 22:31:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 T3yGLAbvs_qi for <>; Tue, 3 Dec 2019 22:31:54 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::72d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B385412008C for <>; Tue, 3 Dec 2019 22:31:54 -0800 (PST)
Received: by with SMTP id a10so6087924qko.9 for <>; Tue, 03 Dec 2019 22:31:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=641AAUsvOfPWw1ex2+W9+Va4SCgVPMjx08F67T17Kvg=; b=S15iUP/qN1VrTdFhHTe40LgE5VujLP51jakzDTjmyRc8vaASjfz1yuGRx8Gud9NxIk 6liJKuAlGMxZcI8fi52CS3mcPWl1UyIdKUJU6vseOhwlLMHN+PuED+aFw5oSOyuklwFG DddKAPErGQueCkzh3d9w8AMmVpXymCWAapT5JGD5g9D8e3JQ6YtFzKE7985UJU0d/xjE /fFNllmCADKM9/coyfqIBr37wBdB3vQh7PMcvKPdNdSLGJ4ooRO6pF3RY12T+EACP0uc glOb/SFpPdWeK4FFaBfg5yMjKyyMl6+Ob0kf/lCEdwk7aT6sLv93KDSC9i6pOMGwbMvG SsZg==
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-transfer-encoding :content-language; bh=641AAUsvOfPWw1ex2+W9+Va4SCgVPMjx08F67T17Kvg=; b=XjGBHt6HHt+svFqBKyAv/WmZYebrUnxw//UdNxIS/qOeV6VBHxDIsVLjc708JqQkup D6HM89iCQTBK9oAgLiTl5xaIz4eeKeKR3h813ZDu4BQHGWaFPJ28eFag6aLepHX+2V8a LIYHsD/S6pG4pOfXDUCJtUHLmeCEc8tJHtOBLtIB2J5lPQZXKUfbNrVFtVqY9oMErib8 rj9AX9VTYjrRcmnjytxGTfuuGEJDsZSaHrsRXHEVLX8EcCaZDPnkzxXe6bJ+u9nJ7uCx wr39oyuTaENgF3woEPcfGrUuv04XYFCKjU+Oprju+fX+IABKKVlBUAMzeTEqeXg9Hw7q 4dZg==
X-Gm-Message-State: APjAAAUJ/CKxUvqhagH7Ci6FKUV2svkkRmuwVwgUVXu2a9y2Xm2f7nMZ XEWe8Ar6VElxg2qTL3DF0lku4yQlstc=
X-Google-Smtp-Source: APXvYqxYQJ5Lgc4zU84USg0GM4evIR9mmf+m3wBbcRgREf40HXJ1870GfKqwn6cmHZA5GD1mY1ApnQ==
X-Received: by 2002:a37:8306:: with SMTP id f6mr1375188qkd.372.1575441113277; Tue, 03 Dec 2019 22:31:53 -0800 (PST)
Received: from ?IPv6:2601:152:4400:437c:31e5:9fab:8387:7fc1? ([2601:152:4400:437c:31e5:9fab:8387:7fc1]) by with ESMTPSA id x8sm3129198qki.60.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Dec 2019 22:31:52 -0800 (PST)
To: Ralf Weber <>
References: <> <> <>
From: Michael StJohns <>
Message-ID: <>
Date: Wed, 4 Dec 2019 01:31:50 -0500
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; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [DNSOP] Consensus suggestion for EDE and the TC bit
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, 04 Dec 2019 06:31:57 -0000

On 12/3/2019 5:21 PM, Ralf Weber wrote:
> Moin!
> On 3 Dec 2019, at 3:15, Michael StJohns wrote:
>> From 2181:
>>>   The TC bit should be set in responses only when an RRSet is required
>>>     as a part of the response, but could not be included in its 
>>> entirety.
>>>     The TC bit should not be set merely because some extra information
>>>     could have been included, but there was insufficient room.
>> I finally got a chance to go back and do some reading and found the 
>> above.
>> The way I read this is that setting the bit simply because you 
>> couldn't include diagnostic info is a no-no.   Let's not do it.
> I disagree. The EDNS0 OPT RRSet is needed and thus if can not be 
> fitted entirely a TC bit has to be set. Also 2181 was before EDNS0 so 
> IMHO it doesn’t apply here anyway. EDE is all is new stuff we have to 
> decide over what do with it now and not some ancient RFC. And a lot of 
> people (including me) have said that they, because of the rare cases 
> this appears, see TC as the right solution as it is simple and 
> backwards compatible. EDE already is complex we should not increase it 
> complexity for a rare corner case.


In the querying EDNS0 set a bit (EDERequested) that says "Consider EDE 
as 'important' in the response - return TC if there is an overflow and 
EDE is omitted".   Maybe set a second bit (EDERequired) that says "EDE 
is more important than any other data - return it at the head of the 
response and drop something else in preference."


If EDERequested or EDERequired is set, and overflow occurs because of 
the EDE, set the TC bit on the response.

If EDERequired is set, return the EDE EDNS0 option in preference to any 
other data - you may still end up setting the TC bit if other info is 

The first bit says that the client understands EDE and that it considers 
it is as important as any other data and should not be omitted without 
setting the TC bit.

Clients that don't understand EDE (e.g. most of them right now) that 
would ignore EDE anyways don't need to re-query for data that they don't 

Clients that do understand EDE leave both bits unset if they really 
don't care about the reasons why (e.g. the typical end user), can set 
the first bit if they do (typical resolver) and can set both bits for 
debugging (the geeks in the DNSOP group).

In the case of truncation due to EDE, omit the EDE option from the 
response EDNS0 RR.  If you're still overflowing, set the TC. (E.g. this 
isn't about omitting the EDNS0 in the response, only about removing 
bloat when the client hasn't indicated the bloat is useful.

Later, Mike

> So long
> -Ralf
> —--
> Ralf Weber