Subject: RE: [dnsext] BGP, CDNs and Stupid DNS tricks

From: Greg Daley <[email-masked]>
Date: Tue, 1 Jun 2010 13:39:25 +1000

[ 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. ]

A bigger issue with using BGP is that in IPv6 the Address block is by default
tied to the upstream ISP (Provider Aggregatable).

For systems with multiple ISPs, there will often be multiple addresses,
from each ISP's address block.

The destination address selection is performed at DNS level.  This means
that hacks will be necessary to provide preference information regarding
the better ISP to reach a service on.

Sincerely,

Greg Daley 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jim Reid
> Sent: Monday, 31 May 2010 8:21 PM
> To: Colm MacCárthaigh
> Cc: Wilmer van der Gaast; Nicholas Weaver; Joe Abley; Paul 
> Vixie; IETF DNSEXT WG
> Subject: [dnsext] BGP, CDNs and Stupid DNS tricks
> 
> On 30 May 2010, at 17:28, Colm MacCárthaigh wrote:
> 
> > I don't think it's controversial to claim that BGP takes no 
> account of
> > endpoint latency in its decisions to resolve ties. AS path 
> length is a
> > poor proxy, and I think we all realise that the size of AS's vary  
> > greatly.
> 
> 
> True. And presumably if BGP addressed these concerns, CDNs 
> could make  
> use of that to direct punters to their closest CDN node. [For a  
> hopefully better definition of "closest".] So since we're really  
> talking about a routing issue why isn't this presented as a problem  
> statement for the BGP folk to work on? It makes no sense to me why  
> this needs to be "fixed" in the DNS.
> 
> 
>

---

From: Greg Daley <[email-masked]>
Date: Tue, 1 Jun 2010 13:44:38 +1000

Hi Joe, 

I agree, and I've told my customers to get PI address blocks, but
is there a DNS solution which makes a better class of swamp?

Greg  

> From: Joe Abley [mailto:[email-masked]] 
> Sent: Tuesday, 1 June 2010 1:43 PM
> To: Greg Daley
> Cc: Jim Reid; Colm MacCárthaigh; Wilmer van der Gaast; 
> Nicholas Weaver; Paul Vixie; IETF DNSEXT WG
> Subject: Re: [dnsext] BGP, CDNs and Stupid DNS tricks
> 
> 
> On 2010-05-31, at 23:39, Greg Daley wrote:
> 
> This is how it was envisaged that things would work, 
> universally, but since RIRs are now handing out PI space to 
> end-users and there's no perfectly-aggregatable address 
> hierarchy in practice, the cynical prediction would be that 
> what we will get with IPv6 will be what we have with IPv4.
> 
> The swamp will look different, but it'll still be a swamp.
> 
> 
> Joe
> 
>

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 1 Jun 2010 11:05:15 -0400

Hi Jim,

Thanks for bringing up the end-to-end principle. Of course, you have its
application completely backwards in this case.

The rigorous application of the end-to-end principle to the domain name
system would mean direct connection of ultimate clients to authoritative
servers with no recursion. Under such circumstances, you would certainly
have the unmodified payloads being sent back and forth and authoritative
servers would always know the full IP address of their clients.

However, to be practical, you need these intermediate boxes, like
non-authoritative caching servers and those pesky NAT boxes, which mess up
the end-to-end principle. To the extent that you can approximately
measure draft-vandergaast-edns-client-ip-01 on the "end-to-end principle"
axis, it certainly comes out positive, although, of course, it does not
succeed in restoring the 100% rigorous end-to-end situation I described
above.

Thanks,
Donald
=============================
Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
155 Beaver Street
Milford, MA 01757 USA
[email-masked]

2010/5/31 Jim Reid <[email-masked]>

> On 30 May 2010, at 02:28, Colm MacCárthaigh wrote:
>
>  On Sat, May 29, 2010 at 5:13 AM, Jim Reid <[email-masked]> wrote:
>>
>>> Oh and it doesn't make sense for a recursive resolver to add this option
>>> to
>>> "vanilla" inbound queries from stubs because that means it's making
>>> assumptions about end client behaviour/requirements which are at best
>>> misguided or unwanted and at worst downright evil. I'm fairly sure this
>>> was
>>> mentioned last time round. A resolving server shouldn't be tampering with
>>> a
>>> stub's queries or the resulting responses. This violates the end-to-end
>>> principle.
>>>
>>
>> Section 4.1 of RFC2671 makes plain that there is no end-to-end
>> principle for EDNS options.
>>
>
> In that case, why is the draft forcing Intermediate Resolvers to pass on
> as-is any edns-client-subnet options on inbound queries?
>
> BTW, this draft says "an Intermediate Resolver... MAY add an
> edns-client-subnet option" to a query that doesn't already have one.
>
> IMO the (covert) insertion or removal of an edns-client-subnet is a
> violation of the end to end principle. To repeat what I said earlier, a
> resolving server should not be tampering with the contents of a stub's query
> or the resulting response. This should be common sense.
>

---

From: Jim Reid <[email-masked]>
Date: Tue, 1 Jun 2010 16:30:00 +0100

> application completely backwards in this case.

That may be true Donald. But end-to-end backwards is still end-to- 
end. :-)

> the end-to-end principle.

Indeed. However even though we accept these middleboxes as a necessary  
and probably unavoidable wart on a pure end-to-end model, this does  
not mean they have a free hand to tamper with DNS queries and replies.  
[Like secretly adding or removing EDNS options as this draft  
proposes.] And yes, I know some middleboxes already do stupid/evil  
things to DNS traffic. IMO, that's not an excuse to encourage more of  
that sort of behaviour. Or standardise it.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Tue, 1 Jun 2010 08:48:03 -0700

On Tue, Jun 1, 2010 at 8:30 AM, Jim Reid <[email-masked]> wrote:
> Indeed. However even though we accept these middleboxes as a necessary and
> probably unavoidable wart on a pure end-to-end model, this does not mean
> they have a free hand to tamper with DNS queries and replies. [Like secretly
> adding or removing EDNS options as this draft proposes.]

I think your quarrel is with EDNS itself - that is what the EDNS spec
is designed for. Proposing changes to the EDNS spec itself might
remedy your concern -  but I think that's orthogonal to the details of
any particular option :)

-- 
Colm

---

From: [email-masked]
Date: Tue, 1 Jun 2010 17:38:27 +0000

On Tue, Jun 01, 2010 at 12:12:03AM -0400, John Payne wrote:
> 
> 
> On May 31, 2010, at 11:52 AM, Bruce Campbell <[email-masked]> wrote:
> 
> > Most web browsers seem to look up domain names en-mass and incur max(latency difference) or latency difference * number of concurrent queries, rather than one-by-one and thus latency difference * N.
> 
> The latency is not in the name lookups....
> 
> > As a corporate admin, I'd hate to have details of my internal infrastructure walking out along with the DNS queries, and I fear that this will trigger more active inspection and modification of DNS packets at the egress of such networks, with accompanying poorly-implemented breakage.
> 
> Then you wouldn't enable the option, and you wouldn't enter into an agreement with any auth server operator to use that option if you did accidentally enable it.

	are you suggesting this option is enabled on a per server basis (e.g. pairwise betwn
	servers?)  or will it also have zone granularity as well?

--bill

---

From: Paul Vixie <[email-masked]>
Date: Tue, 01 Jun 2010 17:53:37 +0000

> From: Jim Reid <[email-masked]>
> Date: Tue, 1 Jun 2010 16:30:00 +0100
> 
> ... even though we accept these middleboxes as a necessary and probably
> unavoidable wart on a pure end-to-end model, this does not mean they have
> a free hand to tamper with DNS queries and replies.  [Like secretly
> adding or removing EDNS options as this draft proposes.] And yes, I know
> some middleboxes already do stupid/evil things to DNS traffic. IMO,
> that's not an excuse to encourage more of that sort of behaviour. Or
> standardise it.

+1.

---

From: John Payne <[email-masked]>
Date: Tue, 1 Jun 2010 14:20:57 -0400

> 	servers?)  or will it also have zone granularity as well?

That would be implementation details :)

However, I am suggesting that there are or will be business drivers that require some form of agreement between operators in some use cases.
I would be surprised if (m)any CDN operators enable this without at least some form of whitelisting where they'll accept the option from.
To a lesser degree, I'd also be surprised if the 3rd party resolvers enabled sending this option without some form of whitelisting where they send it.

But, I've been surprised before....

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 1 Jun 2010 15:36:11 -0400

No hat.

On Mon, May 31, 2010 at 11:48:07AM +0100, Jim Reid wrote:
> resolving server should not be tampering with the contents of a stub's 
> query or the resulting response. This should be common sense.

What implications, if any, does that common sense have for DNSSEC
validation at intermediate resolvers on behalf of "dumb" stub
resolvers?

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: [email-masked]
Date: Tue, 1 Jun 2010 20:41:11 +0000

> That would be implementation details :)

	perhaps ...  TSIG and SIG(0) are server/server not zone/zone 
	and DNSSEC is on a per-zone basis, not server/server or even RRset/RRset.
	So I don't see this as an "implementation detail" or "local policy"...

	Something like this has to be -CLEARLY- specified as to its intended/expected
	use and mapping prohibitions on uses that would break/violate other parts of
	the DNS... IMHO, not an implementation detail. :)

