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

From: Wilmer van der Gaast <[email-masked]>
Date: Wed, 27 Jan 2010 23:56:45 +0000

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.

Regards,

Wilmer van der Gaast
Carlo Contavalli
Google

Sean Leach
Darryl Rodden
Neustar/UltraDNS

>From i-d-announce:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> 	Title		: Client IP information in DNS requests
> 	Author(s)	: C. Contavalli, W. van der Gaast, S. Leach, D. Rodden
> 	Filename	: draft-vandergaast-edns-client-ip-00.txt
> 	Pages		: 20
> 	Date		: 2010-1-26
> 	
>    This draft defines an EDNS0 extension to allow Authoritative
>    Nameservers to return varying replies based upon the network address
>    of the client that initiated the query rather than of the client's
>    Recursive Resolver.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-vandergaast-edns-client-ip-00.txt

---

From: Colm MacCárthaigh <[email-masked]>
Date: Thu, 28 Jan 2010 00:59:47 +0000

> Maastricht later this year.

+1 - As someone with an interest in writing an implementation, it
would be great to know at what stage an EDNS option code may be
assigned, if appropriate.

> Comments are more than welcome.

Section 1; Instead of "most nameservers" maybe "most such nameservers" ?
                "at best sub-optimal" -> "sub-optimal" but it's just a nit.

Section 2; The term "VLSM" (variable lengh subnet mask) may be more
technically correct than the use of the term "CIDR" - though I don't
think it matters much, the meaning is clear.

Section 4.1; The question naturally arises as to what happens when
there is a mismatch between the address-family used for the DNS query,
and the eventual address family of the client request. However as
these addresses may be considered to be located in similar topologies,
I don't think this is a hindrance and endorse the simplicty chosen in
the I-D.

On the subject of security;

"   A Recursive Resolver set up to serve clients in private address space
  (as defined in [RFC1918] and [RFC4193]) MUST NOT add edns-client-ip
  options containing a non-public address to its queries.  An edns-
  client-ip option MUST never contain a non-public address."

I think more general advice may be useful, rather than wording it as
"non-public" maybe come at it the other way and say;

 "A Recursive Resolver SHOULD add edns-client-ip options corresponding to
  publically routeable IP addresses only".

additionally, for better caching efficiency, it may be worth adding
text along the lines of;

 "Where the operators of a recursive resolver are aware of a client's
network routing policy, adopters are encouraged to ensure that a
NETMASK value corresponding to the largest network subject to a common
internet routing policy
should be used".

In other words, if it's a large ISP, and they know that an entire /20
is routed identically, then advertising the /20 makes the most sense
and results in more cache hits. This would pressure auth servers to
correctly aggregate their datasets, rather than the back-and-forth
negotiation of NETMASK which the I-D permits, but I think this might
be a positive thing :)

Sections 4.1/4.2:

 I think more detail is needed on how the system works when the
netmask returned is higher.  For example;

   client 192.0.2.53 makes query
   resolver sets option as 192.0.0.0/16
   auth server responds with 192.0.0.0/24

what should the resolver do in this case? 192.0.0.0/24 doesn't
correspond to a network 192.0.2.53 is in, but should it use the answer
anyway? What goes in the cache? The I-D says;

" A Recursive Resolver MUST return this entry from cache only to
queries that do not allow a higher NETMASK to be forwarded."

but does that mean this response should be cached for 192.0.2.53 too,
if it doesn't allow a higher netmask to be forwarded.

Section 8;

I would be more stern about one thing;

   "Authoritative nameservers MUST NOT use the contents of the
edns-clientip option as a means of access-control."

experience from HTTP and X-Forwarded-For has shown that people will do this :)

--
Colm

---

From: Paul Vixie <[email-masked]>
Date: Thu, 28 Jan 2010 05:46:29 +0000

if we're going to add client identity to the query, can we do so in a more
general way?  i'd like to know lat-long, country, isp, language, and
adult/child.  and the ip address should be multiprotocol, covering ipv6.

---

From: Tony Finch <[email-masked]>
Date: Thu, 28 Jan 2010 14:32:51 +0000

> adult/child.  and the ip address should be multiprotocol, covering ipv6.

And implementation name and version number?

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: Paul Vixie <[email-masked]>
Date: Thu, 28 Jan 2010 16:13:50 +0000

> From: Carlo Contavalli <[email-masked]>
> Date: Thu, 28 Jan 2010 16:07:05 +0000
> 
> On Thu, Jan 28, 2010 at 5:46 AM, Paul Vixie <[email-masked]> wrote:

> The doc does cover ipv6, and allows for other protocols to be supported,
> if necessary.

great.

> Rather than adding client identity, what we're trying to do is address
> a concrete problem that affects CDNs, open resolvers, and many large
> sites, that for whatever reason, use the source ip of the query to
> determine which reply to return to the user.

i don't think that's a general enough solution to be worth standardizing.
please investigate the larger context of client identity, beyond the needs
of CDN's.

---

From: Carlo Contavalli <[email-masked]>
Date: Thu, 28 Jan 2010 16:07:05 +0000

> adult/child.  and the ip address should be multiprotocol, covering ipv6.
The doc does cover ipv6, and allows for other protocols to be
supported, if necessary.

Carlo

---

From: Sean Leach <[email-masked]>
Date: Thu, 28 Jan 2010 09:25:59 -0700

> please investigate the larger context of client identity, beyond the needs

I have to agree with and Carlo/Wilmer here (no surprise) that we should keep this focused as this is a real (and growing) problem that we (UltraDNS) face all the time as well.  Both from our anycast recursive service and for our auth DNS customers whose end users utilize OpenDNS, Google DNS etc.  There are more and more anycast recursive systems popping up daily it seems, so the problem is only going to get worse.

Adding identity etc. feels like a different problem that doesn't need to be solved with this standard.  Just my .02

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 28 Jan 2010 08:41:17 -0800

>please investigate the larger context of client identity, beyond the needs

OK, I'll bite. I thought your first message was you using your dry humor voice; now it seems like you really meant it.

What technical problem would identifying the lat-long of the requester solve? I'm not asking "is there someone who would want to collect this information for later marketing purposes"; I'm asking what technical problem would knowing that information solve.

Ditto for the other things you listed, of course, but they seemed less likely (to me) to have an answer to the question.

--Paul Hoffman, Director
--VPN Consortium

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 28 Jan 2010 08:54:57 -0800

> please investigate the larger context of client identity, beyond the needs

ANY system which desires that a request be routed to the "best" instance which is appropriate to handle the request, without the need to introduce divergent names (which impacts user experience), detailed protocol changes to HTTP and a host of other protocols, front-end redirection, or IP routing (multipathing), would greatly benefit from knowing the requesting client's IP address in the name lookup, and can ONLY route 

That may "only" be CDN, but CDN or CDN-like tricks are VERY important on the current Internet, and without the ability for CDN's to produce meaningful values, this limits the ability of third-party DNS resolver providers to do any good: one of the common complaints about OpenDNS is it "makes YouTube slow".

However, on this draft I'd recommend that resolvers implementing this should do a fallback model:

When initially querying any new authority, the resolver is advised that it should conduct both a query with this EDNS0 extension and, if no result is seen in a shortened timeout (1s) a second one without, using different transaction IDs and port numbers, and use a TRW-style count of success/failure to determine whether the authority accepts such records or not.  

If there are more than T such failures for an authority, it should be noted as not supporting this EDNS0 extension in a broken manner (causing failure), and this extension should not be used in subsequent communications with this authority.

Thus authorities which react badly to unknown EDNS0 extensions will still be reachable, and after only a few short timeouts, not experience any worse resolution latency.

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 28 Jan 2010 09:00:12 -0800

> What technical problem would identifying the lat-long of the requester solve? I'm not asking "is there someone who would want to collect this information for later marketing purposes"; I'm asking w…

It would be really nice for (ab)using DNS as an exact match database:

dig TXT food.whereami.com -> records of the nearby resteraunts.

