[dns-operations] Mozilla Firefox and ANY queries

[Bob Harold]

(In reply to Patrick McManus [:mcmanus] from comment #22
<https://bugzilla.mozilla.org/show_bug.cgi?id=1093983#c22>)> ((In
reply to bugzilla.mozilla.org from comment #21
<https://bugzilla.mozilla.org/show_bug.cgi?id=1093983#c21>)
> > 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?




-- 
Bob Harold
hostmaster, UMnet, ITcom
Information and Technology Services (ITS)
rharolde at umich.edu
734-647-6524 desk

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
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20150304/8b7f7d9f/attachment.html>