Subject: [dnsext] add support for latency-sensitive dns applications such as the web?

From: Paul Vixie <[email-masked]>
Date: Wed, 14 Apr 2010 19:00:58 +0000

if there are latency-sensitive dns applications (such as the web) who can't
manage their routing efficiency at their application layer, and we want to
add features to dns to support these applications, then the way to do this
in a noncontroversial way is to make the new behaviour fully opt-in, end to
end.

for example, in the current proposal along these lines, if stub resolvers
were required to add the new option before a full resolver (recursive dns)
would behave differently, then it would just be a matter of rolling out a
newer runtime (which happens very frequently for opera, firefox, explorer,
safari, and konquerer, who between them represent 95% of the web market)
in order to make this new feature near-universally available.

if, further, a full resolver's "different behaviour" in the presence of
this option included not only using a wider cache key (to given ip-range
specific responses) but also the decisionmaking power to say that the
client's represented IP address makes no sense (for example it's RFC 1918)
and thus uses a different notion (for example, transport source address as
provided by a NAT/ALG) as its cache key and as what it forwards to the
authority server, then we still preserve the basic "opt-in" feature level
as far as the enduser is concerned.

if a browser, or stub resolver, or operating system, or NAT/ALG box, were
to strip off this blob, or to add it without the user's permission, then
the user would have recourse against those technology or service providers
("you are in violation of RFC XYZ, please fix your product/service") and
the strippage/addage would be detectable using outside services like ICSI's.

as a bonus, we could make it so that in the presence of this option
(assuming that it was present in both the request and the response), rrset
order was no longer incidental, and should be preserved from the authority
all the way to the application.  that would allow deliberate fallback/
priority to be expressed by web service operators, which has been long
desired and often wrongly presumed.

the option blob would ideally include more than just the client ip address
(which might be useless or pessimal for predicting web performance anyway)
and should contain a UUID for the enduser, their preferred human language,
their GPS coordinates if known, their directional vector if mobile, and
room for expansion within the blob if more ideas come later.  in other
words if we're going to do this at all, let's really do it right.

i can write a -00 i-d along these lines if there's general interest in it.

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 14 Apr 2010 13:08:40 -0700

Uhh, why?

We already have a model that actually WORKS, and is shown to work: you don't need end-to-end behavior or changes to handle latency sensitive applications already, you simply have to have a reasonably good understanding that "users behind resolver X are on network Y, because resolver X is affiliated with network Y".

I know you hate this on a near religious ground, and it is based on a very ugly assumption, but it does WORK.  

Adding in more detail might help a little, but only at the edges, since almost all of the win is simply identifying network provider Y (or for a national ISP, what region of the nation within Y), not where the user is in detail in Y's network. 

And measure for yourself: what is the latency to www.bing.com, www.yahoo.com, and www.google.com, when you use your network's resolver and the result from Google Public DNS?

All three play these DNS games on the authority side to various degrees.

And the only major case where this doesn't work is when the user wishes to use resolver Z, which is not affiliated with network Y.

Thus requiring the stub resolver to change FIRST is really a polite way of saying "kill this alltogether", because you know and I know that such extensions aren't going to happen.

Furthermore, this option is useful when the stub resolver has already opted in to using resolver Z: should clients have to opt-in TWICE?  Should ALL clients change just so the few who don't want to use their ISP provided resolvers will see benefit?  (because the only way the stubs will change is if ALL of a large set change, not just those who would receive benefit)

Finally, clients actually have very poor notions of where they are in network space, thanks to NATs, tunnels, etc.  Far better to have the resolver identify where the client is in network space, as they implicitly do in most cases anyway.

And if you want to encode MORE information about the client in an app-dependent manner beyond where they are in the network topology space, simply add garbage within the intermediate domains (eg, hey.i.am.at.1947.center.street.amazon.com) and thus only the final authority and the client applications have to do anything about it, and no protocol changes are required.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 14 Apr 2010 13:57:39 -0700

> in order to make this new feature near-universally available.

Surely hiding the option in the code of browsers is less privacy and
user friendly than people simply choosing the resolvers they use?

> desired and often wrongly presumed.

Another attempt at RFC3484? why not simply rewrite web browsers to use
_http SRV ?

> words if we're going to do this at all, let's really do it right.

Based on discussion on this list, I think it would also need to
include the possibility that the user and client does not reside on
this planet. So, GPS may not suffice :)

-- 
Colm

---

From: Michael Graff <[email-masked]>
Date: Wed, 14 Apr 2010 16:09:09 -0500

> this planet. So, GPS may not suffice :)

Ironically enough, I have issued DNS queries from space.  Well, I wasn't
in space, but the CPU running the code was.

- --Michael

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 14 Apr 2010 14:11:45 -0700

> Another attempt at RFC3484? why not simply rewrite web browsers to use

I don't think SRV handles localized resources any better than A
records do now.  They add priority and weighting and alternate ports,
but none of those help guide users to the geographically nearest
server.

---

From: [email-masked]
Date: Wed, 14 Apr 2010 21:49:25 +0000

On Wed, Apr 14, 2010 at 02:11:45PM -0700, Matthew Dempsky wrote:
> 2010/4/14 Colm MacCarthaigh <[email-masked]>:

	just for fun...

	many moons ago, there was much hue and cry over the fact
	that a law office in a building in Seattle had nearly 800ms
	latency to the partner firm one floor down.  Seems they
	used different ISPs, different long-haul carriers, and
	the only place these two peered was someplace in Northern
	Europe.  (a canonical argument for local peering, e.g. exchange
	points).

	I suspect that geographic proximity is not really what you
	are after... I think topological proximity might be a better
	first metric.

--bill

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 14 Apr 2010 15:01:36 -0700

>        are after... I think topological proximity might be a better

Right, I had already meant "geographically nearest" in the abstract
sense, but I realize now "topologically nearest" would have been a
better phrase to use.  Sorry for any confusion.

---

From: Jim Reid <[email-masked]>
Date: Wed, 14 Apr 2010 23:43:07 +0100