> However, I am suggesting that there are or will be business drivers that require some form of agreement between operators in some use cases.

	twas ever thus.

> I would be surprised if (m)any CDN operators enable this without at least some form of whitelisting where they'll accept the option from.

	ok - so you believe that EDNS options are negotiable on a pairwise basis between
	operators on a per zone basis...  interesting.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 02 Jun 2010 05:59:38 +0900

Donald Eastlake wrote:

> Thanks for bringing up the end-to-end principle.

FYI, DNS, with a lot of intermediate servers for intermediate
zones, is *NOT* end to end. PERIOD.

						Masataka Ohta

---

From: John Payne <[email-masked]>
Date: Tue, 1 Jun 2010 18:52:31 -0400

>    operators on a per zone basis...  interesting.

No... I think that there will be use cases for both server whitelists and zone whitelists on the recursive side.
This says nothing about what I believe about existing EDNS options (or their cachability)

---

From: Paul Vixie <[email-masked]>
Date: Wed, 02 Jun 2010 03:09:12 +0000

> Date: Tue, 1 Jun 2010 15:36:11 -0400
> From: Andrew Sullivan <[email-masked]>
> 
> > ... a resolving server should not be tampering with the contents of a
> > stub's query or the resulting response. This should be common sense.
> 
> validation at intermediate resolvers on behalf of "dumb" stub resolvers?

i think what's happening there is upstream validation is failing, so the
data can't enter the cache and can't be used to regenerate responses no
matter whether to queries that don't ask for validation in their own right.

---

From: Jim Reid <[email-masked]>
Date: Wed, 2 Jun 2010 09:44:00 +0100

> validation at intermediate resolvers on behalf of "dumb" stub

Bad Things will happen if/when the stub and intermediate resolvers  
don't have the same validation policy.

Maybe there should be another flag bit to signal to an intermediate  
resolver whether a query is to get validated or not? And, in keeping  
with the end-to-end principle, this bit would be preserved when the  
intermediate resolver forwards the inbound query elsewhere.

---

From: "Marco Davids (SIDN)" <[email-masked]>
Date: Wed, 2 Jun 2010 11:54:24 +0200

On 2010-06-02 10:44, Jim Reid wrote:
> Bad Things will happen if/when the stub and intermediate resolvers don't
> have the same validation policy.
> 

Isn't the CD bit suppose to take care of this?

-- 
Marco

---

From: Jim Reid <[email-masked]>
Date: Wed, 2 Jun 2010 11:17:52 +0100

> Isn't the CD bit suppose to take care of this?

It does. My earlier comment about an extra bit was before the morning  
coffee had kicked in to refresh my recollection of RFC4035. Apologies.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 02 Jun 2010 19:45:02 +0900

> Bad Things will happen if/when the stub and intermediate resolvers

As the DNS, including DNSSEC, is not end to end because of
intermediate name servers and zones, addition of resolvers
does not recover it.

According to the end to end argument by Saltzer et. al., the
intermediat name servers makes DNS incomplete and incorrect,
which is, for example, why DNS RRs are not always up to date.

						Masataka Ohta

---

From: Wilmer van der Gaast <[email-masked]>
Date: Wed, 2 Jun 2010 16:02:52 +0100

>        the DNS... IMHO, not an implementation detail. :)
This is an interesting point, actually. If there's going to be some
automatic negotiation, all parties have to do this the same way.

Say, we have an authority configured to handle edns-client-subnet
options for zone A but not for zone B, and returns responses with
absolutely no edns-client-subnet option for queries to zone B.

And, we have a RR/INS that keeps a list of servers that support
edns-client-subnet. If the first query between these servers is going
to be for zone B, the RR/INS won't even try sending an edns-client
option with a query for zone A.

It seems best to me to make the negotiation per-server, not per-zone,
so if an authority has at least one zone that uses edns-client-subnet
info, it should return the option for all queries, with a 0/0 address
for the other zones.

We'll make sure to include this in the next version of the draft.

Regards,

-- 
Wilmer van der Gaast, Traffic SRE/Google Public DNS team.
Google Ireland.

---

From: Wilmer van der Gaast <[email-masked]>
Date: Wed, 2 Jun 2010 16:16:39 +0100

On 31 May 2010 16:52, Bruce Campbell <[email-masked]> wrote:
>> A latency difference of 200 or 300ms doesn't really matter by itself.
>> The problem is web pages which result in *many* DNS queries and thus
>> latency difference * N.
> Most web browsers seem to look up domain names en-mass and incur max(latency
> difference) or latency difference * number of concurrent queries, rather
> than one-by-one and thus latency difference * N.
>
I'd say difference * 2.

It can't immediately do all lookups. It'll have to start downloading
the HTML before it will have any clue what other names it's going to
have to resolve.

> As a corporate admin, I'd hate to have details of my internal
> infrastructure walking out along with the DNS queries,

Which details?

If you're running a small corporate network and are just using the
resolver run by the ISP or maybe a third party one. If the resolver
adds an edns-client-subnet option, it will just contain the /24 that
contains your external IP address (range).

If you're running a bigger network, you're probably running your own
local nameserver already, and there's no need to enable
edns-client-subnet support on it since CDNs will already have enough
information to serve you.

Regards,

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 2 Jun 2010 09:10:28 -0700

> the HTML before it will have any clue what other names it's going to

And remember, this does NOT affect the latency of DNS lookups (although it may add an additional lookup if the reply specifies too narrow a subnet).  

Rather, it affects the latency to the resulting server, which is critical for HTTP.

Lets actually look at the example of www.yahoo.com:

The total # of items fetched is 77, from 9 domains total.

Most (51) are from l.yimg.com, so lets focus on that:

The browser (firefox, mac) opens six TCP streams to l.yimg.com, but because the browser doesn't pipeline, it has to wait for each element to be received before the next one is fetched.  Thus fetching those 51 images requires at least 9 RTTs to the server.  (For a typical connection in this flow, replies are 1-2 packets, so the TCP windowing doesn't come into effect, and I'm on a 100 Mbps connection here)

Thus it is critical that the IP address of the server be at least on the right part of the correct continent, as if the DNS authority for l.yimg.com gave me an east-coast server, the latency would be increased by at least 100ms, adding in at least 1s to page load time.

And this is yet another example of how HTTP redirects don't work: There is no way to say 'fetch all requests for l.yimg.com from a2354.l.yimg.com' with an HTTP redirect, so doing redirects wouldn't help here: you'd still take the latency hit FOR EACH REQUEST to l.yimg.com.

Rather, what would have to happen to see the latency savings without the DNS games is the web page itself would need to be dynamically generated and customized for my IP address, replacing every reference to l.yimg.com with a reference to something like a2354.l.yimg.com.

---

From: Ted Hardie <[email-masked]>
Date: Wed, 2 Jun 2010 11:25:55 -0700

> The browser (firefox, mac) opens six TCP streams to l.yimg.com, but because the browser doesn't pipeline, it has to wait for each element to be received before the next one is fetched.  Thus fetchi…

This argues for increased pipelining; that slipped off the common
road because of head-of-line blocking problems for generated
resources, but it may be time for some discussions on that point again.

> And this is yet another example of how HTTP redirects don't work: There is no way to say 'fetch all requests for l.yimg.com from a2354.l.yimg.com' with an HTTP redirect, so doing redirects wouldn't…

Would a new HTTP 30x message with the meaning "all URIs from this host
and/or all URIs from this point in the hieirarchy" be a useful point to make
then?  That seems like something that is useful whether you use a CDN
or are simply moving hosts from a previous name.

regards,

Ted

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 2 Jun 2010 11:39:40 -0700

> resources, but it may be time for some discussions on that point again.

Agreed, but it requires browsers changing.

Basically, the only "major" browser that does pipelining is Opera.  Even the very much speed obsessed Chrome doesn't do pipelining, which makes me think that, even though pipelining is supposed to have been supported for years, the browser developers still don't trust stupid middleboxes to not break it.

> or are simply moving hosts from a previous name.

That would IMO, be really useful to have, but it would probably require a crap-load of changes in browsers to actually implement, because it would require effectively hostname/suburl aliasing infrastructure.  It would be great if it was in the protocol from the start, but I seriously doubt you could add it in NOW.

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 2 Jun 2010 11:41:23 -0700

> Basically, the only "major" browser that does pipelining is Opera.  Even the very much speed obsessed Chrome doesn't do pipelining, which makes me think that, even though pipelining is supposed to…

Especially since head-of-line blocking can be handled easily enough by keeping the conncurrent TCP connection model so if one pipeline is blocked, just rerequest through a different one once the work queue is empty.

---

From: Doug Barton <[email-masked]>
Date: Wed, 02 Jun 2010 12:41:14 -0700

[ meta-note, if you're going to send long lines in your message (which
is fine) please turn on the format=flowed option. Without it, when I hit
reply your text shows up as one long line and I have to do extra steps
to fix it. With that option this doesn't happen. Meanwhile, the
combination of format=flowed + wrapping at around 72 columns is the best
of both worlds. The text will still reformat to fit the size of the
screen for newer clients, but those with older mail software still see
something that looks familiar/readable. ]

