Subject: [dnsext] Re: draft-vandergaast-edns-client-ip-01

From: Andrew Sullivan <[email-masked]>
Date: Fri, 21 May 2010 14:38:29 -0400

On Fri, May 21, 2010 at 11:29:27AM -0700, Carlo Contavalli wrote:
> The end result is that the document is still called edns-client-ip,
> but the option is called edns-client-subnet. Hope this won't cause too
> much confusion. -02 of the draft will address this issue.

This is a common issue.  No worries.

> If still possible, we'd like to discuss this at IETF 78?

We haven't even decided whether we're having a meeting there yet :)
I'll put you in the queue if we decide we will.

A

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

---

From: Carlo Contavalli <[email-masked]>
Date: Fri, 21 May 2010 11:29:27 -0700

Hello,

we just uploaded a second version of edns-client-ip:
http://www.ietf.org/id/draft-vandergaast-edns-client-ip-01.txt

We believe it addresses many of the comments that were raised on
namedroppers previously, please have a look and let us know.

Also, we had a little fight with the upload script, as we tried to
rename the option (and the draft) to edns-client-subnet, as was
suggested.

Thanks,
Carlo

---------- Forwarded message ----------
From: IETF I-D Submission Tool <[email-masked]>
Date: Fri, May 21, 2010 at 10:56 AM
Subject: New Version Notification for draft-vandergaast-edns-client-ip-01
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]

A new version of I-D, draft-vandergaast-edns-client-ip-01.txt has been
successfully submitted by Wilmer van der Gaast and posted to the IETF
repository.

Filename:        draft-vandergaast-edns-client-ip
Revision:        01
Title:           Client IP information in DNS requests
Creation_date:   2010-05-21
WG ID:           Independent Submission
Number_of_pages: 23

Abstract:
This draft defines an EDNS0 extension to carry relevant network range
information.  In a query, it conveys the network address of the
originator.  In a response, it conveys the scope of network addresses
that the answer is intended.

The IETF Secretariat.

---

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

> http://www.ietf.org/id/draft-vandergaast-edns-client-ip-01.txt

Hello everyone,

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.

If it's decided that there will be a dnsext session at IETF78 in
Maastricht, we'd love to discuss this proposal in person in more
detail there.

Regards,

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

---

From: Colm MacCárthaigh <[email-masked]>
Date: Fri, 28 May 2010 07:49:14 -0700

> like to know if the WG is more in favour of this new version.

I think that this draft is better, and incorporates lots of great
feedback. Some
observations;

  * Rather than specifying the netmask and scope fields as 1 octet,
maybe that size should depend on the FAMILY. Otherwise we exclude >
256 bit address families.

  * I think "SOURCE NETMASK" might be ambigous - source means a lot of things.
     "CLIENT NETMASK" and "CLIENT SCOPE" and "CLIENT ADDRESS" might be
    more in keeping with the draft name.

  * The new scope netmask behaviour implies some negotiation might occur e.g.

Actual client IP:  192.0.2.130
Resolver sends:  192.0.2  source netmask; 24
Auth sends:         192.0.2  scope netmask;  26
Resolver sends:  192.0.2.128 source netmask; 26

Is that the idea? It might be worth adding an example of this, and
noting the boundary cases that may occur (e.g. what if there are
varying degrees of granularity).

-- 
Colm

---

From: Paul Vixie <[email-masked]>
Date: Fri, 28 May 2010 16:50:33 +0000

> Date: Fri, 28 May 2010 12:40:45 +0100
> From: Wilmer van der Gaast <[email-masked]>
> 
> Does nobody have any comments on this draft?

no new comments.

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

i said "this is a bad idea and should never be done in any form". i don't
think you've addressed that concern with this new draft.

---

From: Jim Reid <[email-masked]>
Date: Sat, 29 May 2010 13:13:03 +0100

> think you've addressed that concern with this new draft.

+1

The new version of this draft is still a bad idea IMO.

