Re: [dnsoverhttp] New draft: draft-hoffman-dns-over-http-00.txt

[Paul Hoffman <[e-mail]>]

On Sep 21, 2016, at 3:31 AM, Patrick McManus <[e-mail]> wrote:
> Paul - thanks for the draft! This is a good contribution - Some thoughts, in no particular order:
> 
> * I don't have a strong opinion on whether or not the prefix can be discoverable for some use cases, but it seems for h2 push it needs to be in the .wk space in order to give the client enough context to recognize this is dns data. given that, it might make sense to just use .wk everywhere instead of making it discoverable.

I'm maybe hearing a trend here. Does anyone have a strong argument for discoverability over .well_known?

> * you have a todo on how trust works for prefixes based on IP instead of name.. I think that's a little backwards - you want to think of a prefix always using a name (for validation purposes) and in conjunction how to bootstrap an address for it when necessary (i.e. allow optional stapling of some sort)

The TODO is more of a flag on "minefield of widely differing opinions". My current intention is to punt on the topic completely and point to an RFC or IESG statement.

> * the discussion of content negotiation (aka Accept:) doesn't really add anything to the existing http definition - i.e. using it might help you get a content type you know how to decode. Perhaps having a MTI type (json?)  gives this more pertinence and helps deployability. Might as well get the hard stuff on the table early :)

In the DNSOP WG, there isn't agreement that JSON should even be on standards track; the same is true for the wireformat draft. Personally, I don't see a strong reason for a mandatory-to-implement response format. For example, when the JSON format has settled, I intend to spin a really similar experimental document for CBOR in case the IoT folks want one.

> * the observation to set the cache age to the minimum of the included RR TTL is good.. I wonder if you need to go farther in a couple of ways: a] this impacts what you might want to bundle together as additional records etc.. especially when pushing and those could be served as their own pushed responses.. some advice on that would be useful b] I wonder (in the true sense of I don't know) if there is difference in a recursive resolver in just marking this as remaining max-age, or giving the max-age of the fresh TTL and using Age headers to indicate how much of that has passed.. mnot probably has keen insight into that - but it seems to me if the TTL is part of the json or wire format response then this has implications for revalidations and etags

Yeah, this is all good stuff that complicates DNS implementations too. We'll add a bit to the draft and then start a separate thread on it.

> * some advice on how to create etags might be helpful.. especially to the extent that it is responding with tags that represent sets, traditional version tracking might be really hard. hashes spring to mind as something to consider - at the very least the issue should be discussed

Sounds good.

> * with respect to dnssec not authenticating everything we want I personally have a bit of a shrug response.. because obviously adding trust to that response just because of the ip address on the reply doesn't really add any significant value either imo. Caching recursive resolvers tend to obscure this stuff anyhow - especially big public ones. If we thought this was a critical concern (I likely don't) then we could define some opt-in bit for the zone owner to sign indicating they were ok with caches handing out their data on their behalf. But I tend to agree with Martin that the http client needs to be conservative about how far to propagate this information - widening the circle as it gains confidence in it. That's what is happening with other pushed data right now anyhow in practice (it gets scoped to the resource that did the pushing, but after it is used successfully it may end up in the general cache) - though feedback has been that this is too conservative. its an interesting discussion.

...but one that I don't think belongs here. That is, the questions of "who do you trust for your answers, why do you trust them, should they let you trust them" come up occasionally in the DNS working groups as well. If we get an answer to those from the DNS world, that answer needs to be reflected in this protocol, but I don't think the fact that the queries are going over HTTP over TLS makes these queries special.

--Paul Hoffman