Only slightly tounge-in-cheek.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 28 Jan 2010 17:18:07 +0000

> From: Sean Leach <[email-masked]>
> Date: Thu, 28 Jan 2010 09:25:59 -0700
> 
> > i don't think that's a general enough solution to be worth
> > standardizing.  please investigate the larger context of client
> > identity, beyond the needs of CDN's.
> 
> I have to agree with and Carlo/Wilmer here (no surprise) that we should
> keep this focused as this is a real (and growing) problem that we
> (UltraDNS) face all the time as well.  Both from our anycast recursive
> service and for our auth DNS customers whose end users utilize OpenDNS,
> Google DNS etc.  There are more and more anycast recursive systems
> popping up daily it seems, so the problem is only going to get worse.
> 
> Adding identity etc. feels like a different problem that doesn't need to
> be solved with this standard.  Just my .02

if we're going to add something to a global protocol and a global system,
we have a burden to do good engineering, not just offer point solutions
that help a single industry.  there's a reason why web browsers can state
their preferred language, which is customized content.  if we're going to
customize dns responses at all (which is controversial) then we have to
allow for the possibility that some dns content producers will want to
customize based on things beyond just client ip.

(also, many client-ip addresses will be nat'd, and in that sense, ip is no
longer end to end, and so including a client-ip in the query is a layering
violation beyond just its fealty to dns incoherency.)

---

From: Alex Bligh <[email-masked]>
Date: Thu, 28 Jan 2010 18:10:09 +0000

I have read the draft.

Re Paul's comment:

> violation beyond just its fealty to dns incoherency.)

I had thought your "also" would be the main justification. With carrier
grade NAT and so forth appearing as v4 address exhaust, it's going to
become less and less reliable to map IP address to a specific geography,
and more and more likely a client IP address is "192.168.0.2"
(where both recursive resolver and client are behind the same NAT,
e.g. office LAN with NAT), in which case per the draft you get
nothing (as opposed to a GPS coordinate).

I'm nervous about overloading transport identifiers as a source of
geographic information in the first place, particularly it's yet
another thing middleboxes will decide, rightly or wrongly, they
need to fiddle with. Not allowing something which is a better indicator
of geography (e.g. GPS coordinate) seems to compound the problem.

More generally:

* I am concerned that the IP included is the transport layer IP
  visible to the client/resolver. That might have little to do
  with the IP address from which a subsequent (e.g.) http connection
  appears to originate.

* I am concerned that even if you put in (e.g.) GPS, that gives
  you geographic proximity data, which may not correlate well
  to best match in terms of network topology.

* I am concerned the privacy provision is neither sufficient
  nor harmless. It may be insufficient as even at a /24 level
  it is possible to identify a large organisations outbound
  NAPT external IP range. It may not be harmless as two /25s
  may be in different geographies. Given people make DNS
  queries in general so they can communicate with the (e.g.)
  A record given, and the (e.g.) http server on that IP address
  can log connections, what privacy is lost by transmitting
  the address given in full? Wouldn't it be simpler to say
  that the querying client MAY (if it wishes) include a net mask
  showing which bits are accurate, and bits outside that
  mask are to be ignored and are undefined? That way, if a
  client wants to give incomplete information, it may. You
  leave this choice to the recursive resolver, I think, not
  the client, and require that at least some bits are cleared.

* I am concerned about section 4.3 causing algorithmic
  complexity, and an explosion in cache size. If NETMASK
  is set small, you will get a ton of records for
  www.google.com cached. That's going to be unworkable,
  which will encourage large settings for NETMASK.

I have to wonder whether the simpler solution to fix this is
not just to deploy more resolvers closer to the edge.

-- 
Alex Bligh

---

From: Paul Vixie <[email-masked]>
Date: Thu, 28 Jan 2010 18:42:38 +0000

> Restricting the technique to Client IP seems very reasonable, mainly
> because it's the most prevalent such factor today. But also because
> the aim here should be to improve DNS as a naming mechanism for the
> internet, not to make it arbitrary client-identification mechanism.
> That doesn't seem like poor engineering.

it does if many clients are behind NAT.

it does if there are other factors that other industries outside CDN would
use to manage their incoherency.

it's not worth a global upgrade to DNS in its current form.

it may be too dangerous in any form but that's a separate issue.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Thu, 28 Jan 2010 18:38:00 +0000

> customize based on things beyond just client ip.

Customising responses is already a de-facto part of shared internet
infrastructure. It seems like a standard that mitigates the
sub-optimalities of this approach and improves service for users and
providers alike is desireable. The alternative is non-interoperable
and behind-the-scenes ad-hoc mechanisms.

> violation beyond just its fealty to dns incoherency.)

I think the draft takes explicit account of this issue.

-- 
Colm

---

From: Colm MacCárthaigh <[email-masked]>
Date: Thu, 28 Jan 2010 18:53:53 +0000

> it does if many clients are behind NAT.

 If many clients are behind NAT then a resolver operator may ensure
that the NAT IP is forwarded in the option. It doesn't seem like a big
problem.

> use to manage their incoherency.

I can see the case for LOC forwarding ... some do forward answers
based on GeoIP lookups (it's a common PowerDNS configuration for
example). But it seems like directing clients to internet nodes based
on non-internet-routing criteria is itself poor engineering.

> it's not worth a global upgrade to DNS in its current form.

I don't think a global upgrade is being proposed. More likely; a
relatively small number of large resolver operators, and interested
authoritative DNS destinations (e.g. CDNs) would utilise the option.
In many cases, such operators may already be using non-standardised
mechanisms to achieve the same effect. I think it's better for the
internet that there be a published, interoperable, solution which is
well engineered for efficiency, efficacy and privacy. It would be
disappointing were this not within the remit of a task force charged
with engineering the internet.

-- 
Colm

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 28 Jan 2010 11:02:50 -0800

> it does if many clients are behind NAT.

No it doesn't, because the global NAT'ed IP address is still the network closeness metric that is probably most desirable.

EG, even if Comcast put everyone in Napa behind a single NAT'ed IP address, that external IP address is a VERY good locator for things like Akamai, Youtube, etc etc etc etc.

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

> it may be too dangerous in any form but that's a separate issue.

Because you can do it with only changes to recursive resolvers and authorities, with resolvers understanding where and how authorities might fail, you can mitigate these dangers.

---

From: Ted Hardie <[email-masked]>
Date: Thu, 28 Jan 2010 11:07:18 -0800

Howdy,

The draft currently says:

   Authoritative Nameservers of most major web sites today return
   different replies based on the perceived vicinity of the user to a
   particular location and knowledge of available resources.  This
   significantly reduces the overall latency of connections established
   by the end user and optimizes network resource usage.

   To find the best reply for a given query, most nameservers use the IP
   address of the incoming query to attempt to establish the location of
   the end user.

This seems to mix two different motivations, based on two different
ideas about locality.  In the first, you want to provide data from the HTTP
server to the end user along the path with the lowest possibly latency,
so you want to do some lookup of the relationship between the client's
network location and the list of available servers' locations before providing
the DNS response.  The first 24 bits of the client's IP address are used
to determine this network location.

The second motivation is to return different content based on geographic
location and the likely implications for default language, character sets, and
so on.  For that motivation, you want to associate the client with a server
having that data as quickly as possible--without, for example, doing a
3xx redirect after reading the client's language preferences in their first
request.

I would be personally surprised to find that the first 24 bits of an IP address
of the client are actually better at the association needed for your
first motivation
than the full IP address of the querying resolver, but I've been
surprised before.
Minimally, you'd seem to me to need to do something to figure out what
an "external" value of an IP address for that host was when the
resolver populated
that field for hosts behind NATs.  If the client did not have one (yet), a
heuristic population of the first 24 bits of the field seems possible
but mighty
unlikely to be terribly accurate (beyond the accuracy of the querying resolver's
IP anyway).  If you're going to simply population it with the first 24
bits of the
NATted address, this seems to be of pretty low utility.

