Subject: Re: [dnsext] Re: I-D ACTION:draft-vandergaast-edns-client-ip-00.txt

From: Ondřej Surý <[email-masked]>
Date: Mon, 01 Feb 2010 15:25:05 +0100

I am replying to several mails at once, since some of them address my 
concerns after reading whole draft.

On 28.1.2010 00:56, Wilmer van der Gaast wrote:
> Hello everyone,
>
> I spoke to Olafur about this idea in Hiroshima last year. I'm afraid
> the deadline for Anaheim already passed, but we hope we can discuss it
> on-line in the meantime and decide if it should become a WG item in
> Maastricht later this year.
>
> To summarize the I-D: It specifies an EDNS0 option that carries IP
> address information (by default only the first 24 bits to preserve
> privacy) of the user that triggered a DNS resolution. This should
> allow authoritative nameservers that give geo-targeted responses to be
> more accurate, even in cases where the resolver and its users aren't
> close to each other. To preserve the ability to cache such responses
> efficiently, the option in the response can indicate which exact
> subnet it should be cached for.
>
> Comments are more than welcome.

#1: There should be a way how to ask recursive resolver if he has set 
edns-client-ip on query or not, so end client knows if authoritative 
server knows his IP or not. (let's call it stalk flag)

On 28.1.2010 20:02, Nicholas Weaver wrote:
 >> it's not worth a global upgrade to DNS in its current form.
 >
 > It can be done WITHOUT a global upgrade: you can do it with JUST
 > upgrades to the recursive resolvers and authorities desiring such
 > behavior, see my note on fallbacks from the resolver point of view.

No you can't.  Since all end users would loose privacy from day zero, 
since this proposal is opt-out, not opt-in.  Therefore you need to do a 
global upgrade.

On 29.1.2010 12:32, Stephane Bortzmeyer wrote:
 > 2) A more ambitious one (may be too ambitious), to have an EDNS option
 > code "Client info", with sub-codes and various fields (and a registry
 > at IANA to register these fields) to carry absolutely everything from
 > the desktop client to the authoritative name server. IP address
 > information would then be just a special case.

I like this proposal, you can then set country to CZ, or language to 
"cs" as opt-in (same as in the browser).  I would just hate if my 
resolver starts to send my IP address to authoritative DNS without 
asking me.

Ondrej
-- 
  Ondřej Surý
  vedoucí výzkumu/R&D manager
  -------------------------------------------
  CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
  Americka 23, 120 00 Praha 2, Czech Republic
  mailto:[email-masked]    http://nic.cz/
  tel:+420.222745110       fax:+420.222745112
  -------------------------------------------

---

From: Ondřej Surý <[email-masked]>
Date: Mon, 01 Feb 2010 15:33:09 +0100

On 28.1.2010 21:19, Nicholas Weaver wrote:
> The client has ALREADY given up the privacy to the third party DNS resolver, the additional privacy leakage thereafter would be trivial.

I strongly disagree with this statement.  You can have all sorts of 
agreements with third party DNS resolver provider, including privacy 
agreement, etc.  This is one-to-one relationship.  On the other hand 
giving your IP address (or netblock) to random third party authoritative 
DNS providers is a different thing in my view, since you give your IP 
address/netblock to every-typo-you-make authoritative DNS server.

Ondrej

---

From: Martin Barry <[email-masked]>
Date: Tue, 2 Feb 2010 01:57:46 +1100

$quoted_author = "Ondřej Surý" ;
> >The client has ALREADY given up the privacy to the third party DNS
> >resolver, the additional privacy leakage thereafter would be trivial.
> 
> giving your IP address (or netblock) to random third party
> authoritative DNS providers is a different thing in my view, since
> you give your IP address/netblock to every-typo-you-make
> authoritative DNS server.

I'm not sure I understand this concern. 

A DNS request is usually followed by a connection from an application.

Given that the edns-client-ip option in the draft would apply a netmask,
surely that is providing less information to the service operator than the
subsequent connection to their service.

cheers
Marty

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 1 Feb 2010 16:17:21 +0100

On Tue, Feb 02, 2010 at 01:57:46AM +1100,
 Martin Barry <[email-masked]> wrote 

> I'm not sure I understand this concern. 

Then you did not read the whole thread:

From: Stephane Bortzmeyer <[email-masked]>
To: Alex Bligh <[email-masked]>
Cc: [email-masked]
Date: Fri, 29 Jan 2010 12:38:13 +0100

This would lose a lot of privacy since the IP address of the "desktop"
client would be transmitted in full, not only to the HTTP server but
also to middlemen, the authoritative servers of the root, the TLD,
etc.

The draft has a provision for this (section 4.1) but it is just a MAY
and does not blend well with the general zone cut rules.

Also, the HTTP request may be through a proxy, too, so you cannot even
say that the HTTP server would know the address.

---

From: Carlo Contavalli <[email-masked]>
Date: Mon, 1 Feb 2010 15:29:39 +0000

On Mon, Feb 1, 2010 at 2:25 PM, Ondřej Surý <[email-masked]> wrote:
> No you can't.  Since all end users would loose privacy from day zero, since
> this proposal is opt-out, not opt-in.  Therefore you need to do a global
> upgrade.

Define "from day zero"? recursive resolvers do not have to implement
edns-client-ip, and they do not have to turn it on. They CAN, if they
want, and the hope is that they eventually WILL when it brings
advantages to their users. And it'll take time for each one of them to
eventually decide they want to enable the option.

It is opt-in from the recursive-resolver point of view. It is opt-out
from the end client point of view. But again, we are defining a
*protocol*, a means for two computers to exchange data with each
other, not a policy.

> opt-in (same as in the browser).  I would just hate if my resolver starts to
> send my IP address to authoritative DNS without asking me.
Eg, what's preventing recursive resolvers from forwarding your IP
address now? the lack of protocol support? or a contract/privacy
statement with their users? if IETF does not allow a protocol to do
so, will they NOT forward your IP address? and again, we're not even
talking about the full IP address, and in most cases you just connect
to the server right after doing the lookup.

It's similar to when you use a proxy: will it include a
X-Forwarded-For header? or not? how do you know it is? how do you know
it won't include the header in the future? how do you know they are
not forwarding your data by some other means? is this ground to say
that X-Forwarded-For should not exist? is this a problem at the
protocol layer?

Carlo

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 1 Feb 2010 07:36:04 -0800

On Feb 1, 2010, at 6:25 AM, Ondřej Surý wrote:
> #1: There should be a way how to ask recursive resolver if he has set edns-client-ip on query or not, so end client knows if authoritative server knows his IP or not. (let's call it stalk flag)
> 
> 
> No you can't.  Since all end users would loose privacy from day zero, since this proposal is opt-out, not opt-in.  Therefore you need to do a global upgrade.

I still don't get what your obsession is here:  DNS is already horrible from a privacy perspective, and third party resolvers make it worse:

OpenDNS specifically keep IP adresses for two days, and aggregate information beyond it.

Google Public DNS is roughly the same, and Google's public DNS is specifically FOR aggregate discovery of information.  Third party DNS costs money, and the ONLY money Google makes from Public DNS is as the result of data mining information.

If you want privacy, you DO NOT USE THIRD PARTY DNS!

And there is no real benefit for network-provided DNS to use this feature.

The leakage to upstream authorities unrelated to the final name in this draft is primarily through the design decision of DNS where the whole query is sent to the upstream authority (and typos etc).

Except in the case of third party resolvers, the upstream authorities and typo authorities is going to effectively get this level of information anyway (because of the direct DNS resolver identity tends to convey most of this outside the 3rd party resolver case, after all, thats WHY this draft is proposed!), and you're assuming this information doesn't cache more (so the upstream authorities don't see most of this).

DNS is specifically used so the end system can talk to the end site, so leakage from the end user to the end authority (and in most cases, the typo authority when it doesn't NXDOMAIN, and how many typos nxdomain these days?) is a complete nonissue.

Basically, if you want privacy of your IP, you don't do normal DNS, you HAVE to use the same mechanism for DNS that you use to provide the same privacy of your IP for your final traffic or some other mechanism.  

EG, route the request through your web proxy or an open proxy.  

Some 3%+ of NATs out there we tested will proxy external DNS requests (and a few of those even have a full recursive resolver), so route your request through THEM.  

Or Tor.  Or the squid proxy you're using for your HTTP traffic, or....

The existing DNS infrastructure would be so bad by your query (after all, the goal is to basically put third party DNS on the same footing as first-party DNS, which puts it on the same privacy footprint!) that you need to add significant privacy preservation to the DNS architecture before you should consider this a threat.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 1 Feb 2010 08:04:25 -0800

At 1:57 AM +1100 2/2/10, Martin Barry wrote:
>$quoted_author = "OndÞej Sur˜" ;
>>

This assumes that they system that is making the DNS request is the one that is about to make the connection. That is the common, but not universal, case.

--Paul Hoffman, Director
--VPN Consortium

---

From: John Payne <[email-masked]>
Date: Fri, 29 Jan 2010 10:51:27 -0500

On Jan 29, 2010, at 8:05 AM, Roy Arends wrote:

> Webserver now knows the clients IP address (10.0.0.2), issues a redirect toB8AAAQ.localized.google.com 

For whatever reasons... that does not fly in the real world.   
It's hard enough getting content providers[1] used to a redirect from http://example.com/ to http://www.example.com/

[1] I am only emphasizing that there is a distinction between content provider and CDN.  Given the confusion over language localization I feel it's necessary to point out that content providers are the ones who own and create the content.... CDNs deliver the content.  Only in corner cases are they the same company.

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 1 Feb 2010 08:39:06 -0800

> It's hard enough getting content providers[1] used to a redirect from http://example.com/ to http://www.example.com/

Additionally, in many contexts, such redirects may not be applicable:

a)  Not everything is HTTP or HTTPS and supports such clean redirections.

b)  Exporting user-visible URLs like that is ugly.  (we do it on Netalyzr for transparency & debugging, but its ugly)

c)  HTTPs is very fussy on names in many cases.

---

From: Ted Hardie <[email-masked]>
Date: Mon, 1 Feb 2010 09:44:57 -0800

Howdy,

> a)  Not everything is HTTP or HTTPS and supports such clean redirections.
And this is one of the clearest point in this whole debate:  CDNs serve one
sort of application, which has a host of other methods in play (redirects,
content negotiation, an UPGRADE mechanism to change the security characteristics
of the channel).   Many other applications do not have any of these or use
fundamentally different approaches (store-and-forward protocols, for example,
are pretty unlikely to use a redirect-style approach).

Are we expecting the client's interaction with the DNS to be different on an
application basis here?  Specifically, do we expect the DNS query to look
different when the browser makes a request than when the mail stack does?
How realistic is that, really, without the browser maintaining its own stack?
Isn't it more likely that this will be turned on or off globally?  If
it does vary, what
does that mean for intermediate caching?  Does
this create yet another pressure to reduce cache times?

On a slightly different point, I think Stephane's point on the prevalence of
tunnels in Mobile IP situations is being lost here--we not only have the case
of proxy/tunnels configured for specific applications, but the MIP tunnels which
may be in play here--and that hits a lot of mobile clients that I fear are not
captured in netalyzr data.

regards,

Ted Hardie

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 1 Feb 2010 10:45:18 -0800

> are pretty unlikely to use a redirect-style approach).

Here's a concrete example, lets take imap.google.com (latency matters for IMAP, bigtime...)

Do a query through a random open DNS proxy in Finland, you get:
;; ANSWER SECTION:
imap.gmail.com. 		A       74.125.43.109

Do it through a random open DNS proxy in australia you ge:
imap.gmail.com.			CNAME   gmail-imap.l.google.com.
gmail-imap.l.google.com. 	A       74.125.39.109

Do it through new zeland you get:
imap.gmail.com. 		CNAME   gmail-imap.l.google.com.
gmail-imap.l.google.com.	A       74.125.95.109

Do it through my local DNS settings you get:
imap.gmail.com.			CNAME   gmail-imap.l.google.com.
gmail-imap.l.google.com		A       72.14.221.111
gmail-imap.l.google.com		A       72.14.221.109

