Re: [Doh] Clarification for a newbie DoH implementor

[Vladimír Čunát <[e-mail]>]

Hello!
Reactions to particular parts inline.  I omitted those where I can't say
too much.

On 4/18/19 9:12 AM, Mark Delany wrote:
> [...]
> ## TTL reduction due to HTTP "Age" header
>
> RFC8484 Section 5.1 advises that clients MUST account for the HTTP "Age"
> header by reducing TTLs. Unfortunately the RFC is silent on what to do if
> that reduction causes the TTL to be reduced to zero or below. Should the RR
> be removed which could result in an empty/odd response? Should the TTL be set
> to zero and let the client deal with it? This seems a risky choice as client
> behaviour with zero TTL is well-know to be quite unpredictable.
>
> Current behaviour is to never set the TTL lower than 1s and leave
> every RR in place.

I believe the HTTP "Age" makes sense as the minimum of all TTLs in the
packet, or optionally smaller but never larger.  Therefore it should not
happen, but in case it does, I can't think of anything better than
resetting the underflowed TTLs to 1s.

The RFC only bounds to minimum TTL *in answer section*, but I believe
that's a mistake as you can't just ignore authority section at least. 
There may be records vital for DNSSEC validation of negative answers,
for example.


> ## ECS Performance, Privacy, etc.

I can't see how using a different transport makes ECS issues different. 
If you use UDP forwarding to some public resolver, you are in pretty
same situation, except that you're more likely to be intercepted, etc.


> ** RFC8467 DNS Padding for DoH client

I'm not so sure about this, but my point of view is, shortly, that
padding is a per-hop thing.  It depends on the particular transport -
for unencrypted ones it doesn't even make any sense, so I can't see why
padding should matter between your proxy and its clients.  I believe
this point of view is consistent with the RFC, too.


> ** RFC8484 DNS Padding for GET requests
>
> My first thought is that DNS padding should apply to both GET and POST
> methods, but 4.1.1 says "Finally, a GET-based query ... and that padding is
> omitted". Is "padding omitted" referring to DNS padding or base64url padding?
> I presume base64url padding, but it's ambiguous.
>
> For now the implementation doesn't add DNS padding for GET requests. Should I
> change that?

That's certainly about base64url padding.  It could get clarified in the
RFC, but I suspect most people don't get to reading errata or
"corrected" RFC versions.


--Vladimir (Knot Resolver)