On 06/02/10 11:39, Nicholas Weaver wrote:
>>> The browser (firefox, mac) opens six TCP streams to l.yimg.com,
>>> but because the browser doesn't pipeline, it has to wait for each
>>> element to be received before the next one is fetched.  Thus
>>> fetching those 51 images requires at least 9 RTTs to the server.
>>> (For a typical connection in this flow, replies are 1-2 packets,
>>> so the TCP windowing doesn't come into effect, and I'm on a 100
>>> Mbps connection here)
>>>
>>

IIRC firefox used to enable pipelining by default but stopped, probably 
due to the issues you mention here. It's easy enough to enable it to see 
if it gives you any benefit. Just type about:config in the address bar, 
type pipe into the Filter window, and enable the 2 
network.http.pipelining options by clicking them.

> Basically, the only "major" browser that does pipelining is Opera.
> Even the very much speed obsessed Chrome doesn't do pipelining, which
> makes me think that, even though pipelining is supposed to have been
> supported for years, the browser developers still don't trust stupid
> middleboxes to not break it.
>
>>> And this is yet another example of how HTTP redirects don't work:
>>> There is no way to say 'fetch all requests for l.yimg.com from
>>> a2354.l.yimg.com' with an HTTP redirect, so doing redirects
>>> wouldn't help here: you'd still take the latency hit FOR EACH
>>> REQUEST to l.yimg.com.
>>>
>>
>> Would a new HTTP 30x message with the meaning "all URIs from this
>> host and/or all URIs from this point in the hieirarchy" be a useful
>> point to make then?  That seems like something that is useful
>> whether you use a CDN or are simply moving hosts from a previous
>> name.
>
> That would IMO, be really useful to have, but it would probably
> require a crap-load of changes in browsers to actually implement,
> because it would require effectively hostname/suburl aliasing
> infrastructure.  It would be great if it was in the protocol from the
> start, but I seriously doubt you could add it in NOW.

So this point, and the one above about pipelining reinforce what I said 
last time this issue came around. The latency problem is primarily (IMO 
by a wide majority) a browser/web problem, and needs to be solved at the 
HTTP layer, not at the DNS layer.

Doug

-- 

	... and that's just a little bit of history repeating.
			-- Propellerheads

	Improve the effectiveness of your Internet presence with
	a domain name makeover!    http://SupersetSolutions.com/

---

From: [email-masked]
Date: Wed, 2 Jun 2010 20:06:12 +0000

> something that looks familiar/readable. ]

	sorry Doug, can't find "format=flowed" 

> HTTP layer, not at the DNS layer.

	Perhaps, maybe, this thread touches on a DNS concern to wit...

	is the DNS infrastructure (however loosely defined) is -UNABLE-
	to handle the expected query load from applications that expect 
	consistant, subsecond name resolution from many different sources
	is argueably poorly implemented.   Given that auth servers have a
	fairly high degree of autonomy and are constrained by geo/topo location,
	the use of third party caches makes lots of sense ... and if those caches
	can direct stubs to the "best" cache or the "best" auth source - then
	clearly this is a win.  A stop-gap, but a win.   In some sense these
	discussions are moving intermediate caches from a useful adjunt to the
	stub to deal w/ transient service unavailability to a full-blown, critical
	player in the DNS ecosystem.  I, for one, would prefer to reduce my
	systems dependence on a "middle-man" ...

	Some rambling thoughts on (for me) this friday afternoon.

--bill

---

From: Tony Finch <[email-masked]>
Date: Wed, 2 Jun 2010 21:33:48 +0100

> 	sorry Doug, can't find "format=flowed"

http://tools.ietf.org/html/rfc3676

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
FAIR ISLE FAEROES: SOUTHWESTERLY 5 OR 6, BECOMING VARIABLE 4. ROUGH,
OCCASIONALLY VERY ROUGH AT FIRST. OCCASIONAL RAIN, FOG PATCHES FOR A TIME.
MODERATE OR GOOD, OCCASIONALLY VERY POOR.

---

From: Doug Barton <[email-masked]>
Date: Wed, 02 Jun 2010 13:32:40 -0700

> 	sorry Doug, can't find "format=flowed"

You're not using Apple Mail, and Mutt wraps it's lines already, so 
you're off the hook. :)

--

---

From: David Ulevitch <[email-masked]>
Date: Wed, 2 Jun 2010 19:30:08 -0700

2010/5/31 Jim Reid <[email-masked]>:

> To repeat what I said earlier, a

Some background -- When I started OpenDNS numerous folks (including
Vixie) told me the market for people who wanted their responses
tampered with was zero.  They wished me luck, expecting me to fail.
Today we have millions of users who use our service to control the
responses they receive as they see fit.  Some of these users use this
power to block certain kinds of DNS lookups so people don't visit
MySpace or Facebook or Playboy.  Some use it to prevent malware on
their network from phoning home to known botnets and divulging their
private data.  Regardless of the reason, there is clearly a market for
tampered DNS responses as we've been doing this since 2006, and
profitably since 2007.  Today, the vast majority of our revenue growth
is from paying enterprise customers deploying this globally.  These
are not naive users by any means.

So unfortunately, conventional wisdom disagrees with what you believe
to be common sense.

So on this issue I've remained largely quiet here for a bit, since
most of the discussion is circular and the opponents have no desire to
see this move forward. But I want to address two points: Internet
architecture and privacy concerns.

1) Internet architecture.  Vixie suggested this draft represents a
change to the architecture of the Internet and needs to be reviewed by
the IAB.  By his reasoning, nearly everything (not just DNS) is a
change to the architecture of the Internet.  Using an EDNS0
option-code to add some metadata to requests has been happening for
years, as designed, and this proposed draft contains a new use that
people would like to standardize upon.  The entire point of EDNS0 is
to let clients advertise capabilities to authoritative servers in a
way that doesn't break the Internet.  One such capability -- for
example -- is to serve a particular client in a particular way.  I
cannot think of a more appropriate use for EDNS0.  To suggest that
this changes the architecture of the Internet is truly bizarre when
compared against every other non-IAB-reviewed DNSWG RFC which has
moved forward in the last decade.

2) As for privacy concerns, there is, unfortunately, no possible way
to make what is being proposed an opt-in option as determined by the
stub resolver originating the query.  Not philosophically, or even
technically as far as I can think.  Certainly resolver authors can
(and should) implement it the way we have done it so that the service
is available to some clients and not others, to some authoritative DNS
servers and not others, and for some zones not others.  But still
there have been concerns that this creates a data leak that previously
did not exist.  There has yet to be an example shown where this is the
case and the "interceptor" is not already situated as a man in the
middle of a plaintext DNS conversation.  So I'm not sure why it
persists.

Ultimately, when client decides to run their own recursive DNS server,
which has been pointed out as being "so trivial," they are in complete
control of that experience to the degree that they are in control of
their Internet connection.  When they pick someone else to run it,
they still control that experience as a matter of choice (voting with
one's wallet if you will).  If they pick a service or deploy a piece
of software with policies they do not agree with, they will switch.
The focus here is in the wrong place -- I think this particular bit of
energy is better directed at preserving the right for people to run
their own resolver or choose a third-party, not about dictating the
capabilities of what resolvers can and can't do when it will have no
impact on anyone else.

-David

---

From: Doug Barton <[email-masked]>
Date: Wed, 02 Jun 2010 20:32:24 -0700

Some snipping ...

> So unfortunately, conventional wisdom disagrees with what you believe

David,

Congratulations on your success. :) I think it's worth exploring what 
you've said further. You've got millions of clients who have all _opted 
in_ to using your service. To the extent that they understand what 
they've gotten themselves into they have chosen to use it with the 
knowledge of what they are giving up to get the benefits that you 
provide. So, good on you, and I hope things continue to go well for you 
and yours.

> technically as far as I can think.

Thanks for being honest about this. I made this same point last time 
around (from a different perspective) but it's good to see that we at 
least have some common ground here. Another poster mentioned that for 
those wishing to allow their customers to opt out of this service 
another set of resolvers could be provided that don't have this feature. 
I think that while that option has the merits of technical feasibility 
it has the significant downside that few if any ISPs would actually be 
willing to offer it.

> Certainly resolver authors can

And I'm not sure why you're confused. The common case is Janet User sits 
on one of N subnets of BigISP, her DNS queries are directed to BigISP's 
resolver which queries the authoritative servers for CoolWebPages.com 
and sends back the answer. At no point do the packets going from the 
resolver to the authoritative servers and back again have any 
information about Janet.

> I think this particular bit of

And my assertion continues to be that this is a bad idea on its face, 
and therefore should not be done. Some of the reasons I think it's a bad 
idea are that it's a layering violation (already covered today, so I 
won't dwell) and that it's a privacy violation (covered in detail during 
the last round of discussion on this topic). I understand that you and 
others don't agree with these concerns, and that's ok too. However I 
think that as a result by definition we do not have consensus on this 
topic; and are not likely to reach consensus on it give the intractable 
nature of the positions in both camps.

Doug

--

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 2 Jun 2010 23:48:13 -0400

