Subject: Re: [dnsext] draft-vandergaast-edns-client-ip-00 and combining queries

From: David Ulevitch <[email-masked]>
Date: Thu, 1 Apr 2010 08:24:54 -0700

On Wed, Mar 31, 2010 at 7:23 PM, Paul Vixie <[email-masked]> wrote:
>> Date: Wed, 31 Mar 2010 19:04:52 -0500
>> From: Michael Graff <[email-masked]>

>
>> Now, with this client-ip idea, it seems this may no longer work as
>> expected.  Many more queries may be issued to servers which otherwise
>> would be pooled together.
>
> client-ip is a bad idea for other better reasons than this.

Can you elaborate? Is it because it provides more specific, better
answers (read: different) based on who is querying much like Akamai,
Google, Yahoo, Amazon, etc. do today on the authoritative side?  Or
are you opposed to something more fundamental about the idea or
implementation itself?

-David

---

From: Paul Vixie <[email-masked]>
Date: Thu, 01 Apr 2010 16:58:30 +0000

> Date: Thu, 1 Apr 2010 08:24:54 -0700
> From: David Ulevitch <[email-masked]>
> 
> Google, Yahoo, Amazon, etc. do today on the authoritative side?  Or are
> you opposed to something more fundamental about the idea or
> implementation itself?

before i elaborate, can ed lewis talk about complexity and q-tuples again plz.

---

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

>before i elaborate, can ed lewis talk about complexity and q-tuples again plz.

Altho this is sort of rhetorical, let's see if I can in a few 
paragraphs explain the sanctity of the Q-trinity and why this is not 
an obstacle for edns-client-ip (or vice versa).  (I don't touch on 
combining queries.)

Boiling DNS to it's very essence is the mapping of:
     Q-NAME, Q-TYPE, Q-CLASS to Q-NAME, Q-TYPE, Q-CLASS, RDATA.
The three Q's is where I get "Q-trinity" from.  Protocol 
archeologists can see this in examining the syntax of the question 
section and the answer section of a DNS message.  Over time we've 
dressed this up a bit, namely dealing with sets of the mappings, 
later round-robin, and other icing.  But it all boils down to the 
ability to ask for a Q-trinity and get back a (set of) RDATA.

Over time we have seen various attempts to augment the Q-trinity or 
to vary the RDATA set based on something other than the Q-trinity, 
namely:
- tell a cache to ignore what it had and fetch an authoritative answer
- respond tailored to the addresses in the enveloping protocol header
- assess the load on the application servers
- altering answers for any other kind of policy (political or parental even).

Some of these are workable, some are not.  The first one is one I 
recommended against because it involved the header bits.  The second 
and third use non-DNS data as part of the answer generation process. 
The fourth also uses non-DNS data.

To stay on theme, the second item, tailoring responses to 
(specifically) a query source IP address has already proven workable, 
despite the obvious problems caches should face.  Instead of being 
theoretical here, let's look at a example of this in use.  There is 
support for this in BIND (views, match-source) which is so widespread 
that users of it take for a DNS standard (it's not!).  edns-client-ip 
is extending the concept of BIND's views.  Because views is rather 
undetectable (there are no traces of it in the response), caches 
treat the data as if "match-source" was 0.0.0.0/0 and ::/0.

Without edns-client-ip, an authority server has to assume the address 
it sees as the source is the appropriate source.  With edns-client-ip 
there is no need to assume.  In the response, an authority server 
implicitly states that the response is for 0.0.0.0/0 or ::/0.  With 
edns-client-ip the authority can scope the answer.  edns-client-ip 
doesn't change the means by which an authority server prepares a 
response (if using views) but it does change how it determines the 
source IP address and how it expresses the applicability of the 
answer.

For a caching server, edns-client-ip does represent a significant 
change to how it caches data.  Fortunately, edns-client-ip is largely 
inappropriate for the majority of cache implementations, including 
just about all general purpose caches.  On the other hand 
edns-client-ip is very important to a non-trivial population of 
caches which are chartered with offering DNS recursive service to 
topologically diverse stub resolvers and other DNS clients.

Complexity is always a concern, it is what crimps scaling of any 
system.  It is a subjective term though.  We do like optimization - 
but each optimization is an instance of increasing complexity.  (If 
internal combustion engines shied away from the complexity of 
electronic fuel injection, we'd all be mechanics in a polluted 
world.)  The question isn't whether complexity is bad, but what it 
costs and what it gets us.

What I would be more mindful of is the question "if edns-client-ip 
benefited only a certain segment of the population (of DNS 
instances), is it causing a fracture in the nature of the protocol?" 
That would be a more immediate threat.

 From what I've read (which includes unpublished rewrites of the -00), 
I don't think it does present an architectural fragmentation.  I 
think the original draft on the topic wasn't clear enough and 
deserved to be hammered in a few places and parts of the definition 
needed to be fixed.  But at the core of the proposal lay something 
that can work.  With complexity only on those willing to take it on, 
edns-client-ip can be added to the protocol without causing 
fragmentation.  Does this warrant a specification?  Yes, in that 
there's a large enough group that needs to be interoperable.

Other factors on "what's fragmentation?" - MX records are pretty much 
SMTP specific but that doesn't mean the protocol is fragmented. 
EDNS0 has a DO bit, only meaningful for DNSSEC, also not representing 
fragmentation.  If edns-client-ip assumed any negotiation between the 
client and server or reinterpreted a field, flag, or bit, then it 
would be fragmenting the protocol.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

New pithy statement under construction...

---

From: David Ulevitch <[email-masked]>
Date: Tue, 6 Apr 2010 11:34:02 -0700

On Thu, Apr 1, 2010 at 12:59 PM, Edward Lewis <[email-masked]> wrote:
> From what I've read (which includes unpublished rewrites of the -00), I
> don't think it does present an architectural fragmentation.

Okay Paul -- back to my original question.  What is your objection to
providing optional hints via edns0 options between recursive and
authoritative servers that improve the DNS answers a querying resolver
is asking?  Is it philosophical about different answers to different
people or something more fundamental about the  this proposed
implementation?

Thanks,
David

---

From: Paul Vixie <[email-masked]>
Date: Tue, 06 Apr 2010 19:55:28 +0000

> Date: Tue, 6 Apr 2010 11:34:02 -0700
> authoritative servers that improve the DNS answers a querying resolver is
> asking?  Is it philosophical about different answers to different people
> or something more fundamental about the this proposed implementation?

i think i need to write a longer article about this, with drawings.  but
briefly, i have five areas of serious heartburn.

first, this proposal inures to a hub/spoke topological model, where edges
might be NAT'd and that as a query gets closer to the core it's less likely
that a forwarding agent (could be DNS-layer or IP-layer) would need to 
rewrite this option's payload because it's more likely that the payload
would exist in the same addressing realm as the responder.  since i know
that other topological models are now in use, and since i hope that IPv6
will encourage exploration of even more alternative models, i'm reluctant
to pour any concrete around the model this proposal presumes upon.

second, this proposal opens a new information pathway, which will often be
enabled by default, thus newly leaking a lot of information that end users
might wish hidden if they know about it but often won't know.  defaults are
not always privacy-friendly and sometimes overrides aren't available or
aren't apparent.  this reminds me of web cookies in that the implications on
privacy won't be in the public's awareness and so the "analytics" people
will have a wealth of new information to play with, some of which will be
used commercially or even hostilely against unsuspecting end users.

third, this proposal assumes that triangulation is a predictor of either
performance or reachability or locality.  if somebody proxies their DNS in
one direction and proxies their HTTP in another direction, or if distance
A-C is completely unrelated to distances A-B and B-C due to wormholes, then
locality logic will either add no value or actually subtract value.  this
kind of differential proxying and these kinds of wormholes are already quite
common and there's no reason to expect a reduction here, not even based on
theoretical advantages offered indirectly by the proposal we're discussing.

fourth, this proposal assumes that all applications want locality expressed
in terms of IP addresses, and does not generalize it to include language
preference or geolocation or political boundary information.  if we're going
to add locality or identity information to DNS queries then we should find
out what the W3C people think, and other non-web applications people think,
since when locality was added to HTTP it was expressed as a longer vector
than just "client's IP address".  we should do this right if we're going to
do it at all.

fifth, this proposal will raise the bar for all service providers even if it
adds very little value (or is an aggregate value subtract for the reasons
given above and possibly other reasons i haven't thought of yet.)  thus, all
authority and recursive providers/implementors/operators will have some
competitive pressure to support this proposal or else face loss of relevance
or loss of revenue.  thus the complexity added won't be optional in any
practical sense.  debugging all this, and debugging the resulting system
after it has this feature inside it, will be a new and permanent and global
"operations tax" on the I.T. industry.

note that i'm not listing the concern you said you expected, having to do
with the stability and coherency of answers.  that's not because i've stopped
having that concern, but because i've already expressed it elsewhere:

	"What DNS Is Not" (ACM Queue, 05-November-2009, Paul Vixie, ISC)
	http://queue.acm.org/detail.cfm?id=1647302

rest assured that if the give concerns i've given here are somehow answered
or ignored, then my previous objection, stated in the ACM Queue article
referenced above, would remain very much "on the table" as far as i'm
concerned.

(i apologize for the high density here.  i will try to write this up in a
longer gentler way, for ACM Queue or Circle ID or similar, when i next come
up for air.)

---

From: David Ulevitch <[email-masked]>
Date: Tue, 6 Apr 2010 13:35:03 -0700

> briefly, i have five areas of serious heartburn.

Thanks for the response.  All good questions, but I don't think they
are valid concerns.  I don't understand the first, so I snipped it.

> used commercially or even hostilely against unsuspecting end users.

Speaking personally -- while I would enable this by default, and let
people turn it off if they want -- our implementation would only
enable this information pathway on a zone by zone basis.  We don't
want to trust unknown authoritative servers from filling our caches
either.

> theoretical advantages offered indirectly by the proposal we're discussing.

Again, when coordinating with a known authoritative for a specific
zone, this point is moot.  They know the right answer to give, and
there are multi-billion dollar companies that are good at this.
Akamai comes to mind as one of them.

> than just "client's IP address".  we should do this right if we're going to

This is orthogonal.  edns-client-ip is intended to help deliver
answers based on topographic proximity, not language or similar.  And
it does that based on the answers given by the owner of the zone being
resolved.  Who better to deliver that answer than the content owner?
I can think of no one.

> "operations tax" on the I.T. industry.

The fortunate thing here is that nobody is required to implement it.
There is no tax being created.  And nobody is required to support it
unless they will derive benefits from it.  Major content providers
will derive benefits.  Major DNS resolution services and ISPs will
derive benefits.  Debugging is also no harder than it is today (and
perhaps is easier!).  Today, when you resolve www.google.com,
www.yahoo.com and www.amazon.com you get different answers depending
on where you are and on what network you sit.  This will remain the
case with edns-client-ip.  Any operations tax has already been in
place for years and has already been fully realized. :-)

-David

---

From: Ted Hardie <[email-masked]>
Date: Wed, 7 Apr 2010 08:12:57 -0700

Hi David,

First, while we're back on this topic, would you address the issue Michael
Graff pointed out at the top of this thread?

Some further discussion in-line.

> are valid concerns.  I don't understand the first, so I snipped it.

That's a fairly hilarious response to a concern, but I am easily amused.

> want to trust unknown authoritative servers from filling our caches

How does this address the concern about the user's information leaking?
This appears to address the provider's concern about doing this without
recompense instead.

> Akamai comes to mind as one of them.

Again, this doesn't seem particularly responsive to Paul's point about
the topology.  If proxy my DNS in one direction (e.g. my office servers,
in order to take advantage of split dns) but HTTP in a different direction
(through a socks tunnel at a public WiFi), the locality logic here
will not work and may be worse than the unoptimized version.  When
the actual application connection comes in, they may realize it is
unoptimized and react (if the app-layer protocol supports it), but they
do not know the right answer to give in this case.

You may argue it is rare, of course, but this is a fairly clear case where
the topology does not match.

As a further aside, you seem to focus a good bit on coordinating with
"known authoritative for a specific zone", but the draft is written with
a default that seems more likely to turn it on unless the user has inserted
the appropriate bits to turn it off.  If you actually expect this to be turned
on only when there is an out-of-band agreement, explaining why
this should be a standard with that configuration would help.

regards,

Ted Hardie

---

From: Paul Vixie <[email-masked]>
Date: Wed, 07 Apr 2010 15:19:27 +0000

> Date: Wed, 7 Apr 2010 08:12:57 -0700
> From: Ted Hardie <[email-masked]>
> ...

ted, i found david's reply to be completely nonresponsive.  if i've spent
20 years considering the points of view i expressed, then i'd like david
(or anyone else responding to me) to spend at least 20 minutes considering
their own position in light of what i said.  i guess it's time to rename
my personal blog "hey you kids get offa my lawn" or similar.

however, the fault is mine, i compressed way too much information into a
single page of text.  i owe, as i said in my postscript, a longer treatment.

--paul

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 7 Apr 2010 11:48:50 -0400

No hat.

> single page of text.  i owe, as i said in my postscript, a longer treatment.

With this, I disagree strongly.  Information density is good.  At
least one of your concerns is a significant objection that needs
treatment in a Security Considerations section of a draft.  At least
another one, and by my reading two, amounts to an objection that the
proposal contains architectural assumptions about the relationships
amongs query originators, intermediate resolvers, and authority
servers.  In my view, those objections have to be answered in their
own terms, or else we need an argument why the terms are wrong.

Best,

A

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

---

From: David Ulevitch <[email-masked]>
Date: Wed, 7 Apr 2010 08:58:54 -0700

> Graff pointed out at the top of this thread?

Michael was asking about concurrent outstanding queries having an
impact on DNSSEC validation overhead (and ultimately the potential to
cause a denial of service I suppose).  There isn't any more cause for
concern here than there is with just DNSSEC.  DNSSEC has a significant
tax on resources for the benefits of some increased security, but
edns-client-ip doesn't make that tax any better or worse.  Just as a
client can ask for ${random}.${random}.dnssec-enabled-zone.com 1000's
of times, they can spoof a request from a number of source IPs much
the same way.  The problem exists with or without edns-client-ip and
the mitigation methods are the same in either scenario.

> That's a fairly hilarious response to a concern, but I am easily amused.

I've re-read it this morning.  I'm still confused but I think it's
because I'm coming from a different point of view.  We're not
discussing a hypothetical protocol extension, we're discussing
something that already exists and are trying to standardize it.  If
paul believes that putting a standard in place so people can know what
to expect, look for, and observe equates to pouring "concrete around
the model" then I disagree with his view.  Not standardizing it won't
make it go away.  Maybe folks don't know this -- lots of edns
option-code's are in use today, and like this one, they should at
least be published so others can understand them if they observe them
in the wild and want to respond to them.

> This appears to address the provider's concern about doing this without

There's 4 scenarios I see --

1) A user is using a specific recursive DNS server visiting a resource
where the authoritative DNS server is hosted by the resource owner.
2) A user is using a non-specific recursive DNS server visiting a
resource where the authoritative DNS server is hosted by the resource
owner.
3) A user is using a specific (local resolver, OpenDNS, etc.)
recursive DNS server visiting a resource where the authoritative DNS
server is hosted by a third party (like UltraDNS).
4) A user is using a non-specific (internet cafe, ISP, etc.) recursive
DNS server visiting a resource where the authoritative DNS server is
hosted by a third party (like UltraDNS).

