Re: [Doh] A question on the mix of DNS and HTTP semantics

[Ted Hardie <[e-mail]>]

Howdy,

On Sun, Mar 18, 2018 at 4:43 AM, Daniel Stenberg <[e-mail]> wrote:

> On Sun, 18 Mar 2018, Ted Hardie wrote:
>
> Saying something in the document like "only 2xx response codes will carry
>> response bodies with DNS UDP wireformat" would be a short and sweet way of
>> saying that in the document, if there is working group consensus that this
>> is true.  Based on my conversations yesterday, I am not sure that there is
>> complete consensus on this point, though there may very well be rough
>> consensus.
>>
>
> I'm firmly in the only-2xx-carry-response-bodies-to-care-about camp. I
> don't even understand how it would work otherwise.
>
> What other HTTP response codes could be used to transmit DNS responses?
>
>
The 4xx ones, might, as I noted below.


> A pure transport failure may result in a retry.  There are some of these
>> responses which strongly indicate that such a retry will result in failures
>> (e.g. 403).  If you do not synthesize some message to the DNS client about
>> the type of failure, and the server does not provide one, what part of the
>> system avoids the retry?
>>
>
> For all 4xx HTTP response codes, the "fault" is in the client side (the
> request) so if you as a client decide to retry the request it doesn't at
> least make any sense to send an identical request again.
>
>
I think you're thinking of a different layering than I am.  If the DNS
client is talking to the HTTP stack as if it were a transport, and it gets
nothing back (transport failure), it may construct and send the query again
(it might do that in the UDP transport case, for example, on the theory
that the network had dropped the response packet).  To avoid that, you
might want to send a DNS message that encodes the information that this
server will not fulfill this request over this transport.

regards,

Ted


> I don't think 4xx strictly avoids retries. It informs the client about the
> fact that the request, as-is, was denied. A retry would then have to change
> something in the request for it to be successful. 401 and 407 are good
> examples of this, for which clients often retry with a modified request
> (with added auth headers).
>
> --
>
>  / daniel.haxx.se
>