I've read this draft again and my comments are below. 6.3. Handling edns-client-subnet Replies and Caching:
>> If the SCOPE NETMASK in the reply is longer than the SOURCE NETMASK, it means that the reply might be suboptimal. A Recursive Resolver MUST return this entry from cache only to queries that do not contain or allow a longer SOURCE NETMASK to be forwarded, or to queries originating from the network covered by the ADDRESS and SCOPE NETMASK.. This paragraph isn't clear to me, I read and re read several times and can’t figure out if there are any case where it will be possible to create one request that will never be cached. Like stub create one request with source netmask and some combination of resolver configuration and authority answer, where in the end, resolver can’t cache the answer. 6.4. Transitivity: In my point of view, this is like Stub/Resolver behaviour when Stub generate edns-client-subnet packet. If it's, I think it can be removed to keep it simpler. 10.1. Privacy: >> To protect users' privacy, Recursive Resolvers are strongly encouraged to conceal part of the IP address of the user by truncating IPv4 addresses to 24 bits. No recommendation is provided for IPv6 at this time, but IPv6 addresses should be similarly truncated in order to not allow unique identification of the client. I'd love to see an IPv6 recommendation here too, even 64 bits for example. I vote to recommendation for End Sites in RFC 6177 of 56 bits. 10.3. Cache Pollution: >> o Recursive Resolvers SHOULD limit the number of networks and answers they keep in the cache for a given query. >> o Recursive Resolvers SHOULD limit the number of total different networks that they keep in cache. I'm worried about this, because if the implementators limit to lower limit, this can be a problem. What will happen if reach this limit? I can't find anything if the limit was reach, an non edns-client-subnet was sent and answer without edns-client-subnet. For example, in CDNs, will be a lot of answers with a lot of network subnets and a lower TTL. This behaviour can reach easly those limits if are low. How you guys are seeing this problem? 11.1. Probing: >> Additionally, Recursive Resolvers MAY be configured to never send the option when querying root, top-level, and effective top-level domain servers. These domains are delegation-centric and are very unlikely to generate different replies based on the address of the client. I think we can change MAY to SHOULD, because there's no reason to send edns-client-subnet to ROOT and TLD servers. >> ... it is to be expected that the Nameserver supports edns-client-subnet for all its zones. This might be wrong, not all zones will be able to answer edns-client-subnet. Like I describe below, If a domain announcing their support will be better choice and there's no reason to send edns-client-subnet for all hosted zones. 11.2. Whitelist: About the manually whitelist, I really think it will be a huge problem and I'm not a big fan, since the main problem is in the resolver side and not the authoritative side. The authoritative side know if it support or not for any hosted domain. It's impossible to know all resolvers around the world and contact/appy to all those resolvers. If the resolver side enable edns-client-subnet support, they intend to enable all domains around the world to improve their user experience, because that, does not make sense whitelist edns-client-subnet on the resolver side. I vote to remove the Whitelist. Another comments: * Probing: I think that Probing can be improved to support detection if domain has or not support to edns-client-subnet. Implement something like sending edns-client-subnet query to an TXT or SOA domain, with that result, enable or disable domain's support. TTL of this response can be used to revalidate edns-client-subnet support. With that, domain owner will be able to enable/disable anytime. * Handling edns-client-subnet Replies and Caching: I'm trying to figure out how can support two answers like 10.10.0.0/16 and 10.10.10.0/24 active in resolver side. This can be usual to testing purpose, like send a bunch of users to another place and the rest of users keep going to old place. This not gonna work today because if resolver first query was 10.10.0.0/16, another query will not gonna happen. If the /24 query goes first, then another query /16 will gone later and this will works fine. What you guys thinking about all comments? Best regards -- Marcus Grando marcus (at) sbh.eng.br mnag (at) FreeBSD.org @marcusgrando
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