The second motivation actually takes you straight into GEOPRIV territory, and
it's not clear to me at all how a client would opt-in to revealing geolocation
in some DNS queries and not all, given how applications typically interact
with DNS libraries.  There's some serious fun on the privacy legal fronts
in front of you there, should you decide to take up the idea of actually having
the geolocation directly disclosed, rather than inferred.  If you
leave it inferred,
you still seem to me to have the NAT problem to noted above.

Can you clarify which motivation is driving this draft?

regards,

Ted Hardie

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 28 Jan 2010 11:13:29 -0800

> nothing (as opposed to a GPS coordinate).

Actually, I disagree.  The client still has an external IP address, which should be used if the resolver is outside the nat and, if inside the NAT, the resolver should provide either the external IP address (if known) or no information.

Even in the presence of carrier-grade NAT and both cases of resolver location, the external IP address is a very good approximation of "close" in NETWORK terms, which is what's really needed for CDNs and all this to work right.

I think of this proposal as "provide a strong indication of NETWORK location", which NATs would not interfere with.

> with the IP address from which a subsequent (e.g.) http connection

Only VERY rarely.  Very few users in our observations with Netalyzr are behind manually or automatically configured proxies which route traffic through a different address from the remainder of their network traffic (<3%), with 1/4 of those having the proxy in the same /24 subnet.

And those who are privacy concious can route DNS requests through the same proxy or similar proxies, which you'd want to do anyway because it is network-closeness to the proxy that counts anyway.

> which will encourage large settings for NETMASK.

Memory is cheap.  Seriously, who should worry when any resolver big enough to have this issue is going to be a cluster:  Lets say I have a open recursive resolver for EVERYONE, and 1000 names uses this and are queried by EVERYONE, and I have netmask set to /24.

The total caching space required is 16 Giga-entries.

> not just to deploy more resolvers closer to the edge.

Actually, that IS the fix:  Use the ISP's recursive resolver.

This is necessary if you want to use something OTHER than the ISP's recursive resolver to work well on today's Internet.

Do you want third-party DNS providers to not suck for youtube, akamai, Google, and a good fraction of the net people use every day?  If so, you need this.

---

From: Wilmer van der Gaast <[email-masked]>
Date: Thu, 28 Jan 2010 19:25:02 +0000

Hello Ted,

> 3xx redirect after reading the client's language preferences in their first
Our motivation is purely to improve the ability of authoritative
nameservers to send users to a nearby server. Although indeed the IP
address of the recursive resolver is often enough to do this, we've
seen several cases where it isn't. Think of ISPs with big networks
without setting up nameservers everywhere, or of open resolvers.

> that field for hosts behind NATs.

The I-D specifically disallows exactly that. Resolvers behind NAT
should not need this option at all if they do the recursion
themselves, since the authoritative nameservers will find enough
accuracy in the packet source IP addresses already.

Most people simply don't run their own recursive resolver though.

Regards,

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

---

From: Paul Vixie <[email-masked]>
Date: Thu, 28 Jan 2010 19:45:08 +0000

> From: Nicholas Weaver <[email-masked]>
> Date: Thu, 28 Jan 2010 11:13:29 -0800
> 
> This is necessary if you want to use something OTHER than the ISP's
> recursive resolver to work well on today's Internet.

i love how somebody else (CDN providers) violate all existing assumptions
(by creating requestor-specific DNS replies) which then makes the Internet
work "less well" for lots of people... who are then constrained from doing
what were previously reasonable things (like using distant recursive servers).

> Do you want third-party DNS providers to not suck for youtube, akamai,
> Google, and a good fraction of the net people use every day?  If so, you
> need this.

if youtube and akamai and google want to suck, let them suck.  they weren't
the first movers and they won't be the last and redrawing the protocol to
support their flawed technical model is not in the global system's interest.

this incoherency should be dealt with more harshly, perhaps by minimizing
TTL to 5 minutes, and sharing a single DNS cache across global providers.

any CDN who relies on what i call "stupid DNS tricks" to deliver their
advantage should upgrade to something at the WWW layer, and leave DNS alone.

especially with DNSSEC coming.

---

From: Ted Hardie <[email-masked]>
Date: Thu, 28 Jan 2010 11:55:00 -0800

> without setting up nameservers everywhere, or of open resolvers.

On the first point, you're looking at the case where an ISP is deploying
nameservers such that there is a limited relationship between the
placement of the nameserver making a query to the CDN and the
placement of the original client; hierarchies of nameservers bubbling
up to a few at the top would do that as would some other deployments.
But why is a protocol hack the right answer here, rather than a NANOG
(RIPE/APRICOT/AFnog/et al)presentation that describes the
consequences and encourages the use of nameserver deployments
that match the need?  Presumably the ISPs want fast service from
CDNs and good access to GOOG so as to avoid customer complaints.
They don't even need new boxes here; source IP address selection in the queries
sent outbound can handle this as easily as a new field (yes, that means
routing addresses for addresses in multiple subnets back to the querying server,
but that's hardly rocket science).

Third party resolvers are a different case, and too many of them are being
used because of privacy concerns for me to be overly sanguine about
that use case.  I think you'd find their users opt-ing out of that if the choice
were made.  And that's the crux of the problem here--this is encouraging
a part of the infrastructure to pass an association about the query stream
to an upstream that they didn't before.  Sure, that can be used to provide
better service.  But it can be used for other things as well, and there seems
to be no mechanism provided to allow the client to signal its willingness or
unwillingness to have this invoked on its behalf; without that, I would be
somewhat reluctant to see it in the wild.

regards,

Ted Hardie

---

From: Alex Bligh <[email-masked]>
Date: Thu, 28 Jan 2010 19:51:27 +0000

Nicholas,

> Only VERY rarely.  Very few users in our observations with Netalyzr are
> behind manually or automatically configured proxies which route traffic
> through a different address from the remainder of their network traffic
> (<3%), with 1/4 of those having the proxy in the same /24 subnet.

I am surprised if that is the case and wonder whether you are reading
my sentence in another way. So, e.g. take this set up

                                 192.168.0.2
            192.0.2.0/24       |------------ Resolver
  Internet <-----------[NAT]---|
                               |------------ Client
                                 192.100.0.3

Now, the client IP address in the DNS query is going to 192.100.0.3.
The resolver has no (reliable) way for finding out its external
IP address. It may heuristically determine it is 192.0.2.1 (say)
but that presumes that it doesn't have (e.g.) a forwarder configured.
However, the current draft says it should use 192.168.0.2, but
for the fact that is RFC1918 space, and it should thus discard
it. Best case, the subsequent http connection (or whatever) appears
to come from 192.0.2.0/24.

If you think my using NAT is cheating, then consider the example
of (say) the university with no NAT, but a squid proxy. What's
to say their internal resolvers are on the same /24 as the
squid proxy?

> Memory is cheap.  Seriously, who should worry when any resolver big
> enough to have this issue is going to be a cluster:  Lets say I have a
> open recursive resolver for EVERYONE, and 1000 names uses this and are
> queried by EVERYONE, and I have netmask set to /24.
>

Fair point re memory, but cache misses cost more than memory. They result
in higher load upstream.

> recursive resolver to work well on today's Internet.

I was presuming one problem is that the ISP's recursive resolver
is not topologically close to the source, given the draft authors
say:
:    When the Recursive Resolver does not use an IP address that appears
:    to be topologically close to the end user, the results returned by
:    those Authoritative Nameservers will be at best sub-optimal.

but if the whole problem is people using a DNS provider other than
the one they are "intended to" ...

> Google, and a good fraction of the net people use every day?  If so, you

... my answer would be "don't do that then". Either:
a) run your own recursive resolver on your local box (which is easy
   enough to do); or
b) run one on your own subnet; or
c) accept that if you use someone else's local resolver you will
   suffer

I suspect the reasons for using third party DNS providers are:

1. DHCP results in a dysfunctional resolver (e.g. the middlebox
   broken resolver). See draft-bellis-dns-recursive-discovery for
   a better way around that.