In #1 and #3 I see absolutely no issue.  The user has made a choice to
use a DNS service that operates in this way.
In #2 there is no data leakage that isn't already being leaked to the
resource owner already once a connection is made.
In #4 there is data leakage.  The user's source IP address, assuming
it isn't RFC1918'd, will be passed to a third-party authoritative DNS
service which can collect and track that data in a way they otherwise
wouldn't.  I'm not confident this represents data leakage of any
material significance, but it's certainly worthy of discussion.  Do I
think it has the same utility as HTTP cookies?  Not even close.  Could
it be used to better understand browsing habits of DNS end-users, yes
I think it could.

I do believe the benefits far outweigh the concerns in #4.

> the topology does not match.

But edns-client-ip doesn't make this worse.  The potential problem you
highlight is absolutely the case today when visiting any of the Alexa
top 10 (and probably the majority of the top 100) websites.
edns-client-ip can only make this better, I don't see how it will make
it worse.  Your edge case exists with or without edns-client-ip
because 20%+ of the Internet already uses the location of the resolver
to hand back a response (Akamai).  People who really care about this
do as you describe and handle it higher up in the stack to redirect
appropriately.

> this should be a standard with that configuration would help.

The motivation, in my mind, for this draft is that this stuff is
already happening.  At OpenDNS, we've been using edns option code's
for years to signal information between clients and resolvers,
forwarders and resolvers and between resolvers and authoritative
servers.  Now that there are more and more people trying to do things
the way we've been doing them it makes sense to standardize the
methods, claim the option-code's already in use, etc.  So while we
believe that it only makes sense to do this on a zone by zone basis,
and perhaps that can be written into the draft of why someone might
want to do that, it's more important to make sure we're all doing it
the same way to avoid problems later on.

We're happy to modify our implementations based on whatever standard
is determined, but the higher-level concept of providing better
resource resolution for large-scale recursive services is happening
already and isn't really what is being discussed here (though it seems
as though people wish it were).  That train has already left the
station.  The question that remains is how to best accomplish it in a
way that is open and can be implemented by anyone who wants to
implement it.

-David

---

From: David Conrad <[email-masked]>
Date: Wed, 7 Apr 2010 06:23:39 -1000

On Apr 7, 2010, at 5:58 AM, David Ulevitch wrote:
> Maybe folks don't know this -- lots of edns
> option-code's are in use today, and like this one,

I (as IANA Executive Director (acting)) wasn't aware of this.  How are these unassigned option-codes used?

> they should at

I can see this devolving into the always popular '"don't reward squatters" vs. "document reality"' rat hole.

Regards,
-drc

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 7 Apr 2010 13:09:59 -0400

> to pour any concrete around the model this proposal presumes upon.

I would argue instead that this is about the "cloud and spoke" model, which reasonably accurately represents reality when the goal is to identify which spoke or small group of spokes a user is at.  

After all, if this model did not represent reality, how would Akamai be in business?

> used commercially or even hostilely against unsuspecting end users.

Privacy concerns must be scaled and placed in context.  "You don't worry about mosquito bites when there are arterial bleeds".

The privacy leakage from this proposal is an order of magnitude less than existing privacy leakages through analytics, APIs, web browsers with amazingly agressive prefetching, and a host of other issues: 

Even moreso, the information leakage is minor, and only goes to the authorities where the user is trying to contact! 

If you want to contact a site, it will learn your exact IP address anyway, and you use DNS generally to contact sites with other protocols.

And if you don't want the site to know your IP address, route your DNS through a proxy as well (you should be anyway.  EG, TOR already does that.)

> theoretical advantages offered indirectly by the proposal we're discussing.

Again, the proof is that this actually works.  For those who use their ISP's resolvers, Akamai-type techniques provide very good performance.  

The cases where people put their path through pervented proxying should not be a major concern, its VERY rare, and such deliberate perverted cases could instead relay their DNS through the same path.

> than just "client's IP address".  we should do this right if we're going to

No, this proposal assumes that there is a large group of significant services which have successfully used locality expressed in terms of IP coordinate space, that this information works well already when the ISP's resolver is used, and that such coordinate services should still work when users use a third party resolver.

And you have to do locality at the DNS level, because DNS is the only way you can express the locality WITHOUT adding RTTs in the process (like you would with HTTP redirects): latency is key here.

> "operations tax" on the I.T. industry.

Except that we are in the position where third party resolvers are at a huge competitive disadvantage because a proposal like this doesn't exist.  "Akamai sucks when you use Google DNS or OpenDNS".  And if Akamai sucks, the web sucks.

The question which the detractors have not answered:  Do you want a third party resolver services (OpenDNS, Google Public DNS etc) to be on a significantly disadvantaged footing when compared to the ISP provided resolver services?  

If the answer is yes, say so.  "Akamai should only work well if you use your ISP's DNS infrastructure".  

If the answer is no, there MUST be some mechanism for the third party resolvers to export client-IP information in some form to a group of authority servers.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 07 Apr 2010 17:17:11 +0000

> From: Nicholas Weaver <[email-masked]>
> Date: Wed, 7 Apr 2010 13:09:59 -0400
> 

akamai offers the great boon of requiring consciousness and discipline
on the part of web publishers.  to use akamai's services you have to use
relative URL's for in-site navigation, and you have to know when and what
you are publishing.

as far as the stupid dns tricks themselves, akamai and speedera and the
others are pretty much selling snake oil, but lucky thing is, nobody ever
got fired for signing a purchase order for snake oil.  (see: anti-virus.)

---

From: Ted Hardie <[email-masked]>
Date: Wed, 7 Apr 2010 13:48:32 -0700

> Privacy concerns must be scaled and placed in context.  "You don't worry about mosquito bites when there are arterial bleeds".

Why put someone with arterial bleeding in a roomful of mosquitoes with unknown
exposure to malaria, yellow fever or dengue?

Your for the exploitation of metaphor,

Ted

---

From: Ted Hardie <[email-masked]>
Date: Wed, 7 Apr 2010 13:46:27 -0700

On Wed, Apr 7, 2010 at 8:58 AM, David Ulevitch <[email-masked]> wrote:
> cause a denial of service I suppose).

I think you missed part of his point.  He was saying that oustanding queries
can be merged in the current system and this may not be possible if this
is in use:

"BIND 9 will combine queries currently.  That is, if a query for foo.com
is already in progress another query from a client will cause it to
merge into that same work item. "

The proposal on the table changes the cachability characteristics of the
response, by tying it to a specific  locality in IP space.   That may eliminate
this optimization.

(That's my take, anyway, but Michael should speak up as well if he's still
interested in the thread)

 There isn't any more cause for
> in the wild and want to respond to them.

Sadly, that's not as hilarious; I hope you can work with David on getting
documented what ought to be.

> resource where the authoritative DNS server is hosted by the resource

What does "non-specific" mean above?  Discovered by DHCP, rather
than manually configured?

> use a DNS service that operates in this way.

But this opt-out, not opt-in, and there is no way for the user to tell that
the recursive resolver is operates in this way.

> resource owner already once a connection is made.

You have to know what the application does to know whether this leakage
is new or not.  An http client talking to  a squid proxy does not leak prior
to this and leaks now.

> I do believe the benefits far outweigh the concerns in #4.

I don't think you're getting much useful data on the
"browsing data of DNS end-users", which is, honestly,
not a phrase I'd use.     Or should I assume you mean the
benefit of more money from advertisers paying for locality-targeted
ads, rather than more generic ads?

> But edns-client-ip doesn't make this worse.

I think the point is that it doesn't provide a benefit in this case,
a point on which we appear to agree.

 The potential problem you
> way that is open and can be implemented by anyone who wants to

No, the question is whether there is a method that is architecturally
sound, responsive to privacy concerns, and you know, actually works.
That might be worth a standard.

You can have a method that is "open and can be implemented by anyone"
without being architecturally sound or responsive to privacy concerns without
meeting the other concerns.

Just might two cents,

Ted Hardie

---

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

> response, by tying it to a specific  locality in IP space.   That may eliminate

There's no reason queries with the same edns-client-ip parameter can't
be merged (and to prevent colliding attacks, it's advisable that they
do).  Further, caches should only be sending queries with netmask>0 to
servers they actually expect will give a useful response, so there's
explicit opt-in for the extra bandwidth on both parties.  A cache
won't send queries with a long netmask and an authoritative server
won't suggest longer netmasks unless they want to endure the extra
costs.

> is new or not.  An http client talking to  a squid proxy does not leak prior

How does your HTTP client know that the HTTP proxy isn't adding an
X-Forwarded-For header?

Also, an HTTP client that's talking to an HTTP proxy shouldn't be
talking to DNS anyway.  If you're going to ask an HTTP proxy for
http://www.ietf.org/, the client has no use for resolving www.ietf.org
first.  I'd suggest mail clients resolving DKIM TXT records as a more
realistic example.

That said, I don't see any realistic scenarios where queries for
A/AAAA records could result in privacy leaks, and I don't see any
reason a privacy conscious cache couldn't limit use of edns-client-ip
to those record types.

> meeting the other concerns.

I don't like edns-client-ip's increased cache memory usage, but it's
the best solution we have to date to improve user experience.  If you
have ideas on how to implement a 100% solution to this problem, then
I'm interested.  But in the mean time, I'm happy to use an
easy-to-implement and easy-to-deploy 95% solution.

---

From: Ted Hardie <[email-masked]>
Date: Wed, 7 Apr 2010 15:19:44 -0700

On Wed, Apr 7, 2010 at 2:48 PM, Matthew Dempsky <[email-masked]> wrote:
> do).

Sorry, that's the cachability characteristic I meant:  now you have to merge
based on edns-client-ip parameter, rather than more generally.

> How does your HTTP client know that the HTTP proxy isn't adding an

By running it against a server I control?

How do I know it isn't adding it to only *some* servers?  I don't
know. But I wouldn't support standardizing that behavior either.

> first.

As has been pointed out, my use of "proxy" has varied and been
inexact.  My apologies.

> I'd suggest mail clients resolving DKIM TXT records as a more
> realistic example.
>

Freedom Fighter X from territory FOO queries Bad Gov BAR's
servers for ENUM records related to a specific phone number.
Assuming Bad Gov BAR answers using servers its controls,
it gets the IP address or range used to query for the number.

Constructing the SIP path to initiate the call could use entirely
different IPs and a proxy infrastructure outside Bad Gov BAR's
control. You'd probably pay in call quality, but not with your life.

I did not see a limitation in the draft to A/AAAA, and the problem
with identifying a "privacy conscious cache" goes back to the discussion
raised above--how do I know?

> easy-to-implement and easy-to-deploy 95% solution.

