Subject: [Doh] a tad confused on response sizes

From: bert hubert <[email-masked]>
Date: Tue, 5 Jun 2018 14:05:10 +0200

Dear DOH-people,

As I'm implementing DOH in dnsdist (expect something you can try later this
week), I am a bit confused.

The question is what maximum response size I should send in the absence of
an EDNS buffer size.  So let's say a query comes in without EDNS for
www.whitehouse.gov, but the answer exceeds 512 bytes.  Should I truncate?

I have read the draft and previous discussion, which has led to:

	Also note that while [RFC1035] says "Messages carried by UDP are
	restricted to 512 bytes", that was later updated by [RFC6891].  This
	protocol allows DNS on-the-wire format payloads of any size."

This is not explicit on what an implementation should do, only what the
protocol could support. Some further text:

	A DNS API server is allowed to answer queries with any valid DNS
	response.  For example, a valid DNS response might have the TC
	(truncation) bit set in the DNS header to indicate that the server
	was not able to retrieve a full answer for the query but is
	providing the best answer it could get.  A DNS API server can reply
	to queries with an HTTP error for queries that it cannot fulfill. 
	In this same example, a DNS API server could use an HTTP error
	instead of a non- error response that has the TC bit set.

This seems says sending a TC response is some kind of error, which implies
a DNS API server should be willing to send 65 kilobyte answers.

I think for the new usecases, this would be a fine default. However, there
might be UDP-to-DOH bridges which would then need to put explicit EDNS
buffersize of 512 in there if they get non-EDNS adorned UDP queries.

If the '65 kilobyte' interpretation is correct, I can supply text that will
hopefully make this explicit and unconfuse future implementers.

	Bert

---

From: Dave Lawrence <[email-masked]>
Date: Tue, 5 Jun 2018 09:02:26 -0400

bert hubert writes:
> This seems says sending a TC response is some kind of error, which
> implies a DNS API server should be willing to send 65 kilobyte
> answers.

Yes, based on previous conversations, this is basically the case --
though not just 6kk, but theoretically even longer.  While 64k is the
limit on DNS/TCP, it is not an intrinsic limit of DNS wire format
encoding.

Note, I'm not advocating that DoH servers should be sending such large
messages, just that like with other HTTPS messages there is no hard limit.

> buffersize of 512 in there if they get non-EDNS adorned UDP queries.

Right, there is a separate matter of handling transparent proxies, but
for the basic use case a client/server should not have to muck around
with the network limitations of the DNS protocol.  That's one of the
wins of using HTTPS.

> I can supply text that will hopefully make this explicit and
> unconfuse future implementers.

Excellent, but do note that we are on the cusp of moving the document
along.  Please do so quickly for the authors to evaluate.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 5 Jun 2018 14:13:02 +0000

On Jun 5, 2018, at 5:05 AM, bert hubert <[email-masked]> wrote:
> This seems says sending a TC response is some kind of error

Not at all. The first sentence is quite explicit. 

> , which implies

...if it wants to, yes.

> buffersize of 512 in there if they get non-EDNS adorned UDP queries.

Bridges and proxies and gateways, for any protocol, always have to make these kinds of decisions. 

> hopefully make this explicit and unconfuse future implementers.

Sure, please do.

--Paul Hoffman

---

From: Tony Finch <[email-masked]>
Date: Tue, 5 Jun 2018 15:13:56 +0100

> a DNS API server should be willing to send 65 kilobyte answers.

Yes.

> buffersize of 512 in there if they get non-EDNS adorned UDP queries.

If a UDP-to-DoH proxy gets an oversized answer it will have to do
its own truncation.

My trivial DoH code makes upstream queries over TCP, so the EDNS buffer
size is ignored. I don't think a DoH server should have to truncate
answers.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Tyne, Dogger: North 5 or 6, becoming cyclonic 3 or 4, occasionally 2 later.
Moderate. Occasional drizzle later. Good, occasionally poor later.

---

From: Tony Finch <[email-masked]>
Date: Tue, 5 Jun 2018 15:17:26 +0100

> Not at all. The first sentence is quite explicit.

