[dns-operations] EDNS Client Subnet (ECS) in queries sent to Google Public DNS

[Alexander Dupuy]

Florian Weimer writes:
> How would a DoH client know that the recursive resolver is "forbidden
> to forward" ECS data?

Dave Lawrence replies:

> It doesn't know clearly.  All it knows is that if it gets REFUSED when
> it sends a prefix outside its own address space, then something was
> wrong.  If that then succeeds it can only be inferred that the
> specified network was the problem.

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.

Ralph Dolmans writes:

> Unbound will query again without ECS when receiving a REFUSED.

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?

> Is there a reason these will only be REFUSED when
> using DoT/DoH? I think you never want to return a /0 scope in this case,
> as that makes it possible for an user to trigger an answer that will be
> cached and used for all addresses, assuming the forwarder will also
> forward non-routable ECS source addresses.

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.

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.

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 Mozilla TRR policy
<https://wiki.mozilla.org/Security/DOH-resolver-policy> 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.

@alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20200122/a59b5205/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4849 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20200122/a59b5205/attachment.bin>