[atlas] EDNS Client Subnet

On Mon, Jan 28, 2019, 8:41 AM Philip Homburg <philip.homburg at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/ripe-atlas/attachments/20190128/63c36321/attachment.html>