Re: [dnsoverhttp] Fwd: New Version Notification for draft-hoffman-dns-over-https-00.txt

[Ben Schwartz <[e-mail]>]

On Thu, May 4, 2017 at 11:17 AM, Patrick McManus <[e-mail]>
wrote:

> Thanks Martin.
>
> On Wed, May 3, 2017 at 11:52 PM, Martin Thomson <[e-mail]>
> wrote:
>
>> On 4 May 2017 at 13:15, Patrick McManus <[e-mail]> wrote:
>> > A new version of I-D, draft-hoffman-dns-over-https-00.txt
>>
>> A few nits only; I need to think more about how this fits into the
>> ecosystem.  I am warming to the notion that you have flexibility in
>> representation format, that's a key advantage of using HTTP.  You have
>> neatly punted on the hard parts of that by choosing the dumb option to
>> document, which means that you can bootstrap effectively.
>>
>
> ack - and I believe Paul has a JSON media-type document going on a
> separate path that should dovetail nicely,  but not be a blocker. I
> certainly would hope to see some JSON in the wild.
>
>
>>
>> The query string uses one of the worst encodings known to man.  Did
>> you do any analysis here?  Is base64url bad for some reason.  For
>> instance, I would believe that it increases the length of the string
>> in the aggregate if you told me.
>>
>
> will open an issue for more analysis.. did one example by hand and it was
> a ~wash size wise.. and the hex made a clearer example :) more study would
> be good, but its a micro opt given the existing bounds on the sizes
> involved.
>
>
>>
>> You should use a parameter name for the query string so that you at
>> least have the chance to automatically discover a service and make
>> requests in other forms using the query string without sniffing or
>> other such horrors (conneg works fine for the POST variant, but you
>> are pushing those uses to a method that isn't a great fit).  What you
>> have consumes the entire usable space in the query string, so it would
>> be hard to get in edgewise with an alternative query form.
>>
>
> so this is interesting. I started down that road, but couldn't really
> figure out how to do any form of negotiation beyond the MTI with it so just
> stuck with the simpler variant you see in -00. 415 seems to apply
> specifically to content-type and bodies so wouldn't work as a signal. Or am
> I being too pessimistic?
>
> Strictly speaking we don't need the uglier GET variant at all - the POST
> is absolutely cacheable. But realistically speaking that will not work with
> a lot of existing caches.
>
>
>
>> Do you really need to encode the ID?  I realize that might be
>> construed as opening the floodgates, but it is going to make caching
>> that much more fragmented.  Can you not just trim it off?
>>
>>
> low friction of using an existing (albeit encoded) format traded off vs a
> couple bytes... that is why the normalization of ID SHOULD is in there tho.
>

The text is

   In order to maximize cache friendliness, DNS API Clients SHOULD use
   the same ID (the first two bytes of the header) for every DNS
   request.

That's enough to ensure that the same client making the same request hits
the cache, but it's not enough to make sure that _different_ clients can
hit a shared cache.  Even different tabs in the same browser won't share
the browser cache unless they select matching IDs.

Personally, I would just skip these two bytes.  Instead of being "part of
the DNS format", I think of the ID as being a generic miniature RPC
protocol, which we are replacing with HTTP.  Failing that, I would say the
ID MUST be zero.

>
>
>
> _______________________________________________
> dnsoverhttp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsoverhttp
>
>