It's pretty obvious I don't agree with at least some folks on the requirements.
I think this should be opt-in; that's a non-requirement or too high a deployment
barrier for others.  So it's not 95% of my personal requirements.

regards,

Ted Hardie

---

From: Carlo Contavalli <[email-masked]>
Date: Thu, 8 Apr 2010 01:10:24 +0100

> raised above--how do I know?

Is there anything *now* in the DNS protocol that provides you with any
guarantee that your IP isn't captured or forwarded by other means to
parties you do not want to see it? Eg, how do you know that the
resolver you're using *now* is not forwarding your ip by using a
non-standard protocol extension? or storing it in case law enforcement
agencies ask them? How do you know it's being "privacy conscious"?

I do not think that the lack of a standardized extension decreases the
chances of my ip being forwarded to parties I don't trust against my
will.

If this is something the industry is doing or needs to do, I believe
standardizing it is a way to provide guidelines, better control it,
expose the practice, and increase awareness, even if I don't think
it's a real threat to begin with.

Freedom Fighter X should not use the DNS to begin with, or protect his
DNS queries by other means. There is no way to guarantee that his IP
is not being seen or disclosed to other parties, regardless of
edns-client-ip. If you do not trust your recursive resolver to do the
right thing, all bets are off.

Carlo

---

From: John Payne <[email-masked]>
Date: Wed, 7 Apr 2010 18:28:37 -0400

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

> relative URL's for in-site navigation, and you have to know when and what

Paul... please realize that many people take what you say as completely factual.

You seem to be confusing a particular toolset that I don't think has been in use in about 8 years (an "akamaizer") with the end result of Akamai serving websites.  I can't think of a single instance now that requires relative URLs.  I also would hope that people know when and what they publish with or without CDNs, but that's also not a requirement to use a CDN.

---

From: John Payne <[email-masked]>
Date: Wed, 7 Apr 2010 18:28:26 -0400

> theoretical advantages offered indirectly by the proposal we're discussing.

This proposal closes the "distant recursive DNS" case.  It only makes things better there.

Where DNS and HTTP are deliberately sent via different paths today,  _no_ difference to today.  Some might be better, some might be worse.  Some might see absolutely no difference.  Who cares?  With the popularity of opendns and google public dns, there's instant benefit to many.

> than just "client's IP address".  we should do this right if we're going to

As far as I can tell.... there is no assumption of locality at all, other than proximity.  
Any geolocation, language, etc would be handled at a higher level, _as it is today_.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 8 Apr 2010 10:42:08 -0400

At 15:19 -0700 4/7/10, Ted Hardie wrote:
>It's pretty obvious I don't agree with at least some folks on
>the requirements.  I think this should be opt-in; that's a non-requirement
>or too high a deployment barrier for others.  So it's not 95% of my
>personal requirements.

In the effort to help with the next version of the edns-client-ip 
draft, I am having a hard time understanding why privacy is a 
concern.  Reading the messages I realize that there's a fear that if 
the authority servers know who's asking, then the authority servers 
have a better grasp on who is asking for information.  What I mean by 
"having a hard time understanding" is more a reflection that I think 
the concern, as I am reading it, is unfounded.  I am saying this 
because it could be I'm just not seeing the issue.  And until then I 
wouldn't know what to recommend be included in the draft.

In today's DNS, if you ask for information from a recursive server, 
that server has the ability to record who asked for what at a fine 
level of granularity.  The initiator could use different recursive 
servers to try to "hide" a pattern of access, so one server might not 
see all the queries.  At the authority server, what becomes apparent 
is the IP address of the recursive servers, but at a much lower 
granularity - not each query that is issued but only for queries that 
are cache misses.  If the TTL of an RRset is long, a lot of the end 
queries won't make it to the authority.

There are many factors to consider.  But taking the example of an 
enum query, which identifies an E.164 telephone number that is 
potentially being contacted, what is going on?  There are those that 
propose the TTLs of "enum" records (typically NAPTR) be kept short to 
provide the real-time-iness of the current telephone system.  This 
would mean more cache-misses and therefore more of a reflection of 
actual initiator query activity.  (Are we talking a single initiator 
or multiple?)

Without edns-client-ip, it is still possible to determine the 
recursive servers sending the query, using non-DNS means.  Assuming 
there is legal leverage, an authority could approach/force operators 
to monitor the incoming requests to get closer to the source.  (If 
the operator doesn't cooperate, the authority could simply not 
respond to the recursive server.  But if things are that sinister, 
why doesn't the authority just go after the holder of the telephone 
number and pursue actions there?)  National jurisdictions being what 
they are, one can dream up a lot of spy novel situations - which is 
what makes it hard to quantify the underlying DNS protocol issue at 
hand.

If the situation is not as cat-and-mouse as a political 
cloak-and-dagger mystery, for example, merely trying to capture 
demographic data about shoppers, then you have a situation where the 
recursive cache operator has a competitive advantage over the 
authority server.  Revealing the client IP has to meeting with some 
incentive by the authority server.  (The general lack of this is why 
this is not a general purpose feature.)

If the desire is to hide query patterns even if extreme measures are 
taken, it is still possible to create "reasonable doubt" about the 
actual source via a series of forwarders.  If one is willing to do 
this, then they are also not likely to take advantage of a tailored 
response based on their topology.  (Or have that provided at the 
application management layer.)

