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

Patrick McManus <pmcmanus@mozilla.com> Fri, 08 June 2018 20:50 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 5D319127AC2 for <doh@ietfa.amsl.com>; Fri, 8 Jun 2018 13:50:33 -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 JSQLtkhsdWE3 for <doh@ietfa.amsl.com>; Fri, 8 Jun 2018 13:50:30 -0700 (PDT)
Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 1B26212F1A5 for <doh@ietf.org>; Fri, 8 Jun 2018 13:50:30 -0700 (PDT)
Received: from mail-oi0-f46.google.com (mail-oi0-f46.google.com [209.85.218.46]) by linode64.ducksong.com (Postfix) with ESMTPSA id C81813A0E9 for <doh@ietf.org>; Fri, 8 Jun 2018 16:50:28 -0400 (EDT)
Received: by mail-oi0-f46.google.com with SMTP id b130-v6so12948075oif.12 for <doh@ietf.org>; Fri, 08 Jun 2018 13:50:28 -0700 (PDT)
X-Gm-Message-State: APt69E0qE0wbBfd0uwUnwivlN/tEvq3rCq+qjwz0n9o+HGqzG+p8kpkK OkJii03U2fQhSwvGdhQwUWbC5DmSgdktdsJpo0k=
X-Google-Smtp-Source: ADUXVKLT8awna5+mN9VXOMcpBjvULV2y59ukpHn4b/eM/2ZcKg7Y2VS4pcx+aRGZ8B56TqF7sn1CmwRcjYGQnIXMH3E=
X-Received: by 2002:aca:5a44:: with SMTP id o65-v6mr3792114oib.155.1528491028355; Fri, 08 Jun 2018 13:50:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Fri, 8 Jun 2018 13:50:27 -0700 (PDT)
In-Reply-To: <CAN6NTqxA4PcrtS_3umwGERLt9WPoX4p0a0u8pL-O2=CKKTBfyA@mail.gmail.com>
References: <20180606093212.GA23880@server.ds9a.nl> <alpine.DEB.2.11.1806061501340.10764@grey.csi.cam.ac.uk> <F5774061-35B9-477F-ADDA-8BB3472F30EF@icann.org> <CAOdDvNq9g3ghbg9fkfhP+ZA4-6E5oDNFCGo6NN9bydqUX76cLA@mail.gmail.com> <20180607093647.GB32326@server.ds9a.nl> <CAOdDvNriZDjU9yqUQjqN4fO84ENPWO3si-QePiKRgt+7VJVK0g@mail.gmail.com> <23321.27027.73356.94056@gro.dd.org> <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>
From: Patrick McManus <pmcmanus@mozilla.com>
Date: Fri, 8 Jun 2018 16:50:27 -0400
X-Gmail-Original-Message-ID: <CAOdDvNq=j7dGh9cSeL_vdhbtLO+iO18ToBWrJG_pfRZJffaGVg@mail.gmail.com>
Message-ID: <CAOdDvNq=j7dGh9cSeL_vdhbtLO+iO18ToBWrJG_pfRZJffaGVg@mail.gmail.com>
To: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= <olafur@cloudflare.com>
Cc: Mark Nottingham <mnot@mnot.net>, Patrick McManus <pmcmanus@mozilla.com>, DoH WG <doh@ietf.org>, bert hubert <bert.hubert@powerdns.com>, Dave Lawrence <tale@dd.org>
Content-Type: multipart/alternative; boundary="000000000000c9a108056e278ce4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/02snyi_4WOTPo5zzXINDIu7ED64>
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: Fri, 08 Jun 2018 20:50:34 -0000

On Fri, Jun 8, 2018 at 4:31 PM, Ólafur Guðmundsson <olafur@cloudflare.com>;
wrote:

>
>
> On Fri, Jun 8, 2018 at 5:46 AM, Mark Nottingham <mnot@mnot.net>; wrote:
>
>> AFAICT there are two of situations that might be relevant here:
>>
>> 1. A DOH request is gatewayed to "normal" DNS
>> 2. A DOH response is gatewayed to "normal" DNS
>>
>> Could the folks who are concerned about this explain if there are any
>> others (with detail)?
>
> Actually I think what DNS people are concerned about is
>  Query over DNS ==> DoH ==> Auth server generates big answer ==> Doh Reply
> => Answer over DNS  fails due to size limit.
> so the fundamental problem is when different transports have different
> size "limitations"
> In my mind 64K is fine size and if any entity is STUPID enough to give out
> 888K answer on DNS port they will learn quickly.
>
>
I'm not 100% sure I understand the illustration. perhaps we don't have a
shared understanding of http content negotiation. is the example saying the
terminal auth server generates a non-wireformat big answer and that's why
its big?

A DoH client that was gatewaying from the traditional DNS client wouldn't
send an Accept: big-json (or whatever) request header for exactly this
reason and the DoH server would recognize that and send the best MTI format
it could manage (which is also what the server does if it didn't implement
the json type and it did see the accept header)

but a DoH client that was natively interpreting the response with its own
Json parser would indeed send such a request header. Its effectively an opt
in. (the server isn't absolutely prohibited from sending something you
didn't opt in to, but you would only do it if you had nothing else..
because the client will probably treat it as an error.. so instead you send
whatever version of the MTI you can manage)

a gateway that was playing a caching proxy role just has to deal with 2
variants of the URI in that case - that's a normal http cache problem.

I think that's all 3 versions of that scenario..






