Subject: [Doh] Review of draft-ietf-doh-dns-over-https-04

From: Alexander Mayrhofer <[email-masked]>
Date: Thu, 22 Mar 2018 17:40:09 +0000

Hi,

i've read through the -04 version of the draft. I've notices a few minor things:

- Section 3 contains:

"The queries and responses must be able to be flexible enough to
      express every normal DNS query."

What's a "normal" DNS query? I do suggest we either remove that word,
or specify which (abnormal) DNS queries are not supported (or
explicitely list which we consider "normal). I suppose the "abnormal"
would be UPDATE, NOTIFY, AXFR and the like?

- Also in Section 3, we have "EDNS extensions". Are those supposed to
be "EDNS options"? Suggest "EDNS options as well as future versions of
EDNS"..

- Also in Section 3, what's "legacy Version" of HTTP? If that should
mean "any HTTP version below 2.0", then we should explicitely say so.
This would also match the SHOULD in section 6.2

- Section 4 contains text about http/2 padding. Note that RFC7830 does
also provide padding (on the application level of DNS) to obscure
packet sizes, maybe a respective note should be added here.

- Section 4.1 contains "EDNS extensions" again - suggest rewording to
"EDNS options".

(i have not validated the examples)

- Section 5: Looking at the range of 2XX HTTP responses, i'm wondering
whether it makes sense to restrict the valid HTTP responses further?
I'm not a HTTP guru, so i'm specifically careful about this. Eg. 201
and 202 probably don't make any sense in the context of a DNS
query/response transaction, 204 shouldn't happen if the DNS API server
provides a valid DNS response, and 205 gives me the crazy ID that this
could be used to "update" a local DNS cache with updated
information...

- Section 5: Has another instance of "EDNS extensions", suggest "EDNS
options". "MAY have one or more EDNS extensions, depending on the
extension definition of the extensions given in the DNS request."
sounds.. confusing :)

- Section 5, expiration: I think this should be reworded to be more
concise, i do suggest the following text:

The HTTP response freshness
   lifetime ([RFC7234] Section 4.2) should SHOULD be set to expire at
   the same time the first of the DNS resource record sets in the Answer section
   reach a 0 TTL, and MUST NOT be greater
   than that indicated by the DNS resource record set with the smallest TTL
   in the DNS response.

(does the MUST NOT consider additional sections as well, or just the
answer section - clarification needed..)

Same for the remaining freshness text - all sections, or just "answer" section?

tia, (for now)
Alex

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 25 Mar 2018 16:30:27 +0000

Some comments on your bigger suggested changes.

> could be used to "update" a local DNS cache with updated

The WG seemed hesitant to start listing speicfic types of response codes.

> answer section - clarification needed..)

Your proposed text talks about the first RRset in the Answer section. Why? If there are multiple RRsets with different TTLs, shouldn't the HTTP expiration be based on the shortest of them, not just the first?

> Same for the remaining freshness text - all sections, or just "answer" section?

I used the Answer section because it is the one that is likely to be put into a cache. The data from the other sections might be used by the recursive, but are unlikely to be put in the cache because of the anti-poisoning rules.

--Paul Hoffman

---

From: Alexander Mayrhofer <[email-masked]>
Date: Sun, 25 Mar 2018 21:18:40 +0100

> Your proposed text talks about the first RRset in the Answer section. Why? If there are multiple RRsets with different TTLs, shouldn't the HTTP expiration be based on the shortest of them, not just…

It was meant to be a temporal, not spatial "first" ("first .. to reach
a 0 TTL") - so we mean the same thing (I believe "first" was already
in the text, but there was a third clause in that sentence that
confused me).

Anyways - the gist is, it should be set so that the HTTP response
freshness lifetime expires before any of the DNS RRsets expire.

> I used the Answer section because it is the one that is likely to be put into a cache. The data from the other sections might be used by the recursive, but are unlikely to be put in the cache becau…

Understood!

Alex

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 26 Mar 2018 10:33:12 +0200

On Sun, Mar 25, 2018 at 04:30:27PM +0000,
 Paul Hoffman <[email-masked]> wrote 
 a message of 38 lines which said:

> > 204 shouldn't happen if the DNS API server provides a valid DNS
> > response, and 205 gives me the crazy ID that this could be used to
> > "update" a local DNS cache with updated information...
> 

I would say otherwise: some people in the WG want listing specific
types of response codes, probably in a non-normative appendix, some
people fear we risk to contradict HTTP RFCs when trying to restate
them. AFAIK, no decision was taken yet.