On Fri, 3 Jul 2015, Shane Kerr wrote:
I don't think the authority server ever needs to actually send the new data, only to request that the resolvers remove entries from cache (including negative entries). The resolver can re-fetch records and cache them normally at that point.
How will this work with resolvers behind NAT?
On the resolver side, there needs to be a way to insure that only the authoritative server can clear cache entries. I am not 100% sure, but I think that if a resolver saves the IP address that it got a given RR from, and requires either TCP or DNS cookies on the cache clearing message, that this will be prevented.
A local attacker could still flush your cache and (re)attempt to poison you. In fact, you almost have to mandate DNSSEC for any data to be allowed to get flushed, or else cache poisoning becomes very easy.
Second, how can the authoritative server limit the amount of entries that it contains? For example, if an attacker has a /48 of IPv6 space, then how do we prevent that attacker from registering more and more synchronized resolvers, causing resource exhaustion on the authoritative server?
And since none of this information can be transmitted via chained resolvers, the authoritatve servers have to keep track of all clients? Which is a new privacy concern. I feel unpublishing DNS data should not be faciliated in this way. Use short TTLs. Or on the client side you can enforce a max-ttl to force your local resolver to never cash for longer than X amount of time. There was also other work related to this, something draft-redbutton ? Paul _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