Even if the concerns about Stupid DNS Tricks and how this scheme would  
be implemented and operated are ignored, the draft is deeply flawed.

The end of 4.1 says a recursive resolver MAY throw away this EDNS  
option on an inbound query whenever a delegation response is expected.  
Well, how will a recursive resolver know before making a query that it  
will result in a delegation response? Since the resolving server is  
free to ignore this EDNS option whenever it chooses -- which is  
essentially what the last para of 4.1 means -- what's the point of a  
stub resolver ever using the option?

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.

---

From: Donald Eastlake <[email-masked]>
Date: Sat, 29 May 2010 16:50:45 -0400

2010/5/28 Colm MacCárthaigh <[email-masked]>:
>...

A case where you would want to send more than 256 high order address
bits, i.e., more than /256, sounds implausible. And if it did, which I
can't see happening for decades, you could always allocate another
ENDS option code that had two bytes of netmask...

>    more in keeping with the draft name.

Why not use DNS terminology like RESOLVER NETMASK and SERVER SCOPE?

> varying degrees of granularity).

I think the draft makes it pretty clear that after step 3 above the
recursive server has to return the non-optimal answer it just got.
There is no iteration or "negotiation". But if it caches that answer,
it can only use it to answer clients that match at the /26 level. If
it gets a subsequent query that is the same at the /24 level but
doesn't match at the /26 level, it has to query the auth again.

Donald

---

From: Nicholas Weaver <[email-masked]>
Date: Sun, 30 May 2010 09:18:38 +1200

> The new version of this draft is still a bad idea IMO.

So question for those who think this is a bad idea:

Pick your poison:

a: Enable these tricks to work with 3rd party resolvers

or

b: Accept a world where third party resolvers WILL produce inferior results:
http://www.sajalkayan.com/in-a-cdnd-world-opendns-is-the-enemy.html

Can any of those who oppose this solution make a compelling explanation why B is preferable, because from as far as I can tell, ANY solution for A is opposed by a vocal portion of this group?

Because these "Stupid DNS tricks" do work, are used, and are important, shaving tens or even hundreds of MS off of user perceived latency when the user is using the ISP-provided DNS resolver.

---

From: John Payne <[email-masked]>
Date: Sat, 29 May 2010 20:49:50 -0400

> Can any of those who oppose this solution make a compelling explanation why B is preferable, because from as far as I can tell, ANY solution for A is opposed by a vocal portion of this group?

I'd also be curious how many of those opposing this use on their primary machine(s):
a) a third party resolver (which is irrelevant)
b) their ISP/enterprise DNS
c) a local resolver whether on their local network or localhost. 
d) other

---

From: Colm MacCárthaigh <[email-masked]>
Date: Sat, 29 May 2010 18:28:06 -0700

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.

Resolvers are not proxies - they do not simply forward queries - when things
are working correctly, they do not even forward *most* queries. There really
isn't any relationship between the query in and the query out. They are
separate things.

You could make the same end-to-end argument for EDNS's MTU negotiation. E.g.

 stub <--- MTU 9000 ---> resolver <--- MTU 1500 ---> auth

If the auth truncates a 3K response, and we resort to TCP for a
response there - should we force the stub to use TCP too? of course
not.

-- 
Colm

---

From: Paul Vixie <[email-masked]>
Date: Sun, 30 May 2010 04:13:59 +0000

> From: Nicholas Weaver <[email-masked]>
> Date: Sun, 30 May 2010 09:18:38 +1200
> 

i'm fine with "b" since running your own resolver is so darned easy
that there's no excuse for outsourcing it. resolvers should be on-lan
or on-host.

that third party resolvers could come along and say, since we're here
now, and since we don't share fate with our clients, we need a way to
tell the cdn's of the world that their stupid dns tricks need to be
directed at the client's ip not the resolver's ip, is triply silly.

don't do the stupid dns tricks on the cdn side, and/or, don't outsource
recursive dns. then, as it was before people started doing these silly
things, all will be well.