> better phrase to use.  Sorry for any confusion.

Either could be valid, depending on the circumstances and use case.

As a for instance, wi-fi on the train between Scotland and London goes  
through some Swedish ISP. [No, I don't understand this either...] That  
means I get to browse the ad-splattered version of the BBC web site  
rather than the ad-free one enjoyed by the customers of UK ISPs. Those  
customers presumably pay the TV licence fee that funds the BBC and  
should get free access to all the BBC's services. And the BBC only has  
UK Internet rights for some of that content. So I don't get to see or  
listen to some stuff I should be able to get while on the train.

For this case, if stupid DNS tricks were used, I'd want them to be  
using a metric of "geographically nearest" (if such a thing was  
viable) instead of "topologically nearest". That way I might be able  
to signal to the web server or the train's resolver that I was in the  
UK even if the network thought I wasn't.

IMO DNS is not the place to solve these sorts of irritants because  
they should be something for the web server and browser to work out  
betweem themselves.

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 14 Apr 2010 15:51:20 -0700

> Either could be valid, depending on the circumstances and use case.

Clarifying again, I meant "topologically" in the mathematical sense;
i.e., abstracting away from any particular topology such as either
"network topology" or "geographic topology".

---

From: Paul Vixie <[email-masked]>
Date: Wed, 14 Apr 2010 23:14:31 +0000

> Date: Wed, 14 Apr 2010 21:49:25 +0000
> From: [email-masked]
> ...

address similarity is by itself a poor predictor of topological proximity,
even for evaluators who are holding a "full routing table".  that's why my
proposal is to include many attributes including geo, ip, uuid, and language,
and to let the authority server decide what to do.

it's possible that an authority server will want to send a response that
directs tcp/80 to a low-rtt server, or, given knowledge of the end user's
language and of their location and direction, may wish to send them to a
server that's "better" in some other way than just "low latency".  good
internet engineering means not overspecifying.  i should have titled my
message as follows:

"Subject: support for user-context-sensitive dns applications (e.g.: web)"

---

From: Jim Reid <[email-masked]>
Date: Thu, 15 Apr 2010 00:17:15 +0100

> "network topology" or "geographic topology".

OK. So we're making progress. I think.

IIUC the problem is now about how to use DNS to provide answers that  
are topologically optimal in a mathematical sense (for some definition  
of these terms) that can, depending on context, apply to network or  
geographic topology? Or some combination of these and any other types  
of topology which might apply? Have I got this right?

---

From: [email-masked]
Date: Wed, 14 Apr 2010 23:51:17 +0000

> even for evaluators who are holding a "full routing table".  that's why my

	I did not state or even infer address similarity was 
	indicative of topological proximity.  for topology,
	the best indicator is RTT.  which does not seem to make
	your short list.  perhaps it is in the "includes many attributes".

> and to let the authority server decide what to do.

	well - i suspect that the agony of choice is going to
	be this proposals undoing, UNLESS some bright bulb steps up
	and proposes a rank ordering .. in my case, I think that 
	RTT for topological proximity is the first, best metric.
	the rest is icing.  (well, except for my requested addition
	to this sausage of mishmashed demnads... I want a hash of the
	software version of the resolver handed out....)

	some logic will need to be agreed on as to search order
	for evaluating the range of options or chaos will ensue.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 15 Apr 2010 00:03:58 +0000

> Date: Wed, 14 Apr 2010 23:51:17 +0000
> > proposal is to include many attributes including geo, ip, uuid, and
> > language, and to let the authority server decide what to do.
> 
> 	well - i suspect that the agony of choice is going to be this
> 	proposals undoing, UNLESS some bright bulb steps up and proposes a
> 	rank ordering ..

no, that would be fatal to the effort, being an overspecification.

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 14 Apr 2010 17:04:53 -0700

On Wed, Apr 14, 2010 at 4:17 PM, Jim Reid <[email-masked]> wrote:
> IIUC the problem is now about how to use DNS to provide answers that are
> topologically optimal in a mathematical sense (for some definition of these
> terms) that can, depending on context, apply to network or geographic
> topology? Or some combination of these and any other types of topology which
> might apply? Have I got this right?

Well, I was just trying to be general in pointing out that SRV records
don't support any sort of topological optimization, which as a
corollary means it's insufficient for tackling the problem
edns-client-ip is trying to address.

But yes, there is a general problem of how to improve the topological
awareness of DNS.  I can readily see value in extending it to be
network-topology-aware, but I'm not yet convinced there's any use in
extending it beyond that.  As such, I'm happy for now to adopt a
simple and reasonably adequate solution to that subproblem (e.g.,
edns-client-ip), rather than wait for a more general (and most likely
far more complex) solution.

---

From: [email-masked]
Date: Thu, 15 Apr 2010 03:44:11 +0000

> no, that would be fatal to the effort, being an overspecification.

	sort of like the fatal rank ordering of BGP evaluation,
	IPv6 soure address selection, etc.  I will step back and
	watch this trainwreck... or see vendors "legislate from the
	bench" on "the" defacto packing of attributes.  

--bill

---

From: Paul Vixie <[email-masked]>
Date: Thu, 15 Apr 2010 04:44:40 +0000

> From: John Payne <[email-masked]>
> Date: Thu, 15 Apr 2010 00:03:27 -0400
> 
> Sorry if I missed the problem statement, but are you trying to guess at
> what "stupid dns tricks" are used for and why the client IP is useful in
> some limited corner cases and design to that, or is this an entirely
> different issue than the edns-client-subnet proposal?

neither.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 15 Apr 2010 04:43:38 +0000

> Date: Thu, 15 Apr 2010 03:44:11 +0000
> 	IPv6 soure address selection, etc.

nothing like those.

>                                             I will step back and

some web sites will care about language, others won't.  some end users
will send language, others won't.  this is nothing like bgp tiebreaking.

---

From: Jim Reid <[email-masked]>
Date: Thu, 15 Apr 2010 09:36:55 +0100

On 15 Apr 2010, at 04:55, John Payne wrote:

> And again, you are confusing server selection with content.

I'm not. I think you've not been paying attention.

> In most geo-restricted setups, what matters is your client IP for  
> content selection and localization (if there aren't any application  
> layer hints).
> The "stupid DNS" tricks only select a server for you not the content.

Which means I'm directed to whatever server is "optimal" for someone  
in Sweden. Which probably isn't optimal for my packets or the content  
I'm served.

> For whatever reason, the BBC thinks that your client is in Sweden.  
> Try using opendns or google public dns... You'll likely get  
> different servers than the train ISP's resolvers return...

That's not allowed: you have to use the train's resolving server. [I  
know this because my laptop already runs a resolving server to work  
around the usual hotel network brain damage.] So in this example, I'd  
be relying on the train's network to do the Right Thing with its  
stupid DNS tricks which seems unlikely. Or I'd be hoping it allowed me  
to add the location info of my choice to the outbound queries -- how  
would I know what's optimal for where the train is? -- which is even  
less likely. Or, if I could send location info to the resolver, it  
didn't "optimise" that data before making the query. Which doesn't  
seem likely either.

---

From: Jim Reid <[email-masked]>
Date: Thu, 15 Apr 2010 12:33:21 +0100

> user friendly than people simply choosing the resolvers they use?

Colm, I just don't get it. Sorry. If a web server/browser needs  
location or language info or whatever for some reason, surely the  
sensible place to configure that info is in the web software, not the  
DNS? To rephrase the old joke about DEC Field Service, would you  
change a car's battery because the tyres were flat?

---

From: [email-masked]
Date: Thu, 15 Apr 2010 11:47:58 +0000

> will send language, others won't.  this is nothing like bgp tiebreaking.

	if you say so.  I don't believe you. 

--bill

---

From: Martin Barry <[email-masked]>
Date: Thu, 15 Apr 2010 13:57:36 +0200

$quoted_author = "Jim Reid" ;
> sensible place to configure that info is in the web software, not
> the DNS? 

And web browsers can and do send some of that very information to web
servers.

But the issue here is that the current implementation of "stupid DNS tricks"
performs selection of a server / cluster at the point when DNS is used to
translate a name to an IP. Delaying this redirection till after the
application connects is likely to negate any of the benefits of doing so. It
also can add new issues such as caching and bookmarking of specific server /
cluster URIs.
 
Also, the use of these "tricks" is not limited to the web and as such
pushing the implementation of it out to the application does not make sense.

cheers
Marty

---

From: Alex Bligh <[email-masked]>
Date: Thu, 15 Apr 2010 13:15:02 +0100

--On 15 April 2010 13:57:36 +0200 Martin Barry <[email-masked]> wrote:

> But the issue here is that the current implementation of "stupid DNS
> tricks" performs selection of a server / cluster at the point when DNS is
> used to translate a name to an IP.

This whole discussion to me bears comparison to the railways. In the UK
we have different people running the trains to those that own the tracks.
This discussion is a bit like:

  Various rail operating companies have decided to deploy rolling-stock
  with wider loads. This was much cheaper for them than putting on
  more wagons or using more trains. They've found that occasionally
  the wagons now crash into other wagons and trackside infrastructure,
  and are thus proposing those who own the tracks move them a bit further
  apart. They emphasise use of the new wider wagons will be entirely
  optional.

-- 
Alex Bligh

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 15 Apr 2010 05:18:33 -0700

On Apr 15, 2010, at 1:36 AM, Jim Reid wrote:
> 
>> For whatever reason, the BBC thinks that your client is in Sweden. Try using opendns or google public dns... You'll likely get different servers than the train ISP's resolvers return...
> 
> That's not allowed: you have to use the train's resolving server. [I know this because my laptop already runs a resolving server to work around the usual hotel network brain damage.] So in this example, I'd be relying on the train's network to do the Right Thing with its stupid DNS tricks which seems unlikely. Or I'd be hoping it allowed me to add the location info of my choice to the outbound queries -- how would I know what's optimal for where the train is? -- which is even less likely. Or, if I could send location info to the resolver, it didn't "optimise" that data before making the query. Which doesn't seem likely either.

Guys, such localization is usually NOT done in DNS but at the HTTP layer, when the client IP is actually available and its looked up in a GeoIP database, as such tricks are NOT nearly so latency critical.

My suggestion in the BBC case is look up the external IP you get in the Maxmind GeoIP database (there is an online interface) and if its getting the wrong answer, talk to them (they are the biggest supplier of this data IIRC, although there may be others).

---

From: Martin Barry <[email-masked]>
Date: Thu, 15 Apr 2010 14:44:37 +0200

$quoted_author = "Alex Bligh" ;
> This whole discussion to me bears comparison to the railways.

Actually, it doesn't. Alex, not to pick on you personally, but analogies are
not really cutting it in trying to move this discussion forwards to either
acceptance, compromise or rejection.

The benefits of this proposal accrue to those using DNS resolvers that are
not topologically close to the client and the services they are using that
employ "stupid dns tricks". Implementation of it only really makes sense for
the operators of those resolvers and services. For everyone else it is
completely optional.

There is some privacy concerns with exposing more information about the
client to the authorative DNS server but I am of the opinion that users
would trade that for the better performance of the service they are
connecting to.

cheers
Marty

---

From: Jim Reid <[email-masked]>
Date: Thu, 15 Apr 2010 13:53:14 +0100

On 15 Apr 2010, at 13:48, John Payne wrote:

> You're not relying on the train's network to do anything with DNS  
> tricks.  You're relying on the train to have decent Internet  
> connectivity which it sounds like for some use cases, it doesn't.

You still don't seem to understand. So let me spell it out. Once this  
WG legislates for stupid DNS tricks, the train's network will use  
them. This will not improve my browsing experience. It won't help me  
improve it because I will be unable to know what stupid DNS tricks I  
can configure (ie stub resolver hooks) will work for the network I'm  
using.

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 15 Apr 2010 06:20:43 -0700

On Apr 15, 2010, at 5:53 AM, Jim Reid wrote:

>> You're not relying on the train's network to do anything with DNS tricks.  You're relying on the train to have decent Internet connectivity which it sounds like for some use cases, it doesn't.
> 
> You still don't seem to understand. So let me spell it out. Once this WG legislates for stupid DNS tricks, the train's network will use them. This will not improve my browsing experience. It won't help me improve it because I will be unable to know what stupid DNS tricks I can configure (ie stub resolver hooks) will work for the network I'm using.

The train network is ALREADY seeing stupid DNS Tricks (TM), and actually, they work for the train network because the DNS does match the data path.

Thats the point, the basic trick: That resolver X indicates the user is on network Y, works like a charm EXCEPT if the user is using a resolver NOT AFFILIATED with the network provider.  Since the train network forces you to use resolver X, the DNS tricks work perfectly (its just the routing thats fubared)

Thus the question is not should DNS enable stupid DNS tricks: it already does, simply by the fact that, for most users, the resolver is part of the network provider's infrastructure and can be identified as such.

The question is, should users be penalized for using NON AFFILIATED DNS resolvers: Namely, should OpenDNS and Google Public DNS continue to return consistently inferior results?

And there are three simple choices:

a)  Standardize a way for third party resolvers to explicitly convey this information (edns-client-ip) WITHOUT requiring client changes.

