Subject: [DNSOP] measurements using the EDNS-Client-Subnet extension

From: Florian Streibelt <[email-masked]>
Date: Mon, 8 Jul 2013 10:40:15 +0200

My mail from Wed, 26 Jun 2013 18:01:31 +0200 did not came through:

Hello,

in our work with the EDNS-Client-Subnet extension we noticed that it offers unique measurement
opportunities. Below you find the abstract to our paper on "Unintended Consequences:
Exploring EDNS-Client-Subnet Adopters in your Free Time" where we used the client IP
extension to explore the mapping of client-IP's to server-IP's in CDNs including google and
edgcast.

We mentioned this to Ted Lemon and Andrew Sullivan, who suggested that this work may be of interest to
the wider audience of both DNS related working groups (sorry for cross posting).

As the next IETF meeting is in Berlin (and we are based in Berlin) I would be happy taking
the chance of presenting the paper at the upcoming meeting. Any comments?

cheers,
  Florian

Abstract of "Unintended Consequences: Exploring EDNS-Client-Subnet Adopters in your Free Time";

The recently proposed DNS extension, EDNS-Client-Subnet (ECS), has been quickly
adopted by major Internet companies such as Google to better assign user
requests to their servers and improve end-user experience.  
In this paper, we show that the adoption of ECS also offers unique, but likely
unintended, opportunities to uncover details about these companies' operational
practices at almost no cost.  A key observation is that ECS allows everyone to
resolve domain names of ECS adopters on behalf of any arbitrary IP/prefix in the
Internet. In fact, by utilizing only a single residential vantage point and
relying solely on publicly available information, we are able to (i) uncover
the global footprint of ECS adopters with very little effort, (ii) infer the
DNS response cacheability and end-user clustering of ECS adopters for an arbitrary
network in the Internet, and (iii) reveal the mapping of users to server
locations as practiced by major ECS adopters.  While pointing out such new
measurement opportunities, our work is also intended to make current and future
ECS adopters aware of which operational information gets exposed when utilizing
this recent DNS extension.

-- 
Florian Streibelt
Chair "Intelligent Networks" (INET)
TEL 16
Technische Universität Berlin
Ernst-Reuter-Platz 7
10587 Berlin
GERMANY

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 8 Jul 2013 11:37:14 +0200

On Mon, Jul 08, 2013 at 10:40:15AM +0200,
 Florian Streibelt <[email-masked]> wrote 
 a message of 42 lines which said:

> The recently proposed DNS extension, EDNS-Client-Subnet (ECS), has
> been quickly adopted by major Internet companies such as Google to
> better assign user requests to their servers and improve end-user
> experience.

I just parsed the requests of a TLD authoritative name server and I
find very little use of EDNS options and none of option 8. Is it
because I do not understand how this option is supposed to work?

---

From: Florian Streibelt <[email-masked]>
Date: Mon, 8 Jul 2013 11:51:43 +0200

Am Mo, 08.07.13 um 11:37:14 Uhr 

> because I do not understand how this option is supposed to work?

The extention is only visible when you query an authorative server using an ECS capable client, like a patched dig. The server will then notice you are using that extention and reply accordingly.
The TLD servers make - as far as I know - no use of this but the authoritative server for google.com for example does.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 8 Jul 2013 11:55:10 +0200

On Mon, Jul 08, 2013 at 11:51:43AM +0200,
 Florian Streibelt <[email-masked]> wrote 
 a message of 16 lines which said:

> The extention is only visible when you query an authorative server
> using an ECS capable client, like a patched dig. 

Yes, that's what I thought. So you confirm no software resolver today
sets this option? If so, it is not really deployed.

---

From: Florian Streibelt <[email-masked]>
Date: Mon, 8 Jul 2013 12:03:28 +0200

On Mon, 8 Jul 2013 11:55:10 +0200

> sets this option? If so, it is not really deployed.

ah, now I get your question. 

Indeed, it is not deployed on the "client side" but public dns providers like google rely on it heavily by using this to transport the client IP address, or parts of it, from the frontend servers - reachable as 8.8.8.8 - to the backend servers and whitelisted third party authoritative resolvers.

By this the authoritative server sees the subnet of the client that is using google as forwarder, although it is only contacted by a google backend server.

---

From: ice jew <[email-masked]>
Date: Mon, 8 Jul 2013 18:15:20 +0800

There is 2 questions about deployment.
1,Is there any other  recursive resolver that adopts ECS  except Google and
OpenDNS?
2,Is there any open source solution of recursive resolver that supports ECS?
在 2013-7-8 下午5:56，"Stephane Bortzmeyer" <[email-masked]>写道：

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Florian Streibelt <[email-masked]>
Date: Mon, 8 Jul 2013 12:44:03 +0200

On Mon, 8 Jul 2013 18:15:20 +0800

> 1,Is there any other  recursive resolver that adopts ECS  except Google and

That is not easy to tell. In the paper we focused on the authoritative NS.
The reason is that e.g. google and opendns manually whitelist the authoritative nameservers they send ECS enabled queries to prevent failures in name resolution.
(Some resolvers seem to behave quite strangly if they don't understand the extention.)

> 2,Is there any open source solution of recursive resolver that supports ECS?

I am not aware of any - for testing purposes I did a rough patch against a dns proxy but thats only usable for debuggging and not public.
This makes it especially hard to get whitelisted to find answers to your first question.

---

From: ice jew <[email-masked]>
Date: Mon, 8 Jul 2013 18:57:49 +0800

I think ECS is good for CDNs. But it brings such a great extra load to both
the recursive resolver and the authoritative name servers.
The first question is to check if there're any other public recursive
resolver that supports ECS so I could ask it to enable the ESC white list
for our domain names.
The second question is to check if there is any research on how to increase
the popularity of ECS and how to make ECS higher performance.

Anyway ,thanks for your answer.

On Mon, Jul 8, 2013 at 6:44 PM, Florian Streibelt <[email-masked]
> wrote:

> The reason is that e.g. google and opendns manually whitelist the
> authoritative nameservers they send ECS enabled queries to prevent failures
> in name resolution.
> I am not aware of any - for testing purposes I did a rough patch against a
> dns proxy but thats only usable for debuggging and not public.

---

From: Florian Streibelt <[email-masked]>
Date: Wed, 10 Jul 2013 03:19:54 +0200

On Mon, 8 Jul 2013 12:44:03 +0200

> I am not aware of any - [...]

It seems I was not right, from the PowerDNS Release notes at http://doc.powerdns.com/html/changelog.html#changelog-auth-3-2 in the paragraph "3.10. PowerDNS Authoritative Server 3.0" it reads:

"Add support for EDNS option 'edns-subnet', based on draft-vandergaast-edns-client-subnet (commit 2226, commit 2228, commit 2229, commit 2230, commit 2231, commit 2233)."

---

From: ice jew <[email-masked]>
Date: Wed, 10 Jul 2013 11:02:18 +0800

Well  this seems to be an authoritative version but not a recursive version.
在 2013-7-10 上午9:20，"Florian Streibelt" <[email-masked]>写道：

> It seems I was not right, from the PowerDNS Release notes at
> http://doc.powerdns.com/html/changelog.html#changelog-auth-3-2 in the
> paragraph "3.10. PowerDNS Authoritative Server 3.0" it reads:
>
> "Add support for EDNS option 'edns-subnet', based on
> draft-vandergaast-edns-client-subnet (commit 2226, commit 2228, commit
> 2229, commit 2230, commit 2231, commit 2233)."