otherwise we're compounding bad ideas by adding other bad ideas to try
to make them work, and it all amounts to an architectural change that
neither the IAB nor DNSEXT has ever agreed to.

> Can any of those who oppose this solution make a compelling explanation
> why B is preferable, because from as far as I can tell, ANY solution for
> A is opposed by a vocal portion of this group?

"let's change the protocol to make it more complicated and harder to
debug in order to enable other people to sell more snake oil" is CRAZY.

> Because these "Stupid DNS tricks" do work, are used, and are important,
> shaving tens or even hundreds of MS off of user perceived latency when
> the user is using the ISP-provided DNS resolver.

if that's so, then anycast tcp/80 would also work. even so, we're not here
to argue about whether it works or whether it's used or important. what's
at issue here is "is it necessary?" and "is this an architecture we want?".
i'd answer "no" and "no".

sneaking stuff like this in seems popular. i did it with the SRV RR, which
was an architectural change to the connection model, which neither the IAB
nor anybody else saw coming, and now it's part of the architecture. maybe
that's the only way to get anything done. however, this time, i'm seeing it
coming and i'm opposed to this change to the connection model.

brass tacks now:

i think that what the rules say is, if somebody (me) is opposed on the
grounds that it's a change to the internet architecture, then you need to
get the IAB to either say that it's not such a change, or say that it's a
change that has IETF consensus. i do not think this WG can decide whether
to accept this as a work item with this kind of objection now outstanding.

---

From: Nicholas Weaver <[email-masked]>
Date: Sun, 30 May 2010 16:57:45 +1200

> that there's no excuse for outsourcing it. resolvers should be on-lan

So then why have the recursive resolver at all in the architecture, since this is the one real and certified enemy of DNS security?

And stupid DNS tricks really aren't stupid, because there IS no alternative:  Anycast TCP doesn't work well in widespread deployment, application level redirections both don't work and eliminate the latency savings, etc...  Getting rid of those tricks is going back to a world where you have 100ms more latency visiting many sites.  Sorry, NOT GONNA HAPPEN.

So in the end it seems you are perfectly comfortable in a world where these DNS tricks are used and common and critical (because that is the world already), but you can't have third party resolvers, so we are at the mercy of the (wildcarding, or even MitM-ing!) ISP-provided resolver because no major OS ships with an on-default recursive DNS resolver instead of a stub resolver?

> i'd answer "no" and "no".

There are huge business advantages in being 100ms better on your web site.  So the tricks themselves have become necessary.  Sorry, but thats life.  There is no alternative to shave that particular latency that is proven to work in wide deployment.

Not only that, but I find the complexty arguments dubious at best:  This is an extension which will ONLY affect resolvers and authorities who care.  Its only the pairwise points where this happens.  AND, because all results returned even without this are CORRECT (but perhaps suboptimal), the debugging impact is minor at worst.

> to accept this as a work item with this kind of objection now outstanding.

WHAT change to the internet architecture?  CDN and related DNS tricks are, at this point, in the architecture.  Period.  End of story.  Have a nice day.  Preserving the architectural feature is not changing the architecture.

And my brass tacks now:

If I was OpenDNS, Google Public DNS, etc, I'd say "F-it, we're doing it":  Thats the point of EDNS extensions, they are optional extensions that only create complexity when BOTH sides respect them.

Actually, I'd say "F-it part 2", and do it with pairwise agreements with the major CDNs to communicate in a side channel, so that MY third party DNS service shows good performance but your's doesn't, because I have the pairwise agreements and you don't!

Is that what you want?  Because that seems to be the outcome you are intent on creating.

---

From: Joe Abley <[email-masked]>
Date: Sun, 30 May 2010 09:06:45 +0300

On 2010-05-30, at 07:57, Nicholas Weaver wrote:

> Anycast TCP doesn't work well in widespread deployment,

cite?

---

From: Paul Vixie <[email-masked]>
Date: Sun, 30 May 2010 07:04:01 +0000