b)  Watch as OpenDNS and/or Google Public DNS make pairwise agreements with the major authorities doing these tricks (and therefore lock out other third-party resolvers.)

c)  Let these services be inferior in user experience in the name of DNS purity.

Because without something standard for A, you will get a combination of B and C.  Is that what this working group really wants?

---

From: Jim Reid <[email-masked]>
Date: Thu, 15 Apr 2010 14:29:41 +0100

On 15 Apr 2010, at 14:20, Nicholas Weaver wrote:

> The question is, should users be penalized for using NON AFFILIATED  
> DNS resolvers: Namely, should OpenDNS and Google Public DNS continue  
> to return consistently inferior results?

IMO, people should be free to choose for themselves. If they select  
providers that do evil/stupid things, economic Darwinism will take  
care of that without any help from this WG.

---

From: [email-masked]
Date: Thu, 15 Apr 2010 13:29:43 +0000

> the operators of those resolvers and services. For everyone else it is

	so... if the primary benefit is for stubs that are topologically
	distant from their cache, then much of the justification seems
	hinged on the fact that so many people are in the path between
	the stub and the cache and everyone wants to "help" the stub
	with the "right" information...  wouldn't a simpler approach be
	to reduce the distance between the cache and stub?  

	i mean if the current "distance" between the two is order 7000microseconds,
	wouldn't be easier to just move the cache closer to the stub, say 
	under 300microseconds?  Then the whole point of futzing w/ the 
	protocol, backward compatability, unused/underused code paths, adnasua
	just goes away...  
 
