[dns-operations] Mozilla Firefox and ANY queries
rharolde at umich.edu
Wed Mar 4 12:42:59 UTC 2015
(In reply to Patrick McManus [:mcmanus] from comment #22
reply to bugzilla.mozilla.org from comment #21
> > This whole thing is about getting TTL for in-Firefox caching, right?
> yes - each time we look at this we do need the cache because the the number
> of names that are looked up in the browser (most of them speculatively)
> tends to overwhelm the os cache. I'd be happy to look at data in a separate
> bug to revisit, of course.
Can someone be more specific on what "overwhelm"s the os cache? I
assume all the names still need to be looked up in te os and thus get
in the os cache. Is it cache hits that are too many - that sounds
unlikely. Or is it entries with very low ttl that you are caching
longer in the browser to avoid lookups?
hostmaster, UMnet, ITcom
Information and Technology Services (ITS)
rharolde at umich.edu
On Sun, Mar 1, 2015 at 3:32 PM, Florian Weimer <fw at deneb.enyo.de> wrote:
> * Mark Andrews:
> > In message <87k2z0vksq.fsf at mid.deneb.enyo.de>, Florian Weimer writes:
> >> * Mark Andrews:
> >> > getaddrinfo was designed to extended. It wouldn't be hard to add ttl
> >> > information to getaddrinfo, just add a ai_ttl to the structure at the
> >> > end and define a flag to say whether it is valid.
> >> struct addrinfo cannot be extended in this way because its size is
> >> part of the ABI, and callers are even encouraged to allocate struct
> >> addrinfo objects to pass the hints.
> > And that is something that can be dealt with by setting a flag bit
> > when calling getaddrinfo. As I stated getaddrinfo is designed to be
> > extended.
> This is doesn't work for an important case, which I mentioned in the
> next paragraph:
> >> I've already found one Debian package which embeds a struct addrinfo
> >> field in the middle of a struct defined in a header file (the shishi
> >> Kerberos implementation). Unfortunately, changing struct addrinfo
> >> in the way you propose has an extremely high risk of breaking
> >> applications.
> We don't have the luxury of recompiling the entire world if we change
> something in libc. We tried something similar with another
> supposedly-extensible struct, and all hell broke lose as a result.
> Changing the size of struct addrinfo simply not an option for us.
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> dns-jobs mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dns-operations