> From: "George Barwood" <[email-masked]>
> Date: Sun, 30 May 2010 07:33:51 +0100
> 
> It's one that I have some sympathy for, but the train left the station in
> RFC 1034.

i was there, and i can tell you, that's not how it was.

> I think it is you Paul that is proposing a change of architecture, and
> you need to justify it.

not so much.

> Large shared caches have some benefits ( and various disadvantages ).

that's why there are forwarders.

> If we are proposing to no longer support the shared caching model, that
> is a major change.

shared caching is fine. see above.

---

From: Nicholas Weaver <[email-masked]>
Date: Sun, 30 May 2010 21:22:13 +1200

>> Anycast TCP doesn't work well in widespread deployment,

I can't cite, but can anyone cite someone who IS using widespread TCP multicast, eg, for CDN type applications?

---

From: Wilmer van der Gaast <[email-masked]>
Date: Sun, 30 May 2010 10:49:12 +0100

> I can't cite, but can anyone cite someone who IS using widespread TCP multicast, eg, for CDN type applications?
This point came up in the previous discussion, and Colm MacCárthaigh
had some experiences with TCP anycast (although the post is not backed
up with data):

http://www.ops.ietf.org/lists/namedroppers/namedroppers.2010/msg00120.html

Wilmer.

---

From: [email-masked]
Date: Sun, 30 May 2010 12:01:16 +0000

> Because these "Stupid DNS tricks" do work, are used, and are important, shaving tens or even hundreds of MS off of user perceived latency when the user is using the ISP-provided DNS resolver.

	should I care that I get a wrong answer back faster?

--bill

---

From: [email-masked]
Date: Sun, 30 May 2010 12:07:01 +0000

> response there - should we force the stub to use TCP too? of course

	er... actually we do w/ DNSSEC - presuming the validation process
	is co-resident w/ the resolver process.  That MTU better be big
	enough to pass the full UDP datagram.

--bill

---

From: Colm MacCárthaigh <[email-masked]>
Date: Sun, 30 May 2010 09:28:20 -0700

> http://www.ops.ietf.org/lists/namedroppers/namedroppers.2010/msg00120.html

I think one of  the strongest source of data is that CDNs have built
DNS tricks in the first place, in spite of the fact that they also use
anycast. Clearly it cost money and time to develop the tricks, and it
stretches credibility to suggest that they maintain them for no good
reason. Plainly, CDNs have repeatedly come to the conclusion that
anycast alone does not deliver sufficient latency-oriented network
locality.

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.

-- 
Colm

---

From: Colm MacCárthaigh <[email-masked]>
Date: Sun, 30 May 2010 09:30:51 -0700

>        enough to pass the full UDP datagram.

Are you misreading the example? The MTU is big enough, and I made no
such presumption :)

-- 
Colm

---

From: Colm MacCárthaigh <[email-masked]>
Date: Sun, 30 May 2010 09:51:05 -0700

> to accept this as a work item with this kind of objection now outstanding.

Which rules? I can't see anything to that effect in RFC2026. But there
are a lot of documents it could be in :)

In any event, speaking to the architectural change - do you agree that;

  a) Since day 1 - DNS has not guaranteed consistent answers from
authoritative servers.
      The easiest example is an update that has made its way to only a
subset of the N
      NSs for a zone - say. Can we agree that that is built-in
always-been-happening
      behaviour of the DNS?

  b) There are features of DNS designed to accommodate this
non-atomicity and help
       with the inevitable inconsistency. SOA serial numbers, TTLs and so on.

-- 
Colm

---

From: [email-masked]
Date: Sun, 30 May 2010 21:21:35 +0000