2. Their ISP's nameserver is broken/evil. I'm happy to leave that
   for the market to fix, rather than standardize a behavioural
   change in every caching resolver.

-- 
Alex Bligh

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 28 Jan 2010 12:16:57 -0800

> my sentence in another way. So, e.g. take this set up

No, in that case, the resolver just reports NO IP address, and the internet relies on the external IP address being valid.  So there is no problem in that case.

> to say their internal resolvers are on the same /24 as the

They are, however, in the same closeness of network, so heck, the other side is quite happy.

I thought in particular you were referring to a case more like this

Client -> Non HTTP has an external IP of W.X.Y.Z
     \
      \-> HTTP proxy, HTTP traffic has an external IP at A.B.C.D

THIS is the case where the client's IP address, as externally viewed, differs for HTTP vs non-HTTP traffic.  That does occur, but its rare (~3% in measurements).  And when it does occur, the client could just as easily (and may very well already for the web browser) issue the DNS requests through the proxy as well.

> Fair point re memory, but cache misses cost more than memory. They result

Thus what you want is the authority to be able to specify a broader netmask, if the upstream authority cares about load.  Do that, and the few upsteam authorities which would care about this could be able to prevent it.

> the one they are "intended to" ...

It isn't as close as one would LIKE, eg, comcast's list:
http://dns.comcast.net/dns-ip-addresses2.php

But its 'good enuf for CDN work'.  Better would be better, but the ISP resolvers are already giving out ENOUGH information for the CDN-like tricks to largely work.

> a) run your own recursive resolver on your local box (which is easy

5% of the rather tech savvy Netalyzr users.  And that probably counts a lot of businesses behind single IP NATs.

> c) accept that if you use someone else's local resolver you will

So your advice to my mom is "Tough", basically.  Using a good third-party resolver is a minor change, your recommendations are much harder to instruct my mom to do.

>  change in every caching resolver.

3:  The third party resolver offers a significant value add, such as programmable blocking, automatic blocking of malicious sites, and far more agressive prefetching of common names and related information to speed up results.

People are NOT using OpenDNS, UltraDNS, or Google's public DNS because their ISP's resolver is broken/evil, they are using it because they offer real perceived benefits.

And this ISNT'T a behavioral change for every caching resolver.  One of the beauties of this scheme is ONLY the third-party resolvers and authorities which desire this behavior will need to implement this at all.  In fact, the Bind developers could say "No way in hell will WE implement this", but a few big recursive resolver providers and CDNs do, and it becomes a success and the problem is solved.

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 28 Jan 2010 12:19:15 -0800

On Jan 28, 2010, at 11:55 AM, Ted Hardie wrote:
> And that's the crux of the problem here--this is encouraging

Except this concern is silly in most cases:  The added information flow is from the third party server to the authority server for the domain.

Yet what is the returned value for?  So the client can contact the final server.  

The client has ALREADY given up the privacy to the third party DNS resolver, the additional privacy leakage thereafter would be trivial.

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 28 Jan 2010 12:17:51 -0800

> what were previously reasonable things (like using distant recursive servers).

Why?  IMO, its a great strategy, simply because it not only works WELL for most users (it only fails those who want third party DNS resolvers), 

> support their flawed technical model is not in the global system's interest.

Too late.  They are established.  Your protocol has been rewritten for this.

> advantage should upgrade to something at the WWW layer, and leave DNS alone.

Except THIS assumes that the only load-balancing one wants to do is at the WWW layer, and its possible.  EG, you have this stupid same-origin stuff all over the place on the web that prevents a lot of WWW layer tricks from working.

> especially with DNSSEC coming.

DNSSEC makes no difference to this.  You know the addresses you are going to return in advance.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 28 Jan 2010 21:32:03 +0100

On Thu, Jan 28, 2010 at 02:32:51PM +0000,
 Tony Finch <[email-masked]> wrote 

> And implementation name and version number?

Why, when we have RFC 5001 ?

---

From: Alex Bligh <[email-masked]>
Date: Thu, 28 Jan 2010 20:49:38 +0000

--On 28 January 2010 12:16:57 -0800 Nicholas Weaver 
<[email-masked]> wrote:

> 3:  The third party resolver offers a significant value add, such as
> programmable blocking, automatic blocking of malicious sites, and far
> more agressive prefetching of common names and related information to
> speed up results.
>
> People are NOT using OpenDNS, UltraDNS, or Google's public DNS because
> their ISP's resolver is broken/evil, they are using it because they offer
> real perceived benefits.
>
> And this ISNT'T a behavioral change for every caching resolver.  One of
> the beauties of this scheme is ONLY the third-party resolvers and
> authorities which desire this behavior will need to implement this at
> all.  In fact, the Bind developers could say "No way in hell will WE
> implement this", but a few big recursive resolver providers and CDNs do,
> and it becomes a success and the problem is solved.

Hmmm... ok, part of my objection was to lines like (from 4.1)
 "In the reply, the server MUST include an edns-client-ip option."
On your reading, that MUST only means "where the incoming query
has the option set AND where the server is using the data in
some way". It doesn't, however, say that. I think it should be
clear that a server, whether or not it the software supports
the draft, and whether or not it is configured to return
answers with this option for some queries, is always free
to discard the edns client ip option (i.e. treat it as if
it isn't there). I don't see a particular problem with it using
the data silently then not returning a netmask. In which case
the MUST should simply read "MAY".

But if the idea of this is to institute a signaling mechanism between
caching resolvers that are non-local to their users (and you
say these are >= 97% third party resolvers) and certain authoritive
nameservers, why insist that the IP address passed is the IP
address of the client, which gets you into all these NAT problems.
Why not just allow the end user to specify an arbitrary IP address
which is the IP address he'd like authoritative nameserver to
treat as the source address for the query (possibly with a netmask
to indicate which bits are accurate), rather than saying he MUST
use the local IP address etc. etc.; so I could configure my
local (behind NAT) resolver with the external IP address.
And the privacy-paranoid could just pick any IP they know to
be in the same AS / network locality / whatever. Rather than
"client-ip-option" it is a sort of "source-hint-option".
This would also be useful in debugging problems to do with DNS
'cleverness' too (e.g. "dig +source-hint=x.x.x.x ....").

-- 
Alex Bligh

---

From: Colm MacCárthaigh <[email-masked]>
Date: Thu, 28 Jan 2010 21:11:20 +0000

On Thu, Jan 28, 2010 at 7:45 PM, Paul Vixie <[email-masked]> wrote:>
> what were previously reasonable things (like using distant recursive servers).

Can you expand upon the "less well" ?

> support their flawed technical model is not in the global system's interest.

Surely a large point of extension mechanisms is to cater for unusual
and ad-hoc circumstances in an interoperable way?

> TTL to 5 minutes, and sharing a single DNS cache across global providers.

Why?

> especially with DNSSEC coming.

This I-D seems interoperable with DNSSEC, even NSEC3, on my reading.

-- 
Colm

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 28 Jan 2010 13:13:38 -0800

On Jan 28, 2010, at 12:49 PM, Alex Bligh wrote:

> 
> 
> --On 28 January 2010 12:16:57 -0800 Nicholas Weaver <[email-masked]> wrote:
> 

Agreed.  Perhaps the best way is something like the following rules:

The authority MUST NOT use an EDNS0 client-ip-option if the request did not include a client-ip-option [1]

The authority MAY specify a broader netmask in the returned value [2]

When the resolver's own address is a publically-routable address, it SHOULD use the request's source IP address as the basis for the client-ip-option value, if no client-ip-option value was specified in the request [3]

If the resolver's own address is a non-routable address, it MUST NOT generate a client-ip-option value, but may pass a client-ip-option value [3]

If the resolver receives a request with a client-ip-option value, it should either REMOVE this value or pass it unchanged, it must not modify this value [4]

The resolver which uses or creates client-ip-option values SHOULD keep track of any authority which ignores or responds with an error for a request containing a client-ip-option but responds properly for the same request without a client-ip-option.  After three such failures, the resolver should remove all client-ip-option values in communication with this authority [5]

[1] Ensures that authority changes will not affect non-compliant resolvers

[2] Ensures that the authority if it cares about load, can specify a broader netmask.

[3] Removes the need for client changes under most conditions.  Prevents the NAT from being an issue.

[4] ALLOWS clients to take advantage of this, but doesn't requires it.

[5] Ensures that resolver changes will not prevent names from resolving.

As a result, you get a system where:

a) Partial deployment works with just changes to the authorities and resolvers which care about this feature.

