Re: [Doh] [Ext] DNS Camel thoughts: TC and message size

Patrick McManus <pmcmanus@mozilla.com> Sun, 10 June 2018 23:21 UTC

Return-Path: <pmcmanus@mozilla.com>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE966130F29 for <doh@ietfa.amsl.com>; Sun, 10 Jun 2018 16:21:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.234
X-Spam-Level:
X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] autolearn=no 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 zG9M0msPOokx for <doh@ietfa.amsl.com>; Sun, 10 Jun 2018 16:21:43 -0700 (PDT)
Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 8B436130EDE for <doh@ietf.org>; Sun, 10 Jun 2018 16:21:43 -0700 (PDT)
Received: from mail-ot0-f182.google.com (mail-ot0-f182.google.com [74.125.82.182]) by linode64.ducksong.com (Postfix) with ESMTPSA id 3C9073A019 for <doh@ietf.org>; Sun, 10 Jun 2018 19:21:43 -0400 (EDT)
Received: by mail-ot0-f182.google.com with SMTP id w9-v6so16240635otj.7 for <doh@ietf.org>; Sun, 10 Jun 2018 16:21:43 -0700 (PDT)
X-Gm-Message-State: APt69E1StOnr1cwbrxl900MNOL88y4QMyjsYczJCpkwVmMlykKSwioJ+ uwEIiYY8xYay4JSenTWxa1Hm0z/Z+B9ko+sqslU=
X-Google-Smtp-Source: ADUXVKLY5DtmcYBJqjNQPP/NSTbN1l5f1ovuG7HzoLc0H4aYsZzohwYAgfEdv6bjOW/mdVsIHH1SzwVOJopYqdepcj4=
X-Received: by 2002:a9d:1142:: with SMTP id p2-v6mr8243882otp.110.1528672902934; Sun, 10 Jun 2018 16:21:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Sun, 10 Jun 2018 16:21:42 -0700 (PDT)
In-Reply-To: <20180610231704.GB18326@mx4.yitter.info>
References: <CAOdDvNr=kLHPCtCHRx4=rpA1oDogQqdAJ0nR156BWABiFP_bzA@mail.gmail.com> <20180607215851.GA32738@server.ds9a.nl> <CAOdDvNqNpZ8fKPCO5sEqjROBHjg4wx-GGPMYSSynode10jeC0Q@mail.gmail.com> <9381B529-B2F4-459A-88EB-4410A4C4DB6F@mnot.net> <CAN6NTqxA4PcrtS_3umwGERLt9WPoX4p0a0u8pL-O2=CKKTBfyA@mail.gmail.com> <23322.62892.251560.128565@gro.dd.org> <20180608221700.GC8515@mx4.yitter.info> <23323.5488.915402.337488@gro.dd.org> <20180610161645.GF8515@mx4.yitter.info> <CAOdDvNrj20OVysaQHMczeMaiDhup4f5B=2n0xxQWmtTtm-OROA@mail.gmail.com> <20180610231704.GB18326@mx4.yitter.info>
From: Patrick McManus <pmcmanus@mozilla.com>
Date: Sun, 10 Jun 2018 19:21:42 -0400
X-Gmail-Original-Message-ID: <CAOdDvNoZ-wd21c-rzMB0aGVsZQRrp7bSOQhETwxb3nET2pCmfQ@mail.gmail.com>
Message-ID: <CAOdDvNoZ-wd21c-rzMB0aGVsZQRrp7bSOQhETwxb3nET2pCmfQ@mail.gmail.com>
To: Andrew Sullivan <ajs@anvilwalrusden.com>
Cc: DoH WG <doh@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005b7847056e51e522"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/unECPOUANU_IkICSsR1tMRxkc1w>
Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 10 Jun 2018 23:21:46 -0000

On Sun, Jun 10, 2018 at 7:17 PM, Andrew Sullivan <ajs@anvilwalrusden.com>;
wrote:

> On Sun, Jun 10, 2018 at 07:10:18PM -0400, Patrick McManus wrote:
> > I believe the concern is "traditional -> doh -> doh" where the doh ->
> doh link
> > could use wireformat-64 and then the initial traditional client cannot
> consume
> > wireformat-64 but ends up with it anyhow. Is that right?
> >
> > That shouldn't happen. The middle node realizes it is a gateway for a
> > traditional client
>
> It's the part where the middle node _doesn't know_ it's a gateway for
> a "traditional client" that I've been worried about, because someone
> takes their existing code, plops an HTTPS transit on it, and thinks
> they're golden.


so that's a doh client, not a traditional client. And they would have to
opt into the wireformat-64 bits in my example explicitly with a request
header for a non default media type. At some point you have to give them
what they ask for :)



> I know Tale thinks I'm worrying about something that
> Shouldn't Happen, but I think experience tells us this kind of thing
> happens _all the time_ in poorly-constructed DNS implementations.
>
> In any case, I haven't read it carefully but my quick scan of what
> Paul sent to the list makes me think it's enough to prevent that naïve
> sort of implementation (or anyway, at least the document will have
> said it so that if you do the wrong thing it's obviously your own
> fault).
>
> A
>
> --
> Andrew Sullivan
> ajs@anvilwalrusden.com
>
> _______________________________________________
> Doh mailing list
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
>