My misunderstanding of the privacy concern boils down to - with 
edns-client-ip the authority server will only see the sources that 
cause cache misses from intermediates that are willing to reveal 
where the query came from.  If the intermediate is topologically 
co-located with the client, then there's no need to pass this on, and 
therefore quite useless.  If the intermediate is offering some sort 
of anonymization (wsat? = would scrabble allow that?) then there's no 
incentive to send the edns-client-ip.  Only if the intermediate wants 
to mimic the authority's tailoring service is there incentive to 
reveal something about the query source.  And even then only to a 
fuzzy level of detail (probably never more than a /24 of IPv4 because 
that seems to be the lower limit of what policy carries in an 
exterior gateway protocol.

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

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 8 Apr 2010 11:20:36 -0400

Additionally...

On Apr 8, 2010, at 10:42 AM, Edward Lewis wrote:

> In the effort to help with the next version of the edns-client-ip draft, I am having a hard time understanding why privacy is a concern.  Reading the messages I realize that there's a fear that if the authority servers know who's asking, then the authority servers have a better grasp on who is asking for information.  What I mean by "having a hard time understanding" is more a reflection that I think the concern, as I am reading it, is unfounded.  I am saying this because it could be I'm just not seeing the issue.  And until then I wouldn't know what to recommend be included in the draft.
> 
> In today's DNS, if you ask for information from a recursive server, that server has the ability to record who asked for what at a fine level of granularity.  The initiator could use different recursive servers to try to "hide" a pattern of access, so one server might not see all the queries.  

This is a very poor way to hide a pattern of access anyway.

> My misunderstanding of the privacy concern boils down to - with edns-client-ip the authority server will only see the sources that cause cache misses from intermediates that are willing to reveal where the query came from.  If the intermediate is topologically co-located with the client, then there's no need to pass this on, and therefore quite useless.  If the intermediate is offering some sort of anonymization (wsat? = would scrabble allow that?) then there's no incentive to send the edns-client-ip.  Only if the intermediate wants to mimic the authority's tailoring service is there incentive to reveal something about the query source.  And even then only to a fuzzy level of detail (probably never more than a /24 of IPv4 because that seems to be the lower limit of what policy carries in an exterior gateway protocol.

Additionally, and key, DNS is not used in a vaccume as an information service, but is almost exclusively used as a guideline to actually initiate contact, or as a database lookup after contact has been initiated the other way.  

So even in the E.164 example, a DNS lookup is followed by an actual contact from the initiator to the recipient, so the only privacy leakage occurs when the system running the directory (DNS) does not also have control over the final recipient data.

Thus in nation-state type examples, the nation state can generally get the exact information from the final contact (and if a nation-state adversary is your threat model, you better be using TOR which makes all these issues moot).  

Likewise, for commercial privacy: if you are contacting web service X, who cares that the slash /24 you are using apppears in service-provider X's DNS authority server logs, when your actual IP is in the HTTP logs?

Thus its clear that the ONLY information leakage which can occur, and minor though it is, is when the authority server does NOT have any access to the communication itself.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 08 Apr 2010 16:31:30 +0000

> From: John Payne <[email-masked]>
> Date: Wed, 7 Apr 2010 18:28:37 -0400
> 
> You seem to be confusing a particular toolset that I don't think has been
> in use in about 8 years (an "akamaizer") with the end result of Akamai
> serving websites.  I can't think of a single instance now that requires
> relative URLs.  I also would hope that people know when and what they
> publish with or without CDNs, but that's also not a requirement to use a
> CDN.

i apologize for speaking out-of-date information about akamai's requirements.
john is right, i should have done my homework before posting.

---

From: Ted Hardie <[email-masked]>
Date: Thu, 8 Apr 2010 10:01:20 -0700

Ed,

Please forgive the top posting.  In the text below you are mixing an analysis of
the protocol, the information flow implicit in the query stream, and
your personal take
on whether or not the information is "valuable" for some pretty mixed set of
what "value" might mean.  The discussion to date has covered much of
this ground,
but your posting re-mixes pieces that Paul, David, and I have tried to
pull apart.
That's a bit frustrating.

Since you are interested in helping out with this draft, perhaps you
can start from
the other end.  Why is this proposal of interest to you, and what
benefit do you see
to the DNS?  Maybe if we start back there, we can see other ways to
get to that goal.

regards,

Ted

On Thu, Apr 8, 2010 at 7:42 AM, Edward Lewis <[email-masked]> wrote:
> In the effort to help with the next version of the edns-client-ip draft, I
> am having a hard time understanding why privacy is a concern.  Reading the
> messages I realize that there's a fear that if the authority servers know
> who's asking, then the authority servers have a better grasp on who is
> asking for information.  What I mean by "having a hard time understanding"
> is more a reflection that I think the concern, as I am reading it, is
> unfounded.  I am saying this because it could be I'm just not seeing the
> issue.  And until then I wouldn't know what to recommend be included in the
> draft.
>
> In today's DNS, if you ask for information from a recursive server, that
> server has the ability to record who asked for what at a fine level of
> granularity.  The initiator could use different recursive servers to try to
> "hide" a pattern of access, so one server might not see all the queries.  At
> the authority server, what becomes apparent is the IP address of the
> recursive servers, but at a much lower granularity - not each query that is
> issued but only for queries that are cache misses.  If the TTL of an RRset
> is long, a lot of the end queries won't make it to the authority.
>
> There are many factors to consider.  But taking the example of an enum
> query, which identifies an E.164 telephone number that is potentially being
> contacted, what is going on?  There are those that propose the TTLs of
> "enum" records (typically NAPTR) be kept short to provide the
> real-time-iness of the current telephone system.  This would mean more
> cache-misses and therefore more of a reflection of actual initiator query
> activity.  (Are we talking a single initiator or multiple?)
>
> Without edns-client-ip, it is still possible to determine the recursive
> servers sending the query, using non-DNS means.  Assuming there is legal
> leverage, an authority could approach/force operators to monitor the
> incoming requests to get closer to the source.  (If the operator doesn't
> cooperate, the authority could simply not respond to the recursive server.
>  But if things are that sinister, why doesn't the authority just go after
> the holder of the telephone number and pursue actions there?)  National
> jurisdictions being what they are, one can dream up a lot of spy novel
> situations - which is what makes it hard to quantify the underlying DNS
> protocol issue at hand.
>
> If the situation is not as cat-and-mouse as a political cloak-and-dagger
> mystery, for example, merely trying to capture demographic data about
> shoppers, then you have a situation where the recursive cache operator has a
> competitive advantage over the authority server.  Revealing the client IP
> has to meeting with some incentive by the authority server.  (The general
> lack of this is why this is not a general purpose feature.)
>
> If the desire is to hide query patterns even if extreme measures are taken,
> it is still possible to create "reasonable doubt" about the actual source
> via a series of forwarders.  If one is willing to do this, then they are
> also not likely to take advantage of a tailored response based on their
> topology.  (Or have that provided at the application management layer.)
>
> edns-client-ip the authority server will only see the sources that cause
> cache misses from intermediates that are willing to reveal where the query
> came from.  If the intermediate is topologically co-located with the client,
> then there's no need to pass this on, and therefore quite useless.  If the
> intermediate is offering some sort of anonymization (wsat? = would scrabble
> allow that?) then there's no incentive to send the edns-client-ip.  Only if
> the intermediate wants to mimic the authority's tailoring service is there
> incentive to reveal something about the query source.  And even then only to
> a fuzzy level of detail (probably never more than a /24 of IPv4 because that
> seems to be the lower limit of what policy carries in an exterior gateway
> protocol.
>
> --

---

From: Ted Hardie <[email-masked]>
Date: Thu, 8 Apr 2010 10:04:15 -0700

Hi Nick,

> So even in the E.164 example, a DNS lookup is followed by an actual contact from the initiator to the recipient, so the only privacy leakage occurs when the system running the directory (DNS) does…

It depends entirely on the protocol flow of the application as to
whether or not the
initiated contact leaks any information or not.  With a SIP proxy
infrastructure it
may not (if you are willing to take a hit on poor performance).  With
other proxy
infrastructure it may also avoid this.

> Thus its clear that the ONLY information leakage which can occur, and minor though it is, is when the authority server does NOT have any access to the communication itself.
No, it leaks new information when the communication path from the
initiator is otherwise
not direct--in any case with an application-layer proxy, in other words.

regards,

Ted

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 8 Apr 2010 13:15:16 -0400

> infrastructure it may also avoid this.

You forward the DNS through the same proxy infrastructure, or through another proxy infrastructure!

> not direct--in any case with an application-layer proxy, in other words.

If you are using an application-layer proxy, send the DNS through the same proxy or another proxy.  To not do so defeats much of the purpose of using a proxy if the concern is privacy, no matter what the DNS resolver does, because you are leaking the information to the recursive resolver and the inplicit information from the resolver to the authority!

The "but a proxy" case is IMO, a red herring: our job shouldn't be to protect stupid from very minor threats, when stupid is obviously NOT TRYING TO PROTECT ITSELF (by using the same proxy for DNS as data).

---

From: Edward Lewis <[email-masked]>
Date: Thu, 8 Apr 2010 13:33:39 -0400

>Please forgive the top posting.  In the text below you are mixing an analysis

FWIW, I prefer top posting...

>That's a bit frustrating.

And from that discussion I deduced that the privacy issue is a red herring.

>can start from the other end.

The draft is still an individual draft and I work with some of the 
authors, so I'm talking with them.  That's why I am inquiring about 
the so-called privacy issue.  (As I said, I think it isn't, I'm 
trying to figure out why others think it is and what the implications 
are.)

---

From: Wilmer van der Gaast <[email-masked]>
Date: Thu, 8 Apr 2010 20:39:18 +0100

> The cases where people put their path through pervented proxying should not be a major concern, its VERY rare, and such deliberate perverted cases could instead relay their DNS through the same pat…
Also, IMHO edns-client-ip, if anything, actually improves this situation.

Right now if people have setups like this, it can cause problems with
geo-sensitive DNS authorities. This is not a new problem introduced by
edns-client-ip.

edns-client-ip does, however, allow people to put the IP address from
where subsequent connections will be originated in the option if they
can predict it.

Cheers,

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

---

From: Edward Lewis <[email-masked]>
Date: Fri, 9 Apr 2010 13:23:09 -0400

>but your posting re-mixes pieces that Paul, David, and I have tried to

I am still totally mystified by the concerns labelled as "privacy" 
after trying to identify the above messages.  (As an annoying side 
note - the subject lines haven't been all that useful in identifying 
threads.  To be fair, the messages are wide ranging.)

I'm not a big expert on privacy.  From what I understand the issue is 
that the desire is to limit the amount of personally identifying 
information in an otherwise anonymous interaction.  In a DNS query, 
the identifying information currently is the source IP address and 
port and possibly the question.

The originator of the query (assuming someone who is not advantaged 
by falsifying the source address) will have to reveal the addressing 
information and question to some other entity.  The other entity can 
be a lot of things, including the authority server, but I'm going to 
scope this down to the set of entities that would consider 
edns-client-ip as a feature (which is a much broader scope that 
entities that would make use of it).  The entity scope is now a 
recursive server, notably, one with a cache.

To keep this from being application specific, I'm only going to 
consider a few specific questions related to the adoption of 
edns-client-ip.

- What will an DNS authority server now know (with edns-client-ip) 
that it doesn't know now about the querier?

- What might a cache leak information wise to another querier about 
what it has, specifically, in a way that would identify the original 
querier?

Would that be a sufficient set of questions to cover the "privacy" issue?

1) What does an authority know because of edns-client-ip?

The authority will only see the cache misses, so it is not guaranteed 
to see the frequency of requests nor the set of those sending the 
query (is it one or a botnet's worth of originators?).

One could argue that with low enough TTLs the authority could force 
cache misses and see everything.  But if the authority server is 
performing such manipulation they might as well manipulate the 
targets of the connection attempts.

The percentage chance a query is uniquely identified to an authority 
server could be very small.  If that were the case, then the privacy 
concern would be that anyone was identified at all, not that the 
community of interest was identified.

At this point - I admit I'm not getting the concern.  Is the goal 
blocking of personally identifiable information?  On what scale?  Is 
an IP subnet personally identifying?  Can't a person trying to hide 
tracks use tunneling to avoid detection?  Or work with recursive 
servers that provide source obfuscation?

A side not on the latter, there was once a project that hid the 
accessor from the server via rerouting and tunnelling in a mesh of 
cooperating servers to provide plausible deniability.  I don't know 
if that took off anywhere.  The obfuscation was not just for DNS but 
for any service access.

2) What might a cache leak?

If the cache keeps data "binned" by a gross level network address and 
mask and does not retain the original /32 (v4) or /128 (v6), what 
constitutes personally identifiable information?  This assumes the 
cache is even participating in edns-client-ip.

Idle conjecture: The cache's security is weak, perhaps their are 
other weaknesses in the operator's facility, like the billing machine 
(with credit card numbers) or a staff that is easily socially 
engineered (this is the Albuquerque, Arizona[0] police department and 
you have unpaid parking tickets we will forgive if you tell me ...).

I don't know if you can tie back to a query why a cache has an an 
entry.  And if the network range and mask is determined by the 
authority server, there's no clear indicator that there is personally 
identifiable information there.

Summary -

When one says "privacy" as in "privacy concerns" what is the real 
problem, how is it quantified within the actions of a protocol? 
"Privacy" against what discovery?  Is there a privacy threat model?

What is the concern over allowing a user to opt out of the passing of 
information on?  If the information is not personally identifying, 
does this cross from being privacy to an issue of option negotiation?

Is there some unwritten privacy assumption that one's source IP 
address can only every be used in a certain way?  Is this an 
internet-wide issue which every protocol should be examined to see 
how it uses the layer 3 identifier?  Or is privacy just about 
protecting "personally identifiable information?"

[0] An intentional 'mistake.'

PS - I was thinking about this email some more after writing and 
began to wonder if there's discomfort in the use of any fields of the 
protocol beyond the end-elements.  Is the thought that the client of 
the protocol determines the use of the contents of the message. 
Implicit is an understanding and agreement to the proper conduct of 
the protocol of course.  In this case, it's EDNS0 that is supposed to 
be hop-by-hop but then the use of the client IP is now seen as 
crossing a barrier at the bequest of the server, not the client.  But 
- an IP address is what defines the network...so what is it's scope?

I really don't understand the privacy issue here...
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Michael Graff <[email-masked]>
Date: Fri, 09 Apr 2010 13:14:47 -0500

On 4/9/10 12:23 PM, Edward Lewis wrote:
> information in an otherwise anonymous interaction.  In a DNS query, the
> identifying information currently is the source IP address and port and
> possibly the question.

This is the information that is passed between the client itself and its
recursive resolver.

The auth servers do not see anything more than the question really.

This proposal extends the information from just the query being exposed
to the client's IP address (or so close to it as to not matter.)

All the complaints about "well, you should know you'll leak this
information when you use a web browser anyway" is fair, but the net is
not the web.  I might be trying to find out who is attacking my network
by issuing a dig command, reverse lookup, or I might be sending email.
All of a sudden the root server(s) know I am doing some level of this,
and while it won't happen on each query, over time a fairly good idea of
which network addresses are in use could be collected.

I know there was a proposal to limit it to only the things after the
TLDs, but that still won't help TLDs that have more than one level, like
*.co.uk.

I think the argument about privacy is that who is issuing the query is
no longer just between the client and its ISP, but now between the
client and the world.

--Michael

---

From: John Kristoff <[email-masked]>
Date: Fri, 9 Apr 2010 13:58:18 -0500

On Fri, 9 Apr 2010 13:23:09 -0400

> targets of the connection attempts.

Low TTLs aren't not necessary and won't be reliable.  Using the web
as an example, I'd used wildcards and dynamically generated content.
As you browse to or through my site, you'd be performing lookups on
domain names I generated just for you.  I'd fully expect the web banner
advertisers to do this sort of thing.

> problem, how is it quantified within the actions of a protocol? 

Perhaps it is simply shock at seeing assumptions about the traditional
stub->ISPresolver->authority data flow being challenged?

> I really don't understand the privacy issue here...

You're not paranoid enough?  :-)

John

---

From: Martin Barry <[email-masked]>
Date: Fri, 9 Apr 2010 21:02:42 +0200

$quoted_author = "Michael Graff" ;
> no longer just between the client and its ISP, but now between the

The proposal dictated that it was not the exact IP address but some
enclosing subnet tagged with the appropriate netmask.

Michael, would you still regard such "less accurate" leakage as a privacy
concern?

cheers
Marty

---

From: Edward Lewis <[email-masked]>
Date: Fri, 9 Apr 2010 15:01:59 -0400

>no longer just between the client and its ISP, but now between the

So, first question - why is this a "privacy" problem?

I look at wikipedia for "privacy."  I found this one tidbit:

A word "privacy" is sometimes regarded as untranslatable[2] by linguists.

(I take that to mean it's not something so universally understood.)

The reason I started there is that to me "privacy" involves the 
protection against concealment of personally identifiable 
information.  That isn't the only definition or interpretation as I 
find by casually reading wikipedia's page.

It would help to have some definition of what privacy means in IETF 
protocol engineering - lest this become just a rathole discussion.

Quoting wikipedia -

1 - "The boundaries and content of what is considered private differ 
among cultures and individuals, but share basic common themes."

Is an IP address private data?  What if the address is run through a 
NAT before being routable?  What about randomized IPv6 addresses - 
those where the last 48 bits are not the MAC address but some other 
moving value.

Is an network identifier (net range/mask) private data?

(What is "private data"?  Personally identifiable is what I assume.)

2 - "Privacy is sometimes related to anonymity, the wish to remain 
unnoticed or unidentified in the public realm."

Is this the concern, that loss of anonymity?  Has anonymity ever been 
a goal of the protocol's design?

3 - "Privacy is broader than security and includes the concepts of 
appropriate use and protection of information."

This conflates the definition of privacy with the intent and use of 
the data, not the presence of the data.  In the case of 
edns-client-ip as stated, I would argue that the use to tailor an 
answer is "appropriate use."

All of that is an incomplete analysis by someone who has not spent 
time studying the issue.

The second question - is the issue that the client can't opt-out of 
the dissemination?

If that's the case, then this is solved (at least in the next draft 
as far as I have seen it).  The protocol has in it the opt-out 
option.  When a recursive server gets a query in with a 
edns-client-ip it is forbidden to change the option.  So, to "hide" a 
client could preempt the edns-client-ip by inserting it's own 
"0.0.0.0/0" or v6 equivalent.

Maybe that's the answer to the statement that the client has no 
control ... the control is there ... if you trust the cache to follow 
the protocol ... never mind that it has to follow the protocol to 
send back the right answer.

Still searching for the problem.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 9 Apr 2010 15:04:43 -0400

>You're not paranoid enough?  :-)

Skeptical, sarcastic, cynical, jaded, yes, guilty.

I once was paranoid, now I enjoy feeding it.

---

From: Michael Graff <[email-masked]>
Date: Fri, 09 Apr 2010 14:11:46 -0500

On 4/9/10 2:01 PM, Edward Lewis wrote:
> If that's the case, then this is solved (at least in the next draft as
> far as I have seen it).  The protocol has in it the opt-out option. 
> When a recursive server gets a query in with a edns-client-ip it is
> forbidden to change the option.  So, to "hide" a client could preempt
> the edns-client-ip by inserting it's own "0.0.0.0/0" or v6 equivalent.

So, then all the work we're doing is only useful until every DNS client
out there does this by default.  Or until someone releases a "privacy
enhancer" for windows that sets this option by default.  Or a home
gateway vendor decides to add one on the user's behalf.

One thing about privacy is that it's not for you to decide what I
consider private, it's what I find important to be kept private, for I
in {all people}.

I personally feel it is all too easy to collect online habits already.
Adding another method in the most integral application protocol the
network uses seems bad to me.

--Michael

---

From: Michael Graff <[email-masked]>
Date: Fri, 09 Apr 2010 14:17:03 -0500

> Michael, would you still regard such "less accurate" leakage as a privacy

I seem to remember a study a while back that said anyone in the USA
could be identified 80% of the time with only three bits of personal
information.

http://www.citeulike.org/user/burd/article/5822736

So, given three bits of information is all that is needed, and an IP
address is assumed to be a locality identifier here, a subnet is just as
leaky as an IP address at some point.

So yea, I don't think a subnet is sufficient to lessen my concerns.

--Michael

---

From: Edward Lewis <[email-masked]>
Date: Fri, 9 Apr 2010 15:56:18 -0400

>gateway vendor decides to add one on the user's behalf.

Rathole alert - changing the question after the answer.

>consider private, it's what I find important to be kept private, for I

And I'm asked if I'm paranoid.

>network uses seems bad to me.

"Too easy" is subjective.  I think this concern is the most unfounded 
here because the recursive server operator is already able to collect 
this information and use it or sell it.  Especially in the use case 
envisioned for the proposal as written.  (There's mention on the list 
of other cases too.)