b) Authorities, resolvers, and clients which don't implement this feature won't see an effect.

As important, the number of servers which would need to implement this feature is low, but the number of USERS which would benefit is substantial.

> address of the client, which gets you into all these NAT problems.

Actually, the external address of the request is the right answer for all these NATs, so there is no problem.

> 'cleverness' too (e.g. "dig +source-hint=x.x.x.x ....").

Sounds good, and makes sense.  But in absence of a client-specified value, the default value should be derived from the request's SRC address.

---

From: Alex Bligh <[email-masked]>
Date: Thu, 28 Jan 2010 21:22:41 +0000

--On 28 January 2010 13:13:38 -0800 Nicholas Weaver 
<[email-masked]> wrote:

> Sounds good, and makes sense.  But in absence of a client-specified
> value, the default value should be derived from the request's SRC address.

(Putting aside general unconvincedness about further protocol alterations
to support a hack some might argue should not exist...)

I don't mind a default. What I was objecting to is restricting the
field's use to "the public IP address or nothing". Why disallow
manual configuration? I'd just allow both client and caching
resolver to put in anything they want they think might be useful
for the authoritative server to look at. It means "if you want,
pretend the query came from this IP address rather than looking
at the transport layer IP address". I can then (e.g.) use opendns
and say I'd like the query to be treated like one that came
from (e.g.) one of comcast's DNS servers (specifying its IP address).

-- 
Alex Bligh

---

From: Paul Vixie <[email-masked]>
Date: Thu, 28 Jan 2010 21:41:07 +0000

> Date: Thu, 28 Jan 2010 21:11:20 +0000
> From: Colm MacCárthaigh <[email-masked]>
> 

i can't.  i've been told that because of stupid dns tricks, youtube sucks
for people whose recursive dns doesn't share fate and path with their tcp
stack.  i'm just parroting what i've been told, without understanding.  but
apparently this is the raison e'tre for the "client-ip" option so it's
likely true.

> > this incoherency should be dealt with more harshly, perhaps by
> > minimizing TTL to 5 minutes, and sharing a single DNS cache across
> > global providers.
> 
> Why?

because i like caching, and because i don't think the dns q-tuple should be
expanded to include more elements.  because dns is a phat target for folks
whose business models require cost-shifting from their edge to our middle.
oh hell, i said all this in the acm queue article:

http://queue.acm.org/detail.cfm?id=1647302

and since i mentioned q-tuple complexity, see also:

http://queue.acm.org/detail.cfm?id=1242499

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 28 Jan 2010 17:06:43 -0500

>Maastricht later this year.

<dnsex-chair-hat=on>

For the record, Wilmer and I had a discussion on how to submit Internet
drafts, and why the draft he was proposing was had to be submitted
as independent submission. I did no endorse or discourage this idea.

</dnsext-chair-hat=off>

>Comments are more than welcome.

<no-hat>
In the introduction the term "sub-optimal" is used with out defining
for who and in what context, traffic delay or content. Just because a
computer happens to have an IP address that is registered to be in
Austria does not mean that I'm interested in any Austrian content
when I visit a news site like Reuters.com.

Some people made the not-always-correct assumption that addresses on
DNS questions are an good/decent/reasonable indicator of location.
That does not mean it is DNS protocol role to make their life easier
or to fix their misconception.

The proposal in the draft moves almost all the cost of fixing the
"problem" to the Recursive resolvers. Both by adding the option to the
queries, and by the onerous requirement to fragment their internal cache
based on source address of the stub-resolvers.
This moves the cost of solving the "problem" from the CDN providers to the
recursive resolvers operators, and I question if that is fair or justified.

As Ed Lewis keeps saying "We need problem statements, before proposed 
solutions" and this draft fails to convince me there is a problem that
is worth the working groups time or the mailing list bandwidth.

<dnsext-chair-hat=on>
The open question for the working group is the following:
"Is it one of DNS roles to provide information on where the query
originated from?"

If the answer is yes then we can take on some work in this area.

         Olafur

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 28 Jan 2010 14:51:55 -0800

> recursive resolvers operators, and I question if that is fair or justified.

OTOH, it only moves the cost of fixing the problem to the recursive resolvers where it IS a problem, as the ISP recursive resolvers, and self-run recursive resolvers, shouldn't generally have this as an issue.

> "Is it one of DNS roles to provide information on where the query

A different way of phrasing the question embedded in this draft: 

A significant and well established usage has, largely but not completely correctly, assumed that the DNS query address as seen by the authority provides meaningful information on the client's network location, as a side consequence of DNS resolution either being provided by the network provider or as part of the end network's own systems.

Should DNS enable this assumption to continue when DNS resolution is provided by a different party than network transport?

---

From: Paul Vixie <[email-masked]>
Date: Thu, 28 Jan 2010 23:22:05 +0000

> Date: Thu, 28 Jan 2010 17:06:43 -0500
> From: Olafur Gudmundsson <[email-masked]>
> 
> ...
> based on source address of the stub-resolvers.  This moves the cost of
> solving the "problem" from the CDN providers to the recursive resolvers
> operators, and I question if that is fair or justified.

in fairness, this would be optional behaviour, ignored by authorities who
had no interest in it, and elided by recursives who had no interest in it.

so even though i'm against making dns incoherency any easier than it always
has been, i think that an industry-specific codepoint (where people whose
recursives were global wanted to share client ip information with people
whose web servers were global) and an industry-specific specification ought
to be possible within the IETF framework.

that may mean it's experimental or something.  it could never become a full
or recommended standard given the cost shifting arguments olafur made above
which are pretty much inarguable, but some codepoints and features will
always be industry specific since they'll have no general purpose use.

> If the answer is yes then we can take on some work in this area.

my answer is no.  the q-tuple is right-sized today.

---

From: Alex Bligh <[email-masked]>
Date: Fri, 29 Jan 2010 00:16:21 +0000

> "Is it one of DNS roles to provide information on where the query

Define "where".

-- 
Alex Bligh

---

From: Joe Abley <[email-masked]>
Date: Fri, 29 Jan 2010 13:49:30 +1300

On 2010-01-28, at 12:56, Wilmer van der Gaast wrote:

> privacy) of the user that triggered a DNS resolution.

My initial reading of the proposal suggests that the client that originates the DNS request is the one that MAY populate a client-address option, and that any other resolver or proxy in the chain between the client and a server (cache or authority) which supplies an answer MAY NOT change the client-address option data.

Suppose most clients are numbered using RFC 1918 addresses behind a NAT, and have no trivial way of discovering a non-RFC1918 address that the world might see them as. In that case isn't the address information that ultimately arrives at cache or authority nameservers useless for any purpose other than identifying that RFC 1918 addresses are in use?

I have some suggestions that relate specifically to the text, but the general utility of the proposal seems limited to me: I have doubts that there are significant client populations in 2010 which have useful address information to send.

Joe

---

From: Mark Andrews <[email-masked]>
Date: Fri, 29 Jan 2010 13:05:21 +1100

In message <[email-masked]>, Joe Abley writes:
> My initial reading of the proposal suggests that the client that =
> originates the DNS request is the one that MAY populate a client-address =
> option, and that any other resolver or proxy in the chain between the =
> client and a server (cache or authority) which supplies an answer MAY =
> NOT change the client-address option data.
> 
> Suppose most clients are numbered using RFC 1918 addresses behind a NAT, =
> and have no trivial way of discovering a non-RFC1918 address that the =
> world might see them as. In that case isn't the address information that =
> ultimately arrives at cache or authority nameservers useless for any =
> purpose other than identifying that RFC 1918 addresses are in use?
> 
> I have some suggestions that relate specifically to the text, but the =
> general utility of the proposal seems limited to me: I have doubts that =
> there are significant client populations in 2010 which have useful =
> address information to send.