> The issue with encoding formats is that 1K DNS wire format is not 1K Jason
> or 1K compressed Jason (not saying which one is going to be the biggest)
> So if there is any rule needed it that answer should fit in 64K DNS
> wireformat with Name compression enabled.
> ===> from this my assertion is that any given transport format can have
> its own limit that reflects the "compactness" of the encoding and
> compression but a general rule is not possible
> The guiding light is "do not be stupid" but that does not work in practice
> .......
>
> so we are stuck with artificial limits.
>
>>
>
>
>> For #1, the DOH gateway should know the limitations of the protocol it's
>> gatewaying (in this case, DNS over UDP), and can generate a 413 or 414
>> status code as appropriate (see <https://httpwg.org/specs/rfc7
>> 231.html#status.413>). That's the correct way to express "that request
>> is too big" in HTTP. Some non-normative advice in the spec about DOH
>> servers generating appropriate status codes and clients understanding them
>> might help here.
>>
> +1
>
>
>>
>> For #2, it seems like people are claiming that a client library is going
>> to implement DOH but *not* update itself to take arbitrary-sized responses.
>> Is anyone actually saying that's their implementation strategy, or is this
>> just "what if"-ism?
>>
>
> +1
>
>
>>
>> If it's necessary to support those clients, it would be easy enough to
>> define a preference <https://tools.ietf.org/html/rfc7240> that allows
>> them to say "please give me small* responses", and require DOH servers to
>> honour that preference.
>>
>> +1
>
> Olafur
>
> Cheers,
>>
>> * Where "small" is defined as "able to be expressed in less than N bytes
>> in the UDP wire format" or similar. Limiting *all* DOH messages using
>> Content-Length is not what we want to do here.
>>
>>
>> > On 8 Jun 2018, at 11:34 am, Patrick McManus <pmcmanus@mozilla.com>;
>> wrote:
>> >
>> > I'm not on board with limiting a 2018 protocol to 64KB variants because
>> some parser of some some format might have a bug. At the very least we need
>> to be more specific so we can assess the scope of the interoperability
>> issue. DoH opens up new things - that's a good property. Not everything
>> will be gatewayed back and forth into wireformat, and the wireformat isn't
>> inherently limited to 16bit either. AXFR is an especially interesting case
>> for DoH because it supports multiplexing and priority between streams, it
>> might actually be the best way to carry it.
>> >
>> > as for other formats they are coming. Paul has an informational draft
>> that has been sent to the IESG: https://datatracker.ietf.org/d
>> oc/draft-hoffman-dns-in-json/ and I've heard rumors of others in the
>> works - even from the dns community :)
>> >
>> > If there is a known problem with gatewaying between formats, that's
>> worth some non normative text to mention - but the notion that 64KB is
>> enough for anybody is one I want to push back on. Even for that I would
>> appreciate a citation of where the problem lays - there isn't agreement
>> that wireformat actually has such a limit (though its existing transports
>> do and maybe that's what should be noted), and no particular implementation
>> choices, much less widely deployed and hard to upgrade implementations,
>> have been cited (again - I'm not saying they don't exist.).
>> >
>> > -Patrick
>> >
>> > On Thu, Jun 7, 2018 at 11:58 PM, bert hubert <bert.hubert@powerdns.com>;
>> wrote:
>> > On Thu, Jun 07, 2018 at 11:39:16PM +0200, Patrick McManus wrote:
>> > > > "Sort of".  Wire format itself does not have the limitation.  Its
>> use
>> > > > on certain transports does.  This distinction needs to keep being
>> > > > made.
>> > > tale has convinced me of this point.
>> >
>> > In the interest of reaching consensus, can we park this discussion until
>> > another message type is invented and standardised that is not a DNS
>> message
>> > in "wire format"?
>> >
>> > Whenever we make life harder on the whole DNS implementation community,
>> we
>> > had better have a very good reason for that.
>> >
>> > To put it bluntly, a significant part of the DNS implementation
>> community
>> > (ISC, NLNetLabs, CZNIC, PowerDNS) has voiced that the 2^16 byte limit is
>> > here to stay for now, so I don't see a viable consensus for expanding
>> DNS -
>> > especially given the lack of concrete usecases.
>> >
>> > Finally, I note that the DOH charter contains the following:
>> >
>> > "The working group will coordinate with the DNSOP and INTAREA working
>> groups
>> > for input on DNS-over-HTTPS's impact on DNS operations and DNS
>> semantics,
>> > respectvely.
>> >
>> > In particular, DNSOP will be consulted for guidance on the operational
>> > impacts that result from traditional host behaviors (i.e.,
>> stub-resolver to
>> > recursive-resolver interaction) being replaced with the specified
>> mechanism..
>> >
>> > Specification of how DNS-formatted data may be used for use cases beyond
>> > normal DNS queries is out of scope for the working group."
>> >
>> > It may be good to point out that 'normal DNS queries' have never
>> involved
>> > getting >64KB responses. We might also have to consult DNSOP about
>> changing
>> > DNS semantics, an activity they aren't stimulated to explore.
>> >
>> > Finally, I do really understand how much fun it would be to liberate DNS
>> > from its pedestrian 64KB shackles. It is an arbitrary limitation, and
>> > perhaps one day we'd love to put gigantic post-quantum cryptographical
>> keys
>> > in DNS. But given the amount of developer cycles in DNS, please also
>> > understand my (our) reticence in overhauling this ancient protocol.
>> >
>> >         Bert
>> >
>> > _______________________________________________
>> > Doh mailing list
>> > Doh@ietf.org
>> > https://www.ietf.org/mailman/listinfo/doh
>>
>> --
>> Mark Nottingham   https://www.mnot.net/
>>
>> _______________________________________________
>> Doh mailing list
>> Doh@ietf.org
>> https://www.ietf.org/mailman/listinfo/doh
>>
>
>
>
> --
> Ólafur Gudmundsson | Engineering Director
> www.cloudflare.com blog.cloudflare.com
>