This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/ripe-atlas@ripe.net/
[atlas] EDNS Client Subnet
- Previous message (by thread): [atlas] New on RIPE Labs: RIPE Atlas Anchors 400+
- Next message (by thread): [atlas] EDNS Client Subnet
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Rami Al-Dalky
rami.dalky at gmail.com
Mon Jan 28 14:33:11 CET 2019
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 -------------- next part -------------- An HTML attachment was scrubbed... URL: </ripe/mail/archives/ripe-atlas/attachments/20190128/cfc6a61e/attachment.html>
- Previous message (by thread): [atlas] New on RIPE Labs: RIPE Atlas Anchors 400+
- Next message (by thread): [atlas] EDNS Client Subnet
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]