Re: [Doh] Draft -09 and WGLC #2

[Andrew Sullivan <[e-mail]>]

On Thu, May 24, 2018 at 09:09:45PM +0000, Paul Hoffman wrote:
> Greetings. WGLC #2 generated some good discussion and overlapping pull requests. We have issued draft -09 to deal with the discussion and make clear the current wording. Please see the diffs and let the WG know if there are still any outstanding issues on which there might be general agreement.
> 

Hi,

I've been a little negligent in keeping up with this work lately, so I
thought I'd take this opportunity to do a complete review.  The
editors are free to take this input, ignore it, hold anything that
crops up for post-WG action, or whatever.

By and large, I find the document clear and easy to read, so
congratulations are due to the editors.

This bit in section 4 strikes me as strange:

    A client MUST NOT use a DNS API
   server simply because it was discovered, or because the client was
   told to use the DNS API server by an untrusted party. 

This feels like it's crying out for a definition of "trusted", and yet
that seems to me like a bad idea.  Today, when you use an open wifi,
you probably don't actually _trust_ the network operator, but you
accept the default DNS server you get from DHCP anyway (unless you're
the sort of nerd who thinks about this sort of thing).  I can't tell
from the text whether that kind of "trust" is supposed to be permitted
by this or not.  I recall some discussion about this in the past, but
if the WG thinks that was resolved the resolution is totally opaque to
an uninformed reader.

Section 5.1 might want to note that the very fact of dependence on
HTTPS means that the spoofing-resilience advantage of random DNS IDs
do not apply to this case, but that DNS API servers are expected to
deliver maximal spoofing resilence in performing any (normal) DNS
resolution they themselves must do.  Maybe this goes without saying,
however.

This text in section 6.1

   The stale-while-revalidate and stale-if-error Cache-Control
   directives ([RFC5861]) could be well suited to a DOH implementation
   when allowed by server policy.  Those mechanisms allow a client, at
   the server's discretion, to reuse a cache entry that is no longer
   fresh.  In such a case, the client reuses all of a cached entry, or
   none of it.

ought to come with a note that this may be dangerous -- that is, if
DNS operators are expecting their TTLs to be respected, this is a
(new) way by which stale data might get re-used.  So, DNS API server
administrators ought to be careful with such a server policy.  Maybe
the warning ought to go in section 10, though it's hard to be sure:
it's partially a warning for everyone _else_ on the Internet,
including people who don't support DOH.

In the same section,

   DNS API clients MUST account for the Age response header's value
   ([RFC7234]) when calculating the DNS TTL of a response.  For example,
   if a RRset is received with a DNS TTL of 600, but the Age header
   indicates that the response has been cached for 250 seconds, the
   remaining lifetime of the RRset is 350 seconds.

makes something plain by implication that might not obviously be clear
otherwise.  In the DNS environment today, many "clients" are stubs,
and they're not very smart.  One thing they do not always do is much
cache control: they get the value from the full-service resolver and,
if there is any local caching at all, it's straight decrementing of
the TTL.  What this passage means is that the data that comes in to a
DNS API client _is not_ suitable to hand straight to the local stub
subsystem: instead, some additional processing MUST be performed in
order to ensure that TTLs are not accidentally extended by accident.
Given the quality of a lot of DNS code in the world, I think this
point should be made quite explicit somewhere in the document.  Again,
it might go in section 10, though it's not obvious to me that this is
an operational consideration.  It's more an architectural one.



-- 
Andrew Sullivan
[e-mail]