The presumption is that recursive resolvers would not set the option
if they receive the query from a RFC 1918 (or otherwise deemed
private) address.  The first recursive resolver which received a
query from a non private address would add the option to any upstream
queries made on behalf of the client.

Note you don't need to know your address to make this decision as
it is based entirely on the source address from which you receive
the query.  All the nameservers involved could be on machines using
private address and provided they are not behind a NAT that collapses
the world down to a single address this will just work.  The outbound
NAT sets the source address to a public address and the inbound NAT
preserves it.

This is not a option which would be normally be sent stub resolvers.
This is not a option that works when there are multiple exit points
from the private net and the internal nameserver uses a different
exit point to the actual client.  The presumption is that there is
a single exit point.

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

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 28 Jan 2010 21:09:52 -0500

At 19:16 28/01/2010, Alex Bligh wrote:

>--On 28 January 2010 17:06:43 -0500 Olafur Gudmundsson <[email-masked]> wrote:
>

That is part of the question, some people may argue "where" can be one of
         IP address,
         GPS coordinates
         application name
         Opaque identifier
         combination of different coordinates
or something  different

         Olafur

---

From: Alex Bligh <[email-masked]>
Date: Fri, 29 Jan 2010 06:54:58 +0000

>          combination of different coordinates

OK. I am in the "unconvinced" camp.

The draft doesn't adequately define the problem statement (which
could be fixed), but discussions here suggest it is in essence
that an undocumented and unstandardised hack (using transport
IP source address as a hint for network topology - i.e.
a "where" indicator) is an imperfect heuristic in particular
circumstances (i.e. remote resolvers). The proposed response
is not to standardise the hack itself, but to provide a
facility usable in some cases only to transmit a garbled
"where" indicator that some of those operating that heuristic
might use.

Olafur's question says "should DNS provide information on [something]".
My answer is "not without (a) defining what that something is, and
(b) standardising the use/consumption of that data". We appear to
be trying to standardise its source and transport, without defining
the other end (what the authoritative nameserver might do with it).

If we're going to add yet another saddle-bag to the DNS pony and say
that an authoritative DNS server should be able to answer queries
based on information other than in the QUERY section (e.g. "where"
the source of the query comes from), we should be honest and
come out and say that, rather than document just the effects
elsewhere in the system.

-- 
Alex Bligh

---

From: "George Barwood" <[email-masked]>
Date: Fri, 29 Jan 2010 08:31:08 -0000

----- Original Message ----- 
From: "Wilmer van der Gaast" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, January 27, 2010 11:56 PM
Subject: [dnsext] Re: I-D ACTION:draft-vandergaast-edns-client-ip-00.txt

> Comments are more than welcome.

The proposal does solve problems associated with how CDNs work to select the most
appropriate application server in conjunction with highly centralised recursive caches, and I see no
reason why it should not go forward. It affects only a very small number of DNS servers.

The alternative would seem to be having web servers (for example) issue client-sensitive
URLs at the previous step. This is awkward, so I think the proposed solution is superior.

So I support adoption of this draft.

---

From: Martin Barry <[email-masked]>
Date: Fri, 29 Jan 2010 20:05:42 +1100

Just a small comment on "dns-tricks" versus "routing-tricks".

$quoted_author = "Paul Vixie" ;
> http://queue.acm.org/detail.cfm?id=1647302

"Anycast TCP is also in use by a few CDNs and works at least as well as any
DNS-layer solution. Anycast is stable for minutes or hours at a time, so
it's rare for two TCP packets to the same destination to reach different
anycast contributors."

Anycast usually implies a /24 used for a single service or group of
services. This limits "routing-tricks" to those that have a spare /24, speak
BGP in multiple locations and can justify polluting the global routing table
with another /24.

Conversely "dns-tricks" can be, and are, used by those who don't meet the
above criteria. The only limitations are having authorative servers capable
of applying the "tricks".

Both imply some burden shifting in order to provide "better" service to the
end user.

cheers
Marty

---

From: Colm MacCárthaigh <[email-masked]>
Date: Fri, 29 Jan 2010 09:43:58 +0000

> it's rare for two TCP packets to the same destination to reach different

This statement is not supported by data, and does not seem credible.
While anycast is stable, there is no reason to believe that it works
at least as well as a DNS-layer solution.  At my previous employer
(Joost.com) we ran a small private CDN for P2P seeding, video and
image and distribution, using both anycast and DNS tricks. DNS tricks
proved to be at least twice as good at lowering network latencies,
though granted we were not particularly well-peered and had only a
handful of transit providers.

Anycast directionality is essentially out of the hands of the service
provider and the behaviour depends on such things as upstream transit,
filtering and peering policies. In contrast, DNS tricks are
controllable on a very granular basis. The biggest problem with DNS
tricks is that there may be a anti-correlation between the resolver's
locality and its users - which this I-D is specifically an attempt to
fix.

> of applying the "tricks".

+1

-- 
Colm

---

From: Jim Reid <[email-masked]>
Date: Fri, 29 Jan 2010 10:13:31 +0000

On 28 Jan 2010, at 22:06, Olafur Gudmundsson wrote:

> As Ed Lewis keeps saying "We need problem statements, before  
> proposed solutions" and this draft fails to convince me there is a  
> problem that

+1

---

From: Jim Reid <[email-masked]>
Date: Fri, 29 Jan 2010 10:31:27 +0000

On 28 Jan 2010, at 21:41, Paul Vixie wrote:

> i've been told that because of stupid dns tricks, youtube sucks
> stack.  i'm just parroting what i've been told, without understanding.

I can't speak for youtube (whatever that is). However I can vouch from  
personal experience that stupid DNS tricks get it wrong, even when  
recursive DNS service and TCP traffic share the same path. English  
speakers can see this pretty much every time they connect to a hotel  
or coffee shop network in mainland Europe. The CDNs provide stuff in  
that country's national language -- good luck getting that right in  
Belgium or Switzerland -- rather than English. Similar problems arise  
in large corporate networks which have a small number of interconnects  
to the Internet: the CDNs decide the user is in Germany (say) because  
that's where the firewall or web proxy is located.

---

From: Martin Barry <[email-masked]>
Date: Fri, 29 Jan 2010 21:58:30 +1100

$quoted_author = "Jim Reid" ;
> 
> I can't speak for youtube (whatever that is). However I can vouch
> from personal experience that stupid DNS tricks get it wrong, even
> when recursive DNS service and TCP traffic share the same path.
> English speakers can see this pretty much every time they connect to
> a hotel or coffee shop network in mainland Europe. The CDNs provide
> stuff in that country's national language -- good luck getting that
> right in Belgium or Switzerland -- rather than English. Similar
> problems arise in large corporate networks which have a small number
> of interconnects to the Internet: the CDNs decide the user is in
> Germany (say) because that's where the firewall or web proxy is
> located.

I'm an Australian living in Frankfurt and I feel your pain.

However, it is a failing of the "CDN" application that the language is
determined by location rather than a more accurate guide like the HTTP
Accept-Language header.

It's perfectly appropriate that I hit the google.de cluster as it's "closer"
but it's the web applications fault that it chooses to server me Deutsch
rather than the Queen's English that my browser indicates I prefer.
 
cheers
Marty

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 29 Jan 2010 12:32:54 +0100

On Thu, Jan 28, 2010 at 05:46:29AM +0000,
 Paul Vixie <[email-masked]> wrote 
 a message of 3 lines which said:

> if we're going to add client identity to the query, can we do so in
> a more general way?  i'd like to know lat-long, country, isp,
> language, and adult/child.  and the ip address should be
> multiprotocol, covering ipv6.