> would trade that for the better performance of the service they are

	bad tradeoff imho... just move the cache closer to the stub and 
	most of the world will be happy.

--bill

---

From: Edward Lewis <[email-masked]>
Date: Thu, 15 Apr 2010 09:36:46 -0400

>might apply? Have I got this right?

No, not quite.  "optimal in the business sense."

>This whole discussion to me bears comparison to the railways.

A double hit to Alex on this...(referring to the other message saying 
this isn't the right analogy).  The discussion might relate to a view 
of the railways but the discussion is off the mark with respect to 
edns-client-ip.

IP addresses are used, in the edns-client-ip case, to make networks 
run better.  This isn't just fast browser page loads, it includes 
directing traffic to different data centers for whatever reason - 
load, etc. - known at design time, or even later, if traffic 
monitoring is happening.

PS - Why is is that we say "the web is not the net" and then try to 
come up with solutions that benefit the web?  (Referring to the subj 
line.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Wouldn't it be nice if all of the definitions of equivalence were the same?

---

From: John Payne <[email-masked]>
Date: Wed, 14 Apr 2010 23:55:35 -0400

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

On Apr 14, 2010, at 6:43 PM, Jim Reid <[email-masked]> wrote:

> As a for instance, wi-fi on the train between Scotland and London  
> goes through some Swedish ISP. [No, I don't understand this  
> either...] That means I get to browse the ad-splattered version of  
> the BBC web site rather than the ad-free one enjoyed by the  
> customers of UK ISPs. Those customers presumably pay the TV licence  
> fee that funds the BBC and should get free access to all the BBC's  
> services. And the BBC only has UK Internet rights for some of that  
> content. So I don't get to see or listen to some stuff I should be  
> able to get while on the train.
>
> to signal to the web server or the train's resolver that I was in  
> the UK even if the network thought I wasn't.
>

And again, you are confusing server selection with content. In most  
geo-restricted setups, what matters is your client IP for content  
selection and localization (if there aren't any application layer  
hints).
The "stupid DNS" tricks only select a server for you not the content.

For whatever reason, the BBC thinks that your client is in Sweden. Try  
using opendns or google public dns... You'll likely get different  
servers than the train ISP's resolvers return... but I'd be surprised  
if you got different content.

---

From: Alex Bligh <[email-masked]>
Date: Thu, 15 Apr 2010 15:22:30 +0100

--On 15 April 2010 09:36:46 -0400 Edward Lewis <[email-masked]> wrote:

> this isn't the right analogy).  The discussion might relate to a view of
> the railways but the discussion is off the mark with respect to
> edns-client-ip.

OK, railway analogy aside (it amused me), Paul Vixie has described what
is being done as "stupid DNS tricks" at the authoritative server.
Ignoring the pejorative label, it seems strange to me we should
be considering changing the behaviour of recursive resolvers, rather
than solving the problem these "stupid DNS tricks" were designed to
solve another way.

Martin Barry objected to my characterisation of optionality:
 > For everyone else it is completely optional."
I'm not sure that's true. Firstly, it's yet more protocol
complexity, and that hurts everyone. Secondlym
is this EDNS0 option not going to be found in every query
originated by a recursive resolver that supports it? Receiving
EDNS0 options does not appear to be optional for authoritative
servers, yet 99% of authoritative servers will not process them.

-- 
Alex Bligh

---

From: John Payne <[email-masked]>
Date: Thu, 15 Apr 2010 00:03:27 -0400

On Apr 14, 2010, at 7:14 PM, Paul Vixie <[email-masked]> wrote:

> language,

Sorry if I missed the problem statement, but are you trying to guess  
at what "stupid dns tricks" are used for and why the client IP is  
useful in some limited corner cases and design to that, or is this an  
entirely different issue than the edns-client-subnet proposal?

---

From: John Payne <[email-masked]>
Date: Thu, 15 Apr 2010 08:48:04 -0400

> I'm not. I think you've not been paying attention.

Besides the unoptimal server selection, you were complaining about content (ad laden and UK only stuff).

> 
>> In most geo-restricted setups, what matters is your client IP for content selection and localization (if there aren't any application layer hints).
> Which means I'm directed to whatever server is "optimal" for someone in Sweden. Which probably isn't optimal for my packets or the content I'm served.

Which is an issue, yes.  But it's probably still better than a server in Asia or the Western US (which wouldn't make sense for BBC content, but other popular content without "stupid DNS tricks" would have that problem).

How do you know that latency-wise Sweden isn't the best choice for your packets?  If, for example, the train is bouncing packets off a satellite to a downlink in Stockholm, it's almost certainly going to be better to serve you from Sweden than London or Manchester.

---

From: John Payne <[email-masked]>
Date: Thu, 15 Apr 2010 09:15:10 -0400

> You still don't seem to understand. So let me spell it out. Once this WG legislates for stupid DNS tricks, the train's network will use them. This will not improve my browsing experience. It won't…

As far as the edns-client-subnet option is concerned, if your train's resolver is "close" to you, then it has no incentive to enable it.  If it does, the people that care about such things have no incentive to listen to it.  In the worst possible case, it doesn't help you, no.  But it also doesn't hurt you.

As far as Paul's proposal is concerned, as far as I can make out, it isn't at all useful and is only designed to try and kill the edns-client-subnet option.

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 15 Apr 2010 07:37:17 -0700

On Apr 15, 2010, at 6:29 AM, Jim Reid wrote:

> IMO, people should be free to choose for themselves. If they select providers that do evil/stupid things, economic Darwinism will take care of that without any help from this WG.

Economoic darwinism has a market failure here.

THe existing status quo is "You use your ISP's recursive resolver, you get good results because these tricks work.  Only if you use a third party resolver service do your results suffer".

Do you actually mean to say "Using a third party resolver is a stupid thing and shouldn't happen?"  or "You should only be able to use third party resolvers that make pairwise agreements with major authorities, limiting other market entries?"  

Because that is the equilibrium position you are advocating, because the DNS tricks themselves are now entrenched and won't go away.  

These tricks would only go away if most people switched to third party resolvers, and people won't switch to third party resolvers because 
a: its an explicit act and 
b: the performance gets worse because, among other things, these DNS tricks stop working!

---

From: Jim Reid <[email-masked]>
Date: Thu, 15 Apr 2010 15:49:43 +0100

On 15 Apr 2010, at 15:37, Nicholas Weaver wrote:

> Do you actually mean to say "Using a third party resolver is a  
> stupid thing and shouldn't happen?"  or "You should only be able to  
> use third party resolvers that make pairwise agreements with major  
> authorities, limiting other market entries?"

Neither. I'm saying using a third party resolver is a stupid thing to  
do. [Everyone here should have first-hand experience why that's the  
case.] It's even more stupid because DNSSEC is lurking around the  
corner and that'll mean edge devices validating stuff for themselves.  
But if people want to do stupid things and know what they're buying  
into, they should be free to do that. There's an abundance of that  
sort of thing on the Internet already. Similarly, providers who want  
to offer stupid DNS tricks are welcome to do so. The market will take  
care of them and their business models if DNSSEC deployment doesn't  
kill them first.

Can we now get back to defining requirements and specifying an actual  
problem?

---

From: Colm MacCárthaigh <[email-masked]>
Date: Thu, 15 Apr 2010 08:13:17 -0700

2010/4/15 Jim Reid <[email-masked]>:
> Colm, I just don't get it. Sorry. If a web server/browser needs location or
> language info or whatever for some reason, surely the sensible place to
> configure that info is in the web software, not the DNS? To rephrase the old
> joke about DEC Field Service, would you change a car's battery because the
> tyres were flat?

This is already the case. HTTP provides many of this information
already, and there's a rich and expressive syntax using Accept and
Vary headers to negotiate such things. Because it's relatively easy to
extend HTTP, and to build applications on top of it, implementers now
also support other information - including GPS data, something
browsers can typically provide now.

It is sensible, and it occurs already. But we are not talking about
giving users different data depending on all of these sorts of things;
that is a solved problem. We are talking about routing clients to
their topologically closest node.

I would argue that the average path is stable for long enough, and
enough of internet topology is knowable, that address-based proximity
is not snake-oil.

Real-world operators, including the drafters and contributors of this
I-D, to this today - and it seems to work for them. This is how the
real internet operators right now today. I don't see how it is not
sensible to afford them an option code and a reference text for the
technique so that at least implementations are not fragmented.

It is very hard to build applications on top of DNS in the way that
protocols such as HTTP  can be extended. Most of the properties you
raise did not arise in HTTP through standardisation, but instead
through experimentation. Even the direct analogue of this proposal,
the X-Forwarded-For: header is an "X-" header - it arose through
private experimentation.

DNS would seem like culturally the worst possible place to try and do
this. We now have contributors here arguing that EDNS options are not
in fact optional. There is also no private use range for option codes.
The message seems to be ; all EDNS options have to be universally
suitable, achieve consensus on rationality and meet a technical bar of
perfect.
Faced with that attitude, if browsers were to radically overhaul their
lookup mechanisms, it would make more sense to fork DNS entirely.
Strangely enough, that's essentially what CDNs have already done.

-- 
Colm

---

From: Edward Lewis <[email-masked]>
Date: Thu, 15 Apr 2010 11:14:14 -0400

>than solving the problem these "stupid DNS tricks" were designed to

In the context of authorities that tailor responses to where the 
query is purported to be coming from: The issue is that for the most 
part recursive servers sit topologically close to the users they 
serve.  This option's goal is to make topologically remote (server to 
stub) recursive servers provide service to the stubs (etal) on par 
with what they would get with topologically close (server to stub) 
servers.

That's why this is built into the DNS and not in the applications.

>complexity, and that hurts everyone.

I disagree that it hurts everyone.  I've said this in an earlier 
message, complexity is another word for optimizations.  Before 
declaring complexity as "bad" I would want to see specific reasons 
why.  Complexity does have a cost, but is the benefit of the 
corresponding optimization exceed the cost of the complexity?

>Secondly,

If the problem is that an unrecognized EDNS0 option causes an issue 
for servers that recognize EDNS0 but not the specific option, we 
might as well trash EDNS0 extensions from here on out.  Is EDNS0 
pretty much un-extensible?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 15 Apr 2010 08:17:53 -0700

On Apr 15, 2010, at 7:49 AM, Jim Reid wrote:

> Neither. I'm saying using a third party resolver is a stupid thing to do. [Everyone here should have first-hand experience why that's the case.] It's even more stupid because DNSSEC is lurking around the corner and that'll mean edge devices validating stuff for themselves. But if people want to do stupid things and know what they're buying into, they should be free to do that. There's an abundance of that sort of thing on the Internet already. Similarly, providers who want to offer stupid DNS tricks are welcome to do so. The market will take care of them and their business models if DNSSEC deployment doesn't kill them first.
> 
> Can we now get back to defining requirements and specifying an actual problem?

