On Mon, Jan 28, 2019, 8:41 AM Philip Homburg <philip.homburg@ripe.net wrote:
On 2019/01/28 14:33 , Rami Al-Dalky wrote:
> When I tried to create a DNS measurement, I found that the only way to
> send DNS query with option is to set default_client_subnet to True.
> However, by setting this option, a DNS query will be sent with 0.0.0.0/0
> <http://0.0.0.0/0> as client subnet. 
>
> Is there a reason why ECS is implemented that way? If it for privacy
> issue, the RFC recommends to sent the client IP with /24 prefix for IPv4
> and /56 for IPv6 to preserve the privacy.

Let me point out that we chose 0.0.0.0/0 to avoid all privacy issues.
The recommendation just reduces privacy issues.

Right. However, recursive resolvers already have access to end-user IP address and there is no evidence whether or not they preserve the privacy of those queries (by sharing them with third party). If we talk about preserve the end-user privacy from Auth. DNS, those clients will eventually contact the content server (for instance, HTTP server) which would have access to the end-user IP. So there an arguement that someone can make.

If we talk about the privacy of the probes, I can't see how sending the probe's /24 would violate the privacy of the probes (anyone can harvest the public IP addresses of the probes).

At the same time, it was not clear to us what additional benefit it
would bring to RIPE Atlas measurements to include longer prefixes. In
particular, we assumed that the main purpose of this option would be to
measure interference by firewalls or other middle boxes.

One could study the behavior of different components in DNS ecosystem (for instance, recursive resolvers or Auth. DNS) with this option.