Thinking about this further, I think this is a bug, because a DoH client
doesn't have any way to recover from TC.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Shannon, Rockall, Malin: Variable or cyclonic, 3 or 4. Slight, occasionally
moderate. Mainly fair. Moderate or good.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 5 Jun 2018 14:48:30 +0000

> doesn't have any way to recover from TC.

A non-DOH DNS client that can't get a TCP connection to the resolver open can't recover either. Also note that the second sentence indicates that the TC bit could indicate that the resolver itself couldn't get the full response. 

In both cases, the TC bit means "here's the best I got". 'Twas always thus.

--Paul Hoffman

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 5 Jun 2018 10:50:29 -0400

> In both cases, the TC bit means "here's the best I got". 'Twas always thus.

Except that in DNS there's a clearly defined path for what to do next,
whereas I am equally mystified what a DNS API client is supposed to do
if it receives such a bit.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Tony Finch <[email-masked]>
Date: Tue, 5 Jun 2018 16:07:42 +0100

Paul Hoffman <[email-masked]> wrote:
> A non-DOH DNS client that can't get a TCP connection to the resolver
> open can't recover either.

That's not a supported configuration - RFC 7766.

> In both cases, the TC bit means "here's the best I got". 'Twas always thus.

No, TC means "I have more to tell you but it wouldn't fit in your buffer".

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fisher: East 4 or 5, decreasing 2 or 3. Moderate or rough, occasionally slight
later. Mainly fair. Moderate or good.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 5 Jun 2018 17:13:36 +0200

On Tue, Jun 05, 2018 at 10:50:29AM -0400,
 Andrew Sullivan <[email-masked]> wrote 

> Except that in DNS there's a clearly defined path for what to do

Clearly defined, but certainly not implemented
everywhere. <vague>Many</vague> resolvers cannot retry over TCP.

(At this time, 'DNSKEY renater.fr' cannot be retrieved with a typical
EDNS buffer size. Try it.)

> whereas I am equally mystified what a DNS API client is supposed to
> do if it receives such a bit.

The way I understand it, it is a local decision by the client. Give in
for this data, or choose a better DoH server. I think that a DoH
server returning truncated answers is legal (RFC-compliant) but bad
and, as a client, I would prefer to switch to another one.

Practically speaking, for the RFC, what do you suggest? Forbidding TC?
Then, what would the client do if it still receives one? (The point of
DoH is to use DNS wire format, so a client has to be ready for
anything which is legal DNS.)

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 5 Jun 2018 17:23:55 +0200

On Tue, Jun 05, 2018 at 04:07:42PM +0100,
 Tony Finch <[email-masked]> wrote 

> No, TC means "I have more to tell you but it wouldn't fit in your buffer".

TC is supposed to be hop-to-hop but DoH makes things more complicated,
the HTTPS link having different semantics. For DoH, it means (I quote
the -10 draft) "I was not able to retrieve a full answer for the query
but I give you the best answer I could get"

PS : what happens when a DNS-over-TCP client receives a truncated
answer over TCP? It is technically possible and nobody expects RFC
7766 to address this point.

---

From: Tony Finch <[email-masked]>
Date: Tue, 5 Jun 2018 17:17:00 +0100

> but I give you the best answer I could get"

That is not consistent with RFC 1035:

        TC      TrunCation - specifies that this message was truncated
                due to length greater than that permitted on the
                transmission channel.

Since https's permitted length is longer than a DNS message,
it is invalid for a DoH server to truncate.

> answer over TCP?

RFC 1035 doesn't allow TC for TCP messages.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Portland, Plymouth: Northeast 4 or 5, becoming variable 3 or 4. Mainly slight.
Thundery showers in south. Moderate or good, occasionally poor at first.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 5 Jun 2018 12:42:26 -0400

> everywhere. <vague>Many</vague> resolvers cannot retry over TCP.

Oh, for sure.  But I'm not trying to fault any document for developers
not implementing things :)  I'm just worried that this document
doesn't actually tell anyone what to do if they get such a bit, or if
it does I don't understand it.  (This could well be a failing in me,
please let me emphasise.)

> anything which is legal DNS.)