On Tue, Jun 1, 2010 at 11:30 AM, Jim Reid <[email-masked]> wrote:

> ...
> some middleboxes already do stupid/evil things to DNS traffic. IMO, that's
> not an excuse to encourage more of that sort of behaviour. Or standardise
> it.
>

Recursive servers do and should have a free hand to insert meta-RRs. That's
what TKEY, TSIG, and OPT are for.

There is nothing secret about what is proposed here. The proposal is public.
It does not include encrypting DNS packets.

Ohta-san is correct that DNS isn't an end-to-end communications system. It's
a distributed database system that uses store and forward caching
techniques. So, really, end-to-end arguments are inapplicable.
Never-the-less, if you squint the right way, when a recursive server issues
a query that is pretty much the same as a request it received, you could
look at how close the information received as a result of that recursive
query is to what would have been received if the recursive server hadn't
been in the path. And you will find that the suggested experimental option
makes the recursive server more transparent.

Thanks,
Donald

---

From: Bruce Campbell <[email-masked]>
Date: Wed, 2 Jun 2010 21:46:05 -0700

[cc list trimmed back]

> the HTML before it will have any clue what other names it's going to

Naturally.

> contains your external IP address (range).

Agreed.  In such a setup, there is little operational difference between 
the CDN using the information in the edns-client-subnet option which 
points to my egress /24, vs the CDN using the source IP address of the 
query from the ISP's resolver, as both my egress IP and the ISP's 
resolvers are highly likely to be advertised using the same routing 
announcement.

> information to serve you.

Let's expand the scope of that, and say that my internal non-RFC1918 
network spans several departments which each run their own resolvers 
directly querying the Internet.  The egress NAT ensures that the external 
IP address of these queries is identical irrespective of the department.

However, to be in line with company policies about avoiding leakage of 
network information, my NAT would need to be aware of the 
edns-client-subnet option in order to remove or rewrite it should it be 
present, contrary to section 7 of -01.

Naturally, all NAT/firewall devices do the Right Thing(tm) when it comes 
to packet modification, and my vendor won't charge excessive amounts of 
money when it comes time for adding a particular feature.  (ha!)

If my NAT is actually an Intermediate Server which supports 
edns-client-subnet, it needs to ignore the MUSTs and MUST NOTs in 4.1 
regarding modification of any edns-client-subnet option, following instead 
the advice of 8.1 regarding privacy.

The general gist of this comment is that in order to assure that the IP 
address/subnet of the original stub resolver remains private and not seen 
by any but the first upstream resolver, end-users and administrators must 
make changes to their infrastructure in order to opt-out of the 
edns-client-subnet option.

-- 
   Bruce.

   opt-out; not just for email and web pages anymore.

---

From: Bruce Campbell <[email-masked]>
Date: Wed, 2 Jun 2010 21:55:22 -0700

[cc trimmed]
On Wed, 2 Jun 2010, Ted Hardie wrote:

>> And this is yet another example of how HTTP redirects don't work: There 
>> is no way to say 'fetch all requests for l.yimg.com from 
>> a2354.l.yimg.com' with an HTTP redirect, so doing redirects wouldn't 
>> help here: you'd still take the latency hit FOR EACH REQUEST to 
>> l.yimg.com.
>>
>

Somewhat offtopic for DNS and really scary for HTTP.

-- 
   Bruce.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 03 Jun 2010 22:22:23 +0900

Nicholas Weaver wrote:

> Rather, what would have to happen to see the latency savings
 > without the DNS games is the web page itself would need to be
 > dynamically generated and customized for my IP address,
> replacing every reference to l.yimg.com with a reference to
> something like a2354.l.yimg.com.

I thought queries to www.yahoo.com should be redirected to
www50.yahoo.com, HTML files from which "statically" include
l50.yimg.com, not l.yimg.com, which does not need any
new specification.

But, feel free to develop dynamic generation or whatever, as
long as it does not purposelessly complicate DNS.

					Masataka Ohta

---

From: Paul Vixie <[email-masked]>
Date: Thu, 03 Jun 2010 15:03:21 +0000

> Date: Wed, 2 Jun 2010 21:55:22 -0700
> From: Bruce Campbell <[email-masked]>
> 
> > and/or all URIs from this point in the hieirarchy" be a useful point to
> > make then?  That seems like something that is useful whether you use a
> > CDN or are simply moving hosts from a previous name.
> 

and yet, since the option now being proposed is web-specific, solving it in
the http protocol rather than in the dns protocol seems indicated. that is,
if the only practical way to develop the www is via cdn's who absolutely
cannot function or scale without explicit latency management features, then
the place i'd expect to see this solved is in the web transport (http).

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 3 Jun 2010 07:39:27 -0700

> l50.yimg.com, not l.yimg.com, which does not need any

In order to do THAT, you end up exporting www2350.yahoo.com into the browser's bar, bookmarks, etc, which is COMPLETELY unacceptable to most site designers!

> long as it does not purposelessly complicate DNS.

What complication? These tricks are not only well established, but at this point, should be considered part of DNS because they ARE part of DNS.  

Where does it state that an authority will return the COMPLETE RRSet associated with a name lookup, rather than a chosen subset?  Or do you really want 50,000 answers for www.google.com?

Because "authority choses a subset based on the resolver querying" has become established practice, and at this point has been established practice for well over a decade.  

All this proposal does is ensure that established practice will still work as well when third party resolvers are used, because the information leakage when you use the local resolver is already sufficient for the authority to chose a GOOD subset.

---

From: Sean Leach <[email-masked]>
Date: Thu, 3 Jun 2010 09:38:55 -0600

> the place i'd expect to see this solved is in the web transport (http).

not web specific - i may use this to direct you to the closest SMTP server, SIP proxy etc.

---

From: Tony Finch <[email-masked]>
Date: Thu, 3 Jun 2010 16:51:29 +0100

On Thu, 3 Jun 2010, Nicholas Weaver wrote:
>
> Where does it state that an authority will return the COMPLETE RRSet
> associated with a name lookup, rather than a chosen subset?

RFC 2181 section 5.1.

This doesn't actually prevent you from returning inconsistent or
dynamic results, because you can pretend that each result comes
from a different instance of the zone.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
IRISH SEA: SOUTHEAST 3 OR 4, OCCASIONALLY 5 LATER. SMOOTH OR SLIGHT. SHOWERS
LATER. MODERATE OR GOOD, OCCASIONALLY POOR LATER.

---

From: [email-masked]
Date: Thu, 3 Jun 2010 16:01:49 +0000

> not web specific - i may use this to direct you to the closest SMTP server, SIP proxy etc.

	closest?  how does the third party (C), discover and indicate to client (A)
	about the path between (A) and content (B)?  I'll posit C has not any basis 
	other than presumption and hubris to suggest anything about a path that it is
	not a part of;  tht when/if we do figure that out, are we talking about 
	closest as RTT, same IP block, shared ASN, or some other metric?

--bill

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 3 Jun 2010 09:03:34 -0700

> not web specific - i may use this to direct you to the closest SMTP server, SIP proxy etc.

Probably the most useful non-web one would be the proper VPN tunnel:  If you are a company with east-coast location and a west-coast location, having 
vpn.mycompany.com

resolve to an east-coast host to east-coast users, and west-coast hosts to west-coast users, is a BIG performance win if your VPN software doesn't support the notion of redirects.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 03 Jun 2010 16:04:46 +0000

> From: Sean Leach <[email-masked]>
> Date: Thu, 3 Jun 2010 09:38:55 -0600
> 

nobody in the smtp or sip communities is arguing that their industry
cannot continue to thrive without explicit latency management. if they
do i'll be surprised, since the MX RR and the NAPTR/SRV RRs work well.

arguments about predictivity of latency based on ip address have been
done, here and elsewhere, many times. cisco's "director" products did
not capture the market as well as akamai's services have done, not just
because "ping" and BGP as-path are poor predictors of TCP performance,
but because it takes a *lot* of viewpoints integrated coherently to form
any kind of valid statistical basis. and even so, there are IP cutouts
and wormholes that form stumbling blocks. only global empires need apply.

it's very hard for me to want a DNS option that only supports one
industry, and at that, an industry who has heard many times that DNS is
a publication mechanism for truth not policy, and that they need to use
it as intented, and that their claims about what they can do with DNS are
either snake oil or are impediments to global deployment of things like
DNSSEC. an option that only does any good on its rare best day if content
is available from a thousand different mirrors run by a global empire is
also hard to understand. this goes beyond snake oil, it's cost shifting.

i'm looking at a CDN response:

+---
| ;; QUESTION SECTION:
| ;www.microsoft.com.             IN      A
| 
| ;; ANSWER SECTION:
| www.microsoft.com.      3600    IN      CNAME   toggle.www.ms.akadns.net.
| toggle.www.ms.akadns.net. 300   IN      CNAME   g.www.ms.akadns.net.
| g.www.ms.akadns.net.    300     IN      CNAME   lb1.www.ms.akadns.net.
| lb1.www.ms.akadns.net.  300     IN      A       65.55.21.250
+---

