EDNS Client Subnet
Hello, I was exploring the possibility of using RIPE Atlas probes to do some study on EDNS Client Subnet (ECS), however, the way it is implemented on the probes makes it less interesting. 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 as client subnet. According to the RFC, a compliant resolver which receives such content SHOULD NOT forward the client IP to the Auth. DNS server (which the same behavior when you set the flag to False). That's make it impossible to study the protocol from Auth. DNS perspective. 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. Thanks in advance! Rami
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. 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. Philip
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.
On Mon, Jan 28, 2019 at 1:41 PM 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.
What privacy issues are concerned when allowing a measurement creator to specify an ECS value that the probe should send along with DNS queries? Is it that some actors on the Internet might assume that the arbitrary ECS value actually originated the DNS query without any validation? I think this becomes a non-issue if you restrict the ECS prefix length to something sane like <=24.
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.
I think the benefit here is somewhat clear for measuring the behavior of recursive resolvers and authoritative nameservers when ECS data is present.
Philip
participants (3)
-
Kyle Schomp -
Philip Homburg -
Rami Al-Dalky