(Just from a couple of random DNS proxies)

So its clear that DNS-based network localization is being used for services beyond HTTP already.  Do we want such localizations to still work well when the user is using a 3rd party DNS resolver?

> this create yet another pressure to reduce cache times?

The net result would probably be the opposite:  If you know that an entry will only be cached for requests from a subrange, you can use a longer, rather than shorter TTL.

> captured in netalyzr data.

a:  We don't have web browsers in phones (no java support for iPhone, Blackberry etc), but we DO have plenty of data for web browsers on PCs through wide-area connections.

b:  The purpose is NETWORK identification, so "Customer is 'west coast verizon wireless' " is, in the end, what the authority is trying to infer.  The proxy is still going to be topologically close to the IP address in terms of network behavior and thats what you want.

---

From: Ted Hardie <[email-masked]>
Date: Mon, 1 Feb 2010 11:09:38 -0800

In-line below.

> Here's a concrete example, lets take imap.google.com (latency matters for IMAP, bigtime...)

IMAP is not one of the store-and-forward bits of the email architecture;
SMTP would be.  But the core question comes back to:  how does the
DNS stack know that this application is one for which localization will
be desirable, given that this is a decision made by the authoritative
server?  Do you expect this to be opted-into for every query, or only
for some?

> The net result would probably be the opposite:  If you know that an entry will only be cached for requests from a subrange, you can use a longer, rather than shorter TTL.

You don't actually know that--you're providing a response based on the subrange,
but depending on the liveness of your load balancing and the caching
implementation
you could get a wide variety of results.  If I previously provided a
single response
based on the IP address of the querying server and now provide one based on
the subrange being served, I might choose to lower the TTL to 0 in order to make
sure that each subrange query is served "fresh", rather than from the cache.
Otherwise, I have to trust that the cache is maintaining multiple entries on the
subrange basis.  You want to set a bit for that too?

> a:  We don't have web browsers in phones (no java support for iPhone, Blackberry etc), but we DO have plenty of data for web browsers on PCs through wide-area connections.

And those tend to be nomadic, rather than using Mobile IP to deal with
visited network issues.  Any phone afflicted by (er, using) IMS or the
"visitied network" approach will have two IPs--the one associated with
MIP tunnel
and a local IP in the actual serving network.  It's not uncommon to source
some or all DNS queries from the tunnel interface, because of the joys of
split DNS needed to reach home network resources.  This ID would prefer
them to come from the local IP address for this localization to work--but that
means somehow passing a lot of data to the client on which queries should
go where using what source.

Coherence ain't just elegant, it's easier.  I recognize that there is value to
the CDN approach, but the complications here (and the privacy implications)
aren't trivial.  Doing this may be well past the 80/20 line for DNS-based
localization.

Regards,

Ted Hardie

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 1 Feb 2010 11:49:08 -0800

> server?  Do you expect this to be opted-into for every query, or only

I would expect EVERY query from third party resolvers ONLY: network-provider and user-provided resolvers don't need this, they already export enough information for the authorities to decide based on resolver IP.

And thus the only systems which would need changing are third party resolvers and authorities which desire the ability to act on this information.  No other changes are needed.

ANd I chose IMAP rather than SMTP and IMAP is more important for this than SMTP for DNS games: its a user-interactive application (unlike SMTP which is bulk delivery so latency doesn't matter so much), thats not HTTP and does not support HTTP style redirects, showing how these DNS tricks are

a)  Used across more applications than just web traffic

b)  Used in ways where web-style redirects can't work

Thus the "do it in the app layer" crowd are, unfortunatly wrong, you can't do it in the app layer in important cases, even if you ARE willing to allow ugly URLs to escape into user-visibility for web traffic.

Oh, and you get this for SMTP too:
Me:
gmail-smtp-in.l.google.com. 	A       209.85.222.96

uk:
gmail-smtp-in.l.google.com. 	A       209.85.229.27

Australia:
gmail-smtp-in.l.google.com.	A       209.85.223.62

Singapore:
gmail-smtp-in.l.google.com. 	A       74.125.79.27

> subrange basis.  You want to set a bit for that too?

A cache which is requesting with this enabled has already said it caches per subrange, thats why the netmask is in there in both ways, it says from the resolver -> authority "The guy is somewhere in this part of the network", and authority -> resolver "you can cache it for this part of the network".  That the request was made at all states that the resolver understands not all cache entries are valid for all queriers.

> aren't trivial.  Doing this may be well past the 80/20 line for DNS-based

Coherence is dead.  Opposing this draft won't bring it back.  The choices are either:

a)  Support incoherence for 3rd party resolvers in the protocol.

b)  Don't support incoherence for 3rd party resolvers and wonder why they continue to suck compared with first-party resolvers which will still have proper incoherence support.

Call me firmly in camp a:  I'm not a fan of OpenDNS or Google Public DNS, but for those who use it, I want the users to have the best user experience, and its clear that controlled incoherence in DNS has become a key part of "good user experience".

If you are in camp B, please explain why ensuring that OpenDNS, Google Public DNS, etc are at a significant disadvantage in terms of quality of results is a good thing, when there exists a proposed change which ONLY effects the third party resolvers and those authorities that want incoherent results.

And DNS privacy is a delusion:  DNS leaks so much information already in the current infrastructure that anyone who actually cares about DNS privacy has to take special measures: special measures which would not be affected by this proposal.  Special measures that, in particular, exclude the use of third party resolver services.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 1 Feb 2010 15:41:51 -0500

At 11:09 -0800 2/1/10, Ted Hardie wrote:

>how does the
...
>Coherence ain't just elegant, it's easier.

One of the aspects of this that is missing is that the authority 
server is in on the game and, yes, the incoherency does provide a 
benefit.  This is not the same as wild card redirection, which is 
where the notion "but the DNS doesn't know why you are asking" creeps 
in.  And yes, coherency is easier, but that isn't a weighted factor 
in this application.

Let's begin with the set up.  When I am operating an enterprise I can 
elect to name my networked services in such a way that I can deduce 
why a DNS query comes to me.  For example, I can use 
"www.store.example.", "smtp.store.example.", "imap.store.example.", 
"ftp.store.example." and even "ssh.store.example."  When I embed URLs 
in my web pages, I will use the right domain names and I when I send 
mail I'll put in the right domain names for Reply-To and what not.

By using explicit domain names in the above paragraph, you can 
probably deduce that this is not the same as the use of a wild card 
(from the what I've read it sounds like folks are still afraid of 
that).  With a wild card address record in a TLD, the administrator 
has lost the "knowledge" of the deeper labels.  Incoherent DNS is not 
the same as NXDOMAIN redirection, the challenges and motivations are 
very different.

DNS operators have a long track record of using incoherent DNS 
configurations.  Every employer I've been with since '96 has had one 
version of the zone for the office and another version for the 
public.  CDNs make use of the technique (I should write "are said to 
make use" as I have no hands on experience in that).  But even with 
all of this activity, it's never gotten further in the IETF than this 
draft: 
http://tools.ietf.org/html/draft-krishnaswamy-dnsop-dnssec-split-view-04.

The popular DNS implementation BIND has had support for incoherency 
for a long time, called "views."  (I can't recall when it came into 
being.)  That's a measure of how wide spread incoherency has gotten.

I agree that there are parts of the DNS system where coherency is 
essential.  The root zone and the TLDs (or other widely delegated 
zones) should be coherent because of the mixed operational population 
they cover.  It's hard to remotely debug a system that is in flux, so 
it's necessary to have stability there.  But this observation doesn't 
apply as you dive deeper into the DNS, down to places where there is 
more concentrated effort in maintaining the service.

It can be argued that incoherent DNS is just a special case of a 
coherent DNS system rapidly changing its contents.  Mathematically, 
it's the same.

Coherent operations are easier, no doubt.  But incoherent DNS servers 
can also be managed.  That "rapid change of coherent servers" is a 
lot of work, just like incoherent servers is a lot of work.  But this 
allows the authority to tailor responses to the clients they serve.

>You don't actually know that--you're providing a response based on the
>subrange, but depending on the liveness of your load balancing and the caching
>implementation you could get a wide variety of results.  If I previously
>provided a single response based on the IP address of the querying server
>and now provide one based on the subrange being served, I might choose to
>lower the TTL to 0 in order to make sure that each subrange query is served
>"fresh", rather than from the cache.  Otherwise, I have to trust that the
>cache is maintaining multiple entries on the subrange basis.  You want to
>set a bit for that too?

Load balancing as the differentiator instead of (or in addition to) 
source IP address is a challenge but is just as workable.  Yes, the 
TTLs are lower for this to work.  Generally, with such short TTLs, it 
doesn't matter much what a cache does.

Keep in mind that often times the service being used is much longer 
lived than the DNS lookup.  If it's a TCP connection that will be up 
for an hour, I'm just going to get the one that is best at 9:41 and 
keep it there, even if a 10:13 a different server comes along that 
would be a better fit.

>I recognize that there is value to

The privacy implications are a red herring.  When you go to lookup 
www.store.example., someone is going to know you did that - at least 
so they can return the answer to you.

In many cases it is the operator of the recursive server you are 
using and not the authority server.    While any retailer would like 
to know the demographics of their customers - whether it's e-retail 
or Main Street retail - its a matter of what they can get.  If stub 
resolvers use servers @127.0.0.1 then the authority servers will get 
this.  If the stubs are using a "distant" (i.e., not @127.0.0.1) 
recursive server then the "issue" here is "how much of the 
information the recursive server collects are they willing to give up 
to the authority server?"  Recursive servers do not have the 
motivation to expose their stub resolvers, but there is motivation to 
get better responses to the questions they ask.

This statements address only the issues of the usefulness of 
incoherency, metrics like load balancing, and privacy.  I haven't 
made comments on the EDNS0 option request.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.

---

From: Martin Barry <[email-masked]>
Date: Tue, 2 Feb 2010 07:55:40 +1100

$quoted_author = "Ted Hardie" ;
> IMAP is not one of the store-and-forward bits of the email architecture;

I think he was addressing the "why not just use [HTTP feature X] to
redirect" comments.

> server?  Do you expect this to be opted-into for every query, or only

My reading of it was those resolvers not near the edge they are serving
would opt-in for all queries.

> sure that each subrange query is served "fresh", rather than from the cache

This has drifted away from being edns-client-ip specific, but...

Selecting a TTL will probably depend on how resilient each of the "local"
nodes is. Those using "dns tricks" should already have considered this in
their current implementations. 

cheers
Marty

---

From: Ted Hardie <[email-masked]>
Date: Mon, 1 Feb 2010 14:02:49 -0800

> I would expect EVERY query from third party resolvers ONLY: network-provider and user-provided resolvers don't need this, they already export enough information for the authorities to decide based…

That's only true if the network-provider architectures for DNS match that for
routing--if they have a DNS hierarchy that bubbles up to a top level set,
it's very possible for queries from them to be in different sub-ranges from the
ones which would be best used for localization.

> And thus the only systems which would need changing are third party resolvers and authorities which desire the ability to act on this information.  No other changes are needed.

This presumes that the clients do not have to opt-in to this and so no
changes are needed from them.

> b)  Used in ways where web-style redirects can't work

The point is, though, that there are applications which don't need this;
if you default to leaving it on for all applications, you're passing bits
that are at best not needed and at worst a privacy concern.

> A cache which is requesting with this enabled has already said it caches per subrange, thats why the netmask is in there in both ways, it says from the resolver -> authority "The guy is somewhere i…

This may be the optimal result here, but I suspect that it will not be the only
case seen.  A cache which did not want to store per subrange information
could easily pass the requests up with and then decline to store anything
in cache if the netmask is returned; that would increase load off of your
optimal scenario and still fit the protocol exchange.

> Coherence is dead.  Opposing this draft won't bring it back.  The choices are either:

Please re-read what I said.  I recognize the value of DNS-based localization,
but there is still an 80/20 rule to it.  This adds complexity to parts of the
system outside the authoritative systems that want to use these responses,
and it is not clear that it is worth it from either a performance or privacy
perspective.

> b)  Don't support incoherence for 3rd party resolvers and wonder why they continue to suck compared with first-party resolvers which will still have proper incoherence support.

I think if we started from  a problem statement we might have other choices
that this binary pair.  For one thing, we could a discussion of whether or not
the privacy considerations here merit making this opt-in from a client
perspective
or not.  Please try not to draw  lines in the sand here where they
aren't needed.

> And DNS privacy is a delusion:  DNS leaks so much information already in the current infrastructure that anyone who actually cares about DNS privacy has to take special measures: special measures w…

I disagree that it only affects them, for starters.  It impacts the
privacy considerations
in ways which will force some people who already take special measures to have
to change what they are.  Your own figures put that at 3% of clients,
leaving aside
mobiles and others likely to be hit; that's a much larger number than
the 3rd party
resolvers and authoritative servers.

You may think privacy is a delusion, but you haven't convinced me that
it is worth
leaving it out of the design constraints here.  Geolocation and other
constraints
would be worse, I grant you, but this one is not trivial in my mind.

regards,

Ted Hardie

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 1 Feb 2010 15:30:38 -0800

> changes are needed from them.

You could consider an automatic opt-in from all clients using third party DNS servers, since they opted in to THAT in the first place.

But if you want to require manual opt-in, you're saying "Kill this proposal" just in kinder language.

The reason this proposal works is the only changes needed are to the recursive resolvers and authorities which are affected by this problem.  If you want to suggest that ALL stub resolvers would need to change, you're saying you don't want this period.

And here's why a national ISP wouldn't bother with this:  You are going to do a separate DNS zone for each regional zone, as having everybody go to a central cache, even heirarchically, is going to hurt performance.  If you want the net to "feel snappy" to customers, you don't add 100ms to DNS lookups by having all DNS eventually go to one place, rather you distribute caching recursive resolvers throughout the country

Looking at their resolver list, eg, it appears Comcast, for example, uses 12 such clusters.  And for localizing comcast customers for low latency, good bandwidth, etc, knowing "he's a comcast customer, his DNS resolver is X" is good enough.  

Whats needed is to get third party resolvers on the same footing.

> that are at best not needed and at worst a privacy concern.

But even your example of apps that DON'T need it (bulk SMTP) turn out to use it

This is "near universal" functionality at this point for those deploying internet-scale stuff.

So at this point, I believe we can safely say: "DNS already provides this ability for first-party resolvers, and that this ability is used across a wide variety of applications, including those which do not support application level redirects".

> and it is not clear that it is worth it from either a performance or privacy

It only adds complexity to those outside the authoritative systems for those that want to use the complexity.  So its not an 80/20 rule, its a "only complexity is for those directly benefiting from the complexity".

Otherwise, why have a notion of EDNS options at all, if you can't use em because they don't universally provide benefit?

> or not.  Please try not to draw  lines in the sand here where they

You have staked a binary position, as your "privacy suggestions" are kill the protocol statements, as anything opt-in beyond the use of a resolver at all breaks the deployment model, and if you want opt-out, there already exists plenty of mechanisms FAR better than just saying "no localization data in my queries".

Thus if you want to mandate opt-in, without the notion of "you're using a 3rd party DNS, you opted in", you are saying "third party DNS should suck".  

If you want an opt-out, fine, no objection.  It would be meaningless, really, but that wouldn't affect deployment and its rather irrevelant anyway.

> resolvers and authoritative servers.

Actually, my figure is far less, because 3% is just one of the conditions: use a proxy for HTTP thorugh the browser. Its actually only 1% when you exclude those sessions who's non-browser traffic goes through the proxy.

So of the 1% we see, the ones who would be affected are:

a:  Those who's proxies are significantly different than their non HTTP traffic in terms of network location.

b:  Who use a third party DNS service

c:  Where they don't route the DNS requests through the proxy

d:  Somehow care about privacy despite using a 3rd party DNS service which they explicitly opted-into using in the first place!

We can tell A and B, we can't tell C, or D

For B: Use a proxy that is in their web browser setting (rather than forced by the network) + use OpenDNS: .77%.  Yes, shockingly high, but OpenDNS really is overrepresented in our dataset.

A will take a fair bit more work to answer, I need to start thinking on this.

> would be worse, I grant you, but this one is not trivial in my mind.

The problem is, for those who care about DNS privacy, there exist GOOD opt-in solutions independent of this approach: route your DNS through the same proxy you use for your traffic.

Rather those who this would affect are those who have implicitly stated they do NOT CARE about DNS privacy, because they are taking the privacy destroying action of using a third party resolver infrastructure.  Once you give Google the details of all the DNS requests you make, why should you care if Verisign sees your subnet on the rare requests where there is no cache for the nameserver entries?

---

From: Ted Hardie <[email-masked]>
Date: Mon, 1 Feb 2010 16:40:17 -0800

In-line.  Probably also worth splitting discussion onto other threads
in any case, as
others have done.

> You could consider an automatic opt-in from all clients using third party DNS servers, since they opted in to THAT in the first place.

Except that it wasn't in place when they configured them.  So that's a
post-facto
opt-in, which doesn't seem much like an opt-in at all.

> But if you want to require manual opt-in, you're saying "Kill this proposal" just in kinder language.

Notice that I'm not saying "Don't work on this problem", though.
If the client included a bit that said "feel free to pass my details on"
(what GEOPRIV used to call "setting the ravish-me bit") then I
would have no privacy concern.

> And here's why a national ISP wouldn't bother with this:  You are going to do a separate DNS zone for each regional zone, as having everybody go to a central cache, even heirarchically, is going to…

I'm aware of large scale enterprises that do bubble up to a single
cluster per region,
where region is at a continental scale.  If use my local DNS
infrastructure, for example,
the queries will come from New Jersey.  I am three time zones away.

But fixing that by having the enterprise understand the issue and
re-deploy requires
no protocol changes and saves latency in other ways besides.

> This is "near universal" functionality at this point for those deploying internet-scale stuff.

No.  If a recursive resolver turns this on globally, it will offer the option to
every authoritative server (see section 4.1 of the draft) and it will pass
the FAMILY and ADDRESS fields.  That information will get passed to
every authoritative server, whether that server is localizing or not.  That's
the wasted bits/data leakage issue I mentioned.

<snipped a lot of discussion where there seems to be no basis for
discussion, since we've both stated positions>
> c:  Where they don't route the DNS requests through the proxy

Not all proxy deployments permit the DNS request to be routed through
the proxy.

> A will take a fair bit more work to answer, I need to start thinking on this.

You still seem to be missing the mobile IP case, where there is a long-lived
tunnel to a home network but a portion of the traffic is originated from a local
IP.

> Rather those who this would affect are those who have implicitly stated they do NOT CARE about DNS privacy, because they are taking the privacy destroying action of using a third party resolver inf…

You are equating the terms of use for a service provider with the protocol
mechanics; someone could deploy a 3rd party service with an explicit statement
that the query logs were kept in /dev/null.  Presumably such a service
would never
use this option, but there might well be other solutions which met the
authoritative
servers need and they would be willing to use.  Anything in which the server
was willing to provide the mapping information of networks to responders (along
with a TTL) would have no privacy implication for the individual and would
additionally pre-populate the cache of exactly the data this would provide.

Of course that has the downside of information leaking the other way, as
well as a need to specify what query delivers the goods, but it is obviously
possible to divorce the optimization from the privacy issue.

Someone once called  protocol development as an exercise at deciding whose
ox gets gored.  Goring the privacy of someone who doesn't get to be a party to
the protocol exchange in which the data is distributed doesn't strike me as a
good idea.  Since you've already called me delusional on this point, I doubt
my own ideas convince you.  But I point you to the work of GEOPRIV as an
existence proof that the IETF as a whole at least once cared about a similar
issue (and given the services which correlate IP to location, one which is
a lot closer than the proposal on the table admits).

regards,

Ted Hardie

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 1 Feb 2010 18:51:45 -0800

> opt-in, which doesn't seem much like an opt-in at all.

Have you read a terms of service that hasn't said "we can do whatever we want whenever we want in the future?"

You use a third party DNS service, you've already agreed to things like

> New Features.
> 
> OpenDNS may, in the future, offer new services and/or features through the Service (including, the release of new tools and resources). Such new features and/or services shall be subject to these Terms of Use. Your continued use of the Service after the introduction of new features and/or services constitutes your acceptance of the Terms of Use.

> would have no privacy concern.

IF the client has to notify that its OK, you are saying kill the proposal.

Any change which requires client-change as well as resolver/authority change is a non-starter.  Look at things like Barwood's EDNS0 ping:  It would help against the out-of-path attacker, but because it requires changes to ALL resolvers and ALL authorities its useless.  Now add in changes to clients into the mix?.

> the queries will come from New Jersey.  I am three time zones away.

Then the enterprise is being stupid unless all traffic funnels through the same gateway: Not only is it hurting CDN performance, but it is hurting ALL performance, for no real benefit.

DNS doesn't work well when your cache is 200ms or more away...

> the wasted bits/data leakage issue I mentioned.

But what I am saying is that for 1st party resolvers, BECAUSE the CDN tricks work already, this information is already effectively available for all authorities, this would just give comparable information for the OpenDNS users rather than the Comcast users, or Napanet users, or corporate customers, or....

If this information leakage wasn't already there for the 1st party resolvers, the CDN tricks would never have been developed.  This formalizes the information leakage for 3rd party resolvers.

> Not all proxy deployments permit the DNS request to be routed through

SOCKS does, IIRC, its part of the protocol.  That firefox doesn't actually do this by default is IMO, a firefox bug.

> tunnel to a home network but a portion of the traffic is originated from a local

Route your DNS through the same portal as your tunnel:

If you're tunneling your web traffic, tunnel the associated DNS.  Puts them on the same privacy footing.

If you aren't tunneling your web traffic, why in god's name are you tunneling your DNS?

> additionally pre-populate the cache of exactly the data this would provide.

Assuming you believe them to implement this policy.  If you want privacy, you need to build systems that create this policy REGARDLESS of the behavior of the remote services.

TOR is a system which enforces privacy.  You could build a DNS system which enforces privacy using TOR.  

But current DNS leaks it all over the place, in many cases you already see down to individual institution or small ISP as the authorities & path to authorities.  Using your institution or ISP's recursive resolver already sprays this level of information that we are talking about all over.  And third-party DNS really makes it worse in aggregate, because although the authorities see less due to aggregation, the third party sees all.

And the problem is, ANY "network mapping of requestor" will probably violate your privacy scruples:  Its not possible, the search space is too small for hashing and the like tricks to work, and it needs to be clear to both the final authority AND all authorities on the query path (due to the DNS nature) unless you want to add RTTs in an operation designed to minimize RTT latency.

You can talk about ideals all you want, but the application to be solved can NOT be solved within existing DNS without this or a near equivalent privacy leakage.

The only OTHER option would be to have the authority's response contain netmask rules and force the CDN processing onto the recursive resolver, which would be a huge shift in burden.

> a lot closer than the proposal on the table admits).

You are trying to "protect" the privacy of those who have explicitly and willingly given it up already to a major third party.  They have already been a party to willingly giving up their privacy, so if you are going to gore anyone, it should be them.

And if you are really concerned about privacy, I'd look at web analytics, that is far far FAR FAR more evil in spraying information around and there IS no opt-out other than technical countermeasures!  You are worried about a paper cut (subnet of requester in a DNS message using third party DNS infrastructures) when there is arterial bleeding going on.

---

From: Brian Dickson <[email-masked]>
Date: Tue, 2 Feb 2010 01:24:24 -0400

Leaving aside the questions on privacy, opt-in/opt-out, coherence, etc.,
here are some observations I have:

This proposes putting an incremental level of work onto the recursive
resolver, regardless of where it is.

This raises the question of how to scale the actual amount of work, versus
the benefit (real or perceived) by the resolver and the resolvers' clients.