post-kaminsky, those CNAMEs are useless. an iterator has to restart and
requery after each CNAME, even those which appear to be in-zone by virtue
of being siblings to the QNAME, or which appear to be children of the same
set of authority servers as the QNAME. because any CNAME target could be,
in real life, a zone cut. credibility of CNAME chains has gone to zero,
and the proper resolution for "www.microsoft.com" now takes four RTT's.
but, akamai's marketing continues unabated, and no doubt recursive server
implementors are afraid to do CNAME restarts because it will make them
slower than the implementors who don't do CNAME restarts. i've never been
comfortable having a protocol's evolution controlled by the installed base.
(which is why we push out new code in BIND every time we find we're in the
wrong, and why we gradually change defaults to move the installed base along.)

anyway i've tried hard not to repeat myself, as the chairs have requested.

---

From: [email-masked]
Date: Thu, 3 Jun 2010 15:52:33 +0000

> Because "authority choses a subset based on the resolver querying" has become established practice, and at this point has been established practice for well over a decade.  

	Hum... really?

	RFC 2181 - 5.1 states:

	5.1. Sending RRs from an RRSet

   A query for a specific (or non-specific) label, class, and type, will
   always return all records in the associated RRSet - whether that be
   one or more RRs.  The response must be marked as "truncated" if the
   entire RRSet will not fit in the response.

	draft-iab-dns-choices  states:

	Every resource record (RR) matching a particular name,
   type and class is said to belong to the same resource record set
   (RRset), and the whole RRset is always returned to the client which
   queries for it.  Splitting an RRset is a protocol violation, because
   it results in coherency problems with the DNS caching mechanism.

      Note however that this requirement has nothing to do with the MTU
   size and choice of UDP or TCP as the transport protocol.  The whole
   RRset always has to be returned, and if it doesn't fit in the MTU in
   UDP, TCP has to be used to not break this RRset atomic requirement.

	so, if, as you state, authority servers "pick and choose" a subset to 
	return to a query... that authority is violating the protocol.

--bill

---

From: Sean Leach <[email-masked]>
Date: Thu, 3 Jun 2010 10:12:37 -0600

> do i'll be surprised, since the MX RR and the NAPTR/SRV RRs work well.

on the contrary - I had several of the external anti-spam providers want this very functionality (and a few VoIP providers).  i don't claim to speak for them, just what they asked me for while i was at ultradns/neustar

---

From: Tony Finch <[email-masked]>
Date: Thu, 3 Jun 2010 17:15:34 +0100

> 	return to a query... that authority is violating the protocol.

I note that dynamic geo-IP DNS responses are "just" a more elaborate
version of BIND's "view" feature.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
LUNDY: EAST, VEERING SOUTH LATER, 3 OR 4. SLIGHT OR MODERATE. SHOWERS LATER.
MODERATE OR GOOD, OCCASIONALLY POOR.

---

From: Tony Finch <[email-masked]>
Date: Thu, 3 Jun 2010 17:22:58 +0100

On Thu, 3 Jun 2010, Paul Vixie wrote:
>
> impediments to global deployment of things like DNSSEC

Last time I discussed this I came to the conclusion that it should be
feasible to sign all the possible answer RR sets ahead of time, so it's
possible for a dynamic geo-IP DNS service to support DNSSEC.

(Something like the pool.ntp.org service may need to return fewer A
records in its reply; really silly stunts like returning the queryer's IP
address in the reply (!) would require online signature generation...)

> credibility of CNAME chains has gone to zero

Aside from them being a protocol violation and unusable at zone cuts where
many sites now like to put their web servers...

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
GERMAN BIGHT: NORTHERLY OR NORTHWESTERLY 3 OR 4, OCCASIONALLY 5 IN NORTHEAST.
SMOOTH OR SLIGHT, BECOMING MODERATE FOR A TIME IN NORTHEAST. MAINLY FAIR.
MODERATE OR GOOD, OCCASIONALLY POOR LATER.

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 3 Jun 2010 09:02:30 -0700

On Jun 3, 2010, at 9:01 AM, Nicholas Weaver wrote:
> I stand corrected.  Except for one teeny-weeny little note:  ITs now a decade+ of established practice for authorities to NOT return the full RRSet.  Do you really want the full RRSet for www.l.google.com?

Also, such splitting is NOT a coherency problem:  All subsets chosen will respond properly, and represent proper hosts for www.l.google.com.

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 3 Jun 2010 09:01:14 -0700

---

From: Colm MacCárthaigh <[email-masked]>
Date: Thu, 3 Jun 2010 09:41:40 -0700

> possible for a dynamic geo-IP DNS service to support DNSSEC.

There may be some qualifications. For NSEC(3) users - records must
really either exist or not exist in all "views". Otherwise an NXDOMAIN
from a view where a record does not exist would be replay-able to
other queriers. Similarly, "incorrect" DNSSEC-signed answers are
replay-able across views, though that doesn't seem as harmful an
attack.

> address in the reply (!) would require online signature generation...)

Even for silly stunts, the signatures are cacheable for re-use.

-- 
Colm

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 3 Jun 2010 09:48:00 -0700

> | lb1.www.ms.akadns.net.  300     IN      A       65.55.21.250

I'm looking at another one which uses the same CDN tricks on DNS:

;; QUESTION SECTION:
;www.google.com.                        IN      A

;; ANSWER SECTION:
www.google.com.         94112   IN      CNAME   www.l.google.com.
www.l.google.com.       72      IN      A       74.125.19.147
www.l.google.com.       72      IN      A       74.125.19.99
www.l.google.com.       72      IN      A       74.125.19.103
www.l.google.com.       72      IN      A       74.125.19.104

The long CNAME chains are not necessary for CDN-type tricks to work.  Especially long CNAME chains with short TTLs.  Microsoft could just as easily have
www.microsoft.com CNAME lb.www.ms.akadns.net  TTL 100000
like Google does.

And DNS, for all your harping about it, IS a policy tool:  Its used all the time by all different people to block or redirect or manage traffic.  

Heck, bind supports it!  How is the basic CDN trick different from a programatic view?

---

From: Paul Vixie <[email-masked]>
Date: Thu, 03 Jun 2010 17:01:48 +0000

> Date: Thu, 3 Jun 2010 10:12:37 -0600
> 
> on the contrary - I had several of the external anti-spam providers want
> this very functionality (and a few VoIP providers).  i don't claim to
> speak for them, just what they asked me for while i was at
> ultradns/neustar

assuming for a moment that this was a representative sample of those
industries, and the internet really does need explicit latency management
for many applications, i'd like to see IETF start up a working group on the
topic, to decide where it belongs in the stack and to develop a problem
statement and so on. interactions between proxies and nats that make it
often impossible for a client to have "an IP address" mean that latency
might depend on more than just that. this seems, at the moment, beyond the
scope of DNSEXT, even if many members of this WG would also be members of
that one.

---

From: Carlo Contavalli <[email-masked]>
Date: Thu, 3 Jun 2010 11:18:56 -0700

On Wed, Jun 2, 2010 at 9:46 PM, Bruce Campbell
<[email-masked]> wrote:
> address/subnet of the original stub resolver remains private and not seen by
> any but the first upstream resolver, end-users and administrators must make
> changes to their infrastructure in order to opt-out of the

No. They just won't enable edns-client-ip to begin with? eg, your
resolver within your private network will not add an edns-client-ip
option.

This is what's suggested in the draft wrt private addresses, and
implementations should not enable edns-client-ip by default, and
definitively not add private addresses.

Also, what purpose would serve enabling edns-client-ip forwarding
private addresses? eg, it definitively doesn't help finding a better
result for your query, it would probably be discarded by the
authoritative name server, and ... the source ip in packets (address
of NAT box) is actually the best address that can be used to try to
return a server that's close to the NAT box, eg, the exit point of the
private network.

In case of tunnels or configurations where DNS queries exit from a
different point than the rest of the tcp traffic, nothing prevents an
ISP or network administrator from adding an edns-client-ip headers to
hint the authoritative server in the right direction finding a better
reply.

Which is an improvement over the current world, where dns tricks are
being used, and there is no way for ISPs or CDNs to get the best
results for their customers in a case like the one described above,
ending up introducing 100s of ms of latency on their users.

Carlo

---

From: Doug Barton <[email-masked]>
Date: Thu, 03 Jun 2010 12:44:15 -0700

> not web specific - i may use this to direct you to the closest SMTP server, SIP proxy etc.

As Mark A. has pointed out repeatedly in this and other contexts, SMTP 
(and mail protocols generally) are not latency-sensitive.

SIP certainly is, but there are 2 possibilities for SIP, either it's in 
a static location, in which case it can be optimized fairly easily in a 
static configuration (or even a dynamic one if the provider is clever); 
or it's moving around from location to location. I submit that the case 
of dynamic locations for SIP clients at this time is enough of an edge 
case not to warrant more profound changes at other layers, but would 
welcome evidence to the contrary.

Doug

--

---

From: Carlo Contavalli <[email-masked]>
Date: Thu, 3 Jun 2010 12:44:32 -0700

Ups, I also honestly misread Bruce's email. He was explicitly talking
about a network where hosts have non-RFC1918 addresses, but are still
going through a NAT box to get more privacy. Apologies.

> resolver within your private network will not add an edns-client-ip

