Subject: [Doh] meta qtypes

From: Miek Gieben <[email-masked]>
Date: Sun, 18 Mar 2018 14:38:11 +0000

Hi,

-03 has the following text in section 7.1.

   Other types of DNS data, such as
   zone transfers, may be larger and benefit more from revalidation.
   DNS API servers may wish to consider whether providing these
   validation enabling response headers is worthwhile.

this implies DoH servers need to support IXFR/AXFR (fine), but that replies to 
these may now be cached? I think this is new behavior from a DNS standpoint.

(Should the draft also mention dynamic updates, notify messages and other 
opcodes as being supported?)

/Miek

--
Miek Gieben

---

From: Patrick McManus <[email-masked]>
Date: Sun, 18 Mar 2018 15:44:54 +0000

Hi - DoH itself doesn't require axfr/etc anywhere that DNS would not (I'm
not aware of whether it does or not) - the text is just meant to give the
HTTP considerations when it does carry larger DNS responses such as that.

WRT HTTP caching - section 4 of DoH talks about how HTTP freshness
lifetimes should be set for DoH responses. Is there something different
here?

-Patrick

On Sun, Mar 18, 2018 at 2:38 PM, Miek Gieben <[email-masked]> wrote:

> this implies DoH servers need to support IXFR/AXFR (fine), but that
> replies to these may now be cached? I think this is new behavior from a DNS
> standpoint.
>
> _______________________________________________
> Doh mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doh
>

---

From: Miek Gieben <[email-masked]>
Date: Sun, 18 Mar 2018 19:08:04 +0000

[ Quoting <[email-masked]> in "Re: [Doh] meta qtypes..." ]
>lifetimes should be set for DoH responses. Is there something different

This HTTP caching opens up a pretty big can of worms on what to set the cache
TTL to.

If we consider HTTP/2 *just* the transport than it should not be concerned with
caching (i.e. TCP doesn't cache).

If we do want to cache on this layer a server implementing DoH needs to inspect 
the DNS packet, it should (among other things), look for a SOA record to get a 
TTL or MINTTL, or get the minimum TTL of all the records in the message, or look 
for RRSIG expiration times and distill a minimum TTL from those.

I think this draft should say "MUST not cache these responses".

/Miek

--
Miek Gieben

---

From: Patrick McManus <[email-masked]>
Date: Sun, 18 Mar 2018 19:47:54 +0000

Section 4 has spme rules about generating http freshness lifetimes from dns
responses. Is there a text change to that you are proposing?

On Mar 18, 2018 7:08 PM, "Miek Gieben" <[email-masked]> wrote:

> If we do want to cache on this layer a server implementing DoH needs to
> inspect the DNS packet, it should (among other things), look for a SOA
> record to get a TTL or MINTTL, or get the minimum TTL of all the records in
> the message, or look for RRSIG expiration times and distill a minimum TTL
> from those.
>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 19 Mar 2018 09:16:34 +0000

On Sun, Mar 18, 2018 at 07:08:04PM +0000,
 Miek Gieben <[email-masked]> wrote 

> I think this draft should say "MUST not cache these responses".

I have a less radical proposal:

"DoH servers SHOULD return a Cache-Control header (RFC 7234, section
5.2.2). They MAY send "Cache-control: no-cache" in all cases [if
they're lazy]. For positive
answers (ANCOUNT>0), if the DoH server returns "Cache-control:
max-age=N", the maximum age MUST be the TTL of the answer seen by the
Doh server. For negative answers (NXDOMAIN), if the DoH server returns "Cache-control:
max-age=N", the maximum age MUST be calculated from the SOA record of
the zone (RFC 2308, section 3) [note it allows a server to return
"Cache-control: no-cache" only for NXDOMAIN]"

---

From: Miek Gieben <[email-masked]>
Date: Mon, 19 Mar 2018 09:49:12 +0000

[ Quoting <[email-masked]> in "Re: [Doh] meta qtypes..." ]
>"Cache-control: no-cache" only for NXDOMAIN]"

I agree that this works (but still leaves out RRSIGs).