If, in order to populate a cache with "all" of the relevant entries, for
each leaf on the DNS tree exploiting this option, it takes N
queries/answers, this scales poorly.

However, let's consider a slightly modified arrangement.

What if the answer included not only the "matching" prefix/length, but also
some (perhaps negotiated) additional entries of prefix/length, for which the
same answer would be provided?

This would reduce by at least an order of magnitude the time/bandwidth
needed to populate such a cache.

There would then be the question of the additional computational cost, vis a
vis sorting the answers and hashing them or otherwise putting them into a
meaningful data structure.

What if the standard for this, also specified the order of members of the
returned set of prefixes? This would reduce or eliminate the requirement to
process the results by sorting them, if the order were search-friendly.

This would also reduce the incremental CPU load by at least an order of
magnitude.

Lowering all of time/bandwidth/CPU would perhaps make this at least
palatable (or palletable for the upgrades needed :-))

(There would then be the question of how much data to return, and/or how to
signal/negotiate that, etc., and the potential for abuse, e.g. multiplier
attacks)

Comments?

Brian Dickson
(after a long absence ;-))

---

From: Jim Reid <[email-masked]>
Date: Tue, 2 Feb 2010 09:40:13 +0000

On 2 Feb 2010, at 02:51, Nicholas Weaver wrote:

> You could build a DNS system which enforces privacy using TOR.

True. And perhaps someone's already done that. However this would be a  
disproportionate and excessive way to get round a resolving server  
which sends extra client data to a CDN's name servers just so they can  
do stupid DNS tricks. And no doubt mine that extra data for who knows  
what.

Besides, introducing TOR or VPNs or SOCKS tunnels or whatever to make  
the DNS work better -- for some definition of better -- will create  
new failure modes and operational complexity => adding more  
instability into a core protocol.

> And if you are really concerned about privacy, I'd look at web  
> analytics, that is far far FAR FAR more evil in spraying information  
> around and there IS no opt-out other than technical countermeasures!

That's a discussion for another place.

> You are worried about a paper cut (subnet of requester in a DNS  
> message using third party DNS infrastructures) when there is  
> arterial bleeding going on.

Maybe. But to continue with your analogy this WG gets to deal with  
paper cuts while arterial bleeding is handled elsewhere, even if it is  
by some members of this WG.

Your comments about DNS and privacy are all very well. IMO they don't  
mean that the WG should ignore the privacy concerns arising from new  
drafts or that the WG should endorse stuff that exacerbate those  
concerns.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 2 Feb 2010 12:34:21 +0100

On Mon, Feb 01, 2010 at 03:29:39PM +0000,
 Carlo Contavalli <[email-masked]> wrote 
 a message of 44 lines which said:

> recursive resolvers do not have to implement edns-client-ip, and
> they do not have to turn it on.

Yes, they have to, if they want to keep the SAME level of privacy as
today (not solve every privacy problem, just keep the CURRENT
level). That's the biggest problem with the proposal.

---

From: Carlo Contavalli <[email-masked]>
Date: Tue, 2 Feb 2010 11:55:05 +0000

> level). That's the biggest problem with the proposal.
I sincerely do not understand this comment.

If you don't enable the option, you keep the SAME level of privacy as
of today (eg, no client-ip information is forwarded to other name
servers).

If, as someone running a recursive resolver, you have a contract with
your users that allows you to do so and decide the "reduced privacy"
is worth the benefit for your users, you CAN enable the option if you
WANT to.

And again, this is more of a policy discussion. See my other email.

Carlo

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 02 Feb 2010 13:46:45 +0100

On 2.2.2010 12:55, Carlo Contavalli wrote:
> On Tue, Feb 2, 2010 at 11:34 AM, Stephane Bortzmeyer<[email-masked]>  wrote:

Any recursive resolver end-user or any resolver using forward resolvers 
have to implement edns-client-ip to be able to send 0.0.0.0/0, otherwise 
they cannot keep SAME level of privacy as today.