This is still true: eg, each resolver for each department will have
edns-client-ip disabled, unless you explicitly enable it, so
authoritative servers (or other intermediate servers) will only see
the IP of you recursive resolver (which, by being NATted, will
probably be the address of the NAT box), exactly like today.

Eg, you opt-in by enabling the option on your recursive resolver,
which should be disabled by default.

Yes, the NAT / security box will need to support the option if you
want it to be able to filter out edns-client-subnet, or mangle the
option at will, but this is true even if the protocol was architected
to have clients use some other, more end-to-end, opt-in mechanism.
And it's basically true for any protocol modification.. and I bet that
most of the modifications those boxes do to traffic are in violation
of RFCs. I also bet that many NAT/security boxes by default remove
things they don't know about, which ... make the world a sensibly
worse place in terms of supporting protocol changes, but should
generally work.

I'd personally be open to changing the requirements in section 4.1, to
say that an Intermediate Server with edns-client-subnet support MAY
reduce the number of bits in SOURCE NETMASK, if people think that
would be a good idea.

The rest of my previous mail was pretty much tied to a different case
than Bruce described. Sorry about that, hope this replies makes more
sense :)

Carlo

---

From: Doug Barton <[email-masked]>
Date: Thu, 03 Jun 2010 12:56:15 -0700

On 06/03/10 07:39, Nicholas Weaver wrote:
>
> In order to do THAT, you end up exporting www2350.yahoo.com into the
> browser's bar, bookmarks, etc, which is COMPLETELY unacceptable to
> most site designers!

I agree that what's in the browser bar needs to stay consistent, but as someone else (you maybe? I'm losing track) already pointed out the vast majority of the actual things fetched have no relationship to the URL in the browser bar, and therefore can easily be optimized using any number of client-side tricks (and in fact some of the things below already are). For example, here is the list of elements fetched for my yahoo home page. The URL in the browser bar is simply http://my.yahoo.com/, which shows up twice out of 41 elements in the page.

I have repeatedly asserted that to the extent what you're trying to solve is a browser problem it needs to be solved in the browser. I'm not sure if you (and the others who are pursuing similar lines of argument) continue throwing up red herrings because you don't understand how modern web service works, or with some other motivation; but either way it gets tiresome to keep going in circles.

Doug

http://ads.yimg.com/a/a/ne/df/nflx_20033v3.gif
http://d.yimg.com/a/p/ap/20100603/capt.8616e94329234ee5892461be43db30df-8616e94329234ee5892461be43db30df-0.jpg?x=130&y=98&q=85&sig=tLQBbq7x.K9qNIcWVHyCXA--
http://d.yimg.com/a/p/ap/20100603/capt.8616e94329234ee5892461be43db30df-8616e94329234ee5892461be43db30df-0.jpg?x=130&y=98&q=85&sig=tLQBbq7x.K9qNIcWVHyCXA--
http://l.yimg.com/a/combo?my/css/components/search_assist_0.1.20.css&my/css/components/dragdrop_0.1.13.css
http://l.yimg.com/a/combo?my/css/core_0.1.299.css&my/css/components/modoptions_0.0.12.css&my/css/modules/type_pa_0.1.35.css&my/css/modules/type_weather_0.1.36.css&my/css/modules/type_placeholder_0.1.19.css&my/css/modules/type_simple_0.1.54.css&my/css/controls/tabset_0.1.15.css&my/css/controls/location_panel_0.1.11.css&my/css/modules/type_local_0.1.14.css&my/css/components/showcase_0.1.24.css
http://l.yimg.com/a/combo?my/js/components/search_assist_0.1.31.js&my/js/yui_dragdrop_0.0.1.js&my/js/components/dragdrop_0.1.33.js&my/js/components/vsearch_0.1.58.js
http://l.yimg.com/a/combo?my/js/core_0.1.335.js&my/js/components/modoptions_0.0.30.js&yui/2.5.1/build/selector/selector-beta-min.js&my/js/components/colresize_0.1.8.js&my/js/modules/type_pa_0.1.47.js&my/js/modules/type_weather_0.1.43.js&darla/fc_0.2.9.js&darla/util_0.2.6.js&darla/renderers/complex_renderer_0.3.0.js&my/js/controls/media_0.1.12.js&my/js/modules/type_simple_0.1.66.js&yui/2.5.1/build/container/container_core-min.js&my/js/controls/tabset_0.1.25.js&my/js/controls/location_panel_0.1.15.js&my/js/modules/type_local_0.1.17.js&my/js/components/showcase_0.1.50.js&my/js/components/pageoptions_0.1.16.js
http://l.yimg.com/a/i/brand/purplelogo/my/sm/us.png
http://l.yimg.com/a/i/us/my/gr/bwall6.gif
http://l.yimg.com/a/i/us/my/mw/favicon.ico
http://l.yimg.com/a/i/us/my/mw/gsprite_080509.gif
http://l.yimg.com/a/i/us/my/mw/modules/type_weather/34ds.png
http://l.yimg.com/a/i/us/my/mw/modules/type_weather/sprite_weather_sm.png
http://l.yimg.com/a/i/us/my/mw/modules/type_weather/weather_day_bd_bg.png
http://l.yimg.com/a/i/us/my/mw/modules/type_weather/weather_day_left_bg.png
http://l.yimg.com/a/i/us/my/mw/modules/type_weather/weather_day_right_bg.png
http://l.yimg.com/a/i/us/my/mw/sprite_ltdrk_20090915.gif
http://l.yimg.com/a/i/us/my/mw/sprite_pa_033109.gif
http://l.yimg.com/a/i/us/my/mw/sprite_pg_20090922.gif
http://l.yimg.com/a/i/us/my/mw/sprite_pg_20091007.gif
http://l.yimg.com/a/i/us/my/mw/srch/lip_closed_093008.gif
http://l.yimg.com/a/i/us/my/mw/srch/lip_open_093008.gif
http://l.yimg.com/a/i/us/my/mw/th/sprite_zorro_081208.gif
http://l.yimg.com/a/i/us/my/mw/th/white/gsprite_pg_wht_052308.gif
http://l.yimg.com/a/i/us/my/mw/tooltip_ptr_sprite.gif
http://l.yimg.com/a/i/us/my/mw/trans.gif
http://l.yimg.com/a/i/us/nws/weather/gr/34d.png
http://l.yimg.com/a/lib/my/css/modules/type_insidemycms_0.1.6.css
http://l.yimg.com/a/lib/my/css/modules/type_ymail_0.1.30.css
http://l.yimg.com/a/lib/my/js/core_seed_0.0.5.js
http://l.yimg.com/a/lib/my/js/modules/type_insidemycms_0.1.8.js
http://l.yimg.com/a/lib/my/js/modules/type_ymail_0.1.48.js
http://l.yimg.com/d/lib/bc/bc_2.0.4.js
http://media.nbcsandiego.com/images/120*90/lotto1.jpg
http://my.yahoo.com/e/df
http://my.yahoo.com/e/js
http://myyahooeditorial.files.wordpress.com/2010/05/sudoku.jpg?w=120&h=90
http://s.bit.ly/preview.s3.v2.css?v=4.2
http://us.bc.yahoo.com/b?P=8h4eNtj8evWzKWJjS1DOQRD5TFhc6UwH_4oAB__g&T=18nu9h14h%2fX%3d1275592586%2fE%3d150002246%2fR%3dmy%2fK%3d5%2fV%3d1.1%2fW%3dJ%2fY%3dYAHOO%2fF%3d1299137281%2fH%3dY29udGVudD0ibm9fZXhwYW5kYWJsZSIgc2VydmVJZD0iOGg0ZU50ajhldld6S1dKalMxRE9RUkQ1VEZoYzZVd0hfNG9BQl9fZyIgc2l0ZUlkPSIyNzk4NTUxIiB0U3RtcD0iMTI3NTU5MjU4NjY0MTQ4NyIg%2fS%3d1%2fJ%3dDFCFB444&U=12djmep2c%2fN%3dWkOESNGDJHY-%2fC%3d-1%2fD%3dFSRVY%2fB%3d-1%2fV%3d0&U=13f6gouvu%2fN%3daEOESNGDJHY-%2fC%3d767715.14167687.14076082.13146704%2fD%3dRQ1%2fB%3d6081461%2fV%3d1&Q=0&O=0.7635737163717967
http://us.i1.yimg.com/us.yimg.com/i/us/my/mw/sprite_trough_031008.gif

--

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 04 Jun 2010 05:03:59 +0900

> on the contrary - I had several of the external anti-spam providers
> want this very functionality (and a few VoIP providers).

To your surprise, SMTP servers should be located near receivers, not
senders. So should VoIP servers.

> i don't claim to speak for them, just what they asked me for
> while i was at ultradns/neustar

HTTP people are not the only people not to know what they want.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 04 Jun 2010 05:15:14 +0900

Nicholas Weaver wrote:

> In order to do THAT, you end up exporting www2350.yahoo.com into
> the browser's bar, bookmarks, etc, which is COMPLETELY
> unacceptable to most site designers!

You don't see the reality of HTTP.

As I use

	my.yahoo.co.jp

and click "Inbox" (or, "Jushinbako" in Japanese), I am directed to:

	http://jp.f24.mail.yahoo.co.jp/ym/ShowFolder?rb=Inbox&login=1