I wonder whether the TC should be an indicator that the upstream
resolution process got a truncated response and was unable to fetch a
response that was not truncated.  In such a case, the DNS API client
can do whatever it would do in such cases otherwise.  (Some resolvers
in that case throw some kind of error, whereas others will happily
give you the truncated response and let you attempt to go ahead even
if you may well have poison, &c &c.)  I guess I don't have strong
feelings about the right answer, but I want the handling to be clear.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Star Brilliant <[email-masked]>
Date: Tue, 5 Jun 2018 16:43:59 +0000

> it is invalid for a DoH server to truncate.

No, DoH server never truncates messages.
It is the upstream server that truncates the message.

> RFC 1035 doesn't allow TC for TCP messages.

The fact is that there are TCP servers that do truncates messages.
There are also servers that firewalls TCP by mistake so only UDP could pass.
Some of them are even authoritative server that you have no other ways to bypass.

So here is the question: what should you do if you received a TC from a TCP upstream?
I run massive deployment of DoH server, and I see this kind of packets quite often.

Yes, we know it is not RFC1035-compliant. But what can a DoH server do with this kind of malformed packet?
1) Ignore the TC bit and return the truncated answer to DoH client?
2) Take the TC bit and return the truncated answer to DoH client?
3) Return SERVFAIL and persuade users to give up your DoH service?
4) Return HTTP 500 / 502 / 503 to mislead users that your server crashed?
5) Throw a Segfault with a pretty-printed stacktrace in your syslog?

You could do nothing but keep the TC bit. That is why DoH allows TC bit.

TL;DR: It's not the DoH server that truncates. It's somebody else truncates and DoH could do nothing (even with TCP) to fix it.

---

From: Tony Finch <[email-masked]>
Date: Tue, 5 Jun 2018 18:14:36 +0100

> It is the upstream server that truncates the message.

If a DoH server talks to an upstream resolver over a truncating transport,
the DoH server has to retry over a non-truncating transport.

> Some of them are even authoritative server that you have no other ways to bypass.

They are all broken and don't implement the protocol correctly.

> 3) Return SERVFAIL and persuade users to give up your DoH service?

I think those are all reasonable. My DoH server just returns its
upstream's header verbatim. Its upstream resolver is responsible for
correct DNS semantics.

> You could do nothing but keep the TC bit. That is why DoH allows TC bit.

The point of this discussion is what the client is supposed to understand
by TC in a response. RFC 1035 implies that (over TCP) TC must not be set
by a server and must be ignored by a client. DoH should be the same.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Biscay: Cyclonic 3 or 4. Slight. Thundery showers. Good, occasionally poor.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 5 Jun 2018 17:23:24 +0000

On Jun 5, 2018, at 10:14 AM, Tony Finch <[email-masked]> wrote:
> RFC 1035 implies that (over TCP) TC must not be set
> by a server and must be ignored by a client.

I don't see that implication in RFC 1035.

--Paul Hoffman

---

From: Dave Lawrence <[email-masked]>
Date: Tue, 5 Jun 2018 13:46:40 -0400

> RFC 1035 doesn't allow TC for TCP messages.

It doesn't?  By inference do you mean, only because it got mentioned
in section 4.2.1, UDP usage, and not in 4.2.2, TCP usage?  It's a bit
stronger statement to make that it isn't allowed, especially since
what you quoted from 4.1.1 is transport agnostic:

|       TC      TrunCation - specifies that this message was truncated
|               due to length greater than that permitted on the
|               transmission channel.

---

From: Dave Lawrence <[email-masked]>
Date: Tue, 5 Jun 2018 13:49:54 -0400

> by a server and must be ignored by a client. DoH should be the same.

I do not read that implication at all.  What I would understand as an
implementer if I got TC on any channel is that the message is missing
information it should otherwise have had.  Whether it has enough other
information to me to find useful is a separate matter, but it is still
providing useful signal that the message is incomplete.

---

From: Star Brilliant <[email-masked]>
Date: Tue, 5 Jun 2018 17:50:13 +0000

> the DoH server has to retry over a non-truncating transport.

I agree. But obviously you did not read my message well.
A DoH server should retry over TCP.
I am only talking about the last resort, when TCP does not work or still returned TC.

> They are all broken and don't implement the protocol correctly.