> of today (eg, no client-ip information is forwarded to other name

But we are not speaking about recursive resolver providers, but about users.

> is worth the benefit for your users, you CAN enable the option if you

Well I can very easily imagine some big ISP turning this option on 
without asking their clients.

Ondrej

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 2 Feb 2010 13:47:08 +0100

On Tue, Feb 02, 2010 at 11:55:05AM +0000,
 Carlo Contavalli <[email-masked]> wrote 
 a message of 21 lines which said:

> > Yes, they have to, if they want to keep the SAME level of privacy
> > as today (not solve every privacy problem, just keep the CURRENT

> I sincerely do not understand this comment.

I rewrote it, trying to make it clearer:

Today, if an end-client (the user's machine) wants to keep the SAME
level of privacy as today (not solving every privacy problem, just
keeping the CURRENT level), this end-client has to add a dummy
edns-client-ip with the wildcard address 0.0.0.0/0 (section
8.1). Otherwise, the resolver may, without the consent of the user,
add a real edns-client-ip (section 4.1) revealing the end-client
address. So, EDNS client IP indication is opt-out but should be
opt-in. And end-clients (stub resolvers) must be upgraded to
opt-out. That's the biggest problem with the proposal.

---

From: Jim Reid <[email-masked]>
Date: Tue, 2 Feb 2010 12:55:52 +0000

> of today (eg, no client-ip information is forwarded to other name

Define "you". You as a stub resolver may well decide not use the  
option. But you as their resolving server might do so without the  
knowledge or consent of your clients. [That's probably illegal in some  
countries.] Or you as the resolving server changes whatever address  
info your clients have chosen to disclose before firing their queries  
at the CDN's name servers.

The stub resolver and resolving server will in all likelihood be  
operated by discrete entities with different privacy expectations and  
requirements. The draft ignores that.

> is worth the benefit for your users, you CAN enable the option if you

This is far too vague. It's very unsatisfactory for a protocol  
specification. The current draft says nothing about a number of  
protocol/operational considerations for the three entities involved.

For instance, what should a resolving server do if it doesn't support  
this EDNS option and gets such a query from a stub resolver? What does  
it do if the resolver server does support the option but the client- 
provided data is syntactically incorrect or semantically incorrect?  
What does a resolving server do when it does support the option but  
has disabled it for local policy reasons? How will these conditions be  
signalled to the stub resolver? When the resolving server does support  
this option, is it permitted (or not) to modify the data before  
sending a query to an authoritative server? If it does mangle that  
outbound query, how will the stub resolver know that? Or should it?  
Likewise, what does an authoritative server do if (a) it doesn't  
support this EDNS0 option (FORMERR? NOTIMP? REFUSED? or just ignore  
it?); (b) chooses for some reason not to supply an "optimised"  
response. Can the resolving server mangle the optimised response from  
the authoritative server (say for local policy reasons) before giving  
a reply to the stub resolver?

> And again, this is more of a policy discussion.

Not necessarily. See above.

---

From: John Payne <[email-masked]>
Date: Mon, 1 Feb 2010 17:07:11 -0500

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

> and it is not clear that it is worth it from either a performance or privacy

Yes, it adds complexity to the recursive nameservers _that want to send the information_.

Where else is it adding any complexity?

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 2 Feb 2010 17:21:41 +0100

On Mon, Feb 01, 2010 at 05:07:11PM -0500,
 John Payne <[email-masked]> wrote 

> Where else is it adding any complexity?

In the stub resolvers that _do not want_ to send the information.

---

From: Jim Reid <[email-masked]>
Date: Tue, 2 Feb 2010 16:46:41 +0000

> Where else is it adding any complexity?

[1] Stub resolvers that don't want their address info disclosed. Or  
those who may want to send that info (how??) but are talking to  
resolving servers who don't. Or the resolving servers tamper with that  
data whenever they query the authoritative server(s). Or choose to  
mangle whatever is returned as the optimised response.

[2] Authoritative servers who can't/won't speak this EDNS0 option. The  
draft does not specify how they should behave.

Another Bad Idea in this draft is the concept of not using these  
extended queries to root and TLD servers. [Ironically, this is one  
place where "optimised" addresses in responses could be useful by  
directing resolvers to the nearest server for a referral.] It's not a  
good idea IMO to constrain a particular protocol query format to  
certain parts of the name space or an arbitrary number of labels in  
the QNAME.

---

From: Matthew Dempsky <[email-masked]>
Date: Tue, 2 Feb 2010 08:56:28 -0800

On Tue, Feb 2, 2010 at 4:55 AM, Jim Reid <[email-masked]> wrote:
> For instance, what should a resolving server do if it doesn't support this
> EDNS option and gets such a query from a stub resolver?
> [...]
> What does a resolving
> server do when it does support the option but has disabled it for local
> policy reasons?
> [..]
> support this EDNS0 option (FORMERR? NOTIMP? REFUSED? or just ignore it?);
> (b) chooses for some reason not to supply an "optimised" response.

It would seem a little absurd for an I-D to specify how software that
doesn't follow that I-D should behave.  Obviously, it behaves however
software today behaves already.

> Can the
> resolving server mangle the optimised response from the authoritative server
> (say for local policy reasons) before giving a reply to the stub resolver?
> [...]
> When the resolving server does support this option, is it permitted (or not)
> to modify the data before sending a query to an authoritative server?

Of course it can.  There's no requirement that resolving servers can't
arbitrarily change queries/responses as long as it fulfills the
client's requirements.

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 2 Feb 2010 08:54:05 -0800

> In the stub resolvers that _do not want_ to send the information.

Would the following be acceptable to you?

> This technique SHOULD only be used by recursive resolvers where the end-host or end-host administrator has explicitly selected this recursive resolver over one automatically selected by the network provider.

That should solve your privacy concerns, because the main usage is for third party resolvers where the user or network administrator has already selected its usage, and the terms of service for these providers invariably allow them to add features like this.

Because, frankly speaking, you have to trust that the recursive resolver isn't shipping a copy of all your requests to the NSA anyway, so a client-directive is really meaningless for enforcement.

---

From: Matthew Dempsky <[email-masked]>
Date: Tue, 2 Feb 2010 09:07:44 -0800

On Tue, Feb 2, 2010 at 8:46 AM, Jim Reid <[email-masked]> wrote:
> [2] Authoritative servers who can't/won't speak this EDNS0 option. The draft
> does not specify how they should behave.

Again complaining that a draft doesn't specify how software not
following that draft should behave.

> Another Bad Idea in this draft is the concept of not using these extended
> queries to root and TLD servers. [Ironically, this is one place where
> "optimised" addresses in responses could be useful by directing resolvers to
> the nearest server for a referral.]

The stub resolver's IP address isn't useful when querying zones that
only return delegation responses.  That data is used by the recursive
resolver, not the stub, and authoritative servers already have the
recursive resolver's full IP address.

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 2 Feb 2010 09:13:10 -0800

On Feb 2, 2010, at 8:46 AM, Jim Reid wrote:

> [1] Stub resolvers that don't want their address info disclosed. Or those who may want to send that info (how??) but are talking to resolving servers who don't. Or the resolving servers tamper with that data whenever they query the authoritative server(s). Or choose to mangle whatever is returned as the optimised response.

If the resolver doesn't support it, a) Who cares?  b)  Just run your own recursive resolver.

If you don't trust the resolver, thinking it may tamper with things, why are you using it at all?  Seriously, if the recursive resolver is in your threat model, bypass it and generate your own recursive requests: its not necessary for correct operation of DNS.

> [2] Authoritative servers who can't/won't speak this EDNS0 option. The draft does not specify how they should behave.

You can easily do fallbacks for those who don't speak this EDNS0 option:  If you don't get a response on the first query, retry without this option.  If that works, have your next 2-3 queries be both (with and without).  If those two or three also fail, record that authority as not supporting, and don't use the query in any subsequnet responses

Voila, you have fallback: only ever hits a timeout the first time for authorities which can NOT respond to a request with an unknown EDNS option, and even for those, its only 1 timeout latency and 2-3 extra queries from each recursive resolver which bothers with this option.

This is why the basic scheme is so beautiful: it does NOT require changes to anyone who doesn't actually care about this option.  This is the kind of thing EDNS options should be designed for: optional behavior amongst a subset of the system.

> Another Bad Idea in this draft is the concept of not using these extended queries to root and TLD servers. [Ironically, this is one place where "optimised" addresses in responses could be useful by directing resolvers to the nearest server for a referral.] It's not a good idea IMO to constrain a particular protocol query format to certain parts of the name space or an arbitrary number of labels in the QNAME.

Except that provides the privacy protections that you and S Bortzmeyer want: limiting disclosure, when possible, to the authority of the site the user will be contacting.  If you ONLY include such queries in the queries to the final authority, the information leakage really IS trivial, its so that a host in that particular subnet can contact the authority's associated site!

And for your suggested usage, this isn't necessary, as you refer the RESOLVER's IP to the most appropriate one, not the client's IP, because it is the resolver that needs to contact the domain's authority.

---

From: Eric Brunner-Williams <[email-masked]>
Date: Tue, 02 Feb 2010 12:23:29 -0500

On 2/2/10 11:54 AM, Nicholas Weaver wrote:
>> John Payne<[email-masked]>  wrote

Failing to distinguish between economically irrational actors such as 
the NSA and their pervasive intercept, and economically rational 
actors, such as DoubleClick, is not useful. Both are engaged in 
deterministic, as well as probabalistic profiling, but to radically 
different ends.

I repeat, a data collection policy discovery mechanism is quite 
different from a "don't collect my data" assertion, which may, or may 
not, have any semantic meaning. With the former, the duration that 
data is held, the conditions under which it is provided to third 
parties, and the data it is correlated with, are all discoverable. 
With the later these are ... uninteresting I guess.

Eric

---

From: Jim Reid <[email-masked]>
Date: Tue, 2 Feb 2010 18:06:23 +0000

On 2 Feb 2010, at 17:13, Nicholas Weaver wrote:

> You can easily do fallbacks for those who don't speak this EDNS0  
> option:  If you don't get a response on the first query, retry  
> without this option.  If that works, have your next 2-3 queries be  
> both (with and without).  If those two or three also fail, record  
> that authority as not supporting, and don't use the query in any  
> subsequnet responses
>
> Voila, you have fallback: only ever hits a timeout the first time  
> for authorities which can NOT respond to a request with an unknown  
> EDNS option, and even for those, its only 1 timeout latency and 2-3  
> extra queries from each recursive resolver which bothers with this  
> option.
>
>
> This is why the basic scheme is so beautiful: it does NOT require  
> changes to anyone who doesn't actually care about this option.  This  
> is the kind of thing EDNS options should be designed for: optional  
> behavior amongst a subset of the system.

So, your idea of optional behaviour in some circumstances is to  
increase DNS latency and generate extra queries. I see...

---

From: Tony Finch <[email-masked]>
Date: Tue, 2 Feb 2010 18:26:24 +0000

On Tue, 2 Feb 2010, Jim Reid wrote:
>
> So, your idea of optional behaviour in some circumstances is to increase
> DNS latency and generate extra queries. I see...

Isn't that just how EDNS0 is specified to work?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.

---

From: Wilmer van der Gaast <[email-masked]>
Date: Tue, 2 Feb 2010 18:29:21 +0000

On 2 February 2010 18:06, Jim Reid <[email-masked]> wrote:
>
> So, your idea of optional behaviour in some circumstances is to increase DNS
> latency and generate extra queries. I see...
>
Are you trying to say that EDNS0 options should only ever be used for
extensions designed to slow things down?

Sadly the EDNS0 spec doesn't really describe what an implementation
should do if it sees an unsupported option. So far most of them seem
to just ignore data they don't understand, which is the sanest thing
to do IMHO. A few are different and return something like FORMERR or
just drop the packet altogether. I've dealt with firewalls that drop
any DNS packet with EDNS0 information, getting BIND to work well on
such a network was pretty hard since BIND couldn't be told to disable
EDNS0 globally.

If we want to block DNS extensions because of existing broken
implementations, what's the point of developing anything new at all?

Wilmer.

-- 
Wilmer van der Gaast, Dublin Traffic SRE.
Google Ireland.

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 2 Feb 2010 10:27:54 -0800

On Feb 2, 2010, at 10:06 AM, Jim Reid wrote:

> So, your idea of optional behaviour in some circumstances is to increase DNS latency and generate extra queries. I see...

No.  There are 4 cases, all of them harmless, two which add no latency or additional queries, one which adds one RTT latency on the first query, and one which adds one timeout of latency on the first query and 2-3 additional queries.

Authority knows what the option is:  No added latency, no nothing.

Authority doesn't know the option but follows RFC 2671 5.3:  The server replies with NOTIMPL, FORMERR, or SERVFAIL.  So setry without and cache the behavior of the authority.  Result?  One RTT of added latency on the first query to the authority to learn the state.  No other effect.

Authority doesn't know the option and just ignores it in violation of RFC 2671:  No effect.

Authority doesn't know the option and does a silent failure in violation of RFC 2671 (aka, BUGGY!): Retry after timout, so 1 timeout of added latency on the first query and 2-3 doubled queries subsequently to learn the state of the authority.

This is the whole point of EDNS0 options: there is graceful failure when the authorities don't understand them, both when they follow the RFC and even when they don't!  

Harm to non-compliant authorities is effectively nonexistant: one RTT latency if you follow RFC 2671 for unknown options, one timeout RTT if you don't.

---

From: Matthew Dempsky <[email-masked]>
Date: Tue, 2 Feb 2010 10:46:21 -0800

On Tue, Feb 2, 2010 at 10:27 AM, Nicholas Weaver
<[email-masked]> wrote:
> Authority doesn't know the option but follows RFC 2671 5.3:  The server replies with NOTIMPL, FORMERR, or SERVFAIL.

I don't understand RFC 2671 5.3 as requiring a server to reply with
one of those codes (otherwise it would have made more sense to specify
which one).  Instead, I read it as a warning/reminder to the reader
that a server might not gracefully handle new extensions, and clients
should be prepared to deal with that possibility when making use of
them.

---

From: Jim Reid <[email-masked]>
Date: Tue, 2 Feb 2010 18:44:29 +0000

On 2 Feb 2010, at 18:29, Wilmer van der Gaast wrote:

> should do if it sees an unsupported option.

Indeed. Perhaps this can be clarified if 2671bis gets revived. After  
all there is a difference between "I don't speak EDNS0" and "I don't  
understand this EDNS option". Until then, it would be prudent for  
anyone proposing new EDNS options to specify how implementatons that  
don't support the option should behave. Your mileage may vary.

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 2 Feb 2010 10:49:52 -0800

> should be prepared to deal with that possibility when making use of

To me it sounds like it should:

5.3. Responders who do not understand these protocol extensions are
     expected to send a response with RCODE NOTIMPL, FORMERR, or
     SERVFAIL.  Therefore use of extensions should be "probed" such that
     a responder who isn't known to support them be allowed a retry with
     no extensions if it responds with such an RCODE.  If a responder's
     capability level is cached by a requestor, a new probe should be
     sent periodically to test for changes to responder capability.

Protocol extensions would IMO, include an unknown options.

But in any case, there are graceful failure mechanisms no matter what the authority does: ignore it, reply with any sort of failure, or silently not reply: all can be handled easily.

---

From: Jim Reid <[email-masked]>
Date: Tue, 2 Feb 2010 18:51:10 +0000

On 2 Feb 2010, at 18:26, Tony Finch wrote:

>> increase

Yes, but we're not talking about EDNS0 here. We're talking about an  
EDNS0 option.
The behaviour which was suggested could mean resolvers incorrectly  
deciding a server doesn't speak EDNS0 when in reality it doesn't  
understand a new EDNS0 option. That would be bad.

---

From: Wilmer van der Gaast <[email-masked]>
Date: Tue, 2 Feb 2010 19:02:42 +0000

> should be prepared to deal with that possibility when making use of
+1

Just out of curiosity I did a few test queries to my own server
running BIND, to OpenDNS, Google Public DNS, and amazon.com and
microsoft.com nameservers. They all ignore the option, except the
last: From what I can see this is done by their Netscalers though, not
their nameservers. (dig . ns @65.55.37.62  shows a very typical
response that I've only seen from Netscalers so far)

Wilmer.

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 2 Feb 2010 11:08:31 -0800

On Feb 2, 2010, at 10:51 AM, Jim Reid wrote:

> Yes, but we're not talking about EDNS0 here. We're talking about an EDNS0 option.
> The behaviour which was suggested could mean resolvers incorrectly deciding a server doesn't speak EDNS0 when in reality it doesn't understand a new EDNS0 option. That would be bad.

No, because you retry without the EDNS0 OPTION in question.

To be honest, there already needs to be layers of fallbacks already, because you not only have "don't speak EDNS0", but also fragmentation issues with large responses.

---

From: Michael Graff <[email-masked]>
Date: Tue, 02 Feb 2010 13:22:51 -0600

On 2010-02-02 12:44 PM, Jim Reid wrote:
> Indeed. Perhaps this can be clarified if 2671bis gets revived. After all
> there is a difference between "I don't speak EDNS0" and "I don't
> understand this EDNS option". Until then, it would be prudent for anyone
> proposing new EDNS options to specify how implementatons that don't
> support the option should behave. Your mileage may vary.

I think it's critical for them to discuss what they think will happen to
existing clients.  At the least, it might detect operational problems
before they become widespread deployed problems.

- --Michael

---

From: Michael Graff <[email-masked]>
Date: Tue, 02 Feb 2010 13:21:32 -0600

> Isn't that just how EDNS0 is specified to work?

If a server doesn't understand an EDNS0 option (or EDNS0 at all) it
should just ignore it.  Basically.

My big concern here is not what everyone seems to be discussing, but
caching.

Since the response coming back now has a network range the answer is
good for, this more or less adds another dimension to the cache.  You
may now have many answers for the same data.  Do you have to run DNSSEC
validation on each of these answer ranges specially?  The signatures
have to match up with the records, after all.

How exactly will this work with forwarders?  Most people think of
forwarders as a large shared external cache.  If the forwarder supports
this option will it place the address of the resolver in the option?  If
so, that's not the client's address, but a middle-man.  This
configuration is quite popular.

- --Michael

---

From: Michael Graff <[email-masked]>
Date: Tue, 02 Feb 2010 13:25:20 -0600

>      sent periodically to test for changes to responder capability.

"These extensions" means "ENDS0 data type" really.  It is badly worded,
and I will ensure it is corrected in the update I'm (still) working on.

This is a lot like DHCP options, really.  The client can request option
55, but there is no reason the server must understand that, or reply
with option 55 configuration.  The client has to be able to adapt here.

- --Michael

---

From: Matthew Dempsky <[email-masked]>
Date: Tue, 2 Feb 2010 11:44:20 -0800

On Tue, Feb 2, 2010 at 11:21 AM, Michael Graff <[email-masked]> wrote:
> good for, this more or less adds another dimension to the cache.

Caches already have to deal with a potentially unbounded set of data.
Adding another dimension to this doesn't really change the fundamental
problem.

Resolvers have the option to control when the flag is used or not.
E.g., if the cache is experiencing high levels of churn, they can just
turn it off and fallback to current behavior.  They can only turn it
on for interesting domains that are likely to benefit from it.

I see whether or not to use the option as an administrative choice.

> You

Of course you'd have to.  But as an optimization, you can check if you
already have the same record set + DNSSEC signatures cached for a
different CIDR block, and then short circuit re-evaluation.

---

From: Ted Hardie <[email-masked]>
Date: Tue, 2 Feb 2010 11:55:06 -0800

Comments in-line.

>> OpenDNS may, in the future, offer new services and/or features through the Service (including, the release of new tools and resources). Such new features and/or services shall be subject to these…

Again, I think you're conflating the terms of service for a particular
actor with the protocol semantics here.  You may be right that some
3rd party agreements allow one of the parties to set the ravish-me bit,
but that doesn't make it okay to assume that all DNS users have agreed
to the disclosure of this data.  This wasn't possible before and they
have not opted-in.  You and I may disagree about whether or not they
should, but let's at least be cleared that they have not.

Separately, I agree with Stephane's comments on the method for opting out
in the draft requiring work and having potential deployment difficulties.

> IF the client has to notify that its OK, you are saying kill the proposal.

As I was trying to say in a previous message, there may be ways to get
sufficient
data from authorities to interested recursive resolver without there being
any privacy-related disclosure.  I don't know yet how practical they are, but
the problem statement:

"Authoritative servers wish to provide localized results based on network
proximity.  What is the best way for interested recursive resolvers and
authoritative servers to manage information about these mappings?"

does not automatically imply this solution nor any solution that requires
divulging which client subnets originated specific queries.

> Then the enterprise is being stupid unless all traffic funnels through the same gateway: Not only is it hurting CDN performance, but it is hurting ALL performance, for no real benefit.

Agreed, and that's why I said fixing it by encouraging redeployment rather
than localization was the appropriate remedy here.

> But what I am saying is that for 1st party resolvers, BECAUSE the CDN tricks work already, this information is already effectively available for all authorities, this would just give comparable inf…

We seem to be talking at cross purposes here.  Let me try again.  This proposal
would have the option be present whenever a recursive resolver talks to an
authoritative server if it is globally set.  That means that this
information passes
to every authoritative server, whether the authoritative server is
localizing information
or not.  That means the universe of leaked data is not "Users of 3rd party DNS
requesting info about  localized servers" but potentially "users of 3rd party
DNS requesting info from anyone".  We don't disagree about whether someone
running their own recursive resolver or using a local one is already disclosing
(at least I don't think we do).

If this is not set globally, then the recursive resolver has to
maintain a table or
set of rules that notes when it should be sent and when it should not.  I'm not
sure how it gets knowledge of which services are localized, so it is
my expectation
that anyone who turned it on would leave it on for all queries to authoritative
servers.  I could be wrong, of course, and some other pattern might easily
emerge.

> If this information leakage wasn't already there for the 1st party resolvers, the CDN tricks would never have been developed.  This formalizes the information leakage for 3rd party resolvers.

And puts the onus on clients to opt-out of disclosure without knowing whether or
not that disclosure is going on upstream of them.

> SOCKS does, IIRC, its part of the protocol.  That firefox doesn't actually do this by default is IMO, a firefox bug.

SOCKS 4 did not; SOCKS 5 added support for it, but in many installations
it requires explicitly directing the DNS traffic through the tunnel.  SOCKS
can leak DNS in cases where the tunnel is set up per application and DNS/UDP is
not explicitly redirected.  Some other forms of proxy don't handle UDP at all.

> If you aren't tunneling your web traffic, why in god's name are you tunneling your DNS?

Think of it in VPN terms for a moment.  The VPN set-up directs certain
IP subnets through the tunnel interface, which can have effects from pointing
default through the tunnel to setting up a small number of networks which
are routed through the tunnel but leaving all others to be routed outside the
tunnel.  The resources available through the tunnel can include
local file servers, smtp servers, and other services which are not available
from outside because of firewall restrictions.  The client needs to
pass at least the
DNS traffic related to those services through the tunnel because of split
DNS.  It is easier to pass *all* DNS through that tunnel if the set of resources
the client is interested is {globally available services, private
services available
through the tunnel}.  When it includes {globally available services,
private services
available through the tunnel, and private services available locally but not
globally} I have to actually associate which domains are served where,
and the default can go either to local or tunnel, depending on configuration.

Things in MIP-land are a little more complicated yet (service selection options
and so on), but this gives you an idea of why the DNS might exit someplace
other than the traffic in the presence of a tunnel.

>
>
> And the problem is, ANY "network mapping of requestor" will probably violate your privacy scruples:

No, I'm fine with any mapping that the requester agrees to (a non-starter in
your option) *or* that is actually a network mapping that doesn't disclose
which IP address or subnet generated the request for the mapping.  I could
achieve that steganographically by putting the "real" request in a flood of
requests related to other subnets, but that would be a colossal waste of
resources.

> The only OTHER option would be to have the authority's response contain netmask rules and force the CDN processing onto the recursive resolver, which would be a huge shift in burden.

Is the real problem here a shift in burden of, presumably, processing power
(since the network traffic might actually be less) or of CDN secret sauce?
Because if a zone transfer-like mechanism of mapping info can accomplish
this there is zero privacy implication to my mind, and I would be interested
to see which of the recursive server operators would say yes to using it.

> You are trying to "protect" the privacy of those who have explicitly and willingly given it up already to a major third party.  They have already been a party to willingly giving up their privacy,…
We disagree on this point.

> And if you are really concerned about privacy, I'd look at web analytics, that is far far FAR FAR more evil in spraying information around and there IS no opt-out other than technical countermeasur…
And this is unrelated to the work going on here.

regards,

Ted Hardie

---

From: Michael Graff <[email-masked]>
Date: Tue, 02 Feb 2010 13:58:00 -0600

> Adding another dimension to this doesn't really change the fundamental

I think it quite easily could change it.  The amount of data a cache
must maintain is not my issue really, although it is a concern.

If you query for an MX host, and you get an answer that is valid for a
given address range, will the address records for that MX target also
need to be checked for that range?  What if it's not in it?

What about targets of CNAMEs?

I know caches deal with this type of thing all the time, but it gets
really messy when you do range-checking for the target of the name and
then need to do additional section processing in order to really answer
the query.  Previously, it was "do I have this additional data?" but now
it's "Do I have this additional data, and does it also fit within the
netmask of the actual query?

Perhaps it's just the same thing with the same filters applied.

- --Michael

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 2 Feb 2010 12:45:20 -0800

> in the draft requiring work and having potential deployment difficulties.

No, I am saying that the cases where this would be used, the users have already opted-in to the usage of a system like this, and extensions like this are already covered in the terms of service.

Do you NOT consider explicit selection of a third-party resolver a significant opt-in action?

Should DNS be the only real protocol with an opt-in privacy ability?  HTTP sure doesn't....

> divulging which client subnets originated specific queries.

Actually, it does, here's why:

Network proximity, with any decent quality, be it AS number, hash of AS number, subnet mask, truncated AS path, magic-pixie-number, etc, will leak similar amounts of information.  It has to, because it always has to say "the user is in this part of the network space", its just a matter of how to say it and with what precision: be it subnet, most specific AS number, or pixie-dust: they all say "where you are".  

And, like GeoIP, or Wifi Mac address -> location, or whatever, there will be databases made to unify them all, so we might as well call them roughly equivalent to start with and save us the headache of every alternate form getting the same objections from different people.

Hashing type tricks don't help either, because the search space is way too small.  With a network describable by 10K-100K+ points of locality, there simply isn't enough search space to make hashing tricks work.

QED:  Network proximity is privacy sensitive by your definition, in any form, because they are all roughly equivalent with the only difference being degrees of precision.  

IP subnet just happens to be a very convenient one, because the CDNs are already optimized around that as the metric.  But most specific AS or AS-path fragment would be effectively equivalent in information leakage.

> servers.  I could be wrong, of course, and some other pattern might easily

And you seem to be missing my point:  For users of 1st party resolvers, this information or something semantically equivalent is already being leaked to ALL authorities.  

Just because only a few authorities are USING CDN-like tricks doesn't mean that all authorities aren't already receiving the same network locality information, they just are not bothering to infer anything about it. 

> not explicitly redirected.  Some other forms of proxy don't handle UDP at all.

That does not mean we should work around bugs in proxies that can't handle UDP.  Heck, tunnel your DNS over TCP then, if your proxy doesn't support UDP, to pick the route you want your DNS queries to take.

> and the default can go either to local or tunnel, depending on configuration.

And if you do so, how does this draft really affect you?  

Unless your VPN'ing institution also uses a third party managed DNS service rather than its own DNS resolver, the information all leaks out anyway to the authorities.

And if your institution does not want this information to leak out, why is it leaking it en masse to the third party provider which explicitly says its allowed to use aggregates of that information?

And no matter what, you're CDN performance will be painful since your data IP and query IP are very different, but thats just the limitation of DNS-based CDNs no matter the information.

> your option)

You don't seem to consider "the user specified this non-default resolver" as agreement, however.

> *or* that is actually a network mapping that doesn't disclose
> which IP address or subnet generated the request for the mapping.  

See above, that's impossible short of noise injection, and noise injection would be pointless: you're trying to hide things from the authorities of sites you want to talk to!

Else why are you looking up the names at all?

The "This option is not exported to the TLD servers" part means only the authorities YOU are going to talk to receive this information at all.

> to see which of the recursive server operators would say yes to using it.

Such zone-transfer like mechanisms would undoubtedly be constrained by pairwise agreements between authorities and third-party resolvers, because there is BOTH secret sauce issues and load issues.

So do you really want to ingrain contractual-behavior affecting performance into DNS!?!?  Do you really want contractual barriers to entry for 3rd party DNS services?

> And this is unrelated to the work going on here.

If your objection to something that would greatly improve the ability of people to use DNS service providers other than those of the ISP only comes down to protecting privacy, scale matters.  So it is related.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 02 Feb 2010 20:51:19 +0000

> Date: Tue, 02 Feb 2010 13:46:45 +0100
> From: Ondřej Surý <[email-masked]>
> 
> Well I can very easily imagine some big ISP turning this option on without
> asking their clients.

that all depends on the RFC text.  big ISP's sometimes have privacy policies
and sometimes do not but they do live in some fear of their regulators.  and
while i expect BIND would implement this feature, we would never make it the
default.  so an ISP who turned this on would not have any deniability as to
it being their intent that their users have less privacy.  and, the cost in
terms of memory footprint for their cache, and lower hit rates, will be high.
so, i do not expect anyone to turn this on without intending to.

---

From: Wilmer van der Gaast <[email-masked]>
Date: Tue, 2 Feb 2010 21:27:02 +0000

On 2 February 2010 20:51, Paul Vixie <[email-masked]> wrote:
> default.

Note that this is already recommended in the first bullet point in
8.2. Indeed we didn't ever intend this to be an "enabled by default"
feature.

Wilmer.

---

From: Michael Graff <[email-masked]>
Date: Tue, 02 Feb 2010 15:44:24 -0600

> 8.2. Indeed we didn't ever intend this to be an "enabled by default"

Then how can this possibly be useful?  This sort of optimization
requires it to be performed for a large chunk of the users on the net,
certainly for large ISPs and wireless providers.  While the number of
servers may indeed be small, the number of clients benefiting from this
(and therefore using it with or without their knowledge) has to be large.

- --Michael

---

From: Wilmer van der Gaast <[email-masked]>
Date: Tue, 2 Feb 2010 21:55:58 +0000

> (and therefore using it with or without their knowledge) has to be large.
Only clients of open resolvers and customers of ISPs with more peering
points than resolvers will benefit from this. Everybody else can
completely ignore this extension.

So it seems logical to not turn it on by default, also because it puts
significant pressure on caches and generates more load. *If* anyone
would turn it on by default, it'd better be mentioned in capitals in
the release notes.

Wilmer.

---

From: Michael Graff <[email-masked]>
Date: Tue, 02 Feb 2010 16:08:01 -0600

> completely ignore this extension.

As a client that is likely true.  However, as the topic of this posting
is opt-in, not default config, perhaps that's the important thing to
discuss.

I see the huge benefit large hosting providers get from this extension.
 As a client, I'd benefit hugely from this perhaps, and my iPhone
experience may be better than ever.

However, there is a privacy concern, and that is what the opt-in
discussion is all about.

I also think this is more wide-spread than just the client side.  The
servers will need to be modified to provide address information as well,
and there is no way to do this in AXFR without special changes to group
by address/netmask and add OPT records to AXFR.

I suspect this will affect interop, and no mention of how to tag this
additional data, signal a slave can handle it, nor what happens when a
slave does not handle it is mentioned in the draft.

- --Michael

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 2 Feb 2010 14:55:30 -0800

On Feb 2, 2010, at 2:08 PM, Michael Graff wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

> experience may be better than ever.

Actually, as a client, I hope you'd benefit relatively little if you are using your ISP's resolution infrastructure and the goal is to convey network location (rather than arbitrary location, which the resolver doesn't know anyway). 

The whole reason why all the CDN tricks work is the external IP where the DNS comes from tells the CDN what really counts: what network you are with, and what part of that network you are in, so the CDN-type transaction can know what set of machines are "best" to return to you (lowest latency, lowest cost, etc)...

And the ISP is best served by building a more distributed DNS architecture because that minimizes latency of lookups: having cached DNS go cross-country is a bad design.  Thus if, as a client, you'd benefit from this in your ISP's infrastructure, that implies your ISP's infrastructure is needlessly centralized and all your lookups are suffering higher latency.

Thus the client benefit is almost exclusively when you use third party resolution infrastructures, as the CDN-type operations can NOT identify your network provider and subpiece of that network provider when you use OpenDNS or Google Public DNS or Ultradns etc....

This is why I find client-opt-in a silly notion to insist on in the protocol:  The opt-in was made by using a third-party resolution infrastructure in the first place.  

This doesn't generally make sense for first-party infrastructure, yet putting opt-in into the protocol is a protocol killer: if we want to do changes to the stub resolver, I can think of a lot of better ones (like, say, bypassing the recursive resolver completely because its a lying SOB that may do such things as wildcard or even Man-in-the-Middle www.google.com, and instead generating direct requests.  And if I care about privacy, generate direct requests through multiple TOR paths)

> slave does not handle it is mentioned in the draft.

Except that the authorities which would use this information have already solved this problem.  You don't see Akamai or Google fretting about master/slave coordination, interop, etc.  They just do it.  The code path-change on the CDN-using authority side is very small: where instead of using the resolver's IP in the lookup logic you use the EDNS0 client-ip value.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 03 Feb 2010 10:01:22 +1100

In message <[email-masked]>, Wilmer 
van der Gaast writes:
> just drop the packet altogether.

Define EDNS1 so that unknown option behaviour is well defined and
forget about EDNS0.  EDNS0 servers are supposed to return BADVER
to EDNS1 queries regardless of their payload.  This is defined in
EDNS0.  EDNS0 servers that fail to return BADVER are broken and
their vendors should be fixing them.  Unknown EDNS options behaviour
is undefined in EDNS0 so FORMERR is a legitimate response.  Also
the point of BADVER was to allow a pair of servers to work out what
each supported without having to do a big trial and error dance.

This working group has be remiss in not using EDNS versioning to
signal capabilities properly.

> I've dealt with firewalls that drop

Actually you can disable EDNS globally in all current version of
BIND.  That said you should be replacing / upgrading / reconfiguring
the firewall.  Cisco and other firewall vendors ship firewalls that
are EDNS aware.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Ted Hardie <[email-masked]>
Date: Tue, 2 Feb 2010 16:19:14 -0800

In-line, but getting to be less and less, as the space where
we're not just wearing holes in the carpet seems to be shrinking.

> Do you NOT consider explicit selection of a third-party resolver a significant opt-in action?

Not when many of the folks who chose such a resolver did so when this option
was not known or available.  I recognize that we're likely never going to agree
on this point one way or the other, but please understand that your view is
not universal.

> QED:  Network proximity is privacy sensitive by your definition, in any form, because they are all roughly equivalent with the only difference being degrees of precision.

This starts from the premise that the resolver has to disclose this
privacy-sensitive
information in order to get a meaningful result back.  Anything that started out
without that privacy-sensitive information would be better, in my opinion, and
I do not agree that disclosing this information in order to get the mapping data
is absolutely required.  It's a trade-off between amount disclosed by the
CDN (secret sauce) vs. the customers (privacy).

With an opt-out only mechanism, we also have no way to judge how many of the
customers would voluntarily give their data to get the better performance; it
might be the overwhelming majority.  But you are treating opt-in as a complete
non-starter; if you had not, you and I could be talking about how to create
informed consent from the user to the authority instead.  As I said before,
I would be fine with this as an opt-in; that enables the users to retain
their current levels of privacy by default.

> And you seem to be missing my point:  For users of 1st party resolvers, this information or something semantically equivalent is already being leaked to ALL authorities.

We agree; it is possible to configure a system so that this does not leak,
but those who use a resolver on their system or very close to it are leaking
this data now.

> Just because only a few authorities are USING CDN-like tricks doesn't mean that all authorities aren't already receiving the same network locality information, they just are not bothering to infer…

Except for those who are not using nearby resolvers; I think we agree on
this point as well.

> That does not mean we should work around bugs in proxies that can't handle UDP.  Heck, tunnel your DNS over TCP then, if your proxy doesn't support UDP, to pick the route you want your DNS queries…

This requires a customer configuration change to maintain the same level of
privacy as proxy + 3rd party resolver achieves now.  How do I notify the
affected users they need to change, given that this change in behavior is
not on-path for the customer and they cannot detect it?

> And no matter what, you're CDN performance will be painful since your data IP and query IP are very different, but thats just the limitation of DNS-based CDNs no matter the information.

I was just answering your question about why someone would have DNS go out
a tunnel interface.  I think it is more common than your current data
may suggest,
because the kinds of clients that are doing this tend to be mobile rather than
nomadic.

This implies, to me, that an opt-in mechanism in which the client populated
the IP it is using on the visited network  up the DNS chain might actually
get traction in that part of the ecosystem.  Note, however, that this
still doesn't
require that this get passed all the way to the authority; the CDN providing
mappings to interested resolvers works here just as well.

> So do you really want to ingrain contractual-behavior affecting performance into DNS!?!?  Do you really want contractual barriers to entry for 3rd party DNS services?

You seem to want to rely on contractual language between 3rd party servers
and their clients.  If 3rd party resolver X doesn't bother getting data from
CDN Y, they are no worse off than now.  They can opt-in to it, just as they
can opt-in to sending client IPs; the amount of data and work are different,
but so is the customer experience.

The key question is who should be sending data to whom?  Does the CDN
reveal data in bulk to interested resolvers?  Or does the resolver reveal
data en masse to authorities?

> If your objection to something that would greatly improve the ability of people to use DNS service providers other than those of the ISP only comes down to protecting privacy, scale matters.  So it…

I don't understand how your point about web analytics/scale relates to
which problems
the WG is chartered for.  But please don't worry about it; that
particular tendril of
fog doesn't need much blowing away.

regards,

Ted Hardie

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 2 Feb 2010 17:37:34 -0800

My last comments on this:

> their current levels of privacy by default.

If opt-in is engineered in the PROTOCOL, it really is a non-starter, because opt-in in the protocol requires changing stub resolvers, and if we change stub resolvers, there are far better changes to make first.

My preferred one would be eliminating recursive resolvers entirely from the protocol's usage for anything that the stub resolver can't verify with DNSSEC with a chain of trust from a signed root: the recursive resolver is a proven security and privacy threat that should be eliminated from the architecture entirely. 

If opt-in is not assumed by an already made explicit choice of resolver when such a feature already complies with the existing terms of service, there is no benefit:  OpenDNS and Google Public DNS have gone out of their way to advertise particular "set your DNS here" addresses.  That goes out the window.  So why bother developing this further, since these are the parties who want it, and who have invested a large amount of time and effort into advertising these IP addresses?

Basically, neither of your opt-in choice can work.

So I think we can conclude there is a fundamental difference: 

You believe there are a significant number of users who

a)  Deliberately chose a third party resolver

b)  Chose the third party resolver to somehow prevent information leakage

and that if these can't be accomidated, you don't want the protocol.

I believe that

a)  Most users who chose a third party resolver did not do so for privacy reasons, and are already covered under a contractual relationship with the third party resolver which would enable this feature under the existing terms of service

b)  Those who did, even in the current infrastructure, made a very poor decision that does not significantly enhance their privacy and, if anything, significantly degrades their privacy protections.

And therefore the significant benefit to all the other users of third party resolvers, and the ability to make sure that third party resolvers both work with CDN-style DNS and don't have barriers to entry is far more useful than preserving what privacy protection may be lost.

> but those who use a resolver on their system or very close to it are leaking

Why do you think that using a third-party resolver is a good solution for privacy protection?  Any savings you get by having some requests cached and some requests through their resolver address are lost by giving your entire request stream to companies which specifically states it has the right to datamine the results in the terms of service.  

For at least one major provider, Google, the ability to datamine the query stream is the ONLY revenue source!

> but so is the customer experience.

I want to take advantage of existing contractual relationships between the client and third-party resolvers, yes.  Why create a new mechanism when existing mechanisms will suffice?  How much opt-in is enough?

I don't want to create an incentive for contractual relationships between CDNs and third party resolvers, because that will create barriers to entry for anyone else wanting to do "better DNS"

> data en masse to authorities?

No CDN, because of secret sauce concerns, will reveal the data to ALL interested resolvers:  This is saying "support zone transfers"-type logic to everyone.  Can you believe ANY CDN would do such a thing?  We've gone through years of advice of "disable zone transfers", and now you'd want the CDN's to enable-zone transfer equivelents?

Thus they would ONLY reveal data to pairwise agreements, which creates barriers to entry for other third party resolvers.

Do you really want to ensure that the only solution is anticompetitive?  

> fog doesn't need much blowing away.

Yes it does:  All costs are relative.  You don't go fretting about $1 budget items if you have $1M problems.  

The scale of the problem from APIs and analytics is so much greater than the information leakage you'd generate if you generated all requests through a resolver on your computer (which is far more leakage than you are worried about here).  For those who don't think its a problem, do a search in your cookie store for __utma.  Or run an IDS and look at all the "fetches" for images to google-analytics.  And content yourself with the fiction that google does not consider the IP address PII for the purpose of analytics...

Until you are running techniques to block analytics, APIs, etc, who cares about if DNS starts leaking the subnet you are on when you are using a third-party resolver, only to the authorities for the names you are query, and that already reserved the right to datamine "aggregate" query streams?

---

From: [email-masked]
Date: Wed, 3 Feb 2010 03:10:42 +0000

> Do you NOT consider explicit selection of a third-party resolver a significant opt-in action?

	hum... this leaps out.  being in a situation where your choice is:

	a) leave the computer off and read a book  
	or
	b) use the DHCP server in the hotel and get forced into using the DNS resolvers 
	   they hand you...  while never knowing if their resolvers have set the "ravish-me" bit.

	what other opt-in choice would you have?  DHCP is not tolerant of nodes that want to
	order DHCP offered services "al-cart".