The problem statement:

For several purposes, DNS authorities will operate under the assumption that a request from resolver X is associated with a client on network Y, and uses this assumption to provide higher-quality results.

This assumption is generally valid and useful, except in cases where the user either:

a:  Sends DNS traffic over a different path than the rest of the traffic (boneheaded proxying)

b:  Uses a third party resolver service rather than the network-provided recursive resolver

In such cases, users still get correct results, but the results are of lower quality (usually, higher latency, but also perhaps more costly to the content provider). [1]

The problem statement:  Should such cases be able to convey to the authority servers which care enough information about the client's actual network location, to allow the authority to give the same quality results that the client would receive if they used the network's resolver?

And there is a proposal which solves this problem: edns-client-ip/edns-client-subnet (call it what you will).

There are two other alternatives on the table:

1:  The third party resolvers make pairwise agreements with authorities without creating a standard, acting as a lock-in for just these third party resolvers

2:  Say "third party resolvers should be at a fundamental disadvantage when compared with ISP resolvers"

And not all third party resolvers muck with results: EG, Google Public DNS does not.  

And DNSSEC, even validated on the client, does not prevent the third party resolver from mucking with results, when the value-added is site blocking (which is OpenDNS's real value-add for paid-service): just instead of a redirect to a site that says "this was blocked", the validating client throws up an error.  So the service works in either case: blocking 'undesired' sites from properly resolving.

[1] You can validate this phenomenon for yourself.  Ping www.bing.com, www.yahoo.com, and www.google.com, and ping the systems who's IPs are returned by Google Public DNS's server (8.8.8.8), and compare.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 15 Apr 2010 08:48:58 -0700

>2:  Say "third party resolvers should be at a fundamental disadvantage when compared with ISP resolvers"

The third alternative mentioned (one that I support) is "This should not be dealt with in the DNS, it should be dealt with in application protocols using their built-in redirection functionality".

--Paul Hoffman, Director
--VPN Consortium

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 15 Apr 2010 09:14:12 -0700

> The third alternative mentioned (one that I support) is "This should not be dealt with in the DNS, it should be dealt with in application protocols using their built-in redirection functionality".

That is NOT a viable alternative.

a:  Application level redirects do not work: the additional RTTs involved will often offset the latency savings of being redirected to the proper server.  Remember, an application-level redirect requires two wasted RTTs to the bad-latency server before the application gets to the good-latency server.

b:  Even if the RTTs did not swamp the latency savings, you'd need to change ALL the web browsers to replace a mechanism that ALREADY WORKS TODAY using "stupid DNS tricks" for everyone except those using third party resolvers.

This is because HTTP redirects (the 3xx status codes) are all designed to specify a new URL location, and none of them provide the necessary mechanism: telling the browser to use the SAME URL but to use a different IP address for the hostname portion of the URL.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 15 Apr 2010 09:46:40 -0700

At 9:14 AM -0700 4/15/10, Nicholas Weaver wrote:
>a:  Application level redirects do not work:

Soooo, the last 15 years of HTTP deployment is a failure? I'm not sure how you justify that statement.

> the additional RTTs involved will often offset the latency savings of being redirected to the proper server.

How did you measure "often" there? To be specific, why would an HTTP server use a redirect that would make the user's experience worse? These are people who measure such things much more carefully than the DNS world does. To be sure, it is easy to make bad choices for application-level redirection, but that doesn't mean that those bad choices happen often.

>  Remember, an application-level redirect requires two wasted RTTs to the bad-latency server before the application gets to the good-latency server.

For some applications, such as the web, two wasted RTTs is minor relative to the gain achieved for a web page with a dozen images on it. For others, two wasted RTTs is always just waste.

>This is because HTTP redirects (the 3xx status codes) are all designed to specify a new URL location, and none of them provide the necessary mechanism: telling the browser to use the SAME URL but to…

This is a complete non sequitur. The desire of the web site is to give the user the data at the closes location. They could care less whether that is done with the same domain name in the URL.

--Paul Hoffman, Director
--VPN Consortium

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 15 Apr 2010 10:09:33 -0700

> Soooo, the last 15 years of HTTP deployment is a failure? I'm not sure how you justify that statement.

For the purpose of shaving 20-50ms off of the RTTs it doesn't work.  Because if it did, there wouldn't be a call for the "stupid DNS tricks".

> For some applications, such as the web, two wasted RTTs is minor relative to the gain achieved for a web page with a dozen images on it. For others, two wasted RTTs is always just waste.

With a dozen images to the same host, you aren't necessarily dealing with 1+ RTT per image because the browser will fetch over multiple parallel TCP streams, not to mention HTTP pipelining (Opera does it quite happily.  Chrome will probably add it rather soon, given the performance-obsession Google has).

And why waste two RTTs at all, when the authority can just redirect the user to the right place, WHICH WORKS TODAY!

> This is a complete non sequitur. The desire of the web site is to give the user the data at the closes location. They could care less whether that is done with the same domain name in the URL.

It is not a non-sequiter:  URLs are items which are exported to the user through various means.  

Because there is no way to change just the notion of "host identity" in the redirects, redirects don't work for this fine-grained load-balancing unless it is OK to export node identity to the user, while actually exposing such items in the URL is very VERY bad site design.

Do you honestly think it would be OK for www.google.com to redirect to 1e100-32471.google.com in the URL?

Because the problem is, any HTTP redirect to a different IP address must export a DIFFERENT hostname in the URL, and this shows up to the user in many different places (address bar, cut & paste of URLs, etc).

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 15 Apr 2010 10:27:04 -0700

>For the purpose of shaving 20-50ms off of the RTTs it doesn't work.  Because if it did, there wouldn't be a call for the "stupid DNS tricks".

This is, in my mind, the crux of the issue. The reason that there is a call for "stupid DNS tricks" is because DNS people see themselves and their technology as the saviors of applications. Application people (of which I used to be one) have our own bag of "stupid application protocol tricks".

Is this work motivated by applications people asking for help? If so, I apologize for missing it.

>And why waste two RTTs at all, when the authority can just redirect the user to the right place, WHICH WORKS TODAY!

Because "the right place" is being determined by someone who, if they make a mistake, are not the ones being hurt by the mistake.

>Do you honestly think it would be OK for www.google.com to redirect to 1e100-32471.google.com in the URL?

Yes, I do. I honestly think that is up to Google. If Google wants help from the DNS folk so that they don't have to do that redirection, I would want to hear their requirements and then design a protocol from it.

--Paul Hoffman, Director
--VPN Consortium

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 15 Apr 2010 10:32:17 -0700

> Is this work motivated by applications people asking for help? If so, I apologize for missing it.

No, its motivated by third party resolver providers wanting to be on an equal footing with ISP-provided resolvers in terms of total user experience.

> Yes, I do. I honestly think that is up to Google. If Google wants help from the DNS folk so that they don't have to do that redirection, I would want to hear their requirements and then design a pr…

You've got to be kidding.  You mean you want URLs like

http://1e100-32715.google.com/

exported to the user and spewed throughout the browser?  Because thats what happens if you try to use HTTP-redirects for this purpose without changing both the browsers and the servers.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 15 Apr 2010 17:53:16 +0000

> Date: Thu, 15 Apr 2010 14:44:37 +0200
> From: Martin Barry <[email-masked]>
> ...

for several reasons, i am of the opinion that this preference ("would
trade") be expressed explicitly, with an option that must be presented
by the application and stub resolver.  see my basenote on this thread.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 15 Apr 2010 18:01:46 +0000

> Date: Thu, 15 Apr 2010 09:22:09 -0400
> 
> So what is it?

the internet is much older and larger than the web, and dns serves many
applications other than the web.  from dns's perspective, the web is just
a flash in the pan.  my problem statement is, how can we address the needs
of enduser-context-sensitive applications, of which the web is an example
but so is voip and the sky's the limit for future such apps, in a way that
does not change today's default for enduser privacy and which admits the
use of many factors not just ip addresses as enduser context data.  see my
basenote on this thread.  in the time since writing it nobody has shown

---

From: Carlo Contavalli <[email-masked]>
Date: Thu, 15 Apr 2010 11:25:07 -0700

Regardless of the reason behind those tricks, those tricks are being
used by *a whole lot of sites*, and impact a *whole lot of users*.
Those sites do not use http redirects. 3rd party resolvers are victims
of those tricks as well, as they can't provide good latency and good
locality to their users.

IMHO, we have 3 alternatives: 1 - ignore the problem, leave 3rd party
resolvers on their own, 2 - get rid of dns tricks, 3 - provide a
standardized mechanism so those tricks can at least be worked around.

2 - I don't believe is achievable by any of us, regardless of it being
a good or bad idea. 1 - I think in the long term is bad, there's
already proprietary protocols to try to work around those problems,
which is not good for the market, for the internet, or for its users.
3 - that's what we've been trying to do with the edns-client-ip draft.

Carlo

---

From: Douglas Otis <[email-masked]>
Date: Thu, 15 Apr 2010 11:29:07 -0700

> The third alternative mentioned (one that I support) is "This should not be dealt with in the DNS, it should be dealt with in application protocols using their built-in redirection functionality".
Paul,

I admit to being confused by your statement.

Say someone has a business card with a domain name published in DNS 
using A-Labels printed using easier to read upper-case font.  For 
IDNA2003, it would help people to generate valid A-Labels.  With 
IDNA2008, would a person be expected to enter the name using lower case 
input?  Are you suggesting for say a Cyrillic domain of "example", there 
should be servers located at "EXAMPLE", "Example", "eXample", etc that 
redirect or forward back to "example"?  Of course even this solution 
still faces the task of generating zones that service aliases for 
IDNA2008 names.  In other words, incompatibility resolution still 
largely represents an administrative effort mainly within DNS.  The 
Amber/Shadow zone approach seems to offer the fewest issues related to 
security, and support of existing standards.

Unless DNS is able to collapse many aliases of "Example" back into 
"example", this will cause an otherwise "surprising" NXDOMAIN result 
instead of locating desired services and likely require an expensive 
level of support.  At least once a server is located, it will likely 
already deal with its many new aliases by default.  Once again, the 
simplest solution appears to be the Amber/Shadow zone approach.  I could 
be wrong, and perhaps we are agreeing that applications are not ready to 
rewrite aliased domains.

-Doug

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 15 Apr 2010 14:26:03 -0400

<chair-hat=on>

The noise to signal level in this thread is quite low.
Please stop sending content light/free messages and wasting
everyone's time to the mailing list.

As a matter of working group process, please refrain from posting
any more on topics related to draft-vandergaast-edns-client-ip-00.txt
until/if version 01 is posted.

	Olafur

---

From: Carlo Contavalli <[email-masked]>
Date: Thu, 15 Apr 2010 12:40:09 -0700

>> i can write a -00 i-d along these lines if there's general interest in it.

uhm ..

a draft defining a single option, that can carry structured data,
which would probably look something like 'type-of-information'
(however expressed), 'length-of-data', 'arbitrary-data', in a way that
servers can ignore fields they can't parse?

isn't this edns0? eg, today we're defining an edns0 option to carry
the subnet of the client. Tomorrow, if you really believe it's a good
idea and there's the need for it, you're free to define an edns0
option to carry the gps coordinates of the client? or the language of
the client? Why an additional draft?

Also, earlier I read:

"""
"""

the strippage/addage would be as detectable using outside services
like ICSI's as with the current edns-client-ip draft, especially if
those stub resolvers or NAT box only twiddle those options when
talking to certain servers.

The only difference I can see here is that instead of allowing
recursive resolvers to add the option, you tell the clients to do so.
Which IMHO is worse in terms of complexity - now *all* recursive
resolvers and caches need to deal with it.

"you are in violation of RFC xyz" is also a pretty weak form of
protection. Eg, every time I connect to a hotspot, download my emails,
or go to bbc.co.uk there are *several* rfcs being *violated*. If this
line of defense worked, we could probably just ask any of those sites
to get rid of the dns tricks.

I strongly disagree that this would be better for privacy. It would
mostly create a false sense of security.

As I was pointing out in other threads, there's nothing to prevent a
provider, isp, or recursive resolver from using arbitrary extensions
or proprietary protocols when talking to other 3rd parties, regardless
of the existence of a standardized protocol to do so. What you're
really looking for is an agreement with your ISP saying "you will not
give my data to 3rd parties without my consent".

If anything, a standardized protocol brings awareness and visibility
into those issues, and encourages open policies.

Carlo

---

From: Brian Dickson <[email-masked]>
Date: Thu, 15 Apr 2010 17:47:35 -0300

The issue of "third-party" resolvers is a misnomer, in some necessary,
common use cases:
Split-network VPN (where VPN traffic goes over a tunnel of some kind,
and "Internet" traffic goes directly out the end-user's ISP).

In those instances, it is strictly necessary that DNS resolvers on the
VPN-side of things (i.e. over the tunnel to arbitrarily-distant
resolver(s)) be used.

And this exposes the user to DNS/data path divergence, and the
attendant problems if DNS tricks (stupid or otherwise) get used.

Please keep this in mind when discussing issues like this.

A significant portion of the on-line users (and a very significant
portion of corporate-supported users) have this as a firm requirement.

Just in case the straw-man of "google DNS" or "openDNS" distracts from
the fact that real issues exist and are not (strictly or otherwise)
"opt-in" - and neither are they "opt-out". They are "this needs to
work".

Brian

On Thu, Apr 15, 2010 at 10:29 AM, Jim Reid <[email-masked]> wrote:
>> The question is, should users be penalized for using NON AFFILIATED DNS
>> resolvers: Namely, should OpenDNS and Google Public DNS continue to return
>> consistently inferior results?
>
> providers that do evil/stupid things, economic Darwinism will take care of
> that without any help from this WG.
>
>

---

From: John Levine <[email-masked]>
Date: 15 Apr 2010 23:29:00 -0000

>exported to the user and spewed throughout the browser?  Because
>thats what happens if you try to use HTTP-redirects for this purpose
>without changing both the browsers and the servers.

You say this as though it doesn't already happen several million times a day.

R's,
John

---

From: Alex Bligh <[email-masked]>
Date: Fri, 16 Apr 2010 00:44:36 +0100

--On 15 April 2010 11:14:14 -0400 Edward Lewis <[email-masked]> wrote:

> I disagree that it hurts everyone.  I've said this in an earlier message,
> complexity is another word for optimizations.  Before declaring
> complexity as "bad" I would want to see specific reasons why.  Complexity
> does have a cost, but is the benefit of the corresponding optimization
> exceed the cost of the complexity?

To be clear, I meant it hurts everyone in the sense of it having a cost.
I wasn't arguing it had no benefits. However, the benefits are restricted
to those using third party resolvers, which I believe to be a minority.
I am guessing if this option did something more widely helpful
(traceroute functionality?) and third party resolvers just hung off it,
it might have more support.

-- 
Alex Bligh

---

From: [email-masked]
Date: Mon, 19 Apr 2010 23:35:09 +0000

> As far as Paul's proposal is concerned, as far as I can make out, it isn't at all useful and is only designed to try and kill the edns-client-subnet option.

	may I?

	RTT is a good first metric to select between IMRs - but topologiclly close
	is not the only reason for IMR selection.  As has been pointed out many times,
	the closest IMR might be tainted with "helpful" information, like rewriting 
	all of my queries or providing a single answer, regardless of the question asked,
	or... other "helpful" responses used to monitize my use of the service.

	So RTT can only be one of the metrics used in IMR selection by a stub. My second
	metric is (currently) SIG(0)/TSIG matching.  Yes, this is a problem for IMRs with
	(tens, hundreds of) thousands of stubs... But I reject that design and all its
	works (when I can)... I will go to a trusted IMR with at most 100 stubs, over an 
	untrusted one most of the time.

	Anything else and then we start to seriously blur the distinction between a
	Stub and an IMR... which is fine by me... :)

--bill