In the light of this remark, and of the one by Jim Reid about the
imperfection of load-balancing algorithms based on the IP address, may
I suggest two possibles changes to the draft:

1) A small an reasonable one, deleting every mention of the
load-balancing algorithm and just describing an EDNS option for
carrying the IP address of the desktop client to the authoritative
name server (which, being authoritative, could do what it wants with
it). This would suppress one opportunity to troll and would be in line
with the general IETF rule "protocol, not policy".

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.

---

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

On Thu, Jan 28, 2010 at 06:10:09PM +0000,
 Alex Bligh <[email-masked]> wrote 

> I have read the draft.

Me too, otherwise I wouldn't comment.

>  Given people make DNS queries in general so they can communicate
>  with the (e.g.)  A record given, and the (e.g.) http server on that
>  IP address can log connections, what privacy is lost by
>  transmitting the address given in full?

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.

>  You leave this choice to the recursive resolver, I think, not the
>  client, and require that at least some bits are cleared.

The biggest privacy problem with the current draft is that, for the
"desktop" client, the use of the new extension is opt-out, not opt-in
(section 8.1) which disturbs me a lot.

---

From: Florian Weimer <[email-masked]>
Date: Fri, 29 Jan 2010 12:20:31 +0000

> information would then be just a special case.

I think this approach would be a lot better.  It's also inherently
opt-in, which seems the best way to side-step privacy issues these
days.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Marco Davids <[email-masked]>
Date: Fri, 29 Jan 2010 13:57:27 +0100

+1

Sounds promising. Especially with opt-in functionality.

iPhone/Andoid with GPS might then indeed take you to the nearest
'pizza.restaurants.local'. Or even better: 'nearest.aed.local' in case
the pizza got stuck in your esophagus or something...

And I can think of a lot of other applications to bring new life to our
beloved friend DNS.

But... DNS-queries are not yet 'protected' with DNSSEC, right? A query
might be modified along the way. Resulting in useless answers...

So I also forsee another interesting 'attack vector'.

-- 
Marco Davids

SIDN | Utrechtseweg 310 | 6812 AR | Postbus 5022 | 6802 EA | ARNHEM
T +31 (0)26 352 55 83 | M +31 (0)6 52 37 34 35  | F +31 (0)26 352 55 05
[email-masked] | www.sidn.nl | enum:+31652373435 | sip:[email-masked]

---

From: "Roy Arends" <[email-masked]>
Date: Fri, 29 Jan 2010 14:05:03 +0100

> Comments are more than welcome.

I haven't read the whole thread, so maybe this has been proposed before: 
Why not encode the client IP address (32 bits) plus the netmask in cidr 
form (6 bits) in base32 and prefix it to the query.

So, 10.0.0.2/8 would translate to B8AAAQ=I, and the query would then 
simply be: B8AAAQ=I.localized.google.com 

No stub implementation or resolver implementation has to be changed. 
Transient through resolvers as opposed to EDNS. Example works for IPv6 as 
well.

This can simply be done through a redirect on the server side, plus some 
cookie to keep state: 

Client connects to www.google.com over http.
Webserver now knows the clients IP address (10.0.0.2), issues a redirect 
to B8AAAQ.localized.google.com
Client resolves B8AAAQ.localized.google.com
Auth server responds with B8AAAQ.localized.google.com A 10.90.9.73 

There is no netmask in the above example. Instead of the above method, the 
application can set the query prefix to B8AAAQ=I.

The whole discussion about client privacy is a bit over the top, as 
obviously, google can in theory already harvest client IP address by 
looking what connects to their webserver. With the above trick, it could 
even correlate which ip address uses which resolver.

Roy

---

From: Federico Lucifredi <[email-masked]>
Date: Thu, 28 Jan 2010 21:46:14 -0500

Hello Wilmer,
 one comment: there is an Anycast RFC now: 4786. It deserves mention IMHO.

 Best -F

-- 
_________________________________________
-- "'Problem' is a bleak word for challenge" - Richard Fish
(Federico L. Lucifredi) - [email-masked] - GnuPG 0x4A73884C

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 28 Jan 2010 17:45:17 -0800

>Suppose most clients are numbered using RFC 1918 addresses behind a NAT, and have no trivial way of discovering a non-RFC1918 address that the world might see them as. In that case isn't the address…

Section 4.1 says "An edns-client-ip option MUST never contain a non-public address." To me, that means two things:

- If I'm an end client and I know my address is non-public, I cannot include an edns-client-ip option in my request upstream.

- If I'm a recursive resolver and I get a query that erroneously includes an edns-client-ip option with a non-public address in it, I strip off that option before sending that request upstream.

If I have understood the draft correctly, then the concerns about private addresses their effects on authoritative resolvers are moot.

The biggest stumbling block here is the assumption that developers will know the correct list of non-public addresses. Given lots of deployed counter-examples, that seems like a bad assumption. Specific pointers to specific IANA registries are needed in this draft.

--Paul Hoffman, Director
--VPN Consortium

---

From: [email-masked]
Date: Fri, 29 Jan 2010 17:08:07 +0100 (CET)

> - If I'm a recursive resolver and I get a query that erroneously includes an edns-client-ip option with a non-public address in it, I strip off that option before sending that request upstream.

Given that no recursive resolvers today support this, it's going to 
take a while to get such such behavior implemented, *if* the I-D ends
up as an RFC.

Steinar Haug, Nethelp consulting, [email-masked]

---

From: Carlo Contavalli <[email-masked]>
Date: Fri, 29 Jan 2010 16:47:30 +0000

Ok, trying to respond to Olafur, and to many of the concerns that have
been raised on this thread.

On Thu, Jan 28, 2010 at 10:06 PM, Olafur Gudmundsson <[email-masked]> wrote:
> for who and in what context, traffic delay or content.
The context is traffic delay, not content.

> Just because a
200% agreed.

> DNS questions are an good/decent/reasonable indicator of location.
I don't disagree. However, it is more than just a few corporations
that are applying this misconception. Even sites like debian.org,
kernel.org or wikipedia are doing this today, and most major web sites
either rely on content providers or are doing similar tricks. Many DNS
softwares either support this directly or though external patches
(powerdns, even bind)..

We don't want to enter the debate of this being a good or bad idea.
People are doing it, regardless of what we think and what the DNS
protocol was meant for, or regardless of other alternatives being
available.

And as people are doing it, owner of recursive resolvers, CDNs, or
anyone who has to deal with a large user base need to take this into
account and work on the assumption that this is what the world looks
like now.

> recursive resolvers operators, and I question if that is fair or justified.
So, if you're running a recursive resolver for a few networks that are
topologically close to each other, you probably don't care about this
draft, and will not enable edns-client-ip at all.

If you run an open resolvers, or run a resolver for several,
distributed, networks, chances are that you or your users are already
paying the cost of this.

Either by ignoring the problem and giving your users bad latency in
many cases, or by deploying multiple servers in many different
locations, each one duplicating some of the same entries in the
cache, or by using heuristics to determine what can globally be
cached and what cannot.

This draft, on one side asks recursive resolvers to forward more
information to the authoritative nameservers. But on the other side,
it allows to detect which servers are employing those techniques.
Eg, instead of having heuristics to determine what
can safely be shared in a distributed cache, you can simply look at
the edns-client-ip option. Instead of having to deploy multiple servers
sending queries from different IPs, you now have the choice of using
edns-client-ip to fetch result for different networks.

My point being: if you run a recursive resolver, and care about the
latency of your users, this draft might help you reduce costs and
build better infrastructures. If you run an authoritative name server
that returns different results based on the source ip, you now have
better input data (note: not the best, not exact every time, just
slightly better), can serve better result, and you have a mechanism
to say "yes! I'm pulling dns tricks, please be smart about caching
my data", rather than hope for not-written-anywhere "best practices".

This also helps debugging issues: rather than having to query from
different locations or check what's cached where to determine what's
going on, you can check with the option, or send different options and
verify what's going on directly.