There are many ways to hide your tracks on the Internet.  If you want 
to enhance your privacy, use them.  We keep saying the Internet was 
designed to be insecure so you have to protect yourself.  Is there 
now a declaration that the Internet is insecure but anonymous?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Doug Barton <[email-masked]>
Date: Fri, 09 Apr 2010 13:31:03 -0700

> And I'm asked if I'm paranoid.

There is no de facto paranoia in Michael's statement, in either the
cultural nor the clinical sense; and for the record I agree with his
sentiment.

> this information and use it or sell it. 

But that's a "risk" that is already built into the status quo.

> There are many ways to hide your tracks on the Internet.  If you want to
> enhance your privacy, use them. 

But this proposal dramatically reduces the effectiveness of existing
solutions by adding yet another way for my Personally Identifiable
Information (PII) to leak out into legal and administrative domains that
I have no direct relationship with.

To take one simple and obvious example, if I visit a site at *.yahoo.com
I may have no problem with them having my PII, in fact some of their
services require it. That's my decision. But Yahoo! uses Akamai for
their CDN, and I have not chosen to have a relationship with them. In
fact, the average Internet user would not even know who/what Akamai is,
or why their information is being sent there.

I am actually sympathetic to the concept of "DNS tricks" for CDNs, but
this is going too far.

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: David Ulevitch <[email-masked]>
Date: Fri, 9 Apr 2010 14:19:19 -0700

> I am actually sympathetic to the concept of "DNS tricks" for CDNs, but

I find this surprising.  To the best of my knowledge, every major ISP
(except perhaps Comcast and ATT) is selling or sharing their DNS data
with third-parties.  Nothing in this draft can even remotely be
construed as worse than that practice.  Nor does anything in this
proposal create an information leakage worse than that.  Nor does it
"endorse" or support such behavior.  And, of course, I'm in full
support of a section of the draft discussing these issues and privacy
concerns.

This proposal is deliberately designed for and written by DNS
providers that users OPT-IN to using.  By that very definition, these
users are asking for a service from a company they are establishing a
relationship with.  I can't think of anything less privacy-aware and
privacy-sensitive than that.

-David

---

From: Doug Barton <[email-masked]>
Date: Fri, 09 Apr 2010 14:27:33 -0700

On 04/09/10 14:19, David Ulevitch wrote:
>> I am actually sympathetic to the concept of "DNS tricks" for CDNs, 
>> but this is going too far.
> 
> I find this surprising.

I find a lot of things in this thread surprising.

> To the best of my knowledge, every major ISP (except perhaps Comcast 
> and ATT) is selling or sharing their DNS data with third-parties.

Aside from the obvious EANECDOTAL aspect of this statement, even taking
it at face value what you're saying is that if I have a concern about
privacy of my DNS query data I currently have a choice of using
providers that don't share it. The proposal removes that choice from me.

> Nothing in this draft can even remotely be construed as worse than 
> that practice.  Nor does anything in this proposal create an 
> information leakage worse than that.  Nor does it "endorse" or 
> support such behavior.  And, of course, I'm in full support of a 
> section of the draft discussing these issues and privacy concerns.

I'm sorry, there is not enough rationality in this paragraph for me to
even respond to.

> providers that users OPT-IN to using. 

So the same providers that are currently getting information from their
users "for free" and selling it without their users' knowledge are now
going to put development dollars into an opt-out system that will then
cost them money? Even assuming that signaling mechanisms for the client
side were developed and deployed (which is not likely)? (And yes, I
understand that the proposal says opt-in, but that's just smoke and
mirrors.)

Doug

--

---

From: Michael Graff <[email-masked]>
Date: Fri, 09 Apr 2010 16:37:47 -0500

> privacy-sensitive than that.

Users do NOT opt-in, they opt-out.  An ISP will enable this and all
their users suddenly have their subnets exposed to auth servers.  A user
must insert something into each query to opt-out, and I'm certain that
won't be happening before this would be deployed.

Or am I misunderstanding this?

--Michael

---

From: Matthew Dempsky <[email-masked]>
Date: Fri, 9 Apr 2010 14:37:39 -0700

> providers that don't share it. The proposal removes that choice from me.

Uh, how exactly?  Providers that currently choose not to share your IP
address will surely continue to offer ways for you to prevent your IP
address from being exposed even after this option is standardized.

---

From: Matthew Dempsky <[email-masked]>
Date: Fri, 9 Apr 2010 14:42:48 -0700

> Or am I misunderstanding this?

OpenDNS, Comcast, and possibly others offer out of band configuration
options for controlling what DNS experience they get on a
per-IP-address basis.  This doesn't require any DNS client software
updates.

---

From: Michael Graff <[email-masked]>
Date: Fri, 09 Apr 2010 17:06:20 -0500

> per-IP-address basis.  This doesn't require any DNS client software

What you describe is an opt-out, not an opt-in.  That said...

This sounds like the "DNS servers would do..." argument when someone
really means "BIND 9" does.  Except than there are a whole lot more
players than there are in the DNS server software arena.

What two ISPs do means just that:  two ISPs might decide that allowing
users to opt out of this is a reasonable thing to do.  It doesn't cover
the rest of the planet.

For this to really be an opt-out, the client needs to insert the opt-out
records.  After all, my laptop isn't always at home, but I'd like my
privacy to follow me, not remain at home while I'm out.

--Michael

---

From: Matthew Dempsky <[email-masked]>
Date: Fri, 9 Apr 2010 15:29:42 -0700

On Fri, Apr 9, 2010 at 3:06 PM, Michael Graff <[email-masked]> wrote:
> What you describe is an opt-out, not an opt-in.

I was addressing your concern that DNS client software has to be
updated first.  The issue of whether it's an opt-out or opt-in simply
depends on the default provisioning.

> users to opt out of this is a reasonable thing to do.  It doesn't cover

That's exactly my point.  The Internet is heterogenous.  But there's
this moral panic rising over this draft because people seem to think
that once there's a standard way to do something that people are in
practice already doing, that it will *require* *everyone* to start
doing it.

> privacy to follow me, not remain at home while I'm out.

If you want to maintain privacy on your laptop, you'll need to make
sure you setup a VPN connection everywhere you go, and in which case,
it's the same thing.  You provision your VPS provider to respect your
privacy, and then it doesn't matter where you are.

---

From: Paul Vixie <[email-masked]>
Date: Sat, 10 Apr 2010 00:30:04 +0000

> Date: Fri, 9 Apr 2010 14:19:19 -0700
> This proposal is deliberately designed for and written by DNS providers
> that users OPT-IN to using.  By that very definition, these users are
> asking for a service from a company they are establishing a relationship
> with.  I can't think of anything less privacy-aware and privacy-sensitive
> than that.

so nxdomain-remapping policy-routing udp/53-thieving hotels could not add
this new OPT blob and have it contain PII that authority servers would see?

please point me to the specific design elements which would prevent this?

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 9 Apr 2010 20:00:22 -0700

> this new OPT blob and have it contain PII that authority servers would see?

Why would such a hotel bother?  If the information has value, sell it directly.

---

From: Paul Vixie <[email-masked]>
Date: Sat, 10 Apr 2010 04:14:28 +0000

> Date: Fri, 9 Apr 2010 20:00:22 -0700
> 

that's not an answer to my question.  i would like an answer to my question.

however, in answer to your sidebar, most harm (by volume, from the big bang
through now and likely continuing until heat death) has been, is, and will be
accidental.

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 9 Apr 2010 21:35:40 -0700

> that's not an answer to my question.  i would like an answer to my question.

Yes it IS an answer, because the question you raise is really nonsense as an objection.

You can just as easily ask "is there anything that prevents the hotel from simply selling the complete feed of my DNS requests to the highest bidder?" and, well, the answer is no.

The question is WHAT information would the hotel be exfiltrating that isn't already inadvertantly exfiltrated anyway simply based on RESOLVER IP, and WHY they would bother with uncompensated exfiltration.

---

From: David Ulevitch <[email-masked]>
Date: Fri, 9 Apr 2010 23:04:04 -0700

On Apr 9, 2010, at 5:30 PM, Paul Vixie <[email-masked]> wrote:

>> providers

Being a standard neither requires nor precludes them from doing  
whatever it is they do. Surely you've been on one of their networks  
before. They do all kinds of crazy things, standards or no standards.

> please point me to the specific design elements which would prevent  

It doesn't exist, nor should it. They are not the audience for this  
document, though they are certainly welcome to follow it. If they do,  
users will probably have a better Internet experience.

An aside -- all the comments from people who think this is some win  
for targeting advertising clearly do not work in that industry. Those  
people already buy and sell cookies across domains and tons of other  
far more useful things than seeing a client source IP in a DNS request  
would offer. But this is not relevent to those who feel client-ip is  
enabling potential privacy violations where one previously did not  
exist, I guess.

-David

Sent from my iPhone

---

From: Paul Vixie <[email-masked]>
Date: Sat, 10 Apr 2010 06:05:55 +0000

> From: Paul Vixie <[email-masked]>
> Date: Sat, 10 Apr 2010 00:30:04 +0000

hey, that's me!

> please point me to the specific design elements which would prevent this?

it's been asserted that my question is out of order, which if true means
that the opt-in nature of the underlying proposal is nonfalsifiable.  so as
an answer to doug barton's objection (quoted below), david ulevitch's
message (quoted above) is nonsequitur.  therefore: rewind, restart from
positions, which means right here:

> I am actually sympathetic to the concept of "DNS tricks" for CDNs, but

i'm not sympathetic to "DNS tricks" for reasons i published elsewhere a few
months ago (http://queue.acm.org/detail.cfm?id=1647302, "What DNS Is Not"),
but i agree in spirit with doug that this proposal would make things worse.

---

From: Doug Barton <[email-masked]>
Date: Sat, 10 Apr 2010 12:37:09 -0700

On 04/09/10 23:04, David Ulevitch wrote:
> Being a standard neither requires nor precludes them from doing whatever
> it is they do.

Giving the people who want to monetize DNS query information a standard
way to do this will make this easier, and will contribute to more, not
less of the same.

> Surely you've been on one of their networks before. They
> do all kinds of crazy things, standards or no standards.
> 
>>
> An aside -- all the comments from people who think this is some win for
> targeting advertising clearly do not work in that industry.

I was the DNS administrator for Yahoo! in the 2001-2003 time frame when
we were (arguably) the largest Internet company in the world, and
UNarguably an industry leader in targeted advertising. Before becoming
the DNS administrator I worked as a developer, including web tools for
our customers that required me to learn and develop against our cookie
API. I could go on, but my point is yes, I know a little something about
the business.

> Those people
> already buy and sell cookies across domains and tons of other far more
> useful things than seeing a client source IP in a DNS request would
> offer.

All of which have mitigation strategies that I can easily use, along
with the ability to decide that if a site wants more information than I
am comfortable providing I can ultimately choose not to continue my
experience with them. However, I can't even GET to the site to make that
decision without DNS. And of course, as others have pointed out, the
Internet contains more than just the WWW.

> But this is not relevent to those who feel client-ip is enabling
> potential privacy violations where one previously did not exist, I guess.

Voila!  :)

Doug

--

---

From: Colm MacCárthaigh <[email-masked]>
Date: Sat, 10 Apr 2010 13:47:48 -0700

> way to do this will make this easier, and will contribute to more, not

By monetizing DNS query information, are we talking about;

   A) Encouraging more CDN-like DNS trickery

or

   B) Making it easier for intermediaries to sell targeted advertising

or maybe both. I'm losing track. We've discussed A a lot, I'm less
clear about how B works, can someone provide a worked-out example?

-- 
Colm

---

From: Donald Eastlake <[email-masked]>
Date: Sat, 10 Apr 2010 20:47:57 -0400

I believe that the vast majority of users would be delighted to trade
a slightly fuzzed version of their IP address for better web
performance. As I don't see that trade, in the context to today's
Internet, as having some big hidden downside for them. The very small
minority that would care about this are almost exactly the people who
will understand what's going on and take appropriate measures to opt
out. So I do not see a significant privacy problem with this proposal.

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

---

From: Ted Hardie <[email-masked]>
Date: Mon, 12 Apr 2010 18:15:19 +0900

On Sun, Apr 11, 2010 at 9:47 AM, Donald Eastlake <[email-masked]> wrote:
> performance.

And the DNS knows my query is for a web page how?  What is the proposed
client API to turn this on and off on a granular basis so that I can
get that better
performance for my web search but not reveal what hotel I'm in when doing
the DNS queries that enable my VoIP calls?

 As I don't see that trade, in the context to today's
> out. So I do not see a significant privacy problem with this proposal.

Presuming that the minority that want privacy will have tools to get it
simply does not follow my understanding of the situation.  It certainly
runs counter the understanding that has dominated GEOPRIV's concerns
about location privacy.

