From:  Patrick McManus <mcmanus@ducksong.com>
Date:  14 Dec 2014 11:30:07 Hong Kong Time
Newsgroup:  news.mozilla.org/mozilla.dev.tech.network
Subject:  

Re: Reducing DNS latency

NNTP-Posting-Host:  63.245.216.66

I think you're basically saying that if you had an enhancement that yielded
a 10% improvement in overall pageload times, scaled well, and didn't have a
privacy or security concern would we consider deploying it in the browser?

If that was the most practical way to reach our users, absolutely.

But you've set a pretty high bar and I'm skeptical that this can yield
those kind of  broad based gains. Prove me wrong and we'll all be better
for it. :)

-P



On Fri, Dec 12, 2014 at 3:53 PM, Vulimiri, Ashish 
wrote:
>
> Apologies for the slow response, I was traveling.
>
> Suppose (1) we were going to replicate exclusively to whichever DNS
> servers the OS has configured, so no trust issues would be raised; and (2)
> we had enough large-scale/realistic experimental data to prove the
> technique does significantly reduce page load time when used this way.  In
> your opinion, what would the most appropriate place be for something like
> this to be deployed?
>
> 1.  In the browser.
>
> 2.  As a a separate piece of software users would need to install.
>
> 3.  As part of bind or another DNS resolver.
>
> 4.  In the OS.
>
> > On Dec 7, 2014, at 3:59 PM, Christopher Barry <
> christopher.r.barry@gmail.com> wrote:
> >
> > On Sun, 7 Dec 2014 09:38:36 -0500
> > Patrick McManus  wrote:
> >
> >> On Sat, Dec 6, 2014 at 7:21 PM, Christopher Barry <
> >> christopher.r.barry@gmail.com> wrote:
> >>
> >>>
> >>> My strong opinion, and indeed it is the understood expectation of
> >>> anyone using any application that requires name resolution, is that
> >>> all applications always strictly obey the local resolver
> >>> configuration of the host running the application. Period.
> >>
> >
> > Hi Patrick,
> >
> > I understand the spirit of encouraging investigation and development,
> > that's a great thing and I couldn't agree more.
> >
> > I'm personally skeptical that this redundant name resolution scheme
> > wouldn't just adversely impact name servers and make a lot of noise for
> > relatively imperceptible gain if any, especially if deployed at scale.
> > In my experience, it's not name resolution that's the bottleneck in my
> > web usage. It's typically waiting for ad servers to deliver their
> > drivel.
> >
> > And, while I'm also concerned about the potential of user privacy
> > invasion and tracking capabilities that appear, to me at least, to
> > possibly be a subliminal motive for this research, that's just my
> > personal gut reaction and my *opinion*, and not at all at the heart of
> > my objection to this discussion here.
> >
> > please see comments inline...
> >
> >>
> >> I'm going to push back against this notion that operating system
> >> services must always take priority.
> >
> > well, it's not really a notion. it's established secure practice
> > that's in place for a reason. you're going to say that an application
> > should take *priority*, essentially usurp control over system services
> > for it's own particular reasons? possibly behind the user's back where
> > private data will be shared with unknown third parties? huh? doesn't
> > that basically describe how malware operates? i'm reasonably sure you
> > don't really feel that way.
> >
> >>
> >> For instance, windows provides a trust root list that firefox ignores
> >> in favor of its own. That's a design choice.
> >
> > but, the user in this case is free to control this subsystem, no?
> >
> >>
> >> There are several reasons we might do things like that - performance,
> >> security, and the ability to effect legacy configurations for example.
> >> There are also costs in terms of administrative awkwardness,
> >> surprises, and incompatibilities. Its not to be undertaken lightly.
> >
> > increasing performance and security are correct goals within the scope
> > of the application, absolutely, and reasonable defaults are always a
> > good idea too, but i will posit that it's not the domain nor purview of
> > applications to worry about, nor override system functions. If one
> > has an improvement to the behavior of a system function, they should
> > put their energy into helping improve that system function, but it
> > should not be a part of an application where it's use essentially
> > performs an end-run around the existing system function.
> > simply put, that just ain't cool.
> >
> >>
> >> It would be wrong to interpret this mail as supporting the algorithm
> >> being discussed in this thread (I'm basically open minded on the
> >> topic), I'm just saying its plausible to discuss.
> >
> > well that's encouraging. I consider myself open minded as well, but
> > in this case the discussion should be done in the appropriate forum(s).
> > while the work is interesting, and likely requires much more
> > investigation, the suggested behavior is not germane to this forum.
> >
> >>
> >> The much larger problem, to me, is that use of a public dns adds
> >> another party to your transaction: {client, origin, isp,
> >> public-dns} .. its conceivable such an algorithm would boost
> >
> > bingo. and this is why this is a very bad idea unless the
> > administrator-user has complete control over the name servers being used
> > if and when this idea is deployed as a 'system level daemon'.
> >
> >> performance using only multiple isp servers, but there is no evidence
> >> to show that at this point and honestly thin evidence overall. So its
> >> the kind of thing that bears more investigation.
> >
> > agreed. yet for me, and granted maybe i'm missing something important
> > here, but intuitively, it's not clear how this methodology at scale
> > would not eventually settle into similar (or worse) latencies over time,
> > while at the cost of a lot of resource-consuming noise and churning that
> > would, in my view, ultimately impact the latencies of literally all
> > other traffic. but yeah, it may merit more investigation, but probably
> > not here.
> >
> >>
> >> regardless of possible performance benefit. If this is what FF is doing
> >>> now,
> >>>
> >>
> >> Just to be clear - this thread is discussing the results of a small
> >> academic experiment not of general Firefox behavior. I appreciate the
> >> authors bringing it here to discuss - let's keep it a welcoming
> >> environment for exploration.
> >
> > yes, and discussion of it with the idea of possibly helping the authors
> > find a more appropriate forum in which to investigate it's possible
> > merits should definitely be undertaken. i'm certainly not saying that
> > they should not investigate the potential usefulness of their work, nor
> > that if it does indeed prove to be an effective idea, that Firefox (and
> > any other application) would not benefit from that.
> >
> > i'm simply saying that even considering embedding this technology into
> > any application, not just Firefox, is absolutely not the correct
> > approach, and that i would hope members of this forum, knowing that as
> > well, would help to steer the authors in the right direction.
> >
> > for instance, the bind-* or dhcp-* lists may be a good place for these
> > folks to initially discuss their project ideas, and folks there may have
> > additional ideas about other appropriate lists to address, and where and
> > how this technology can be best investigated and evaluated for use in
> > other client operating systems.
> >
> > The bind/dhcp list server:
> > https://lists.isc.org/mailman/listinfo
> >
> >
> > --
> > Regards,
> > Christopher Barry
> >
> > Random geeky fortune:
> > Round Numbers are always false.
> >               -- Samuel Johnson
> > _______________________________________________
> > dev-tech-network mailing list
> > dev-tech-network@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-tech-network
>
> _______________________________________________
> dev-tech-network mailing list
> dev-tech-network@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-network
>
>