On Fri, 2014-08-15 at 11:32 -0500, Andrew Deason wrote: > On Fri, 15 Aug 2014 12:06:53 -0400 > Jeffrey Hutzelman <[email protected]> wrote: > > > FWIW, I really dislike the notion of caching DNS lookup results for a > > time other than the time-to-live provided by the DNS. If the problem > > is looking for a top-level 'git' domain, then it ought to be solved > > simply by obeying the 1-day TTL advertised by the root servers for > > negative responses (this is the last number in the SOA record for the > > root zone). > > I don't think anything here prevents that. The kernel afsdb entries have > a timeout entry, so that could always be recognized for negative > entries... Though with how rarely a cell is added to DNS, it seems like > a much more minor problem than the problem we're addressing. (I assume > we'd have to query the SOA record ourselves separately? that's > annoying.)
Oh, I should clarify. When I said "it ought to be solved...", I meant that obeying the TTL should make the problem go away. I did not mean that other approaches would not be acceptable. A DNS query that results in an NXDOMAIN response will usually (always?) include the relevant SOA record in its authority section. > > That said, I think it may be a whole lot simpler to simply extend the > > cache manager's existing cache to reflect the possibility of negative > > entries. The only real difficulty here is that such entries need > > eventually to be removed, and I don't think we currently can ever > > remove entries from the cell table. > > I don't think you necessarily need to remove entries. Instead, an entry > can just be repurposed for a newly-added entry (if we've hit some space > limit). That gets a little harder of course if it's a hash table > instead. > > But also, to make it really simple we don't even necessarily need a hash > table. Just using the dumb list that's there you could add negative > entries and limit the number of negative entries to something small like > 50, and any performance difference should not be noticeable. Hm, so you never actually reclaim the memory, but there's a fixed upper bound on how much can ever be allocated, and going beyond that may result in older entries being pushed out prematurely? That seems reasonable to me. > In particular, Markus did mention restricting no-dots entries, but that > doesn't always work. He captured real examples of attempted accesses to > things like latex .sty files, and one thing that even tried to load > library files (/afs/libX11.so). That sounds like a pretty serious misconfiguration. And of course, libX11.so is a perfectly legitimate cell name, if you happen to be Somalia. -- Jeff _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
