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

Ben Schwartz <bemasc@google.com> Mon, 02 December 2019 17:27 UTC

Return-Path: <bemasc@google.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0AC91200C3 for <dnsop@ietfa.amsl.com>; Mon, 2 Dec 2019 09:27:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.499
X-Spam-Level:
X-Spam-Status: No, score=-17.499 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, HTML_MESSAGE=0.001, 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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0RkCi5m9Zsi for <dnsop@ietfa.amsl.com>; Mon, 2 Dec 2019 09:27:36 -0800 (PST)
Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80FAA120099 for <dnsop@ietf.org>; Mon, 2 Dec 2019 09:27:36 -0800 (PST)
Received: by mail-il1-x12a.google.com with SMTP id u17so393896ilq.5 for <dnsop@ietf.org>; Mon, 02 Dec 2019 09:27:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=PfCCL3ZnEXTk7HfPemP26st5xVH8NltL0P/BH/AuZG0=; b=Qe5wZAvgt9b1BBMDCT7tA1FzzpwMcGXAUzxzdialIeirZVIqpWYxBLjRlD7b23us+s WFQ3c/U4CTUCY3WK9HiMQL9fraoAq7pxqJUdon0+3lET8kg5nsWDS44LS8uf+LoChXwL n2DnB23rL8mHfDDoM1hPFeZWxEw2Dhkagym80s8vOVUpN+m7wgdjTTDhSuSVxRQ76Fl8 u50vHDFvmhtsBuaE3JF4Abl9x+PP/ZU2FnPWg8t08DuG7BFyopqASiggtf46Zd8dK32w qbLsyOhlcVonTqwfSIUiFR4D1Qc4U4fRTxI+EdnpSyZrxIOPHaPsXzIcM/A927rtC5dn ycZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=PfCCL3ZnEXTk7HfPemP26st5xVH8NltL0P/BH/AuZG0=; b=Jjm5fpwqtDc4CEknYOgmx9lzSP14lZjWmENquilYC/jAulQysEYLOYT/9BO35MBazQ XpS49FJ0cGx0KWew8GM7WkbZkhIqsi9ip1ujj9OopFXBk7nh9D3ucwtpZTWsnjjc6+ev zs2rW7W+AhNaZuTHNB94tSUJPFZPISYBPJX7y03GOaXF+9GspT58td8/MChthVLBZ912 koxg32tIdi7IkZjbFAcOE/WaySRMuXj2zdAV22DUIxudmx7PvBW3B03PFYQGJohR4xEf wlPU0GkKiLQ0+4pvNhIyqJVqeUpQJt8tuJbUOzA0bVK9wibSDaBO02I8goBZSWkUbaSf L8Fw==
X-Gm-Message-State: APjAAAXZx3YIEf+rqg6VIgRctCzzbvtoNZKn6EJxjf23rO5qqtu7rr4M kIhOFrBSGtXDpCuILB8VM9WIS3Yo3li2l+N7uxcDtKH5
X-Google-Smtp-Source: APXvYqxbU9y7dpGllIL4e2RdPLkThym+bSfq4iD9XnmJWRMWVghzNK+ZL1FgxTe2H7ToJ4Ih/HgJyd4GSb8kK8lhENA=
X-Received: by 2002:a92:6a07:: with SMTP id f7mr68629801ilc.41.1575307655148; Mon, 02 Dec 2019 09:27:35 -0800 (PST)
MIME-Version: 1.0
References: <yblzhgpwwit.fsf@wu.hardakers.net> <CAHbrMsBR6LZ880RXPDW2L+c_gcC6Tpg+L_c78OZvxJs4Gc4pUQ@mail.gmail.com> <9641D361-6A98-4B4B-BAAD-20327194EC4B@dukhovni.org>
In-Reply-To: <9641D361-6A98-4B4B-BAAD-20327194EC4B@dukhovni.org>
From: Ben Schwartz <bemasc@google.com>
Date: Mon, 02 Dec 2019 12:27:23 -0500
Message-ID: <CAHbrMsDQUTZ=M9Pwgs6pXKe0gCcuH6fSSk-4efhXdhfev0W7yw@mail.gmail.com>
To: dnsop <dnsop@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="0000000000003aca170598bbe562"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/x6ZFqh4ukD7ZqOKC1xn3qgpxIs8>
Subject: Re: [DNSOP] Consensus suggestion for EDE and the TC bit
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Dec 2019 17:27:38 -0000

On Thu, Nov 21, 2019 at 3:10 AM Viktor Dukhovni <ietf-dane@dukhovni.org>
wrote:

> > On Nov 21, 2019, at 2:37 AM, Ben Schwartz <bemasc@google.com> wrote:
> >
> > To be clear, we are talking only about the case where a response "fits"
> until the EDE is added, after which it exceeds the limit and is truncated.
> If optimizing this situation is important, I would suggest adding a
> requirement to the EDE draft that EDE be the last option in OPT.  Then as a
> client, I can easily detect this situation, because the truncation point is
> in the middle of the EDE option.  The client logic then is very simple: if
> I don't care about EDE, I can ignore the TC bit.
>
> Not sure what you mean by "in the middle of the EDE option", IIRC
> truncation IIRCin DNS is never "in the middle" of an element, we
> either send the whole element or don't send it.
>
> For the OPT RR, I think that means that it includes a set of
> complete options.
>

Thanks for the correction.  With that in mind, I agree that this trick
would not work.


>
> I do agree that truncation due to EDE should be rare, and therefore
> also TCP failover as a result of such truncation, so if the consensus
> is to keep it simple, so be it, but I don't see how how the client
> could figure out what was left out...
>
>
> --
>         Viktor.
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>