--bill

---

From: Wilmer van der Gaast <[email-masked]>
Date: Wed, 3 Feb 2010 09:35:52 +0000

>           they hand you...  while never knowing if their resolvers have set the "ravish-me" bit.
How is the /24 of the (probably heavily NATted) external IP address of
a hotel you're staying at possibly showing up in packets going to
authorities a privacy concern?

Wilmer.

---

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

> Date: Wed, 3 Feb 2010 09:35:52 +0000
> From: Wilmer van der Gaast <[email-masked]>
> 
> How is the /24 of the (probably heavily NATted) external IP address of a
> hotel you're staying at possibly showing up in packets going to

"your honour, someone in that hotel bought the hashish (exhibit A) over the
internet the night that the defendant was a guest there.  we have records
showing that there were only two other guests, and sworn affadavits from
each of those guests that they do not own or use laptop computers.  the
hotel's own computers are not behind the same NAT as the guests.  so even
though the hashish dealer's web site records show only ToR connections that
night, we have a record of a DNS transaction for that hashish dealer's
address record from that hashish dealer's outsourced DNS provider."

you may think it's silly that most examples of "how could this violate my
privacy" are of illegal activities which the internet ought probably not
support in any case.  substitute the jailing of a dissident if you wish.

i think it's silly that we're circling the wagons on privacy when there are
other better reasons to label this proposal a Really Bad Idea.  are we even?

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 3 Feb 2010 06:37:04 -0800

