From:  "Vulimiri, Ashish" <>
Date:  13 Dec 2014 04:53:13 Hong Kong Time

Re: Reducing DNS latency


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  wrote:
> On Sun, 7 Dec 2014 09:38:36 -0500
> Patrick McManus  wrote:
>> On Sat, Dec 6, 2014 at 7:21 PM, Christopher Barry <
>>> 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:
> --
> Regards,
> Christopher Barry
> Random geeky fortune:
> Round Numbers are always false.
> 		-- Samuel Johnson
> _______________________________________________
> dev-tech-network mailing list