> Are you misreading the example? The MTU is big enough, and I made no

	perhaps i am mis-reading.  there is a 1500byte MTU btwn the auth
	and the "resolver" - which i interpret as a third-party resolver
	injected into the resolution path - and a 9k MTU btwn this "resolver"
	and the stub - which is where validation occurs.  1500 bytes is too
	small.  (but now we are not discussing the "resolver" behaviour, we
	have moved to path charactieristics (see fragmentation), which might
	in fact be an attribute of the box the resolver is sitting on.

	i suspect some of the concern is that the concerns might be better
	expressed (on this vector) with the following ASCII diagrams:

A)
	stub <--- RTT 40ms ---> resolver <--- RTT 28ms ---> auth

	this is where the trusted resolver is far away from the stub. 
	but there is explict trust that is established out of band of the DNS

B)
	stub <--- RTT 15ms ---> resolver <--- RTT 28ms ---> auth

	this is the "common" use case where one is forced to use the immediate
	upstream ISP resolver. (where upstream could be your hotel, etc.)
	your draft seems to be directed at the resolver in this configuration
	and makes certain assumptions about what the stubs are capable of and
	what the user of the apps that depend on accurate DNS resolution will 
	put up with. Or maybe your just trying to ensure that the stub is always
	15ms away from an ISP resolver.

C)
	stub <--- RTT 5ns ---> resolver <--- RTT 28ms ---> auth

	this is where the resolver is in the same chassis as the stub. (highly
	desired outcome imho)

---

From: Alex Bligh <[email-masked]>
Date: Sun, 30 May 2010 14:31:53 -0700

> like to know if the WG is more in favour of this new version.