> address record from that hashish dealer's outsourced DNS provider."

This is a ridiculous example.  If you're using TOR for HTTP, then
you're also using it for DNS.  Only the stub resolver would have the
possibility to add the user's IP address to the DNS query then, and
TOR would obviously make sure to filter that out if it was added.

> support in any case.  substitute the jailing of a dissident if you wish.

I wish you guys would have a consistent stance on privacy.  Apparently
letting sniffing attackers see your DNS traffic is of no concern, but
letting the authoritative server see it is terrifying.

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 3 Feb 2010 06:52:52 -0800

> address record from that hashish dealer's outsourced DNS provider."

This example is not only hypothetical, but rather ridiculous.  (I know I said I wouldn't respond on the privacy side, but when an example is THIS convoluted):

Anyone who's using TOR for the communications is going to use TOR for the DNS.  The nice default Tor-button does this already, IIRC, because it has to and because Tor was written by experts.  And its not our job to protect an idiot who didn't by disabling a necessary feature of TOR.

And because the resolver's log has complete information anyway, so its

"The remote authority's log says its resolver Y which identifies the hotel exactly.  The hotel's log says it was X, the defendent's mac address"

The /24 tagging along in the query is meaningless: the logs have already recorded exact IP, MAC address, etc.

And because the /24 tagging wouldn't be done: the resolver is likely to already be identifying the exact network used just by dint of its own IP.

And because the hotel is NAT'ed, the defense attorney goes:  "There are 15 hotels, 2 businesses, and 47 coffee shops in that /24".  /24 really is not precise for forensics in the days of IPv4 exhaustion.  And if the defense attorney is not able to completely destroy this with an expert, should be disbarred for malpractice.

And because if this option is ever deployed, we'd add a test in Netalyzr so you could find out anyway:  there are far FAR more nasty pillagings on most hotel networks that you SHOULD know about first.

And because if you want to worry about the courts, worry about Analytics, where the DA does a subpoena to Google to reconstruct your movements by seeing where your analytics cookies came from, allowing them to reconstruct exactly where your computer was on the network over a year's time, and about half the sites you visited that you purged out of your browser's history.  

I keep bringing this up because it matters: scale counts, and this information IS exported to google, and Google happily claims that the analytics cookies are NOT PII!?!?

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 3 Feb 2010 07:07:55 -0800

> letting the authoritative server see it is terrifying.

They don't actually care about privacy, at least real privacy.  (if you care about privacy, you flip out about google public DNS)

Rather, they don't like the idea of CDN tricks, and things which would make these tricks continue to work in the face of third party resolvers are to be opposed, so come up with any opposition possible.

Paul Vixie in particular is a zealot on DNS issues.  EG, Bind does't do 0x20, which is proven safe, and still is pretty damn acceptable on accepting AND PROMOTING glue records.

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 3 Feb 2010 07:08:45 -0800

Please accept my apologies for my flaming on this issue.

Apologies.

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 03 Feb 2010 18:08:06 +0100

> So its clear that DNS-based network localization is being used for services beyond HTTP already.  Do we want such localizations to still work well when the user is using a 3rd party DNS resolver?

Then it would make a sense to also send requested protocol in DNS query 
together with client IP address, wouldn't it?  (Not every protocol has 
it's own RRTYPE.)

Ondrej

---

From: Wilmer van der Gaast <[email-masked]>
Date: Wed, 3 Feb 2010 17:41:31 +0000

On 3 February 2010 17:08, Ondřej Surý <[email-masked]> wrote:
> together with client IP address, wouldn't it?  (Not every protocol has it's
> own RRTYPE.)
>
No, that's why we have RFC 2782. Sadly that RFC is an excellent
example of how solving problems in a way that requires work on the
client side takes a long time (where long time approaches infinity).
:-/

