On 22/06/12 11:19 AM, Justin Dolske wrote:
On 6/19/12 9:24 AM, Zack Weinberg wrote:
I think we do need our own DNS resolver eventually (mostly because
DNSSEC) but it's not necessary for this. We'd just have to refuse to do
the DNS query at all for URLs whose hostname component did not contain a
On 6/19/12 9:24 AM, Zack Weinberg wrote:
I think we do need our own DNS resolver eventually (mostly because
DNSSEC) but it's not necessary for this. We'd just have to refuse to do
the DNS query at all for URLs whose hostname component did not contain a
dot, and/or which was equal to or a suffix
On 6/21/12 3:25 PM, Boris Zbarsky wrote:
Please go read about the problem space. Seriously. Start with the fact
that the OS DNS resolution services are blocking and don't allow timing
out requests, meaning that to do N DNS lookups without being screwed by
one of them being slow on some DNS ser
> > I don't see why multiple standard queries has
> > any bearing, dns queries are cheap.
>
> No-find TLD queries are surprisingly slow. Try a few.
No problem here, maybe a second longer. I can't switch tab quick
enough. drill responds immediately. Do you suggest a method of testing
that?
On 2012-06-21 4:02 PM, Kevin Chadwick wrote:
p.s. mozilla uses it's own malloc which is annoying because OpenBSDs is
so much better!!!
We've done extensive tests and believe jemalloc is the best available
malloc for the way we use memory; however, I don't know that we've
tested specifically ag
On 6/21/12 6:40 PM, Kevin Chadwick wrote:
I was under the impression the problem was dotless hostnames
conflicting with search.
That's not the problem motivating custom resolvers.
I don't see why multiple standard queries has
any bearing, dns queries are cheap
Please go read about the probl
On 6/21/2012 3:40 PM, Kevin Chadwick wrote:
I don't see why multiple standard queries has
any bearing, dns queries are cheap.
No-find TLD queries are surprisingly slow. Try a few.
John Nagle
___
dev-security mailin
> >> It'll be confusing, but the fact of the matter is that the "OS service
> >> calls" are pretty broken for cases when you might have more than one
> >> hostname to resolve and might care about doing other things at the same
> >> time (like in a browser, say)
> >
> > I can understand why an OS
> >
> > p.s. mozilla uses it's own malloc which is annoying because OpenBSDs is
> > so much better!!!
>
> We've done extensive tests and believe jemalloc is the best available
> malloc for the way we use memory; however, I don't know that we've
> tested specifically against OpenBSD malloc. In
On 2012-06-21 10:41 AM, Kevin Chadwick wrote:
p.s. mozilla uses it's own malloc which is annoying because OpenBSDs is
so much better!!!
We've done extensive tests and believe jemalloc is the best available
malloc for the way we use memory; however, I don't know that we've
tested specifically
On 6/21/12 1:41 PM, Kevin Chadwick wrote:
It'll be confusing, but the fact of the matter is that the "OS service
calls" are pretty broken for cases when you might have more than one
hostname to resolve and might care about doing other things at the same
time (like in a browser, say)
I can under
> It'll be confusing, but the fact of the matter is that the "OS service
> calls" are pretty broken for cases when you might have more than one
> hostname to resolve and might care about doing other things at the same
> time (like in a browser, say)
I can understand why an OS wouldn't listen to
On 6/21/12 12:11 PM, Dan B. wrote:
and someone else mentioned doing name resolution without going through
normal OS service calls.
That sounds like a bad idea: If the browser resolves names differently
from how everything else on the system (host/nslookup, ping, ssh,
mailers, ftp, etc.) resolve
Zack Weinberg wrote:
...
I confess I see this as another argument for disabling suffix search
altogether. It breaks *more*, but we get a substantial reduction in
context-dependence of URLs in exchange.
and someone else mentioned doing name resolution without going through
normal OS service ca
14 matches
Mail list logo