As I type

	http://www.google.com

I am redirected to:

	http://www.google.co.jp/ig?hl=ja

> What complication?

No complication, as I wrote "does not purposelessly complicate".

> Because "authority choses a subset based on the resolver querying"
> has become established practice, and at this point has been
> established practice for well over a decade.

It does not complicate DNS.

But, you had better see above to learn the established practice
of HTTP and never say "COMPLETELY unacceptable".

					Masataka Ohta

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 3 Jun 2010 14:00:42 -0700

> 	http://jp.f24.mail.yahoo.co.jp/ym/ShowFolder?rb=Inbox&login=1

This is somewhat sloppy design on yahoo's part: google does it far cleaner...

Also, please note that, as ugly as that hostname is, ITS consistent.  Just f24 is some silly little internal code on the part of Yahoo.jp.  The only other one which is valid in that rage is f25.  The rest are invalid, so if you bookmark f24, there is no problem if your computer moves.

> 	http://www.google.co.jp/ig?hl=ja

Uh, thats hardly a "crufy" URL: its "www.google.co.jp, with the iGoogle homepage, in japanese"  Change the ja to en you get it in english.  Drop the ig and you get the classic google homepage in japanese.  

I suspect your Google account settings says "use iGoogle", so thats why you see it in the redirected URL: you have already told Google you want the iGoogle homepage.

