From:  Christopher Barry <christopher.r.barry@gmail.com>
Date:  13 Dec 2014 06:33:21 Hong Kong Time
Newsgroup:  news.mozilla.org/mozilla.dev.tech.network
Subject:  

Re: Reducing DNS latency

NNTP-Posting-Host:  63.245.216.66

On Fri, 12 Dec 2014 20:53:13 +0000
"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.
>

to answer your questions:
1) never.
2-4) possibly, with their buy-in and approval, and global administrative
control


I think you mean 'query', not 'replicate' above... correct?

I suspect your blast technique will show some promise at low levels of
deployment. This seems somewhat obvious. Where the algorithm falls down
is at scales you would not reasonably be able to test at. My suspicion
is that if you a) presented this idea to the glib or bind folks, or b)
created an RFC outlining your proposal you would better see where this
idea stands.


Speaking strictly about *NIX here.

From 'man resolv.conf':

"
 nameserver Name-server-IP-address

 Internet  address  of  a  name  server that the resolver should query,
 either an IPv4 address (in dot notation), or an IPv6 address in colon
 (and possibly dot) notation as per  RFC  2373.   Up to  MAXNS
 (currently  3,  see  )  name servers may be listed, one per
 keyword.  If there are multiple servers, the resolver library queries
 them in  the  order  listed.   If  no  nameserver  entries  are
 present, the default is to use the name server on the local machine.
 (The algorithm used is to try a name server, and if the query times
 out, try the next, until out of name servers, then repeat  trying all
 the name servers until a maximum number of retries are made.)
"

Note that this is the expected behavior of how the glib resolver
handles the configured nameservers. It is not uncommon to configure the
first nameserver as the primary, the second as a secondary (often both
in-house enterprise servers, or redundant ISP servers), with the third
being a public dns only to be used when absolutely necessary e.g. if
both preferred nameservers are down for some reason. This functionality
is desired for many reason already stated below.

Note also that the resolver allows a round-robin query methodology
using the 'rotate' option, which essentially spreads the load around
all configured name servers if that functionality is desired.

Note also, that the resolver only queries the *local* nameserver if
resolv.conf is not present. Again, this is often desired, and would be
something the admin would decide.

-C


>> 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 <
>>> 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



--
Regards,
Christopher Barry

Random geeky fortune:
Q:	What's the difference between a duck and an elephant?
A:	You can't get down off an elephant.