<div dir="ltr"><div class="gmail_quote"><p>Florian Weimer writes:<br>
> How would a DoH client know that the recursive resolver is "forbidden<br>
> to forward" ECS data?<br>
</p>
<p>Dave Lawrence replies:</p>
<p>> It doesn't know clearly.  All it knows is that if it gets REFUSED when<br>
> it sends a prefix outside its own address space, then something was<br>
> wrong.  If that then succeeds it can only be inferred that the<br>
> specified network was the problem.</p>
<p></p>
<p>It’s a bit worse than that, since there is no 100% reliable way to distinguish whether REFUSED indicates a problem with the ECS address data or a queried domain name for which ECS is blocked (or both). However, since the action taken in any of these cases is the same (resend without ECS), it’s not necessary for the client to be able to distinguish them, although it would be useful to be able to do so to determine whether to cache the response as a global answer valid for any address.</p>
<p></p>
<p>Ralph Dolmans writes:</p>
<p>> Unbound will query again without ECS when receiving a REFUSED.</p>
<p></p>
<p>I’m glad to hear that, and hope that other forwarding resolvers do the same. However, I expect there are many that do not. As far as Unbound’s behavior, how does it cache the response that it gets from a non-ECS retry? Are they cached for the client address at some default (/24 or /56) scope? Or are they cached as untargeted responses that could be used instead of making a non-ECS retry (but would not prevent an initial query with ECS)? Or just not cached at all?</p>
<p></p>
<p>> Is there a reason these will only be REFUSED when<br>
> using DoT/DoH? I think you never want to return a /0 scope in this case,<br>
> as that makes it possible for an user to trigger an answer that will be<br>
> cached and used for all addresses, assuming the forwarder will also<br>
> forward non-routable ECS source addresses.</p>
<p></p>
<p>It’s a question of trade-offs. DoH/DoT queries are still a relatively green field; there are fewer DoH/DoT clients (and even fewer that send ECS), and they are more likely to retry without ECS when they get a REFUSED. This reduces the negative impact of REFUSED responses for clients that do not retry without ECS.</p>
<p></p>
<p>There is another possibility besides a /0 scope response (current behavior) and returning REFUSED, which is to send a response without ECS at all. However, clients may interpret that as a lack of support for ECS, which might prevent them from sending zero-length address ECS to stop a recursive from sending their actual IP subnet to authoritative name servers. Since clients may cache a non-ECS response to an ECS query as a global response suitable for all addresses, omitting ECS might be no better than returning a /0 scope. For those reasons, retaining the current behavior for cleartext queries seems the best choice.</p>
<p></p>
<div>In the long term, ECS would only be supported for encrypted transports, to preserve client privacy as much as possible while still giving accurate geo-targeted results. The <a href="https://wiki.mozilla.org/Security/DOH-resolver-policy" target="_blank">Mozilla TRR policy</a> privacy requirement 6 is a first step in this direction, if perhaps somewhat premature, since there is still no standard mechanism for DoT to authoritative, and even opportunistic DoT is only possible for one authoritative server operator. As ECS is still sent in cleartext to authoritative servers, requiring that it be encrypted from a client may seem pointless, but there is some privacy benefit to encrypting ECS at any point, even if it is not encrypted end-to-end. For now, it seemed appropriate to at least require that clients not be sending cleartext ECS address data with longer prefixes than recommended by RFCs, that would not be used by Google Public DNS.</div><div><br></div><div>@alex<br></div></div></div>