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

[Paul Hoffman <[e-mail]>]

Some comments on your bigger suggested changes.

On Mar 22, 2018, at 5:40 PM, Alexander Mayrhofer <[e-mail]> wrote:
> - 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...

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

> - 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..)

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