As we know, the browser that can render broken HTML tag soup wins the battle.
That's the same with DNS. If you are not compatible with broken implementations, users will not use your product.
Our code don't produce garbage, but we need to consume garbage produced by others, right?
So please don't make excuses for your writing less compatibility code (in case if so).

> by a server and must be ignored by a client. DoH should be the same.

The DoH client does not need to understand the TC bit. It just pass the TC bit to downstream.
Let me explain how this work:

When the downstream finds the TC bit, it should retry with TCP to the DoH client.
And the DoH client should return the exactly same answer with TC.
The downstream should stop retrying with the second TC (since there are no more methods to retry).

I think it makes sense.

> size is ignored.

Just a friendly warning:
I have done this thing in my productive server, and soon get banned by some authoritative servers.
Most authoritative servers on the Internet are really really fragile.
Anyway, it's okay to use full TCP, if you don't do recursion yourself.

And in case if I misunderstood... Could we make this discussion less gunpowder-smelly and more kind?

---

From: Tony Finch <[email-masked]>
Date: Tue, 5 Jun 2018 19:02:40 +0100

> I don't see that implication in RFC 1035.

On the server side, RFC 1035 does not say that the TC bit is for TCP
transports, therefore it is left clear. On the client side, TC only has a
defined meaning for UDP.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fitzroy, Sole: Northerly 4 or 5, becoming variable 3 or 4, then southerly 4 or
5 later in west. Slight or moderate. Showers at first, rain later in west.
Good, occasionally poor.

---

From: Tony Finch <[email-masked]>
Date: Tue, 5 Jun 2018 19:12:31 +0100

> The downstream should stop retrying with the second TC (since there are no more methods to retry).

I'm afraid I don't understand that at all.

In many cases, the DoH client will be embedded in an application as an
alternative to a traditional stub resolver, so it doesn't have a
downstream that can retry.

> some authoritative servers.

My DoH server is a proxy that talks to a full-service resolver that I
control.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
fight poverty, oppression, hunger, ignorance, disease, and aggression

---

From: Star Brilliant <[email-masked]>
Date: Tue, 5 Jun 2018 18:28:21 +0000

> downstream that can retry.

I think the problem is simpler when you state your application scenario.

In my opinion (other people may disagree with me), you could just treat a DoH response with TC as a resolve error and give the user a "network error" screen.

In other words, a DoH with TC bit can happen, and that's a common error. (Not as common as an unplugged network cable, but actually happens really frequently on a busy recursion server.)

And TC bit needed to be passed all along the way through bouncers/proxies/SLBs to the user's application, because errors should not "silently fail".

> My DoH server is a proxy that talks to a full-service resolver that I

That's good to know. Thanks.

---

From: Tony Finch <[email-masked]>
Date: Tue, 5 Jun 2018 21:26:14 +0100

Star Brilliant <[email-masked]> wrote:
>
> In other words, a DoH with TC bit can happen, and that's a common error.
> (Not as common as an unplugged network cable, but actually happens
> really frequently on a busy recursion server.)

I would be interested to know of a query that produces a TC response over
TCP.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Southeast Iceland: Variable 3 or 4. Slight. Fair. Good, occasionally poor in
north.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 5 Jun 2018 22:10:33 +0000

> I would be interested to know of a query that produces a TC response over

Resolver 1 sends a query to a Resolver 2 (who allows forwarding) over TCP. Resolver 2 asks an authoritative,  gets a response with TC bit set on, tries on TCP, and gets a failure on TCP. Resolver 2 should send the partial answer it got over UDP to Resolver 1. That answer to Resolver 1 should have the TC bit set on, or not, depending on what you think that RFC 1035 "implies".

--Paul Hoffman

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 5 Jun 2018 18:24:16 -0400

> Resolver 1 sends a query to a Resolver 2 (who allows forwarding) over TCP. Resolver 2 asks an authoritative,  gets a response with TC bit set on, tries on TCP, and gets a failure on TCP. Resolver 2…

Alternatively, maybe Resolver 2 should send some error (I'm guessing
SERVFAIL is the answer, though I suppose Vixie would be unhappy with
that guess).