While they may not come to our meetings, there are people who want
privacy and do not know how to turn on and off specific EDNS options
in their host stacks.  I believe there has already been a pointer given
to the situation in Australia when a group investigating suicide had to be
given lessons to avoid the Australian censorship, but here's another
in case my memory is faulty:
http://www.smh.com.au/technology/technology-news/elderly-learn-to-beat-euthanasia-blacklist-20100405-rn6i.html

This is a bit different and , yeah, it might be possible to teach this
once someone
who cares gens up friendly tools for it, but let's not pretend that
this work is either
already done or that only tech-savvy folks have privacy concerns.

The helpful hotel DNS that starts to do this to make google run faster for its
visitors will turn it on and leave it on for everyone.  If it weren't a corking
pain to configure this on a per-site basis, nobody would be asking for
a standard
here.  That means every protocol, every destination.

Your prediction may differ, but that's mine, and I don't like the results either
in impact to the infrastructure or in privacy.

regards,

Ted

PS.  I'm massively jet-lagged, and my coherence has no doubt suffered;
my apologies if so.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 12 Apr 2010 10:32:34 -0400

At 18:15 +0900 4/12/10, Ted Hardie wrote:

>And the DNS knows my query is for a web page how?

Because you DNS-queried for www.example.com and the host responding 
to the applicable IP addresses only has HTTP ports open there.  THe 
use case here is a DNS server administration that has unified it's 
DNS and server set up for a particular purpose.

>What is the proposed

Remember this is not general purpose DNS.

If you are worried about someone discovering your hotel...there are 
probably other concerns (like the enemy planting a mole at the 
registration desk).  Ok, that's a cheap shot at the problem case, but 
otherwise I can't really relate to the situation.

>Your prediction may differ, but that's mine, and I don't like the results
>either in impact to the infrastructure or in privacy.

I'm struggling with myself to keep the privacy discussion DNS and 
protocol focused.  I can't really.  I keep thinking to myself, the 
issue here is that the IP address information, even obfuscated, is 
being used to help properly address the following traffic.  I would 
term this acceptable use.  But that isn't a technical determination.

IP addresses are sent through the routing system, across router hops. 
Anyone's specific address is revealed net-wide.  This is the 
motivation for what I understand to be obfuscated or randomized IPv6 
addressing.  In the details of the edns-client-ip proposal, this 
activity is still possible.

To me it seems that the objection in this thread is related to the 
fear that the transmitted information might be misused, that is, used 
for some purpose other than directing IP traffic.  There was a time 
in my career that I replied, in a similar situation, "I'm not a 
priest, I cannot engineer according to fear."  I'll use that again 
because I don't know what to say.  It's hard to respond to nebulous 
criticisms.

There's no denying that the address information is being passed 
beyond where it is now.  The new dissemination is to enable 
optimizations at the server-end.  Whether this is traffic 
localization, load shifting, or whatever else, it is still related to 
the movement of traffic.

Can disseminated information be used for any purpose?  Sure.  Can we 
stop this?  No, probably not.  Can the objection be stated in a way 
that can be adequately addressed through a careful design?  That's 
the ideal, but I still can't imagine the issue in purely technical 
terms.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 12 Apr 2010 07:56:00 -0700

Overall, I'm really not getting this privacy rat-hole.  

a)  Information largely equivalent to this is already being exported when first-party resolvers are used, after all, this is why stupid DNS tricks work.  [1]

Especially items like the hotel examples: identifying the resolver may often identify the actual hotel anyway!

b)  DNS is not the end protocol.  Why do you use DNS?  Because your system wants to interact with another host.  

DNS is about name->address mappings, and if you look up something in the DNS, it is because you are either going to be contacting that host, or have been contacted by that host (DNSRBLs).

Just as DNSSEC is pointless for securing name->address mappings from any adversary other than the recursive resolver itself, DNS privacy of your subnet identity from the remote authority is almost completely pointless if you are then going to contact the remote host! [2]

c)  client-ip doesn't provide a good monetary channel.  

If you want to monetize your DNS stream as a resolver, don't leak a little data to authorities, capture the entire resolver stream and sell/use that.  EG, after all, data mining the raw query stream to the resolver is the only monetization source that Google Public DNS has.  And nothing in the DNS protocol prevents this, and client-ip doesn't affect this in any way.

d)  This has no effect on censorship.  If anything, by making third-party resolvers MORE attractive to use, this prevents censorship from being implemented in the resolver (by mandating to the ISP a list of "naughty domains"), forcing it to be instead on the wire.

e)  Unless a privacy problem is within two orders of magnitude of what Google Analytics does, its a non-issue.  Really.  Look in your cookie store for __utma.  Each one of those sites is a cookie where Google tracks everything you do.  In addition to everything on DoubleClick...  

Even if mosquitos have malaria (they don't), its far less of a concern than a severed femoral artery.

The question is really simple, and why I care about this:

Should third party resolution services be able to produce the same quality of results that users get from using their ISP's recursive resolver? [3]

If yes, third party resolvers need to export an abstract of the client IP.  Period.  

If no, say so: "I don't want third party resolvers to be as effective as ISP provided resolvers".

I wonder if a simple name change, and one which actually describes this better, would be good.  How about "edns-client-subnet" instead?

[1] And these tricks are important: like em, or hate em: having the user get to a server 50ms closer will save ~200ms+ on a page-load, as those RTTs add up for handshakes etc.

[2] The only exception is if those running the authority are not related to those running the system itself.

[3] I'm not actually a fan of such services based on the behavior of the principle services (OpenDNS and its wildcarding and MITM games, Google Public DNS for its privacy-compromising design), but that personal.  I still want competition in this space, to limit ISP-related DNS abuses.

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 12 Apr 2010 11:36:12 -0400

Hi Ted,

> the DNS queries that enable my VoIP calls?

I would say that the vast majority of users would be delighted to
trade a slightly fuzzed version of their IP address on all DNS queries
for an improvement in their average network service where that
improvement would be most significant for web and/or higher bandwidth
streaming media.

> runs counter the understanding that has dominated GEOPRIV's concerns

The following comment of might be a bit tangental to your remark
immediately above but isn't GEOPRIV about physical location and the
draft we are discussing about network topology location? No analogy is
perfect, but it feels to me more like the leakage of topological
location through a routing protocol than it does to, say, leakage of
physical location via cell phone triangulation/GPS...

> http://www.smh.com.au/technology/technology-news/elderly-learn-to-beat-euthanasia-blacklist-20100405-rn6i.html

Seems like a great example of a case where those concerned and
technically knowledgeable are providing techniques to those who are
concerned but not as technically knowledgeable. That's what I would
expect in the case of this proposed standard. Although as far as I
know no one is proposing to make it illegal to by-pass the client IP
reporting mechanism :-)

> already done or that only tech-savvy folks have privacy concerns.

I never claimed tools to opt-out of this as yet unadopted standard
already exist. There will be a set of people particularly worried
about privacy and a set of people with the technical capability of
developing such tools. I believe there will be some positive
correlation between these sets and may have exaggerated that
correlation in my initial remarks but I didn't believe the sets are
identical or that only tech-savvy folks have privacy concerns.

> here.  That means every protocol, every destination.

Most likely yes.

>From the infrastructure point of view, this seems to trade a higher
burden on DNS authoritative and caching servers for faster service to
the user and less burden on the network pipes. Given the continuing
fall in the cost of computation and memory, this seems like a
reasonable trade-off from the infrastructure point of view.

On privacy, I'm willing to accept that it has a small negative effect.
But, given that there is currently no way to opt out of similar, if
typically more localized, exploitation of query source information by
DNS servers and that this would provide such an opt-out mechanism as
well as real performance improvements for those who do not opt-out, I
think it will provide an overall benefit.

> PS.  I'm massively jet-lagged, and my coherence has no doubt suffered;

Sorry about that. You seem pretty coherent to me.

Thanks,
Donald

---

From: Paul Vixie <[email-masked]>
Date: Mon, 12 Apr 2010 17:01:23 +0000

> Date: Mon, 12 Apr 2010 11:36:12 -0400
> From: Donald Eastlake <[email-masked]>
> 
> I would say that the vast majority of users would be delighted to trade a
> slightly fuzzed version of their IP address on all DNS queries for an
> improvement in their average network service where that improvement would
> be most significant for web and/or higher bandwidth streaming media.

i don't doubt this.  and yet, this is a rather sweeping change to the
internet's architecture, where is the IAB's position statement on it?

and also yet, the average citizen trades privacy for convenience every
day, but in other non-internet contexts there are regulators who can
say "hold on a minute, that's very sexy but the implications are dire."
shall we say that none of that thinking applies to the freewheeling
internet, and let the buyers simply beware?

---

From: Paul Vixie <[email-masked]>
Date: Mon, 12 Apr 2010 17:18:19 +0000

> From: "George Barwood" <[email-masked]>
> Date: Mon, 12 Apr 2010 17:49:18 +0100
> 
> Concealing the identity of clients is not a design goal of the current
> DNS standard, nor should it be.

it is however an emergent property of the current system, on which many
users may be relying.  this should not be changed without investigation.

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 12 Apr 2010 13:46:09 -0400

Hi Paul,

> internet's architecture, where is the IAB's position statement on it?

It does not seem like a sweeping change to the Internet's architecture
to me. At least no more sweeping than a change from distance-vector
routing, which gives visibility only to summary reports from adjacent
nodes, to link-state routing, which gives a global view of
connectivity throughout the routing domain. Is there an IAB position
statement giving an "IAB position" or even commenting on the improved
performance but decreased node privacy caused by link-state routing? I
don't think so and I do not expect the IAB to produce a position
statement on the particular question we are discussing here, although
they are certainly welcome to produce one if they want.

> internet, and let the buyers simply beware?

That is why, in my initial statement, my observation of customer
willingness was coupled with a statement that I did not see "dire"
implications.

Thanks,
Donald

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 12 Apr 2010 10:49:15 -0700

> users may be relying.  this should not be changed without investigation.

If indeed this was an emergent property of the current system, Akamai tricks wouldn't exist.

Rather, for first party resolvers, with pretty good precision, you get a good idea of where the querying clients are in network-topology space.  

Thus the emergent property is actually the opposite of what you assert: the IP of the recursive resolver tells the authorities where the clients are located in the network.

THIS is the emergent property we should be concerned with: should only those clients who use their ISP's resolver benefit from this property?

---

From: Edward Lewis <[email-masked]>
Date: Mon, 12 Apr 2010 14:03:53 -0400

>users may be relying.  this should not be changed without investigation.

I don't think I agree with that concealing activity is an emerging 
property of the system, nor does a statement including "users may be 
relying" confer any sense of authority to any claim that the 
Internet's architecture is leaning one way or another.

It is true that we don't have a book on privacy, there's no "level 
playing field."  Namedroppers is not the place to write one up 
either, we aren't the experts on the topic. Without that book, a set 
of guidelines and requirements on privacy, or any topic for that 
matter, we are just going to rat hole.

Rat-hole activities just lead to stagnation.  Nothing will ever get 
done in the engineering sense.  Consensus will be impossible to 
achieve because at any moment, some one might say "I have privacy 
concerns."

This is a problem for the chairs - will issues, like privacy, that 
have historically not been discussed on the list be able to block the 
publication of extensions?  I agree that a concern that is shown to 
be well-founded may appear at any time and needs to be addressed. 
But what about concerns that aren't shown to be a direct relation to 
the protocol (architecture)?

In summary of this thread (privacy/edns-client-ip) what I see is this 
round of questions:

One side: Does the option forward on info that is currently not forwarded?
The other side: Yes, what is the problem with that?

(I am trying very hard to find a problem.  I can't.  Not even with 
caller ID as a telephone analogy.)