The HTTP redirect itself was based entirely on the geoIP of your client (http://www.google.com/ncr eliminates country-based redirection, BTW).

And you notice they are VERY careful to not have it be a2345.www.google.co.jp, OR to dynamically rewrite all the subcomponents/subreferences to things like skins.gmodules.com, which is what would be necessary if, as some suggest, latency-sensitive redirection should be done using existing HTTP redirect messages or mechanisms.

Instead it relies COMPLETELY on DNS to ensure that I'm going to an instance of www.google.co.jp which is just 5ms away, and that you are going to servers (probably) 5ms away.  Its a great proof that the DNS games work, and solve the problem for most of the users today: since if we were both going to the same instance, one or the other of us MUST see 100ms latency.

---

From: Doug Barton <[email-masked]>
Date: Thu, 03 Jun 2010 14:49:34 -0700

On 06/03/10 14:00, Nicholas Weaver wrote:
> Also, please note that, as ugly as that hostname is, ITS consistent.
> Just f24 is some silly little internal code on the part of Yahoo.jp.
> The only other one which is valid in that rage is f25.  The rest are
> invalid, so if you bookmark f24, there is no problem if your computer
> moves.

That's basically correct, although I'm not sure I agree with "sloppy." I 
don't think I'm giving out any trade secrets by saying that each Yahoo! 
mail user's account is located on a given "farm," and when you visit 
http://mail.yahoo.com/ it is smart enough to redirect you to the farm 
your account is on. Providing the URL to your specific farm for 
bookmarking is arguably a feature since you can get there that much 
faster next time; and aren't you arguing here that sub-second latency 
issues are important to the eyeball sites?

Doug

--

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 04 Jun 2010 06:55:56 +0900

> This is somewhat sloppy design on yahoo's part: google does it

According to your theory, both yahoo and google are doing thing
you said "COMPLETELY unacceptable".

> so if you bookmark f24, there is no problem if your computer moves.

If you bookmark URL after redirection to reduce delay, there is no
problem if your computer moves, because you will be redirected again.

> Uh, thats hardly a "crufy" URL

"ig?hl=ja" is crufy enough, which is acceptable to google.

Note that, because of language tag in HTTP header, "www.google.com"
can continue to serve my request without redirection.

> I suspect your Google account settings says

I'm helping you learn the reality of web, not vice versa.

						Masataka Ohta

---

From: Bruce Campbell <[email-masked]>
Date: Thu, 3 Jun 2010 16:30:10 -0700

> which should be disabled by default.

Urm... that is one method of opting in, yes.

The other method is performed by the upstream resolver in adding in 
client-specific information before the query is sent onwards, and the 
original client doesn't know whether or not their query was opted-in to 
the behaviour specified in the draft.

To opt-out of the possibility of this behaviour by the upstream resolver, 
my outbound queries need to have edns-client-subnet set to 0/0, ie, I need 
to make a behavioural change within my infrastructure.

I'm not sure that you've addressed the problem that in order to maintain 
the current level of privacy with regards to client IP information not 
being transmitted via intermediate nameservers to the authoritative 
servers, administrators will need to make changes to their infrastructure.

> worse place in terms of supporting protocol changes, but should

So what's to stop my upstream resolver doing the same thing to my queries 
as the above RFC-violating NAT box, and overriding any edns-client-subnet 
option with my egress IP ?

> reduce the number of bits in SOURCE NETMASK, if people think that

I do think that that specific change would make this draft somewhat easier 
to swallow.  You probably also want to specify that the client will accept 
the edns-client-subnet option being returned to it with a smaller number 
of bits in the netmask.

-- 
   Bruce.

---

From: Carlo Contavalli <[email-masked]>
Date: Thu, 3 Jun 2010 17:49:24 -0700

On Thu, Jun 3, 2010 at 4:30 PM, Bruce Campbell <b+dns@bruce->>
> original client doesn't know whether or not their query was opted-in to the
> behaviour specified in the draft.
>

sorry, what's preventing upstream resolvers now from using proprietary
extensions or protocols to forward client-specific information to
other servers? do you know if your upstream resolver is doing it now?

All bets are off as soon as your queries leave your network. Having a
standardized protocol does not make this any worse. If anything, it
brings visibility into the issue, and provides mechanisms to opt-out
and see what the server is doing (does it support edns-client-subnet?
let's see what happens if I include an edns-client-subnet, and query a
domain that uses it - it'd be pretty easy to have servers, like http
header analyzers, that tell you if an edns-client-subnet was received,
and what the content was).

> I'm not sure that you've addressed the problem that in order to maintain the
> current level of privacy with regards to client IP information not being
> transmitted via intermediate nameservers to the authoritative servers,
> administrators will need to make changes to their infrastructure.

you choose the recursive resolver you use, it's entirely up to this
resolver to decide which information is forwarded, and how, and which
intermediate servers are traversed (eg, other recursive resolvers, or
straight to the servers that can provide the answers?), and again,
this is true regardless of edns-client-subnet. I sincerely believe
that your level of privacy will not change because of our draft.

> So what's to stop my upstream resolver doing the same thing to my queries as
> the above RFC-violating NAT box, and overriding any edns-client-subnet

? not sure I understand your question. There's nothing stopping any
middlebox from doing any change to any packet you send out on the
internet...

> the edns-client-subnet option being returned to it with a smaller number of
> bits in the netmask.

sounds good, will keep this in mind for -02. If you have any other
proposal on how we could improve the draft, that'd be great.

Thanks,
Carlo

---

From: [email-masked]
Date: Fri, 4 Jun 2010 01:24:34 +0000

> I stand corrected.  Except for one teeny-weeny little note:  ITs now a decade+ of established practice for authorities to NOT return the full RRSet.  Do you really want the full RRSet for www.l.goo…

	sigh...  sure, bring it on.  TCP use would shake out a whole raft of other problems.

--bill

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 04 Jun 2010 11:58:00 +0900

> sigh...  sure, bring it on.  TCP use would shake out a whole

That's a good news, because DNSSEC is assured not to be deployable.

						Masataka Ohta

---

From: Wilmer van der Gaast <[email-masked]>
Date: Wed, 9 Jun 2010 20:10:48 +0100

On 3 June 2010 04:32, Doug Barton <[email-masked]> wrote:
>
> And I'm not sure why you're confused. The common case is Janet User sits on
> one of N subnets of BigISP, her DNS queries are directed to BigISP's
> resolver which queries the authoritative servers for CoolWebPages.com and
> sends back the answer. At no point do the packets going from the resolver to
> the authoritative servers and back again have any information about Janet.
>
And at no point will they.

First of all, it's the question if BigISP is going to configure their
resolvers to add edns-client-subnet options, even though it's
primarily targeted at open resolvers.
Second of all, if they do, the only information they will add is three
bytes of network address information. Not Janet's full external IP
address.

Now there's indeed a possibility that BigISP has a huge network with
lots of peering points but only a few DNS server pools, and maybe
because of that they *are* using edns-client-subnet. In that case,
they know pretty well what their network looks like and can truncate
the network address information to something bigger than a /24. Maybe
they know that all of 192.0.32/20 is in the same city, in which case
there's no need to send a full /24 (and it's in their and their
cache's advantage to not do that then). In some version of the draft
we had a recommendation like this included, but it's not currently
there. We can definitely add that.

Regards,

---

From: John Kristoff <[email-masked]>
Date: Wed, 9 Jun 2010 20:58:02 -0500

On Fri, 28 May 2010 12:40:45 +0100
Wilmer van der Gaast <[email-masked]> wrote:

> Does nobody have any comments on this draft? We've tried to address as
> many of the concerns brought up in the discussion on -00 and would
> like to know if the WG is more in favour of this new version.

After having read through this version as carefully as I could, I have
a number of comments.  I offer no specific support or opposition to the
specification at this time.  Just comments.

I noticed the change of intended status from Standards Track to
Experimental.

I now think this specification could potentially result in a
significant architectural change for the domain name system as Paul
originally tried to impress upon the group.  However, my reasoning
differs than what I saw Paul say.

The significant change I see is in the caching.  This proposal severely
alters how resolvers do caching,  This is not something anticipated by
the original DNS specifications.  This proposal would have caches
perform similar work similar to routers (route table lookup and
maintenance). It might even be argued that resolvers would have to
implement a form of uRPF for queries that forge the edns-client-subnet
ADDRESS field. I can elaborate further if my reasoning is not entirely
clear.

There is no discussion of authoritative server consistency.  Should each
NS in the set for a zone provide consistent answers for the same
edns-client-subnet detail?  I would assume the answer is yes.

For any particular qname,class,type tuple does the TTL need to be
consistent no matter the edns-client-subnet detail?  I would think not.

I propose that if the SOURCE NETMASK field is set to zero in a query,
the resolver is indicating it is providing the ADDRESS for informational
purposes only and will not cache the answer based on ends-client-subnet
specific detail.  Therefore, the server should give back the most
appropriate answer, as it would if ends-client-subnet option was not in
use.  It would be valuable to offer the edns-client-subnet detail in
many circumstances (e.g. troubleshooting, measurement, auditing), but
desirable not to have to support edns-client-subnet based caching.

In section 4.1, its stated that an intermediate name server must not
modify the edns-client-subnet option if already present.  Later there
is discussion in section 7 about NAT considerations, where this is
reiterated and that special awareness of NAT is not required.  In
addition its stated that recursive resolvers behind NAT must not add
their external address.  ends-client-subnet capable resolvers might not
know they are behind a NAT.  How are they to know.  I believe you will
need special awareness for this option.

On a related note, in section 8.3, its suggested that authoritative
name servers and recursive resolvers should ignore unroutable
addresses.  Rather than reference RFC 1918, perhaps reference RFC 5735
and change the word from "including the ones defined in" to "such as
some address blocks defined in".

To expand on the cache pollution attack in 8.3, an intermediate resolver
that is receiving spoofed IP addresses, spoofed edns-client-subnet
address detail or both not only has to deal with cache pollution, but
perhaps more importantly has to deal with the additional resolution
workload it needs to perform.  Technically this is a problem even
without edns-client-subnet, but may be worth mentioning.

I'd like to restate my prior comment about cache enumeration.  I did
not see discussion on it or consideration for it in the updated draft.
Maybe its not a big deal, but might be at least worthy of a mention.
Today, resolvers will generally report what is in there cache for
anyone is permitted to ask, but with edns-client-subnet they not only
share what they have cached, but who its cached for.

The example detailed in Section 9 is problematic.  Does R need to
consult http://publicsuffix.org now to determine what a TLD is?  Why
not just include the option anyway?  If this is really something
people might want to do, maybe roots and TLDs want to be able to
make use of it too.  Including the option from the root on down would
just be simpler.

In the same section, step 4 is imprecise.  R won't technically know the
authoritative name server until it actually gets an answer.

John

---

From: Danny Mayer <[email-masked]>
Date: Sun, 27 Jun 2010 20:33:10 -0400

>> the HTML before it will have any clue what other names it's going to

Yes and that is the reason that you can have the HTTP server do all the
work. The HTTP server receives the client IP address (no privacy here)
and can craft an frameset answer that points the rest of the URL's to
his nearest (for some biased meaning of nearest) server. The frameset
doesn't need to contain much and can be generated on the fly.

> And remember, this does NOT affect the latency of DNS lookups
(although it may add an additional lookup if the reply specifies too
narrow a subnet).
> Rather, it affects the latency to the resulting server, which is critical for HTTP.

See above.

> The browser (firefox, mac) opens six TCP streams to l.yimg.com, but
because the browser doesn't pipeline, it has to wait for each element to
be received before the next one is fetched. Thus fetching those 51
images requires at least 9 RTTs to the server. (For a typical connection
in this flow, replies are 1-2 packets, so the TCP windowing doesn't come
into effect, and I'm on a 100 Mbps connection here)
> 
> 
> Thus it is critical that the IP address of the server be at least on
the right part of the correct continent, as if the DNS authority for
l.yimg.com gave me an east-coast server, the latency would be increased
by at least 100ms, adding in at least 1s to page load time.
There is no way to say 'fetch all requests for l.yimg.com from
a2354.l.yimg.com' with an HTTP redirect, so doing redirects wouldn't
help here: you'd still take the latency hit FOR EACH REQUEST to l.yimg.com.

So you are saying that the HTTP protocol is inadequate for your
purposes. What did the HTTP Working Group have to say or recommend? You
are saying that this is an HTTP problem.

Danny

---

From: Colm MacCárthaigh <[email-masked]>
Date: Mon, 28 Jun 2010 08:59:09 -0700

> doesn't need to contain much and can be generated on the fly.

Please see the numerous posts on this list debunking this idea. But to
repeat just a little;

Latencies;
C = client, R = resolver, A = authoritative nameserver , I =
intermediary HTTP server, S = Ultimate HTTP server

 (i) DNS tricks

 Client queries the resolver for example.com
 Resolver queries the auth server, auth server responds
 Resolver responds to client
 Client initialises TCP connection to Ultimate HTTP server

 Total network time to first byte;    |CR| + |RA| + 2x |CS|

 (ii) HTTP tricks

 Client queries the resolver for example.com
 Resolver queries the auth server, auth server responds
 Resolver responds to the client
 Client initiaises TCP connection to Intermediary HTTP server
 Client Receives redirect to "192.0.2.1.example.com" say (or a
frameset, or an iframe).
 Client queries the resolver for this new name.
 Resolver queries the auth server, auth server responds
 Resolver responds to the client
 Client initialises TCP connection to ultimate HTTP server

 Total network time to first byte:  2x |CR| + 2x |RA| + 2x |CI| + 2x |CS|

 Total difference between the two;  |CR| + |RA| + 2x |CI|  .

> are saying that this is an HTTP problem.

The utility of finding low-latency endpoints is not restricted to
HTTP, it's merely a common example :)

-- 
Colm

---

From: Paul Vixie <[email-masked]>
Date: Mon, 28 Jun 2010 16:27:42 +0000

> Date: Mon, 28 Jun 2010 08:59:09 -0700
> From: Colm MacCárthaigh <[email-masked]>
> 
> > ...
> 
> Please see the numerous posts on this list debunking this idea. ...

you say debunked, i say armwaved.

> HTTP, it's merely a common example :)

there is however no non-HTTP global industry clamouring for this DNS change.

---

From: Danny Mayer <[email-masked]>
Date: Mon, 28 Jun 2010 14:47:50 -0400

>  Total difference between the two;  |CR| + |RA| + 2x |CI|  .

This means that you didn't understand my comments about framesets. When
you send the initial request to the server, it figures out where your
browser is and then constructs a frameset response containing the
closest URL's to fetch when populating each frame in the frameset. There
are no additional queries that need to be made.

> HTTP, it's merely a common example :)

Really? Then please provide a list (at least one) of other protocols
that needs take advantage of this proposal. I still want to know what
the HTTP WG has to say about all this.

Danny

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 28 Jun 2010 12:08:21 -0700

> the HTTP WG has to say about all this.

vpn.mybigcompany.com

should ideally resolve to different systems whether you are on the east or west coast of the US, unless you LIKE an additional 100ms latency in your VPN tunnels.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Mon, 28 Jun 2010 12:34:07 -0700

> are no additional queries that need to be made.

Plainly an additional query is neccessary - the initial request to the
server (which generates the page containing the frameset reference).
Additionally your solution is HTML specific, not HTTP. Please re-read
the steps involved, it should be clear where the additional latency
comes from.

> the HTTP WG has to say about all this.

Any layer 4+ protocol which uses DNS for endpoint resolution would
benefit from the technique. The list is practically endless, but it's
been used for VOIP conference bridges, FTP and more. Questions
directed at the HTTP WG are best sent there - but working groups don't
speak with single anthropomorphic voices.  Fwiw, if it helps, I'm a
contributor to the HTTP WG, and a HTTP implementation (Apache) and
there is no HTTP technique that I am aware of that is comparable to
DNS tricks.

-- 
Colm

---

From: Danny Mayer <[email-masked]>
Date: Mon, 28 Jun 2010 20:10:12 -0400

> the steps involved, it should be clear where the additional latency

Please reread. Just about all Web sites use framesets to lay out the
pages and create menus etc. There is no additional requests involved.
Now you are saying that there is also a problem with including HTML in
the solution?

> there is no HTTP technique that I am aware of that is comparable to

I hear nothing but HTTP here. If it helps I used to work with the people
who worked on the original HTTP protocol spec and had many discussions
with them, particularly at W3C.

Maybe if you are knowledgeable you can explain how VOIP uses this
technique and why nothing else would work.

Danny

---

From: Colm MacCárthaigh <[email-masked]>
Date: Mon, 28 Jun 2010 17:28:55 -0700

> pages and create menus etc. There is no additional requests involved.

Respectfully, I'm going to bow out of this conversation.

-- 
Colm