The problem, of course, is that a TC'd answer is literally telling you
it's incomplete, and in principle you have an incomplete RRset, which
is maybe important.  It's not clear you should use it, and it's pretty
clear (at least to me) that you shouldn't cache it.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Tony Finch <[email-masked]>
Date: Tue, 5 Jun 2018 23:26:22 +0100

> On 5 Jun 2018, at 23:10, Paul Hoffman <[email-masked]> wrote:
> 

In my experience this results in a SERVFAIL.  RFC 2181 has a specific instruction not to do what you suggest:

>> When a DNS client receives a reply with TC set, it should ignore that response, and query again, using a mechanism, such as a TCP connection, that will permit larger replies. <<

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at

---

From: Star Brilliant <[email-masked]>
Date: Wed, 6 Jun 2018 04:37:21 +0000

On Wed, Jun 6, 2018 at 6:26 AM Tony Finch <[email-masked]> wrote:
> In my experience this results in a SERVFAIL.

What is your "experience"? In my experience, Google does produce TC (see attachment picture).
In other words, even if the RFC is changed to "the DoH server never produces TC bit", your client should still be ready for a TC bit, simply because such implementations already exist.

>  RFC 2181 has a specific instruction not to do what you suggest:

RFC 2181 defines what a DNS server and a DNS client should do, *not a DoH server or client*.
A DoH server or client is not a DNS client or server, because it does not necessarily need to fully understand everything inside a DNS packet (although it can, for cache or whatever reason)

A DoH server *never* touches the TC bit, it's the buggy upstream DNS server that sets the TC bit on a TCP connection. (It's their fault, not DoH's.)
A DoH client *never* reads the TC bit, it just verbatim passes the response to the downstream DNS client. It's the downstream's responsibility to either drop or consume the response.

In your case, you don't have a downstream DNS client, then just imagine two modules in your code.
Anyway, whatever DoH does is not violating RFC 2181, as long as DoH does not touch the TC bit.

"Garbage in, garbage out."
If your network software can't consume garbage produced by others, you are out. (Hi Netscape!)
your software loses users and loses the competition. That's simple.

P.S. I'm not going to talk about this issue any more since I don't think the current specification is inappropriate. Also practice shows it is working.
And just for joke, I'm just too lazy to change the behavior of my software that some hundred people are already relying on. :-)

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 6 Jun 2018 02:23:52 -0400

Dear colleagues,

I gather our colleague Star Brilliant has given up on this thread, but
I think there is still an issue here.

> RFC 2181 defines what a DNS server and a DNS client should do, *not a DoH server or client*.

I think what Tony has been saying, and certainly what I have attempted
to say, is that this sort of dismissal of ordinary DNS assumptions is
just not helpful, because some portion of the audience of this
document will be people coming at HTTP(S) from a DNS background.
They're going to import DNS assumptions, and if we haven't dealt with
them in the document we'll get less-interoperable implementations.

The document as near as I can tell does a lot of work to align nicely
with HTTP "normal stuff".  But I think it ought to be a serious
problem that people with fairly deep expertise in DNS implementation
and deployment keep asking pointed questions.  I don't think anyone
asking these questions is attempting to slow progress or prevent
deployment (people may say what they will of me, but neither Bert nor
Sara nor Tony are, in my books, part of the "get off my lawn" crowd).
It's just that there are well-understood sharp corners in the DNS, and
people who are looking at the current I-D from the point of view of
general purpose resolution are trying to figure out, "How does that
$familiar_thing work?" and coming up with no answer.

The WG can perfectly reasonably conclude, "Yep, that part of DNS
resolution already sucks, and you DNS people ought to burn in hell."
But that needs to go in the document, not be something that people
have to infer.  There's already _way too much_ inference in how
name resolution on the Internet works, and I would like us to make
that better rather than worse.

So, I'd like to understand what the document ought to say about some
things.  In particular,

> A DoH client *never* reads the TC bit, it just verbatim passes the response to the downstream DNS client. It's the downstream's responsibility to either drop or consume the response.