Users want to be concealed?  Show me that.  And show me what they 
want to be concealed from.  (Are you concealing spammers?  Phishers? 
I agree they want anonymity.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Paul Vixie <[email-masked]>
Date: Mon, 12 Apr 2010 18:48:45 +0000

> Date: Mon, 12 Apr 2010 10:49:15 -0700
> 

that's nonsequitur.  akamai needs to guess the location but not the identity,
and in my opinion those tricks are just marketing smoke/mirrors in any case.

this endless back and forth isn't illuminative and won't be conclusive.  i'm
going to lay off the point by point replies for a while until i can get my
thoughts organized well enough for a position-blogpost somewhere.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 12 Apr 2010 19:04:44 +0000

> Date: Mon, 12 Apr 2010 18:48:45 +0000
> ...
> this endless back and forth isn't illuminative and won't be conclusive.
> i'm going to lay off the point by point replies for a while until i can
> get my thoughts organized well enough for a position-blogpost somewhere.

forgot to say:

...and, i recommend that others do likewise.

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 12 Apr 2010 12:22:14 -0700

> and in my opinion those tricks are just marketing smoke/mirrors in any case.

No its not a non-sequiter:  You are implying that location IS privacy-sensitive, since edns-client-subnet [1] exports effectively equivalent location information.

That is exactly the point: to have third party resolvers able to effectively convey the same location information that first party resolvers already do by dint of the resolver's IP address.

[1]  which is really what it is, not client's IP but subnet with mask, there is never a reason to do it more precise than /24, and most resolvers would probably want even coarser to save cache and RTTs.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 12 Apr 2010 19:39:27 +0000

> Date: Mon, 12 Apr 2010 12:22:14 -0700
> ...
> That is exactly the point: to have third party resolvers able to
> effectively convey the same location information that first party
> resolvers already do by dint of the resolver's IP address.

a client who cares about this can use a resolver that shares its IP path.
however, if a client doesn't know or care about this, it won't be as easy
for distant/centralized resolvers to avoid masking the supposed benefits of
Stupid DNS Tricks by CDN's.

seems like akamai and opendns built things that can't work, not even on a
theoretical basis, because IP paths are so often not the same between a web
browser and an opendns resolver, and now they're asking to ratchet up the
complexity level of the whole industry in order to support these
innovations.

that in turn looks like an architectural change to the internet itself,
which i'd like to see debated on that basis rather than just incrementally
added out here in a working group.

the architecture at present assumes a couple of local resolvers per network
and that clients there will use those.  we could achieve the exposure of
web browser IP location to CDNs at DNS query time just by telling opendns
to install proxies on every customer subnet.  or we could tell CDN providers
that they should use HTTP redirects rather than incoherent DNS to achieve
their marketed benefits.

it also seems like this is primarily a web thing not an internet thing, and
that W3C would most likely love to add some kind of XMLRPC lookup mechanism
with a UDP transport so that a web browser could stop asking internet level
questions like "what's the address of web server XYZ" and start asking web
level questions like "if my IP address is X and my language is Y and my GPS
is Z then what are the preferred servers, in order, that i should use to
reach URI Q?"  opendns and akamai could innovate quite well and without any
controversy as web companies within a framework like this.

DNS basically works today, but not without a lot of effort by implementors
and operators of infrastructure.  making it more complicated and less
predictable in order to support a single application (web browsing) is not
something we should do mindlessly or incrementally or lightly.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Mon, 12 Apr 2010 12:54:48 -0700

On Mon, Apr 12, 2010 at 11:48 AM, Paul Vixie <[email-masked]> wrote:>>
> and in my opinion those tricks are just marketing smoke/mirrors in any case.

What kind of experiment and data would convince you otherwise? For
example, would it be sufficient to measure the TCP/80 RTT from say,
100 internet locations from some DNS-tricks based CDNs?

As a control, this data could be compared to the TCP/53 RTT to port 53
at one of the well-deployed anycast root servers.

And as a further refinement, we could then force those 100 locations
to use a public recursive DNS offering, and compare the results again.

The utility of the tricks need not be based on opinions, let's
establish their true effect.

> thoughts organized well enough for a position-blogpost somewhere.

Respectfully; I do not agree with this suggestion. We are supposed to
be engineering here, and should concentrate on establishing facts and
making our decisions data-driven. Further ideological debate and
positioning is not useful. Many here do not agree with the position
outlined in the ACMqueue article, months after the fact, so
unfortunately evidence does not suggest that this will be a productive
line of endeavor.

Personally I think it is most useful to state objections explicitly,
and to give examples or evidence as to how they can be demonstrated.

All of that said, it feels like we need a summary of where we are, so I'll try.

It seems that at at the core of all this is simply an ideologically
disagreement about what DNS actually is, and what it should be. One
camp feels that the DNS has become a lookup and mapping system. And
also that one useful property of such a system is to be able to
route/map users to their nearest network endpoints. Their argument is
that it benefits end user experience, and makes the internet "better"
to some. It is also a source of profit to some who have decided to
operate DNS in this way.

The other camp feels that DNS is a database (and in fact RFC1035 talks
about the DNS in these terms), and that modulo the effects of caching,
that it is about presenting a consistent view of data - and that to do
anything else is "lying". In real terms, this camp feels that the
effects of this "lying" are a shifting of burden - both operational
and economic - to innocent middlemen without their consent, and that
this is harmful.

In ideological and sensibility terms, the conversation seems to be;
"We shouldn't afford DNS tricks any stamp of approval, it's a harmful
precedent that encourages lecherous entrepreneurship at the expense of
bystanders" Vs "We should recognize how the real internet is working,
irrespective of how good/evil some of that is, and try to engineer it
better".

It feels like the privacy-arguments are merely a proxy for this core
disagreement. Do what I'm wondering is - do we have any engineering
methods at are disposal to arrive at a middle-ground, or consensus.

For example, would another DNS option be useful that explicitly
declares the answer section as "dynamic", aka "not a database" aka
"lying" (I guess an evil bit for DNS) be useful?

If there are no such methods for resolving the core disagreement, then
it seems that we should ignore it, and move on to quantifying the
measurable and real effects of the proposal and what benefit or harm
it may cause.

-- 
Colm

---

From: Paul Vixie <[email-masked]>
Date: Mon, 12 Apr 2010 19:59:36 +0000

> Date: Mon, 12 Apr 2010 12:54:48 -0700
> From: Colm MacCárthaigh <[email-masked]>
> 
> example, would it be sufficient to measure the TCP/80 RTT from say, 100
> internet locations from some DNS-tricks based CDNs?

that would not convince me, nope.  a representative sample of services
and consumers would be orders of magnitude larger than those size numbers.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Mon, 12 Apr 2010 13:08:54 -0700

On Mon, Apr 12, 2010 at 12:39 PM, Paul Vixie <[email-masked]> wrote
> complexity level of the whole industry in order to support these

Just to be very explicit about this; my understanding of the proposal
is that it is not being considered as a mandatory option, and probably
not even the standards track. In other words, using the above
examples, only opendns and akamai would have to implement the option
and deal with the complexity fallout.

An ordinary client, using public DNS, or openDNS, or whoever, need do
nothing special and the net effect to them is that they may get
different answers depending on the IP block they query from.
Inconsistent answers towards clients is a pattern DNS has exhibited
since day one (due to caching) - so it certainly seems well-tested.

If a network operator that forwards to public DNS, or openDNS, chooses
to implement the option, then they will get extra complexity - but
clearly they are opting in. And again, the behaviour towards clients
regresses to the same situation as my previous paragraph.

Can you give some concrete examples of what "ratchet up the complexity
level of the whole industry" corresponds to?

-- 
Colm

---

From: Jim Reid <[email-masked]>
Date: Mon, 12 Apr 2010 21:13:07 +0100

> something we should do mindlessly or incrementally or lightly.

+1,000

---

From: Colm MacCárthaigh <[email-masked]>
Date: Mon, 12 Apr 2010 13:15:16 -0700

> and consumers would be orders of magnitude larger than those size numbers.

Can you propose a specific experiment that could be run practically?

-- 
Colm

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 12 Apr 2010 13:27:59 -0700

> Stupid DNS Tricks by CDN's.

Except the point is that the CDN tricks work because users generally DO use network-local resolvers.  This architecture works!

> that they should use HTTP redirects rather than incoherent DNS to achieve

This straw-man doesn't work because it is LATENCY that matters.  If you go through an HTTP 302 redirect or similar, you add 2 more round trips.  The goal of all of this is to greatly improve the latency, and the way to do that is to limit DNS to one RTT, and have everything else go to a very close server.  Adding 100ms+ for a 302 redirect kills any savings you get by going to a "close" server vs just one on the same part of the continent.

Why isn't everything over SSL when you go to Google?  Its not the crypto (even public key is cheap these days, and you can always throw hardware at it), but SSL adds RTTs on setup.

There is an overall desire to make web pages load in 200ms or less, from when the user clicks on the link.  And one of the key tenants for that to work is for DNS to be able to deliver the IP of a "topologically close" server.  And this works when you use the ISPs' resolvers.  

It is only when you use third party resolvers that this assumption breaks down, and since it is a very small minority that currently uses third party resolvers, AND this behavior is a barrier to third-party resolvers becoming more popular, how can you not class this as a bug?

> controversy as web companies within a framework like this.

So you don't want DNS?  You want a competing system, specifically for server discovery, and full deployment in order to be useful?

This seems a silly straw man argument.  

Almost as silly as requiring any viable third-party resolver to attain CDN-level deployment of resolvers WITH multihoming (since resolvers are found by IP, not name).

> something we should do mindlessly or incrementally or lightly.

Client-subnet passes your complaints here:  It only makes things more complicated for those who actually would benefit from using it.  

As long as existing authority implementations properly behave when they receive unknown EDNS options, its a complete non-issue: only those who directly benefit from this would bother to implement it, so the resolvers for Google, OpenDNS, etc, and the authorities which are already doing CDN tricks.  Nobody else would be affected.

Unless you are saying authorities are going to blow up and catch on fire if you throw unknown EDNS options their way.

So in the end, pick your poison:

#1: Allow third-party resolvers to gain the same benefits that first-party resolvers have by adding a mechanism for them to express client subnet to the domain authorities, information that first-party resolvers implicitly reveal already and such authorities already rely on.

or

#2: Decide that third-party resolvers MUST remain at a competitive disadvantage to first party resolvers.

Because option 3, making these DNS tricks go away, or asserting that they aren't useful, ain't gonna happen.

---

From: Matthew Dempsky <[email-masked]>
Date: Mon, 12 Apr 2010 13:56:19 -0700

> and consumers would be orders of magnitude larger than those size numbers.

One of the fundamental theorems of statistics is that statistical
power depends only on sample size, not population size.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 12 Apr 2010 21:18:16 +0000

> Date: Mon, 12 Apr 2010 13:08:54 -0700

if akamai and opendns are doing it, then who among their competitors would
not also be doing it?  this is not as simple as "opt-in" or "opt-out", even
if we were sure that intermediate caches weren't going to strip off the
client's opt-out client-ip 0.0.0.0 blob and put in an accurate one, either
by malicious intent or just by nonmalicious operator/implementor error.

but apart from that i had another thought at lunch today.  if we're adding
to the lookup tuple, then in dnssec terms don't we also have to add to the
thing that rrsig is denoted by and/or the thing that rrsig covers?  that is,
if we're going to have N:N>1 rrsets having the same <name,class,type> at the
same time visible by the same intermediate cache and also by mobile clients
within a single TTL and signature validity period, then won't we also have
N:N>1 RRSIGs at the same owner name and having the same type-covered?

---

From: Paul Vixie <[email-masked]>
Date: Mon, 12 Apr 2010 21:20:45 +0000

> Date: Mon, 12 Apr 2010 13:15:16 -0700

as a lot of people in a position to say so authoritatively and based on
personal experience can tell you, i'm no scientist.  i'd like to believe
that there's an empirical test whose inputs would be less burdensome than
those of an actual working implementation of stupid dns tricks -- that is,
less than complete knowledge.  but if so i don't know what it is.  weav?

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 12 Apr 2010 14:51:27 -0700

> by malicious intent or just by nonmalicious operator/implementor error.

Anyone who cares about privacy BETTER NOT be using OpenDNS, Google Public DNS, or similar services.

These services are specifically NOT privacy preserving, and anyone who considers using them in this way would be misusing them.

And you WANT the competitors to be doing this:  Without something standard, you get pairwise agreements and provider A can do better than provider B.  Standards prevent this.

> N:N>1 RRSIGs at the same owner name and having the same type-covered?

If you think of client-subnet as representing a scope, you only have 1 signed RRSET per scope in the cache, which would make this not-a-problem.  You wouldn't be able to DNSSEC-protect that the value is in the proper scope, but since the scope is an optimization, not an absolute, this would, IMO, be OK.  

If you wanted to add scope restrictions in the signature of the RRSET, you'd need a new RTYPE rather than an EDNS option in replies, which conveys that this RRSET is valid for this client subnet only.

> i'd like to believe

A thought comes to mind:  

Time the time it takes to load a sample web image OR an error message with a cache-busting NONCE for a known-akamai'ed site from the client, and from the same site when queried through OpenDNS, UltraDNS, and Google Public DNS.

For a known-failure, this should be DNS time (measure separately), and 2x RTT to the Akamai'ed site (make the request with connection-close to terminate), which will allow one to see how the different DNS providers + akamai behave and if (and how much) it really makes a difference.

You'd probably want to do it in signed java, but it MIGHT be doable in Javascript.  Its actually on the list of "hmm, might be interesting".

---

From: Paul Vixie <[email-masked]>
Date: Mon, 12 Apr 2010 22:06:33 +0000

> Date: Mon, 12 Apr 2010 14:51:27 -0700
> 
> > but apart from that i had another thought at lunch today.  if we're
> > adding to the lookup tuple, then in dnssec terms don't we also have to
> > add to the thing that rrsig is denoted by and/or the thing that rrsig
> > covers?  that is, if we're going to have N:N>1 rrsets having the same
> > <name,class,type> at the same time visible by the same intermediate
> > cache and also by mobile clients within a single TTL and signature
> > validity period, then won't we also have N:N>1 RRSIGs at the same owner
> > name and having the same type-covered?
> 
> If you think of client-subnet as representing a scope, you only have 1
> signed RRSET per scope in the cache, which would make this not-a-problem.

that covers the caching intermediary, with the understanding that the RRSIG
has to be treated as having scope.  what about a mobile client whose scope
can change within a TTL and signature validity period?  are you assuming
that mobile clients will always set edns-client-ip and will scope any
rrsets they cache, along with any signatures?  if so then i wonder what
happens if the client doesn't set edns-client-ip and its caching intermediary
changes as a result of mobility.  are you expecting the (unscoped) underlying
rrset and its (therefore also unscoped) covering RRSIG to expire in tandem?

> You wouldn't be able to DNSSEC-protect that the value is in the proper
> scope, but since the scope is an optimization, not an absolute, this
> would, IMO, be OK.
> 
> If you wanted to add scope restrictions in the signature of the RRSET,
> you'd need a new RTYPE rather than an EDNS option in replies, which
> conveys that this RRSET is valid for this client subnet only.

that sounds right to me.

> > ... that is, less than complete knowledge.  but if so i don't know what
> > it is.  weav?
> 
> A thought comes to mind:  
> 
> Time the time it takes to load a sample web image OR an error message
> with a cache-busting NONCE for a known-akamai'ed site from the client,
> and from the same site when queried through OpenDNS, UltraDNS, and Google
> Public DNS.
> 
> For a known-failure, this should be DNS time (measure separately), and 2x
> RTT to the Akamai'ed site (make the request with connection-close to
> terminate), which will allow one to see how the different DNS providers +
> akamai behave and if (and how much) it really makes a difference.
> 
> You'd probably want to do it in signed java, but it MIGHT be doable in
> Javascript.  Its actually on the list of "hmm, might be interesting".

