-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi,
On 18-02-15 18:19, Marcus Grando wrote: >>> 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. I don't think this is about if an answer should be cached or not, but rather if we we are allowed to serve it from the cache or not for a particular query. Thus having this in cache: 10.10.0.0/16/24 you are allowed to use that cache entry for the query: 10.10.0.0/16/0 but not for: 10.10.0.0/17/0 You'd have to requery or keep looking in your cache for a more specific answer. > (cut) > * 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. I see no benefit in doing so. However, there is an issue when one of the authoritative servers signals no support for ECS, A situation congruent with answering with SCOPE 0. If you cache this you effectively disable ECS for that name for its TTL. I'm not really concerned about serving a suboptimal (not wrong!) answer for some time but I've been told by operators this is a deal breaker. The only way around this IMHO is not to cache answers when you would have expected the option but did not get it. For which I can't imagine anyone would argue is a good idea. I'm bringing this up because I hoped your proposal would solve this issue but it does not as far as I can see. > * Handling edns-client-subnet Replies and Caching: > > I'm trying to figure out how can support two answers like > 10.10.0.0/16 <http://10.10.0.0/16> and 10.10.10.0/24 > <http://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 > <http://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. There are no issues supporting this. You need to remember though that you have both SOURCE and SCOPE in your cache. If you correct your example to include both values I can show you how it would work for a resolver. //Yuri -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlTk9D0ACgkQI3PTR4mhavjKkQCgrZylWCtLPDE+OqLkWcpjiYeQ CFsAnAofmNMhkdMvkkyKb0dMt66JmbTj =XE9y -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