This is just a completely useless response, unless that is literally
placed into the document.  Because what it means to me is that any
TC-bit-containing DOH message is almost certainly garbage that needs
to be resolved via a different path, and it's therefore pretty hard
for me to see why this isn't just an error condition.  If someone (or
the document or ideally both) wants to explain why I'm wrong, that
would also be helpful.  But at the moment, I think I agree with Tony.
If there's a TC in a DOH message received by a DNS API client, that
client needs to be able to decide what to do.  _I_ think it's an
indication that DOH resolution has failed and the client needs to do
something else, but I can see arguments about two-sided systems
(effectively "full service DNS API servers") that might want to pass
on anyway.

> P.S. I'm not going to talk about this issue any more since I don't think the current specification is inappropriate. Also practice shows it is working..

I am pleased to observe that someone has surveyed the population of
all possible DOH resolution systems, and concluded that the current
text will ensure they'll all work.  I am sceptical of the result,
however, and would like another report from the possible worlds.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Patrick McManus <[email-masked]>
Date: Wed, 6 Jun 2018 11:50:13 +0200

On Wed, Jun 6, 2018 at 8:23 AM, Andrew Sullivan <[email-masked]>
wrote:

> for me to see why this isn't just an error condition.

It is my understanding that the TC bearing response is the best one that
the DOH Server could generate. The assumption is that this is better than
returning no response at all (i.e. just an error) because the client might
be able to make use of it. If it has no value, then it should be an error
(which probably means must not send and if received must be treated as
error). But my understanding is it may have value to some clients. Set me
straight as necessary.

It is what it is - if you need more information and have another path
available then try and resolve it that way assuming it meets whatever
security requirements you have - but beware that some clients won't have
another path.. for example javascript clients have only access to http, and
the servers they may connect to are constrained via same origin policy.

In practice DoH isn't constrained by size - so shifting to another
transport with the same recursive isn't likely to improve things; I would
think using a different recursive would be more likely to bear fruit.
There's obviously no way to say that definitely.

---

From: Massimiliano Fantuzzi <[email-masked]>
Date: Wed, 6 Jun 2018 13:57:43 +0200

Dear memebers of the WG and/or DoH list

Similar questions arose in 1995 and 1996 IETF meetings,
https://tools.ietf.org/html/rfc2181#section-9

TC can have multiple origins.

I guess we:

- cannot fix what is broken (configurations)
- cannot establish a new concept of "best effort" answer, not better than
the one clarified in the 2181 section 9
- can live with broken answers, broken servers...

We shall though, agree on mechanisms to:
- clear, ignore or warn about TC bit and implications.. Let's reason on how
to switch protocol, and why TC was set.
- clarify the need to process (proxy) the ADDITIONAL section ? (the TC bit
could be set as effect of that section being too big, not the RR queried
for)
- make clearer who has to go and try TCP query, as we need to support both.
Is it the DoH client or DoH server ? how is this preference expressed from
a client perspective (do we still have two content types, i forgot) ?
- can we say that TC + minimal + TCP is a FAIL ? (or create an universal
URI) ?

I want to mention also "minimal-responses" option in BIND.
Overhead/overkill from a DoH point of view (certificates, sessions,
perceived speed), but that might be a benefit for a DNS server... nowhere
in RFC is written than a client needs more than what it queried for
(recursion) !!
http://www.zytrax.com/books/dns/ch7/queries.html#minimal-responses

Another important nuance we should agree on... HTTP is stateless, are we
discussing about building a stateful API server ? One that works with
"states" before giving out answer? A server able to judge the quality of a
given set????? because i do not see how a single API call can drive
multiple "interpretation" of the same message (received upstream).
Otherwise as usual, the intelligence must reside on client (aka retry,
fallback or fail).

DNS clients do already "suffer" from the same issues, as also mentioned,
many firewalls in between...

I think the "retry intelligence" should reside on client, as a DoH server
is by definition a proxy (eventually offering options to
minimise/alter/complete responses if you want).

On Wed, Jun 6, 2018, 11:50 Patrick McManus <[email-masked]> wrote:

> _______________________________________________
> Doh mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doh
>

---

From: Ray Bellis <[email-masked]>
Date: Thu, 7 Jun 2018 22:31:53 +0100

> In both cases, the TC bit means "here's the best I got". 'Twas always thus.

There's a school of thought that says a TC response should contain the
absolute bare minimum, per RFC 6891, i.e. the question section, an OPT
RR if there was one in the original query, and *nothing else*.

Ray