The (major) downside is that a DoH server doesn't just ship bytes anymore; it 
need to fully inspect the payload to make an informed cache TTL decision.

Note: I'm fine with either - nocache or something along the lines Stephane 
proposes.

/Miek

--
Miek Gieben

---

From: Patrick McManus <[email-masked]>
Date: Mon, 19 Mar 2018 10:13:08 +0000

we need to be careful about recommending a blind tunnel (aspect) of using
HTTP by just disabling caches. That's not really great and doesn't meet the
DoH goals - HTTP has a rich language to control caching at its level which
I think can be well aligned with the DNS TTL architecture (and if no-cache
plays a role for some small part, that's fine.). There is document text
that already tries to discuss that in Section 6. Hopefully we can revise
that if necessary.

The text already contains a normative MUST NOT about using a http freshness
lifetimes that exceeds DNS based TTL lifetimes of the response. A DOH
server that cannot figure this out can comply with a freshness lifetime of
0 - but the goal here is not that a DOH server is a non-DNS-aware tunnel.

Please note the draft uses language about freshness lifetime instead of
normatively referencing cache-control for a reason (cc is used in "such as"
and in an example). There are a number of ways in HTTP to express this
concept and you want to be compatible with the existing definitions.

Perhaps it just needs an additional para indicating a response bearing a
negative answer needs a more pessimal algorithm (e.g. either not cachable
or the SOA approach)?

On Mon, Mar 19, 2018 at 9:49 AM, Miek Gieben <[email-masked]> wrote:

> The (major) downside is that a DoH server doesn't just ship bytes anymore;
> it need to fully inspect the payload to make an informed cache TTL decision.
>

---

From: Miek Gieben <[email-masked]>
Date: Mon, 19 Mar 2018 10:26:56 +0000

>negative answer needs a more pessimal algorithm (e.g. either not cachable

I think it should. I really wish we could point to one DNS RFC that tells 
implementers on how to determine the cache TTL, but afaik that does not exist.

So, yes, either new text in this I-D or referencing a whole slew of DNS RFCs 
that say things about TTL in relation to caching.

/Miek

--
Miek Gieben

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 19 Mar 2018 06:44:05 -0400

> implementers on how to determine the cache TTL, but afaik that does not

Could you expand on this?  NXDOMAIN has an explicit TTL, so I don't
understand why the "negative answer" case requires a different algorithm.
What are you thinking of?  Could you suggest some text?

> So, yes, either new text in this I-D or referencing a whole slew of DNS
> RFCs that say things about TTL in relation to caching.
>
>
> /Miek
>
> --
> Miek Gieben
>

---

From: Dave Lawrence <[email-masked]>
Date: Mon, 19 Mar 2018 07:36:41 -0400

Ben Schwartz writes:
> NXDOMAIN has an explicit TTL, so I don't understand
> why the "negative answer" case requires a different algorithm.

NXDOMAIN's (and pseudo-rcode NODATA's) version of "explicit TTL" is:

1) Is there an SOA in authority? Use the mininmum of the RR TTL or the
   negative TTL in rdata.
2) No SOA?  Implementation dependent.  Please try to pick a
   subjectively sane value.

And that's just NXDOMAIN/NODATA, not REFUSED, SERVFAIL, or other
non-NOERROR rcodes.

Personally I think that the best that can be hoped for when you don't
get back RRSets with clear TTLs, or an SOA for negative answers, is
probably no-cache, with "please try to pick something subjectively
sane" a not unreasonable choice.

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Mon, 19 Mar 2018 12:15:59 +0000

I would prefer if the draft did NOT even consider Meta types, but limited
itself to pure queries i.e. excluded query type's 128..255
Additionally doing other things like Updates and Zone transfers should
involve different meta types (lets learn from experience here not repeat
mistakes)

While I do not mind having the udpdnswire format for now,
I think most users would prefer to use a simple Jason format of answers
like the ones that Google provides
https://dns.google.com/resolve?name=www.cloudflare.com?type=aaaa

