Re: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-dns-wireformat-http-02.txt

Paul Vixie <paul@redbarn.org> Thu, 22 March 2018 17:11 UTC

Return-Path: <paul@redbarn.org>
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 305F212704A; Thu, 22 Mar 2018 10:11:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
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 lqJnQMG9ZccM; Thu, 22 Mar 2018 10:11:21 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E83A8126D85; Thu, 22 Mar 2018 10:11:21 -0700 (PDT)
Received: from [10.8.2.102] (185.173.180.112.mixvoip.solutions [185.173.180.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id DD9FE7594C; Thu, 22 Mar 2018 17:11:20 +0000 (UTC)
Message-ID: <5AB3E3B7.3080607@redbarn.org>
Date: Thu, 22 Mar 2018 10:11:19 -0700
From: Paul Vixie <paul@redbarn.org>
User-Agent: Postbox 5.0.24 (Windows/20180302)
MIME-Version: 1.0
To: Bob Harold <rharolde@umich.edu>
CC: Dave Lawrence <tale@dd.org>, dnsop <dnsop@ietf.org>, doh@ietf.org
References: <152168039295.5550.9572034766968749020.idtracker@ietfa.amsl.com> <CAAObRXLm3c-p9rZkn6H6tcEoh3-UT5JW06NXQ_FMyyr2NFMmyw@mail.gmail.com> <23219.33838.166003.614689@gro.dd.org> <CAAObRX+xF5SwVd3x3iXSWd-A0Kpr_ubbOJzn0yTrSk8pc+tm6Q@mail.gmail.com> <23219.56569.2064.711002@gro.dd.org> <CA+nkc8ANQh2wAr6==eNuM82mbD+E2ELzHGizdqF_sGdY-kkOqg@mail.gmail.com>
In-Reply-To: <CA+nkc8ANQh2wAr6==eNuM82mbD+E2ELzHGizdqF_sGdY-kkOqg@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/2radEo9KGcW0AXexNGThct9PbEw>
Subject: Re: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-dns-wireformat-http-02.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 22 Mar 2018 17:11:23 -0000


Bob Harold wrote:
>
> ...
>
> Unfortunately, the resolver needs to make decisions based on the
> original transport, for example if the transport is TCP, it can send any
> size response.  But if UDP, it needs to fit in a smaller size, and it
> often sends less info in the response.  Likewise, session signalling,
> anti-spoofing decisions, etc depend on the transport.

except that i don't find it unfortunately but simply factual, i agree.

>
> That brings up another question.  Would it also need to know the MTU of
> the original connection, or any other info?  (Assuming EDNS is not
> used)  In that case, a different media type is not enough, and we need
> to change the format to add some 'header" info.

not in my opinion. if the far end has a larger MTU outbound than the 
near end had inbound, then truncation damage will occur -- and the 
original initiator will retry with TCP. we just need to be transparent 
so that the original initiator can drive its own transport selections.

-- 
P Vixie