But yes, if you want to do that, send a SRV query. For at least XMPP
and ActiveDirectory it may work. :-) I'm all for wider adoption, but
that's well outside the scope of this draft.

Wilmer.

---

From: William Allen Simpson <[email-masked]>
Date: Wed, 03 Feb 2010 13:56:22 -0500

I almost overlooked this thread, because it was started as a reply deep
inside another thread.  Stop doing that!

> Paul Vixie in particular is a zealot on DNS issues.  EG, Bind does't do 0x20, which is proven safe, and still is pretty damn acceptable on accepting AND PROMOTING glue records.
You've impugned the integrity of one of the foremost DNS developers and
thinkers.  But I've been involved in both DNS and privacy for as long
or longer, and have a pretty consistent stance on privacy....

Paul's correct.  You're wrong.

First of all, you're misusing the term "privacy", and that alone shows
that your thinking (or lack thereof) is not to be trusted on this issue.

  1) Anonymity -- nobody can identify any party, including another party.

  2) Privacy -- only the parties involved can identify each other.

Evesdropping is a violation of privacy, and that is a concern.  However,
it's not solvable by the DNS protocol.  So, it's out of scope here.

Thirdly, any protocol element that is not "opt-in" and reveals an identity
to an uninvolved party is a violation of privacy.  Privacy requires a
choice of the party to the transaction, in both legal and security sense.

There is no difficulty with CDN that uses Internet routing to distribute
traffic.  There have been an awful lot of "stupid DNS tricks" -- they are
bad ideas.

Just because somebody has an idea on how to make money doesn't mean it's a
good idea.

---

From: Jacco Tunnissen <[email-masked]>
Date: Wed, 3 Feb 2010 22:04:08 +0100

On Wed, Feb 03, 2010 at 07:07:55AM -0800, Nicholas Weaver wrote:

>Paul Vixie in particular is a zealot on DNS issues.  EG, Bind does't do
>0x20, which is proven safe, and still is pretty damn acceptable on
>accepting AND PROMOTING glue records.

Would you mind... Please do not take your attacks to the personal level, it
doesn't help this long winded discussion at all, really. Perhaps you meant
ISC as an organization?

Jacco

---

From: "Greg Daley" <[email-masked]>
Date: Thu, 4 Feb 2010 08:10:24 +1100

Hi Jim,

(From your response)
"... Until then, it would be prudent for anyone proposing
 new EDNS options to specify how implementatons that don't
 support the option should behave. Your mileage may vary." 

Isn't that a circular argument?

If I do not implement EDN0 Option X, I need to implement the
correct behaviour for not supporting the option?

I think the focus should be on specifying how systems using
options should behave if they encounter a system which cannot
support the option.

Greg Daley

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jim Reid
> Sent: Wednesday, 3 February 2010 5:44 AM
> To: Wilmer van der Gaast
> Cc: Nicholas Weaver; [email-masked]
> Subject: [dnsext] something for RFC2671-bis
>

---

From: Paul Vixie <[email-masked]>
Date: Wed, 03 Feb 2010 21:36:30 +0000

> From: Nicholas Weaver <[email-masked]>
> Date: Wed, 3 Feb 2010 07:07:55 -0800
> 
> They don't actually care about privacy, at least real privacy.  (if you
> care about privacy, you flip out about google public DNS)

that's why i said, privacy is the least of my worries in matters of DNS,
and i think it's silly to bring it up in conjunction with this proposal.

> Rather, they don't like the idea of CDN tricks, and things which would
> make these tricks continue to work in the face of third party resolvers
> are to be opposed, so come up with any opposition possible.

that's what they told me when i was opposed to sitefinder's *.COM wildcard.
my answer then, as now, is "you've got me mixed up with somebody, i'm trying
to keep the system working and to keep it expandable in the future, and what
you're trying to do would act as a prior restraint on both of those goals."

> accepting AND PROMOTING glue records.

i'm not sure how you were justifying the (vixie = isc && isc fears 0x20 &&
vixie wrote the 0x20 draft) logic here.  but vixie != isc, and in any case
bind will get 0x20 in due course.  as to glue promotion, florian has filed
a bug report and that too will get fixed in due course.

---

From: John Payne <[email-masked]>
Date: Tue, 2 Feb 2010 15:51:42 -0500

> [1] Stub resolvers that don't want their address info disclosed. Or those who may want to send that info (how??) but are talking to resolving servers who don't. Or the resolving servers tamper with…

The choice exists to use a recursive nameserver which has the behavior you desire without modifying the stub resolver at all.

> [2] Authoritative servers who can't/won't speak this EDNS0 option. The draft does not specify how they should behave.

If this idea can't be made to work without any change to Authoritative servers who can't/won't speak this EDNS0 option, then it has no business progressing beyond this draft.

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 3 Feb 2010 14:42:05 -0800

Again, apologies for my inappropriate response.

---

From: Jim Reid <[email-masked]>
Date: Wed, 3 Feb 2010 23:20:14 +0000

> correct behaviour for not supporting the option?

That's one interpretation. However it's not a good one as it obviously  
makes no sense.

It trust the following makes things clearer. Until such times as an  
RFC provides a formal mechanism for a server to indicate they do not  
support a specific EDNS option, those proposing a new option should  
ensure there's a mechanism for the EDNS response to show that the  
option is supported. This could be something as simple as an option- 
specific flag bit or response code in the reply. So if it's missing or  
not set, the client should proceed on the basis that the server it  
queried did not understand/support that option.

> options should behave if they encounter a system which cannot

Well that's certainly part of it. But how will the clients who want to  
use a funky new option find out they've encountered something which  
can't or won't support that option?

---

From: "Greg Daley" <[email-masked]>
Date: Thu, 4 Feb 2010 13:12:22 +1100

Hi Jim,

I think you and I are in agreement, but have been missing each other
slightly

> ...This could be something as simple as an option- 
> specific flag bit or response code in the reply. So if it's 
> missing or not set, the client should proceed on the basis that
> the server it queried did not understand/support that option.

This is good because the responsibility is on the option user, and
makes use of positive acknowledgement.

> Well that's certainly part of it. But how will the clients 
> who want to use a funky new option find out they've encountered
> something which can't or won't support that option? 

Unless the protocol can stimulate a response related to the option,
you cannot create a negative acknowledgement for a protocol option
which is unsupported by the recipient.

The system you mentioned above is a good one, since it relies on 
positive acknowledgement.

Your earlier post didn't seem to make the distinction, and where
placing requirements on protocol developers, its important to be
clear of the limitations of their environment.

Whether that was the case or only in my head, I am satisfied now.

Thanks,

Greg Daley

---

From: [email-masked]
Date: Thu, 4 Feb 2010 03:33:42 +0000

> authorities a privacy concern?

	the privacy concern was releated tot he line you elided - the (in)ability
	to select a third party.  Some folks like using DNS resolvers/forwarders
	in the same fashion as some use TOR onion routers - as a way to preserve
	anonymity.  Not being able to chose your DNS resolution path is problematic.

--bill

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 3 Feb 2010 20:46:09 -0800

>        anonymity.  Not being able to chose your DNS resolution path is problematic.

Just as there are TOR routers today, I'm sure there will be open DNS
caches that don't use this option.

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 3 Feb 2010 21:38:45 -0800

On Wed, Feb 3, 2010 at 9:36 PM,  <[email-masked]> wrote:
>        they don't have to be open...
>        the trick is, how does the hobo, migrant stub resolver
>        -know- that the sole-source IMR/cache that is offered
>        does or does -NOT- have this tracking collar on?

How does it know whether or not the cache is shipping all of its query
logs to the FBI/CIA right now?

---

From: [email-masked]
Date: Thu, 4 Feb 2010 05:36:43 +0000

--bill

---

From: [email-masked]
Date: Thu, 4 Feb 2010 05:45:58 +0000

> logs to the FBI/CIA right now?

	well - if one is allowed to choose their first hop IMRs,
	there is a much better chance wiretapping on the first hop
	out.

--bll

---

From: Alex Bligh <[email-masked]>
Date: Thu, 04 Feb 2010 11:59:57 +0000

--On 3 February 2010 13:38:01 +0000 Paul Vixie <[email-masked]> wrote:

> i think it's silly that we're circling the wagons on privacy when there
> are other better reasons to label this proposal a Really Bad Idea.

+1. Whilst I remain somewhat skeptical about the proposal, I am
pretty relaxed about the privacy aspects.

-- 
Alex Bligh