that's good news.

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 12 Apr 2010 15:20:13 -0700

> You'd probably want to do it in signed java, but it MIGHT be doable in Javascript.  Its actually on the list of "hmm, might be interesting".

Just as a single data point, where I would actually expect everything to work well for third party resolvers (given my bay area location):  

I did this for a321.g.akamai.net (which is the name used for amongst other things, the IRS website).

Local resolver:  Gets me 198.189.255.73, ~3ms latency.  
Traceroute shows to cenic.net in oakland to an akamai node.

OpenDNS: Gets me 72.246.53.9, ~3ms latency.
Traceroute shows to cenic.net in oakland to two akamai hops.  Slightly different but the same effective path

Google Public DNS: Gets me to 96.17.8.97, ~20ms latency.
Traceroute shows to Transitrail to seattle, WA.

That 20ms will add up on a real web visit however, as 3-4 RTTs are burned for various things: SYN, page load, image page load, script loads, etc...

---

From: John Payne <[email-masked]>
Date: Tue, 13 Apr 2010 08:37:15 -0400

> something we should do mindlessly or incrementally or lightly.

CDNs do a lot more than web stuff these days.
"Stupid DNS tricks" have use cases (some more general than others) in  
almost every application that uses DNS (and some that didn't before  
the application users wanted to make use of CDNs).

Where are the naysayers expecting this option to be deployed? I  
suspect you have a different answer to those for it.

I'm deliberately not taking a position on this draft, although it  
might seem that I am because the only corrections I have made are to  
comments from the naysayers.

ISPs have little incentive to enable this on their recursors - it will  
increase their complexity and cache misses whereas the client location  
granularity is "good enough" without this.

Lying-port53-theiving hotels are already doing whatever they want with  
your dns stream. This makes no difference to them.

I would have to imagine that Google public dns is using the client IP  
to construct answers for Google server names. Isn't it only fair that  
other recursive operators and other authorative operators get a chance  
to play in a standardized field?

I'm less certain about whether authorative operators will want to  
enable this option as it does enable a potential information leak on  
their side., and cherry picking recursive operators to enable this for  
adds additional complexity and non-technical pain.

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 13 Apr 2010 07:53:07 -0700

> rrset and its (therefore also unscoped) covering RRSIG to expire in tandem?

Who cares?  

edns-client-ip doesn't affect the correctness of the validation: the whole point of the CDN tricks is the set of valid answers is VASTLY larger than could be returned in a DNS record, and the authority makes a decision as to which subset to give as an answer to a particular request.  In the DNSSEC world, it happens to have a matching RRSIG for that subset.

But the "wrong" node is still a valid answer, and will still validate, its just a less efficient answer.

And mobile clients ALWAYS have this problem with CDN'ed tricks: a less efficient IP when they move, and this doesn't change it, and thus the reason why many CDNs use very short TTLs (probably too short actually)

And its actually not THAT bad a problem: the #1 key for CDN being good is physical geography: getting a server in Oakland is vastly better than one in LA or Seattle.  The #2 is then network provider, but that matters less as the CDN nodes may be in the ISPs, but they are in the close-to-the-exchange-points side of the ISPs.

WHat are the odds that a client moves >100 miles before the timeout expires.

As for setting edns-client-ip, there really is no point in the client actually setting it in almost all cases: it is the resolver which sets it based on the IP the request came from.  The only reason a client should set it is because it is

a)  Sending DNS through a different proxy than the rest of the traffic (which is a Bad Thing to do anyway, but edns-client-ip supports)

b)  The client is paranoid and wants to disable this feature altogether

c)  An intermediate cache that is not on the network path for the rest of the traffic, and is not a recursive resolver, wants to set it when forwarding to the actual recursive resolver. (a very rare case)

Apart from these exceptions, clients should neither know nor care about this EDNS option.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 13 Apr 2010 15:47:19 +0000

> Date: Tue, 13 Apr 2010 07:53:07 -0700
> ...
> What are the odds that a client moves >100 miles before the timeout expires.

non-negligible.

anyway, if this means clients have to know how to recognize this or else face
unexpected/unexplainable errors, then the document should say that.

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 13 Apr 2010 09:16:13 -0700

> unexpected/unexplainable errors, then the document should say that.

But as I said, the ONLY thing the client sees as a result of moving is they still use a "sub par" (20ms higher latency) node.  So the client doesn't actually face an error, just mildly degraded performance.

---

From: David Ulevitch <[email-masked]>
Date: Tue, 13 Apr 2010 12:21:20 -0700

> But as I said, the ONLY thing the client sees as a result of moving is they still use a "sub par" (20ms higher latency) node.  So the client doesn't actually face an error, just mildly degraded per…

We can be more precise in describing the impact of this case (and "sub
par" is a misnomer) -- The nomadic client's quality of service could
really only be identical or better than if they had instead received a
non-specific response ("dns trick" response).  The worst case here is
not "sub par" -- it's just "par." :-)

-David

---

From: Doug Barton <[email-masked]>
Date: Tue, 13 Apr 2010 17:31:03 -0700

M) This draft proposes changing the DNS protocol to benefit
latency-sensitive applications.
m) Not all applications that use DNS are latency-sensitive.
C) Latency-sensitive applications should use application layer
mitigation strategies, and this draft should not be adopted.

Doug

--

---

From: Paul Vixie <[email-masked]>
Date: Wed, 14 Apr 2010 01:13:38 +0000

> Date: Tue, 13 Apr 2010 17:31:03 -0700
> From: Doug Barton <[email-masked]>
> 

+1 on this, though i still think there are better reasons for nonadoption.

---

From: Matthew Dempsky <[email-masked]>
Date: Tue, 13 Apr 2010 18:19:02 -0700

> latency-sensitive applications.

The draft adds an *option* to the DNS protocol.  The great thing about
options is you don't have to implement them.

---

From: Doug Barton <[email-masked]>
Date: Tue, 13 Apr 2010 18:29:44 -0700

On 4/13/2010 6:19 PM, Matthew Dempsky wrote:
> The draft adds an *option* to the DNS protocol.

Even setting aside the other concerns I've already raised about this
"option," the fact that it is "optional" doesn't change my argument.

--

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 13 Apr 2010 18:35:06 -0700

> +1 on this, though i still think there are better reasons for nonadoption.

Almost no applications currently existing that use DNS benefit from DNSSEC, do we want to use that as an argument?

Additionally, as I explained, the latency mitigation strategies can't be done at the application layer (redirects eliminate the latency savings), and at this point, these DNS tricks are well established and do actually seem to work well for those who stick with their ISP's DNS resolver.

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 13 Apr 2010 22:19:04 -0400

Hi Doug,

> m) Not all applications that use DNS are latency-sensitive.

So? I don't see why you would think anything can be deduced from the above
two statements. Protocols are changed all the time, particularly when the
change is in the form of adding a backward compatible extension or option,
for the benefit of only some users of the protocol. You have to weigh the
various present and future costs and benefits of the change to be able to
decide if it is a net benefit.

> mitigation strategies, and this draft should not be adopted.

Your point "C" above is an opinion. Seems very general and is presented with
no supporting facts or arguments (certainly I don't consider your points M
and m to be an argument in favor of C), but you are welcome to your opinion.

Doug

Thanks,
Donald

---

From: Paul Vixie <[email-masked]>
Date: Wed, 14 Apr 2010 04:57:28 +0000

> Date: Tue, 13 Apr 2010 18:19:02 -0700
> From: Matthew Dempsky <[email-masked]>
> 

that's not true.  i'm not calling you a liar, i am sure you believe this.
but it's just not true, especially in the case of a stupid-dns-tricks option.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 14 Apr 2010 05:04:51 +0000

> Date: Tue, 13 Apr 2010 18:35:06 -0700
> 
> Almost no applications currently existing that use DNS benefit from
> DNSSEC, do we want to use that as an argument?

you're saying there could be a new breed of new applications in orbit
waiting for a chance to land, which will benefit from latency-optimized dns
incoherency?  can you give us a ferinstance?  (in supposedly parallel case
you pointed to, i'd like to replace the x509 CA system with dnssec-signed
records, but even without that, the ability to be sure the nameserver i'm
talking to really is authoritative and that the mx i'm processing really
is the real one will eventually lower my insurance rates.)

> Additionally, as I explained, the latency mitigation strategies can't be
> done at the application layer (redirects eliminate the latency savings),

did you not know about permanent redirects?  that's how ibm websphere
works.  perhaps if it's not beneficial you should notify them that you
think they are selling snake oil?  (yes, there's web client-to-server
optimization in the world that isn't based on dns incoherency.)

> and at this point, these DNS tricks are well established and do actually
> seem to work well for those who stick with their ISP's DNS resolver.

you have a very high onus of proof barrier to overcome before that statement
will be generally accepted beyond those who won't be fired for buying akamai.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Tue, 13 Apr 2010 23:27:46 -0700

> optimization in the world that isn't based on dns incoherency.)

Can you provide some references explaining this technique? I'd
consider myself an experienced HTTP implementer (Apache httpd, if that
counts) and know of no HTTP-level technique, using redirects or
otherwise, that can rival the latency optimisations capable today at
DNS level.

Permanent redirects are URI specific,  rather than domain specific,
and have non-trivial interactions with caches.

Even in the ideal case, let's say we minimise the surface area to a
single portal url;

 http://myexampleportal.com/

and a HTTP request to it then 301 redirects to a new domain which is
network-locality dependent, say;

  301 -> http://new-york.myexampleportal.com/

and all embedded URLs are relative, and so on, so that subsequent
links stick to the same new domain. There are still some clear
problems;

  1. Obviously the first request must incur a latency penalty to get
the redirect in the first place.
  2. Such redirects are, as the name suggests, permanent. When you add
more destination network sites - what do you do? How do you tell the
clients that have cached the redirect? And temporary redirects - which
are generally not cached at all - are obviously even worse.
  3. The burden of caching is thinly spread across browsers and
proxies, and is not particularly efficient.

> will be generally accepted beyond those who won't be fired for buying akamai.

I again will repeat my suggestion; can you describe an experiment that
can be practically
run, or data that would be sufficient, to demonstrate to you that such
tricks do or do not definitively seem to work. What would your burden
of evidence look like?

If you can commit to an experimental protocol, then this barrier may
be overcome relatively trivially with data.

-- 
Colm

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 14 Apr 2010 05:37:21 -0700

> proxies, and is not particularly efficient.

4.  It exports visible URLs, which people will bookmark, and which may need to be redirected when mobile clients move.

> be overcome relatively trivially with data.

One can actually see the effect with a simple test for at least their own case.

Ping www.bing.com (a heavily akamaized' site)
Ping the results returned for www.bing.com when fetched through google public DNS instead (8.8.8.8).

EG, I just saw 30 ms for the result returned by my ISP's resolver (comcast), 90ms for Google public DNS!

Even just a 20ms difference in latency is compounded, as a typical web interaction will need several RTTs.  In this case, it was 60ms.

Same results apply for www.yahoo.com (40ms vs 100 ms, where the lookup through the ISP's resolver puts me to a san jose yahoo cloud (although the peering point with as6453 is down in LA) while the lookup through Google Public DNS will route my packets to a washington yahoo cloud, but through level 1 peering point so down to LA first!).  

Yahoo doesn't use Akamai for this, but just uses Stupid DNS Tricks for selecting the right subcloud.

This doesn't apply to Google, which is sending all my packets to a texas server irregardless, and therefore www.google.com is 70ms for both cases.

This may just be one datapoint, mind you, but this is exactly why people push stuff towards the edge or to at least many-geographic distribution and use stupid DNS tricks to ensure that the user gets to the right one: 50ms counts for something in the world where the resulting interactions will have several RTTs worth of latency.

And so why should someone want to use Google Public DNS, which will cause significant sites to slow down measurably on interactivity?