As for a more expressive format that supports doing DNSSEC validation that
is IMHO a separate  goal,
as we need to think about usage cases i.e. does the client trust the
resolver or not if the client trusts then the AD bit good enough, if the
client wants to verify then the client should express that in the query
either by adding field or ask for different media type.
Just MHO

Olafur

---

From: Miek Gieben <[email-masked]>
Date: Mon, 19 Mar 2018 13:11:34 +0000

[ Quoting <[email-masked]> in "Re: [Doh] meta qtypes..." ]
>involve different meta types (lets learn from experience here not repeat

Yes! So make the draft say?

    MUST support opcode QUERY. MUST NOT support any other opcode.
    MUST support all RR types excluding the meta range 128..255.

    A non supported query MUST be rejected with a ... ?

/Miek

--
Miek Gieben

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 19 Mar 2018 14:01:25 +0000

> On Mar 19, 2018, at 1:11 PM, Miek Gieben <[email-masked]> wrote:
> 

No, please don’t prevent DNS Stateful Operations from working which is in Last Call and uses a new Opcode.

https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/ <https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/>

Tom

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 19 Mar 2018 14:18:56 +0000

> No, please don’t prevent DNS Stateful Operations from working which is in Last Call and uses a new Opcode.

DOH is not an appropriate transport for stateful sessions.

--Paul Hoffman

---

From: Patrick McManus <[email-masked]>
Date: Mon, 19 Mar 2018 14:20:46 +0000

I'm happy to learn more, but it appears to me that DoH is not suitable for
use with session signal because:

1] DSO messages communicate operations within persistent stateful sessions

and 2] The Hypertext Transfer Protocol (HTTP) is a stateless
application-level protocol

The HTTP semantics that DoH uses (i.e. it does not require a particular
usage of a particular HTTP wire protocol - it exists at the method and URI
level of things) don't give you basic properties like a stateful session
layer. For instance, your messages could go out of order or even to
different servers.

On Mon, Mar 19, 2018 at 2:01 PM, Tom Pusateri <[email-masked]> wrote:

> https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/
>
> Tom
>
>

---

From: Miek Gieben <[email-masked]>
Date: Mon, 19 Mar 2018 14:22:16 +0000

[ Quoting <[email-masked]> in "Re: [Doh] meta qtypes..." ]
>https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/ <https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/>

OK, so put the above wording in the context of disallowing any caching on the 
HTTP layer and not rejecting anything out right.

---

From: Tony Finch <[email-masked]>
Date: Mon, 19 Mar 2018 14:24:50 +0000

> in Last Call and uses a new Opcode.

The way I would like a DoH proxy to work is to have a pool of
persistent TCP connections from the proxy to the DNS server; the proxy
would then multiplex queries from HTTPS onto the backend TCP connections
with no particular coupling between client TLS connections and backend
TCP connections.

The problem with AXFR is the response is multiple messages, and it takes
over the connection, so it doesn't fit into my proxy model, nor does it
fit into the udpwireformat media type.

Stateful options have a similar problem. Really, the state of the backend
connection belongs to the proxy, not to the https client.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Malin: East, becoming variable 3 or 4, occasionally 5 at first. Slight or
moderate. Fair. Good.

---

From: Dave Lawrence <[email-masked]>
Date: Mon, 19 Mar 2018 10:29:57 -0400

Tom Pusateri writes:
> No, please don t prevent DNS Stateful Operations from working which
> is in Last Call and uses a new Opcode.

Please refer to:

https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues/68

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 19 Mar 2018 14:36:31 +0000

> On Mar 19, 2018, at 2:29 PM, Dave Lawrence <[email-masked]> wrote:
> 
> Tom Pusateri writes:
> https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues/68 <https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues/68>

Thanks for the pointer. I missed that discussion.

Tom

---

From: Dave Lawrence <[email-masked]>
Date: Mon, 19 Mar 2018 10:42:12 -0400

