Re: [Doh] DoH client-server interoperability vs. strict HTTP parameter checking

[Vladimír Čunát <[e-mail]>]

On 6/1/19 4:42 PM, Paul Hoffman wrote:
> RFC 8484 makes it clear that a "DoH server" is just an HTTP server that understands the DoH semantics. Trying to limit it beyond that is just wrong (or maybe just lazy).

OK, I'm certainly not familiar with all HTTP customs, I'm afraid, so
this expectation wasn't clear to me just from reading RFC 8484.


On 6/1/19 11:22 PM, Patrick McManus wrote:
> 8484 does not, and really cannot, proscribe the error handling for
> whether the rest of the http server fixes the issue

I fail to see reasons why an RFC can't (or shouldn't) specify behavior
around unknown parts in the URL.  In this case I suspect that a clear
decision will be better than leaving it unspecified, *regardless* of
which way it will be decided.  I believe the robustness principle is
about handling messages that do *not* conform to such a specification.


On 6/1/19 6:08 PM, Mark Delany wrote:
> Surely a server has to expect that it will eventually be talking to a
> client from the future which will, by definition, be adding unknowable
> parameters.

I wouldn't really expect extensibility on *this* layer.  For DNS itself
there's the whole DNS message in the request and answer (we have EDNS
there).  The HTTP layer would be covered by HTTP headers, I thought.

In particular both these extension "layers" communicate in *both*
directions, which seems very useful for interoperability (first Bert's
paragraph, essentially).  I'm not aware of the HTTP parameters being
usable in both directions, but I'm certainly not a good judge in the
HTTP parts.  I'd generally hope for DoH trying to avoid transmitting
additional information that's not in the embedded DNS messages.


On 6/2/19 5:54 PM, Joe Abley wrote:
>  - I want an answer to the question PIR.ORG/IN/SOA
> <http://PIR.ORG/IN/SOA> with RD=1
>  - I want query minimisation and secure transport for recursive queries
>  - I want you to confirm explicitly that you understand the request
> for query minimisation

DoH is sending binary DNS messages, i.e. they include the RD flag inside
and you actually have to set it the way you want it.  You can also put
EDNS inside and receive it back - that's the probable target of your
second and third example, as I see nothing specific to DoH in there, but
so far there aren't any standardized extensions usable for these (I
believe).


P.S.:
In Knot Resolver case it actually is a bit easier to be strict in this
respect, but that's not important for the protocol discussion ;-)

--Vladimir