> is worth the working groups time or the mailing list bandwidth.
Agreed, the discussion would probably be much more focused if we had a
clear problem statement and some numbers to look at. We can't
promise anything at this time, but if we had a slot at the next IETF
meeting or at the following one, we could probably put together a
presentation with some concrete data to look at, and discuss this in
person, which would probably help a lot.

For what is worth, this is an important problem to solve for us, and
for most of the industries we talked to. We also know that in some
cases it's being solved with proprietary or non standard approaches.
We pretty much believe that many would benefit by publishing a
standardized way to handle those cases. (an experimental extension
is fine, or whichever form IETF deems more suitable)

In any case, we've seen lot of useful feedback in this thread, we hope
to upload a -01 version soon.

Carlo

---

From: Carlo Contavalli <[email-masked]>
Date: Fri, 29 Jan 2010 17:35:15 +0000

> with the general IETF rule "protocol, not policy".
That was the intention :-), we'll try to review the document, and
clean up references to any such algorithm if there's still any.

> information would then be just a special case.

Personally, I'd rather have different EDNS options. Eg, we're now
/trying/ to standardize an option to carry the user ip, there's 16 bit
of space to register other options, it's already possible to register
an option to carry my location, or whatever else I want to carry
there?

So we wouldn't have to create a new register, and we wouldn't have to
nest another header that would look very similar to the enclosing
edns0 header, and we wouldn't have to write more code to parse or
handle those options.

But I don't feel strongly, it's just my 2 cents,
Carlo

---

From: Wilmer van der Gaast <[email-masked]>
Date: Fri, 29 Jan 2010 18:42:07 +0000

Let me clarify a few more things.

* Fallback mechanism:
Good idea. In fact I have noticed that not only cheap home routers can
choke on DNS packets with EDNS0 options, even Netscalers (with some
versions + configs at least) can intercept them and return a FORMERR
response.

This isn't so much a problem specific to edns-client-ip, but I agree
we should describe a fallback mechanism in this I-D (and for now in
every I-D describing an EDNS0 option, it seems. :-( )

* RFC1918 IP space, NAT, etc.
Nicholas Weaver's e-mail
<[email-masked]> /
<http://www.ops.ietf.org/lists/namedroppers/namedroppers.2010/msg00105.html>
explains the behaviour we intended perfectly. We'll make sure to make
this behaviour much clearer in -01 since clearly it's currently
lacking.

* DNS/HTTP coming from different IP addresses:
I believe this is not so much related to our draft, or if anything,
our draft will make it possible to solve this problem by letting the
resolver include the external IP address from where HTTP traffic will
exit. If the resolver can't know this information (i.e. if it's not
predictable) then there isn't *any* way for CDNs to fix this problem;
even when using something like a 302 it's entirely possible that
another exit point will be used for the new connection.

* The requirement to include the option in responses only if the
request contained one.
Obviously our intent is to require edns-client-ip options only in
responses to queries that contained one. We'll clarify that in the
doc.

* Allowing to use the option without returning it in the response:
There's one problem with that. Without getting back the option a
caching resolver doesn't know how reusable the response is and will
assume it's suitable for everyone. Allowing that behaviour would allow
one to trick a resolver in Europe to cache the result of
www.example.com for Asia. Although this isn't cache poisoning in the
strictly malicious sense, it's definitely undesirable.

* Making larger netmasks (i.e. lowering the number) optional:
Although I'm not against making this a weak recommendation, doing this
affects not only the auth. resolver with generating more traffic, it
does also increase cache pressure on the resolver. Needs more
discussion.

Regards,

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 29 Jan 2010 11:07:56 -0800

On Jan 29, 2010, at 10:42 AM, Wilmer van der Gaast wrote:

> Let m* Making larger netmasks (i.e. lowering the number) optional:

Actually, it should decrease the cache pressure on the resolver, as it allows the authority to say "you can cache this for a larger fraction of the users than you asked about".

Depending on the resolver's cache (fixed netmask vs variable netmask, and capacity), the resolver may cache it for just the original netmask or the larger netmask, depending.

---

From: Joe Abley <[email-masked]>
Date: Sat, 30 Jan 2010 09:34:12 +1300

> Section 4.1 says "An edns-client-ip option MUST never contain a non-public address." To me, that means two things:

Ah, I missed that text, thanks.

> The biggest stumbling block here is the assumption that developers will know the correct list of non-public addresses. Given lots of deployed counter-examples, that seems like a bad assumption. Spe…

Yes, it does seem to imply the hard-coding of special values into software.

An alternative would be to add the query source as viewed by every option-understanding nameserver that receives the query and performs a recursive lookup, forget the "non-public" text in 4.1 and let any nameserver that whats to process the option make whatever interpretation they want. That isolates the need to concern yourself with unique vs. non-unique addresses to the point of analysis, not data collection.

I think the general idea of being able to better understand your user community would have some operational/diagnostic benefits for any authority-only nameserver. No doubt there are also privacy implications.

Joe

---

From: Tony Finch <[email-masked]>
Date: Sat, 30 Jan 2010 22:27:27 +0000

On Thu, 28 Jan 2010, Alex Bligh wrote:
> use the local IP address etc. etc.;

I thought one of the aims of the draft is to avoid specifying changes for
the protocol between stub resolvers and recursive resolvers.

Tony.

---

From: Nicholas Weaver <[email-masked]>
Date: Sat, 30 Jan 2010 15:00:12 -0800

> the protocol between stub resolvers and recursive resolvers.

Clients shouldn't NEED to specify, but should be ABLE to specify.  Likewise, you could have a stub resolver to proxy to recurvise, and that proxy may benefit in being the place to add that information.

And as mentioned by others, being able to specify in a query would really aid in debugging if nothing else.

---

From: [email-masked]
Date: Sun, 31 Jan 2010 20:30:55 +0000

> also to middlemen, the authoritative servers of the root, the TLD,

	well - it sort of seems unfair to have the client know the
	address(s) of the authoritative server(s), but the authoritative
	servers have no means of knowing the address(s) of the clients.

> (section 8.1) which disturbs me a lot.

	it is a change in legacy behaviours.

--bill

---

From: [email-masked]
Date: Sun, 31 Jan 2010 20:21:56 +0000

> adult/child.  and the ip address should be multiprotocol, covering ipv6.

	many of these requests are for data not visible to the DNS
	directly and may not be visible to the user.

	but since we are asking for the brass ring, I'll add my two
	to the list,  vector and speed

--bill

---

From: Eric Brunner-Williams <[email-masked]>
Date: Sun, 31 Jan 2010 19:04:06 -0500

in 8, there is a repetition of the choice (mistake in my opinion) that 
truncating a 32bit address to 24bits provided "privacy".

there are two issues.

first, what data is being collected by the server, independent of any 
assertions of preference by the address provisioning client?

i'm not suggesting that the server should signal the client what its 
data collection practices are, but it is a possibility, this is what 
the w3c's p3p work has made possible, and there is a dcp element (data 
collection policy) in epp.

the mistake made in the p3p spec group was to pick 24bits as providing 
"privacy". this choice was made without reference to the structure of 
any particular address allocation in which an address for which some 
"privacy" was desired, or to the temporal properties of addresses in 
the smallest block to which that address belong.

in short, for the purposes of geo-mumble, a purpose this draft appears 
to share, no use was made of information that may be sufficient to 
identify the geo property sufficient for the proposed service, e.g., 
is this user on mars, for some value of mars, and, there was no 
awareness that dynamically provisioned 32bit identifiers are "static" 
of significant periods of time, and other correlative tools are 
available for user profiling business (and non-business) models which 
have access to "masked" data and other sources of data.

second, there is the utility of the client, the address bits 
provisioning source, asserting what the provisioned bits are.

this draft appears to comingle locality, which may be useful, and the 
frequently repeated "privacy toggle" semantics, which ignores the 
richer semantics of discovering the policy of the address bits 
collector, which should discard these bits as soon as the localized 
service is accomplished, but could keep them indefinitely, and 
corrolate them with other data sources (see "doubleclick" generally).

eric