Tony Finch writes:
> The problem with AXFR is [...] it [doesn't] fit into the
> udpwireformat media type.

Setting aside the other points you brought up ... it doesn't?

I mean, sure, an AXFR would likely exceed UDP packet sizes typically
seen in the wild, but why not a hypothetical jumbo packet,
content-length mumblety-megabytes?  dns-udpwireformat is not defined in
the doc as intrinsically limiting message length; multiple messages
happen with DNS/TCP only because of the defined 64k limit for them.
"udp" in the type only means "doesn't have the 16 bit prefix length".

Does this too need to be made more explicit in the doc?  I don't
recall any discussion of message size limits, or lack thereof.

---

From: Petr Špaček <[email-masked]>
Date: Mon, 19 Mar 2018 22:56:52 +0100

> "udp" in the type only means "doesn't have the 16 bit prefix length".

Oh, but in that case the theoretical "proxy" would have re-assemble
answers from TCP connection to a DNS server into jumbo-message. Bleh,
please do not do this. DNS is complex as hell now and additional layer
of complexity in translation is going to be major pain.

Maybe we can get out first version without metatypes and add these later
on, if there is an actual demand for them.

Petr Špaček  @  CZ.NIC

> recall any discussion of message size limits, or lack thereof

---

From: Dave Lawrence <[email-masked]>
Date: Tue, 20 Mar 2018 05:38:02 -0400

> of complexity in translation is going to be major pain.

If your HTTP server didn't want to do an AXFR because of the extra
coding involved, it's got HTTP error codes to signal that.  Should the
doc recommend a specific one for whatever DNS features the HTTPS
server chooses not to support?

My main point is that on a practical level nothing precludes being
able to do a DNS response greater than 64k over HTTPS, and if an
implementer wants to support AXFR for whatever reason I don't see why
they need to be blocked from that.

---

From: Patrick McManus <[email-masked]>
Date: Tue, 20 Mar 2018 10:11:21 +0000

> server chooses not to support?
I know this is sounding like an old refrain - but we want clients to handle
all applicable codes and also need to be aware that HTTP servers other than
DoH servers might be generating error responses. So in general creating
laundry lists of response codes is an anti-pattern of over specification.
BCP56bis talks about this.

In the case of a server that doesn't want to answer a request, 7231
provides all of 5xx to mean that. i.e. the server is aware it has erred or
is incapable of handling the request. Restating just that is less
objectionable but we run the risk of introduce subtle mistakes when all we
want is redundancy. We're much better off just including HTTP by reference
as we're doing.

(personally I would use 501 or maybe 502 if I squinted at it hard.)

> personally agree

---

From: Patrick McManus <[email-masked]>
Date: Tue, 20 Mar 2018 10:11:21 +0000

---

From: Dave Lawrence <[email-masked]>
Date: Tue, 20 Mar 2018 06:22:53 -0400

> (personally I would use 501 or maybe 502 if I squinted at it hard.)

501 is where I was going to go with it, but I appreciate your point
about not specifying here.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 22 Mar 2018 08:43:50 +0000

On Tue, Mar 20, 2018 at 10:11:21AM +0000,
 Patrick McManus <[email-masked]> wrote 
 a message of 122 lines which said:

> Restating just that is less objectionable but we run the risk of
> introduce subtle mistakes when all we want is redundancy. We're much
> better off just including HTTP by reference as we're doing.

I understand, but what about a non-normative appendix saying "This is
non-normative text. The normative references is RFC [insert HTTP RFC
number(s)]. Nevertheless, here is some guidance for the people who are
not familiar with HTTP: [insert Tony Finch's proposed list of common
error cases and recommended error codes]."

---

From: Dave Lawrence <[email-masked]>
Date: Thu, 22 Mar 2018 06:29:20 -0400

> error cases and recommended error codes]."

Personally (no hat) I like this idea.

---

From: Tony Finch <[email-masked]>
Date: Thu, 22 Mar 2018 13:01:55 +0000

> Personally (no hat) I like this idea.

As a lapsed Apache committer I have to say, +1 :-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Forties, Cromarty, Forth, Tyne, Dogger: Southwest, backing south, 4 or 5,
increasing 6 or 7. Slight or moderate, becoming rough. Rain later. Good
occasionally poor.