A question (I'm afraid I have not fully been through the draft yet).
Take this not uncommon configuration

   STUB --> NAT --> RECURSIVE --> AUTHORITATIVE

Do I read the draft (specifically 4.1 para 3) correctly that if STUB
sets edns-client-subnet, then RECURSIVE may not alter it, despite
the fact STUB will no doubt have put in RFC1918 space?

I take it the point of the 4.1p3 injunction is to enable the end
user to be less specific about IP address than an upstream
'Intermediate Server' (draft's term) might be. I would have thought
allowing an Intermediate Server to rewrite the subnet if the querying
IP address falls outside the subnet specified should be permissible.
IE if STUB specifies 0.0.0.0/0 then RECURSIVE cannot rewrite, but
if STUB specifies 10.1.1.0/24 and the query is received on
192.0.2.4, I don't particularly see a problem rewriting.
Can I suggest that you simply make the rule that any rewrite
must use a netmask that is no longer than the incoming netmask?

-- 
Alex Bligh

---

From: Donald Eastlake <[email-masked]>
Date: Sun, 30 May 2010 19:49:54 -0400

Hi,

> the fact STUB will no doubt have put in RFC1918 space?

I think the idea was, as you mention below, that the STUB might put in
0/0. In addition, the stub might put in some routable network because
it wants to appear to be coming from somewhere else. But I think the
logic could be improved as one might want to do client IP within a
large enterprise or the like.

Thanks,
Donald

---

From: Paul Vixie <[email-masked]>
Date: Sun, 30 May 2010 23:57:16 +0000

> Date: Sun, 30 May 2010 21:22:13 +1200
> 
> I can't cite, but can anyone cite someone who IS using widespread TCP
> multicast, eg, for CDN type applications?

not that i see this as topical for this draft, but see:

http://www.merit.edu/mail.archives/nanog/2006-06/msg00139.html

and its references:

http://www.nanog.org/meetings/nanog37/abstracts.php?pt=Mzg0Jm5hbm9nMzc=&nm=nanog37
http://www.nanog.org/meetings/nanog37/presentations/anycast.ram
http://www.nanog.org/meetings/nanog37/presentations/matt.levine.pdf

---

From: Alex Bligh <[email-masked]>
Date: Sun, 30 May 2010 17:02:41 -0700

> large enterprise or the like.

I was concerned that a default setting where this was on would generate
unhelpful options, and encourage NAT vendors to attempt to correct
things (not in general a good idea).

As long as the netmask is made no longer, I see no additional harm
in rewriting.

Not that I'm entirely convinced by the concept as a whole...

-- 
Alex Bligh

---

From: Donald Eastlake <[email-masked]>
Date: Sun, 30 May 2010 21:06:21 -0400

Hi Paul,

> coming and i'm opposed to this change to the connection model.

I was around when SRV was adopted. There was no sneaking or attempt to
surprise. There was quite extensive public discussion..

The authors of edns-client-ip are specifically bringing it up for
discussion in the appropriate WG. I do not see any sneaking or attempt
to surprise here.

> to accept this as a work item with this kind of objection now outstanding.

I think you have a very active imagination. I may not have been around
quite as long as you but I'm sure there is no such "rule".

Of course, anyone who wants to can send email to the IAB or any member
of the IAB asking them to consider or look into this draft or whatever
they want.

Thanks,
Donald

---

From: Jim Reid <[email-masked]>
Date: Mon, 31 May 2010 11:11:45 +0100

On 29 May 2010, at 22:18, Nicholas Weaver wrote:

> shaving tens or even hundreds of MS off of user perceived latency

Have you any objective data for this claim?

Next, I very much doubt human beings are able to tell the difference  
between a packet RTT of 200ms and one of 300ms. Or 50ms and 100ms.  
Unless (maybe) it's for bi directional real-time audio/video.

Finally, doesn't it strike you as odd that changes to the DNS are  
proposed as the solution to what appears to be a routing problem?

---

From: Jim Reid <[email-masked]>
Date: Mon, 31 May 2010 11:20:45 +0100

> poor proxy, and I think we all realise that the size of AS's vary  

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: Jim Reid <[email-masked]>
Date: Mon, 31 May 2010 11:48:07 +0100

On 30 May 2010, at 02:28, Colm MacCárthaigh wrote:

>> option to

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: [email-masked]
Date: Mon, 31 May 2010 14:18:38 +0200 (CEST)

> Unless (maybe) it's for bi directional real-time audio/video.

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.

> proposed as the solution to what appears to be a routing problem?

Agreed. I don't support the draft.

Steinar Haug, Nethelp consulting, [email-masked]

---

From: [email-masked]
Date: Mon, 31 May 2010 14:09:42 +0200 (CEST)

---

From: Bruce Campbell <[email-masked]>
Date: Mon, 31 May 2010 08:52:13 -0700

> The problem is web pages which result in *many* DNS queries and thus

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.

> Agreed. I don't support the draft.

ditto.

As a CDN administrator, I'd love to get more details about where queries 
are coming from.  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.

-- 
   Bruce.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 31 May 2010 16:29:22 +0000

> Date: Mon, 31 May 2010 14:09:42 +0200 (CEST)
> From: [email-masked]
> 

sounds like dns-based cdn's want to send long cname chains and are noticing
the number of round trips, and third party recursive dns providers want folks
to outsource recursive dns and are noticing the length/cost of round trips.

it's as though dns-based cdn's and outsourced third party recursive dns were
bad ideas to begin with and the providers of same have woken up to the fact
that dns doesn't work this way, and so now, they'd like it to work that way.

cart. horse.

---

From: Joe Abley <[email-masked]>
Date: Mon, 31 May 2010 13:13:54 -0400

On 2010-05-30, at 05:22, Nicholas Weaver wrote:

> I can't cite,

I see.

> but can anyone cite someone who IS using widespread TCP multicast, eg, for CDN type applications?

You mean anycast, not multicast.

Radio NZ and Citylink stream audio content using anycast nodes in Auckland, Wellington and San Francisco, and have been doing so since 2005.

Joe

---

From: [email-masked]
Date: Mon, 31 May 2010 17:56:07 +0000

Ok, 

	So this draft is a really interesting idea that is very poorly
	thought through.  it makes some (more) presumptive statements about
	the ability of an intermediate party to tamper with/manipulate 
	data in-flight between an authoritative source and the requesting
	client.  yes, there are use cases that argue for its use - but 
	a use-case alone may not be sufficent to change a fundamental architectural
	design.

	under the current IETF mode of operation, I would have to say that I
	am not in favor of advancing this draft.

	that said, I think that the IETF has lost track of what was a historical
	stance - to document the evoultion of the protocol(s).  And what we have
	here is an evolutionary branch that ought to be documented someplace
	and marked as "this is a bad idea for these reasons".  Not so much
	experimental, although that would work, in the strict sense of experimental.
	What is needed (IMHO) is a class of documents that describe ideas and
	branches not taken and why.  Email archives are very poor repositories
	for such things.

--bill

---

From: Colm MacCárthaigh <[email-masked]>
Date: Mon, 31 May 2010 11:31:22 -0700

>        a use-case alone may not be sufficent to change a fundamental architectural

Resolvers are not routers :-) What exactly is the point of EDNS
options otherwise? The standard
makes it plain that;

   client query <---------> resolver <-----------------> auth server
                                                      EDNS option

is not only valid, but *expected*. Are you saying that the entire EDNS
spec should be thrown away?

Another non-EDNS example, this might happen;

   client query <--- 'A foo.com' ---> resolver <--- 'A bar.com' ---> auth server

because the resolver knows that foo.com is a CNAME or DNAME. Is that
tampering too?

-- 
Colm

---

From: [email-masked]
Date: Mon, 31 May 2010 19:03:05 +0000

> because the resolver knows that foo.com is a CNAME or DNAME. Is that

	and how does te resolver know this?

--bill

---

From: Colm MacCárthaigh <[email-masked]>
Date: Mon, 31 May 2010 12:22:30 -0700

>        and how does te resolver know this?

Cached from a previous response for foo.com. This is
common, normal, every-day caching resolver behaviour. My point is that
resolvers are not routers - they do not simply blindly forward queries as-is
from clients unless there is an exact match. Here's a list of common
differences which can occur;

 1. As above, the resolver may know about intermediary redirection,
and so query
     for an entirely different name.

 2. The resolver may opt to use TCP or UDP, independent of what it chooses to
     negotiate with the client.

 3. A resolver may opt to use IPv4 or IPv6, independent of what it
chooses to negotiate
     with the client.

 4. The resolver may negotiate different MTUs, resulting in different
responses.

 5. The resolver may vary the query name, for better entropy, e.g.

        foo.com becomes   "FoO.cOm"

 6. Resolvers may be using DNSSEC and DLV in ways that the queries
between it and the DNSSEC capable auth server are very different indeed from
simple A requests.

Each of these is happening right now, every day, for millions of
queries in some cases. Considering that the EDNS specification itself
calls out that options are hop-by-hop mechanisms - I think it's fair
to say that the notion that there is an end-to-end principle for DNS
query payloads does not stand up to scrutiny.

-- 
Colm

---

From: Florian Weimer <[email-masked]>
Date: Mon, 31 May 2010 21:52:34 +0200

> Unless (maybe) it's for bi directional real-time audio/video.

There's a good chance that we're going to see many more interactive
real-time applications.  But I guess you could put the client's IP
address, as seen as from the server, into subsequent (DNS) requests
(and some folks already do that).  This gives you the opportunity to
reroute mostly statelessly if you feel like doing that.

Oh, and in other news---how's the IPv6 deployment going?  When major
ISPs can't get their act together and provide native IPv6 to their
customers, we're going to see a lot of tunneling, and IP addresses as
location indicators will be less reliable (much like tunneling tends
to worsen routing protocol decisions).

---

From: Paul Vixie <[email-masked]>
Date: Mon, 31 May 2010 22:12:00 +0000

> From: Florian Weimer <[email-masked]>
> Date: Mon, 31 May 2010 21:52:34 +0200
> 
> ..., and IP addresses as location indicators will be less reliable ...

were they ever reliable?

---

From: Mark Andrews <[email-masked]>
Date: Tue, 01 Jun 2010 08:18:56 +1000

> that dns doesn't work this way, and so now, they'd like it to work that way.

It would also help if they were EDNS aware (some are) and that they
return good responses to AAAA queries that won't be rejected by the
recursive nameservers.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 31 May 2010 15:24:22 -0700

> Next, I very much doubt human beings are able to tell the difference between a packet RTT of 200ms and one of 300ms. Or 50ms and 100ms. Unless (maybe) it's for bi directional real-time audio/video.

Actually, you can, because there is a lot of needless chaining and dependencies.  An extra RTT of 100ms can easily add up to a half a second or a second on page load time,  Especially since many HTTP clients don't agressively pipeline because some HTTP servers barf on it.

> Finally, doesn't it strike you as odd that changes to the DNS are proposed as the solution to what appears to be a routing problem?

Uh, actually, it IS a DNS problem: its a name->address mapping problem, which, once complete, things work well.

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 31 May 2010 15:25:57 -0700

> Radio NZ and Citylink stream audio content using anycast nodes in Auckland, Wellington and San Francisco, and have been doing so since 2005.

Broadcast audio is NOT latency sensitive.

Web page loads are.

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 31 May 2010 15:41:16 -0700

Where did CNAME chains come in?

The latency hit people are worried about is NOT the DNS lookup itself, but the latency to the system who's A record was returned as a valid answer.

The difference between "good" and "bad" on this latency may be ~100ms or more.  And this difference is huge when doing things like HTTP fetches because fetches of a typical web page incur many RTTs of latency in processing, because you have the initial TCP handshake, the fetching of the root page, and then the fetching of many subsequent pieces (images, scripts, etc) in a NON-pipelined manner

IE8, Firefox, Chrome, etc do NOT do HTTP pipelined fetches by default, according to the Wikipedia entry ( http://en.wikipedia.org/wiki/HTTP_pipelining )

Thus the difference of 100ms RTT may be a second or more on page load time, and there are a LOT of people who care about 1 second page load times.

---

From: Joe Abley <[email-masked]>
Date: Mon, 31 May 2010 19:31:26 -0400

On 2010-05-31, at 18:25, Nicholas Weaver <[email-masked]>  
wrote:

>> Radio NZ and Citylink stream audio content using anycast nodes in  
>> Auckland, Wellington and San Francisco, and have been doing so  
>> since 2005.
>

So you're saying you asked the wrong question?

Joe

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 31 May 2010 18:17:40 -0700

OK, then, the more precise question:
 
Is anyone significantly using anycast, for a latency sensitive application over TCP (eg, serving pages using HTTP)?

We have had reports in the threads on this subject that at least one company tried and compared it with DNS tricks, and decided DNS tricks were superior for reducing latency.

On May 31, 2010, at 4:31 PM, Joe Abley wrote:

> 
> On 2010-05-31, at 18:25, Nicholas Weaver <[email-masked]> wrote:
>

---

From: Joe Abley <[email-masked]>
Date: Mon, 31 May 2010 23:42:53 -0400

On 2010-05-31, at 23:39, Greg Daley wrote:

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

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: John Payne <[email-masked]>
Date: Tue, 1 Jun 2010 00:07:06 -0400

> to outsource recursive dns and are noticing the length/cost of round trips.

The latency improvements mentioned have nothing to do with any cname chain.

---

From: John Payne <[email-masked]>
Date: Tue, 1 Jun 2010 00:09:33 -0400

On May 31, 2010, at 6:20 AM, Jim Reid <[email-masked]> wrote:

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

Who gets to decide what's "better"?

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

Because the problem definition hasn't been framed as routing problem, its been framed as a name -> address problem.

---

From: John Payne <[email-masked]>
Date: Tue, 1 Jun 2010 00:12:03 -0400

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.

---

From: [email-masked]
Date: Tue, 01 Jun 2010 08:38:20 +0200 (CEST)

> The latency hit people are worried about is NOT the DNS lookup itself, but the latency to the system who's A record was returned as a valid answer.

People are definitely worried about the latency incurred for multiple
DNS lookups per web page. These lookups may be due to the way the web
page is organized, possibly in combination with CNAME chains.

The DNS lookup is only part of the page loading latency, of course -
as you have observed the actual TCP session(s) are also extremely
important.