Subject: Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00

From: "Marc Lampo" <[email-masked]>
Date: Thu, 1 Sep 2011 09:24:35 +0200 (CEST)

Hello,

As one of the authors observed in a reaction to this posting,
the publication of this draft went mostly unnoticed -
I must admit I missed it as well ...

But now that I have read it, I have one observation regarding the content
 (something I feel is missing)
and one global, "architectural", remark.

About the content :
In my opinion the impact of DNSSEC is underestimated
when the RFC refers to an "optimized reply".

Assuming a service has multiple address records,
optimization could mean
 - order the address records in such a way that the "most optimal address"
is first,
    in the reply from authoritative name server to caching name server.
    (which assumes that that caching name server will not change the order
again)
    --> (for DNSSEC) the RRset remains complete, corresponding RRSIG's can
be used
 - only the "most optimal address for this client" is returned.
    --> (for DNSSEC) the RRset is *modified*, the RRSIG must be
recalculated !

For an authoritative name server, implementing DNSSEC and this RFC,
it probably implies that it must be able to calculate RRSIG's "on the
fly";
Which implies that it must have access to the private part of DNSKEY's;
Which implies that signing on a hidden master
and distributing signed data to public slaves is not enough.
Though I know some name server implementations implement "on the fly
signing",
 I'm hesitant about the consequence of having to transport the private
parts of DNSKEY's
 to all Internet facing name servers.

For this RFC, I suggest some additional text is added to describe
consequences
of implementing both DNSSEC and this RFC.

About the architecture :
Although there is much merit in offering a public, resolving, service (for
individual PC's),
it is quite dangerous for companies to have their (internal) caching name
service
forward (only) to such a service !
A (slight) variation of Dan Kaminski's cache poisoning attack could really
cause big
Problems in such a setup.
Without going in too much detail,
1) a forwarding name server must accept more additional data than a
non-forwarding one !
   Basically because it asks one question, expects one useable reply.
2) the window-of-opportunity for a cache poisoning attack is *seconds* !!!
   (with Dan Kaminsky : *fractions* of seconds : it closes when the reply
from the auth NS arrives)

The only (full proof) way for the forwarding name server to defend against
this,
is by validating (DNSSEC) received answers.
To that purpose, the forwarding name server will need more info (like DS
records).

Which brings me to a demand to those organisations offering such a public,
resolving, service :
Please *do start* to implement DNSSEC *first*,
so that at least this public name service knows where to look for DS
records !
(you could leave the actual verification of signatures to your users - who
wish to do so.
In Bind syntax :
options {
        ...
        dnssec-enable yes;     // <-- name server knows where to look for
for DS records
        dnssec-validation no;  // <-- at your discretion to validate
yourself, or not
};

Kind regards,

Marc Lampo
Security Officer
 
    EURid
    Woluwelaan 150     
    1831 Diegem - Belgium
    [email-masked] 
    http://www.eurid.eu

Want a .eu web address in your own language? Find out how so you don't
miss out!

---

From: Tony Finch <[email-masked]>
Date: Thu, 1 Sep 2011 16:13:36 +0100

> it probably implies that it must be able to calculate RRSIG's "on the

That isn't required. You can pre-calculate RRSIGs for multiple versions of
the same RRset and arrange your stunt DNS server to serve up the most
optimal version of the RRset depending on the client. No need for dynamic
calculation.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Lundy, Fastnet: Southeast veering southwest 3 or 4, increasing 5 at times.
Slight or moderate. Showers. Good, occasionally poor.

---

From: Jaidev Sridhar <[email-masked]>
Date: Thu, 1 Sep 2011 12:45:50 -0700

For some reason my original email never made it to the list.

On Wed, Aug 31, 2011 at 07:18, Wilmer van der Gaast <[email-masked]> wrote:
>
> I just realised, after looking through our revision history, that we
> haven't made any changes to the NAT section since edns-client-ip-00
> (i.e. January 2010). Since then we have made some changes to
> transitive behaviour so there are definitely some contradictions to be
> found here.
>

I agree. Rewording that section would make it more consistent with the
rest of the document.

>
> The big-bad-NAT use case is also not a scenario we thought of so far.
> It's also a pretty hard one to support without putting a lot of
> additional intelligence into resolvers (i.e. a mapping of internal IP
> addresses to their external equivalents). I'd like to know if any
> implementor is actually willing to implement that.

Again I agree that NAT implementations will probably not care about
adding a edns-client-subnet option. However, my point was just that
you shouldn't use language such as "intermediate devices MUST NOT add
or change a edns-client-subnet option". Also, an intermediate device
should have the option of zeroing the IP information (for instance: to
enforce organizational privacy policies).

-Jaidev

-- 
The older a man gets, the farther he had to walk to school as a boy.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 3 Sep 2011 23:03:17 -0400

It occurs to me that this thread demonstrates that a Standard is NOT
required. Nor has it ever been.

Anyone who wants to can choose any code point and use it. If they have
enough market presence they can make sure that nobody else wants that same
code point.

I do not agree with the need for a private use space. Private use just means
that each experiment will burn a minimum of one code point and if successful
will burn a second plue require a transition. We have been there with
X-headers. They didn't really work.

One of the problems with the DNS area is that there are far too many people
who think that they have a veto point on the Internet and that is just not
true (thank the deity).

I am not trying to pick on the DNS area, just point out that it is not only
governments who regard it as a chokepoint and thus the subject matter
inevitably attracts people who think that it is their mission in life to
protect the Internet from making the mistakes that they in their wisdom are
uniquely capable of recognizing.

I am willing to follow a process if an assignment process gives me a
reasonable chance of getting an assignment on a reasonable schedule. By
which I mean a small number of months as for RR code points. But do not be
mistaken: I am not recognizing a right of veto by doing so.

If the barrier is Standard required then I am simply going to tell people
the number I have picked. I didn't get to vote for anyone involved so they
should not exactly be surprised if I don't recognize their right to a veto.

Some of you know the political sympathies that got me involved in the
Internet in the first place: I believe in democracy. Do not be at all
surprised if my lack of tolerance for unaccountable decisions is not limited
to those of dictators and autocrats.

A consensus based approach can be appropriate if the remit of an
organization is limited to finding out what we can agree to do together. It
is not acceptable if the organization is going to presume to claim veto
power over what they do when agreement is not reached.

We have a similar situation with SRV prefixes which for various reasons have
not been properly tracked for the past ten years. Each time there are
proposals to rationalize the prefix registry people pull out absurd
technical and logistical issues until the enthusiasm for the proposal is
beaten into submission and lies bleeding and battered but not quite dead for
the next few years.

In the meantime every protocol designer who believes inthe SRV approach just
does what I have done in W3C and OASIS standards and writes the stupid code
points into the spec. There, done.

On Wed, Aug 31, 2011 at 7:47 AM, Andrew Sullivan <[email-masked]>wrote:

> On Tue, Aug 30, 2011 at 08:23:51PM -0700, Colm MacCárthaigh wrote:
> > On Tue, Aug 30, 2011 at 8:12 PM, Andrew Sullivan <[email-masked]>
> wrote:
> > > I actually don't care about the IETF process.  What I do care about is
> > > the potential for interoperability headaches later because of
> > > undocumented collisions in EDNS0 option code interpretation.  Avoiding
> > > that sort of headache is the exact reason we have a registry.
> >
> > How would you feel about proposing more relaxed registry criteria to
> > IANA (by way of an RFC), similar to how the ports registry works?
>
> In my personal, no-hat opinion, the registry rule could be made
> first-come, first-served until (say) 50% of the code space was used
> up.  I see no reason not to do this.
>
> The current edns0-bis draft actually moves things in the opposite
> direction: whereas now the rule is RFC Required, the current draft
> makes things Standards Action.  In my opinion (again no hat), this is
> the wrong direction to be moving.
>
> > EDNS0 option codes don't appear to be in much demand, so exhaustion
> > isn't as much of a concern.
>
> Right.  And we could solve that worry by making the relaxed rule
> automatically tighten after a certain number of the codes are gone
> anyway, just the way we did for the DNSSEC algorithm numbers.
>
> A
>
> --
> Andrew Sullivan
> [email-masked]
> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext
>

-- 
Website: http://hallambaker.com/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 4 Sep 2011 08:39:49 -0400

If EDNS0 codes were ever exhausted it is a trivial matter to generate more.
Just assign a new extension RR code.

I suspect that it won't be a problem though, I can't see how we could run
out of EDNS codes before RR codes.

2011/8/31 Jim Reid <[email-masked]>

> On 31 Aug 2011, at 04:23, Colm MacCárthaigh wrote:
>
> Sounds like a good idea.
> A process comparable to the one for RRtype code assignment could take care
> of this. The expert review would provide a sanity check and rate limiter in
> case we started burning through EDNS option codes. What if marketroids were
> to decide these are more valuable for vanity purposes than new gTLDs?
>
> It's a pity RFC6195 didn't ring-fence some of the EDNS OPT code (and
> Extended RCODE?) number space for private use and/or experiments just like
> it did for the RRtype, CLASS and RCODE spaces.
>
> ______________________________**_________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/dnsext<https://www.ietf.org/mailman/listinfo/dnsext>
>

---

From: Nicholas Weaver <[email-masked]>
Date: Sun, 4 Sep 2011 06:05:52 -0700

On Sep 4, 2011, at 5:39 AM, Phillip Hallam-Baker wrote:

> If EDNS0 codes were ever exhausted it is a trivial matter to generate more. Just assign a new extension RR code.
> 
> I suspect that it won't be a problem though, I can't see how we could run out of EDNS codes before RR codes. 

You don't even need to do that.  If we reach 50% exhausting of the code space, just define the reserved EDNS0 options code of FFFF as "the next 4 bytes are the extended extended option code", and from that point onward, experimental extensions have to use the extended option code space.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 4 Sep 2011 19:49:31 -0400

I think it rather more likely that we end up changing the DNS
client-resolver protocol first.

One of the things I have found playing about with DPLS is that probably the
biggest leverage performance upgrade that can be done is to change the
client resolver protocol so that while a request is still one UDP packet,
the reply can consist of several.

Another thing that I realized is that the cost of transitioning to DNS 1.0
over DPLS (or DTLS) is exactly the same as the cost of transitioning to DNS
2.0 over DPLS. So if people go this route they might as well take the
opportunity to tweak the protocol to fix some of the more irritating
restrictions (e.g. only one request per request packet).

On Sun, Sep 4, 2011 at 9:05 AM, Nicholas Weaver
<[email-masked]>wrote:

> > If EDNS0 codes were ever exhausted it is a trivial matter to generate
> more. Just assign a new extension RR code.
> >
> You don't even need to do that.  If we reach 50% exhausting of the code
> space, just define the reserved EDNS0 options code of FFFF as "the next 4
> bytes are the extended extended option code", and from that point onward,
> experimental extensions have to use the extended option code space.
>
>

---

From: Wilmer van der Gaast <[email-masked]>
Date: Mon, 5 Sep 2011 18:09:25 +0100

On 31 August 2011 17:03, Ted Hardie <[email-masked]> wrote:
> * Rewrote origination sections to clarify that normally only recursive
> resolvers generate edns-client-subnet options.
> * Discussion on whitelisting or automatically detecting if an
> authority supports edns-client-subnet.
> * More precisely specifying (optional) transitive behaviour.
> * Minor revisions to improve clarity and correctness w.r.t. other RFCs.
>
> None of these changes seem to address the balance of discussion of the
> previous two versions.
>
I assume you are referring to the discussion about edns-client-subnet
or DNS-based CDNs being a reasonable solution at all?

A short discussion of various CDN techniques is, IMHO, outside the
scope of an RFC describing an EDNS0 option. Instead, we summarised our
concerns about alternative methods suggested in these discussions on
http://www.ietf.org/mail-archive/web/dnsext/current/msg08962.html .

Regards,

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

---

From: Wilmer van der Gaast <[email-masked]>
Date: Mon, 5 Sep 2011 18:28:24 +0100

On 1 September 2011 08:24, Marc Lampo <[email-masked]> wrote:
> [...]

As someone else already pointed out, this is not strictly necessary.
Also, this is not specific to edns-client-subnet as there are
nameservers right now that use the query source IP to determine the
optimal response.

>From how I parse the DNSSEC specs, the OPT record is not signed
(wouldn't be possible without secret keys on the server anyway), so
edns-client-subnet doesn't change the situation.

It may still be reasonable to mention something along these lines in the I-D.

I assume the attack scenario you're talking about is sending queries
with many different source IP addresses/client-subnet options and
sending spoofed responses with no client-subnet option at all?

Regards,

---

From: SM <[email-masked]>
Date: Mon, 05 Sep 2011 13:03:48 -0700

>scope of an RFC describing an EDNS0 option. Instead, we summarised our

If it wasn't for the intended Experimental status, there a lot of 
topics that cannot be said to be out of scope for this proposal.  In 
the reply to the WG Chairs' comments, it was mentioned that HTTP is 
the main focus.  The following DNS services support edns-client-subnet:

   - OpenDNS
   - Google Public DNS

I might describe the problem as follows.  These DNS services provide 
an "off-net" recursive resolver service for clients.  Clients are 
generally assigned a DNS server that is topologically close to them, 
i.e. their ISP's DNS service.  The above-mentioned DNS services are 
are supposed to speed up web browsing.  That only works if the 
content provider can determine the "nearest" HTTP service from where 
the content can be served.  It does not work well when OpenDNS or 
Google Public DNS are used, hence this proposal to provide some 
client identifier through an EDNS option.

If these DNS services were small fry, I doubt that CDNs would bat an 
eye about the problem.  After all, their existing DNS tricks seemed 
to be working quite well.  If using the DNS services result in slower 
web access, it is a disadvantage for these two services.  The fix 
proposed is for the these DNS services to send a client identifier to the CDNs.

 From Section 9.1 of draft-vandergaast-edns-client-subnet-00:

   "Users who wish their full IP address to be hidden can include an
    edns-client-subnet option specifying the wildcard address 0.0.0.0/0"

It was mentioned previously that:

   "We believe, however, that a perfect solution would require
    making changes to how the user agent works. We can't do that, we
    only get to change the nameservers and recursive resolvers."

And:

   "We don't see this option being enabled by anyone else,
    or worse, by default."

Users who do not wish to provide a client identifier will have to 
update their software to support this specification.

As to being the default, if OpenDNS and Google says that it is better 
for the Internet and I say it isn't, who would you believe?

Regards,
-sm

---

From: Martin Barry <[email-masked]>
Date: Tue, 6 Sep 2011 09:28:58 +0200

$quoted_author = "SM" ;
 
> update their software to support this specification.

Or they could just not use OpenDNS, Google DNS or any other 3rd party
recursive DNS provider who enables edns-client-subnet.

cheers
Marty

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 06 Sep 2011 16:58:31 +0900

SM wrote:

> The above-mentioned DNS services are are supposed to speed
> up web browsing.

Do you mean that the motivation is to improve TCP performance by
reducing TTL and *NOT* to reduce privacy?

> I might describe the problem as follows. These DNS services provide an 
> "off-net" recursive resolver service for clients. Clients are generally 
> assigned a DNS server that is topologically close to them, i.e. their 
> ISP's DNS service.

Then, as as an IP address of "a DNS server (resolver is the
correct word, here) that is topologically close to them" is
known to OpenDNS and Google Public DNS, why do you have to
be bothered by client subnet?

I'm afraid your actual motivation is *NOT* performance *BUT*
precise geo-location of clients.

Yes, content providers can still know IP addresses of clietns,
from which precise geo-location may be obtained.

However, I can see no reason why clients privacy information
must unnecessarily known by OpenDNS and Google Public DNS
servers.

> That only works if the content provider can
> determine the "nearest" HTTP service from where the content can be
> served.

For performance purpose, HTTP server "nearest" to "a DNS
resolver that is topologically close to them" should be
enough.

						Masataka Ohta

---

From: "Marc Lampo" <[email-masked]>
Date: Tue, 6 Sep 2011 10:53:21 +0200 (CEST)

Hello,

Point taken about it not being strictly required to effectively calculate
RRSIG's
on slave name servers.
While the caching name service might be aware about this particularity of
RRSIG's :
 - several RRSIG's for same "RRset" but with different number of records
in the RRset.
Other problems to be solved :
 - how can caching name service know which RRSIG, applying to RRset with
eg one A-record,
    goes with which A-record ?
    Do you want to check RRSIG in the caching name service and send only
the RRSIG that matches ?
 - this is not "standard" for the authoritative name services,
    to provide these multiple RRSIG's.
    In case of 3 A-records in a RRset,
    it would mean 3 RRSIG's applying to RRset with one A-record only,
     + 1 RRSIG applying to complete RRset (all A-records).

The EDNS0 OPT record is mandatory, for DNSSEC.
Records from client to server cannot be signed anyway;
I see no requirement/recommendation of signing the OPT record from server
to client.
(the OPT record does not "live" as "signable data" in the zone file !
 it holds data that is applicable to a particular name server :
 eg depending on how (what MTU) is valid at that particular name servers
location)

No, that is not the attack scenario I am referring at.
But this mailing list is hardly the place to show potential cache
poisoning attacks, is it ?

What I really meant to express, is that, for public caching name services,
I'd recommend they implement DNSSEC themselves
 (first - before implementing this/your draft RFC)
at least to the extend that they know where to locate the DS records.
That way, forwarding name servers are at least allowed to/capable of
performing DNSSEC validation themselves,
thus eliminating the risk of getting their cache poisoned.

Kind regards,

Marc Lampo
EURid
Security Officer

-----Original Message-----
From: Wilmer van der Gaast [mailto:[email-masked]] 
Sent: 05 September 2011 07:28 PM
To: Marc Lampo
Cc: [email-masked]
Subject: Re: [dnsext] afasterinternet.com trial and
draft-vandergaast-edns-client-subnet-00

It may still be reasonable to mention something along these lines in the
I-D.

Regards,

---

From: Tony Finch <[email-masked]>
Date: Tue, 6 Sep 2011 14:29:07 +0100

Marc Lampo <[email-masked]> wrote:
> eg one A-record, goes with which A-record ?

An RRSIG covers an entire RRset. Different caches may see different
RRsets, and the same cache may see different RRsets at different times, so
caches need to ensure each RRSIG is transmitted, cached, and expired
alongside its RRset.

The EDNS client subnet option allows caches to store multiple RRsets for
the same name, type, and class at the same time, distinguishing them
according to the client IP address.

>     to provide these multiple RRSIG's.

Correct. Geo IP requires stunt name servers for all authoritative servers.
The servers hand out different versions of the same RRset according to
some internal logic. Each version of the RRset needs an appropriate RRSIG.
There only need to be RRSIGs for the RRsets that are actually served.

> The EDNS0 OPT record is mandatory, for DNSSEC. Records from client to
> server cannot be signed anyway; I see no requirement/recommendation of
> signing the OPT record from server to client.

SIG(0) / TSIG.

>  (first - before implementing this/your draft RFC)

Yes, but the only people who need to implement this draft are those
running open resolvers with a very widely dispersed client population, and
content delivery networks who want accurate geo IP for users of large open
resolver services.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Portland, Plymouth: Southwest veering west 6 to gale 8, occasionally severe
gale 9 at first in Portland, decreasing 5 at times later. Rough, occasionally
very rough at first. Rain then showers. Moderate or good.

---

From: Florian Weimer <[email-masked]>
Date: Tue, 06 Sep 2011 13:32:33 +0000

* Matt McCutchen:

> From the peanut gallery, having a private use range seems like a
> no-brainer.

Some EDNS0 server-side implementations treat unknown option codes as
hard errors.  I'm not sure how widespread they are (but I believe at
least one of them is still under security support).  If widespread, it
would make it difficult to define new option codes and make them work.
A private use range implies an implicit promise that you can actually
use it for experiments, and this may not be the case here.

-- 
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: Edward Lewis <[email-masked]>
Date: Tue, 6 Sep 2011 09:56:02 -0400

Marc,

Some of your concerns are already addressed by production software, 
even prior to the client-subnet proposal.  Some concerns are already 
addressed by code that's "on the whiteboard" or better.  And some 
concerns do need to be described in the document.

As far as authoritative servers, the code that does the same as 
client-subnet is out there.  For example, BIND has had "views" for a 
long time to support split DNS.  BIND allows packets to be segregated 
by source IP or by destination IP (for use in servers that are 
multihomed). BIND uses particular zone files (which may be signed) 
for each "bucket" where queries are segregated.  BIND's approach is 
not the only way to do this, just the most mature deployment out 
there, especially when confining the discussion to open source.

Neustar (for one, one I have knowledge of) has a proprietary 
implementation that can do the same.  Today our offered service does 
not support DNSSEC but should in some coming time frame.  (I.e., it's 
whiteboard or better.)  Our technical challenge is to sign the 
different possible answers ahead of time (easy) and then make sure 
the signature records are correctly associated with the appropriate 
answer sets (moderate problem).

To us (Neustar's authoritative service), the only difference between 
today's offering (plus DNSSEC) and what client-subnet proposes (plus 
DNSSEC) is that when we choose based on only on the query's source IP 
address, we will have to substitute what's in the proposed EDNS0 
option field and return appropriate address scoping information. 
Outside of where we get the parameter for "IP of who's asking" not 
much changes.

As far as how recursive servers handle this, I don't know of any 
currently distributed servers that support this.  (I'm sure there are 
some, I just am not privy to them.)  The matter of assembling the 
query is rather simple, just put into the proposed option the value 
(IP subnet) to be used.  (Having to treat BCP 153 space is needed as 
the equivalent in IPv6.  And then there's NAT, etc.)  The matter of 
how an iterative, caching server handles all this has to be 
accomplished.  A lot of this though is implementation specific, the 
draft does need to lay out what defines "interoperable."

All in all, though, DNSSEC isn't hard part of this.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Vote for the word of the day:
"Papa"razzi - father that constantly takes photos of the baby
Corpureaucracy - The institution of corporate "red tape"

---

From: SM <[email-masked]>
Date: Tue, 06 Sep 2011 07:46:01 -0700

>reducing TTL and *NOT* to reduce privacy?

See http://forums.opendns.com/comments.php?DiscussionID=1096  The 
privacy threads are at 
http://www.ietf.org/mail-archive/web/dnsext/current/msg06548.html and 
http://www.ietf.org/mail-archive/web/dnsext/current/msg06577.html

For anyone interested in privacy, there was a position paper 
submitted by IETF participants ( 
http://www.w3.org/2010/api-privacy-ws/papers/privacy-ws-32.pdf ).

>be bothered by client subnet?

The authors of draft-vandergaast-edns-client-subnet-00 might point to 
Section 9.1.

Regards,
-sm

---

From: Ted Hardie <[email-masked]>
Date: Tue, 6 Sep 2011 10:22:04 -0700

> or DNS-based CDNs being a reasonable solution at all?

Not exactly, no.  Some of those discussions suggested that this be opt-in
rather than opt-out (so that the EDNS option is set by the client when
desired, rather than it setting 0.0.0.0. when it does not desire it).

The basic issue here is that this effectively changes the q-tuple to include
a subnet as part of the question being asked.  A discussion of why
an intermediate should be the one to change the question seems warranted,
if only to highlight the parameters  of the experiment.

regards,

Ted Hardie

---

From: Ted Hardie <[email-masked]>
Date: Tue, 6 Sep 2011 10:25:44 -0700

> recursive DNS provider who enables edns-client-subnet.

Hi Marty,

The current draft says:

   In any case, the response from the resolver to the client MUST NOT
   contain the edns-client-subnet option if none was present in the
   client's original request.  If the original client request contained
   a valid edns-client-subnet option that was used during recursion, the
   Recursive Resolver MUST include the edns-client-subnet option from
   the Authoritative Nameserver response in the response to the client.

Given that, how is the client to know whether the service they are using enables
edns-client-subnet?

regards,

Ted

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 6 Sep 2011 10:26:58 -0700

> use it for experiments, and this may not be the case here.

Unless the authority actually CRASHES when it receives an unknown EDNS0 option code, there is no problem.

All the resolver/client using the EDNS0 unknown option code needs to do is treat it the same way you treat lack of EDNS0 support/lack of fragment support already:  Detect and fallback to not using the unknown option code.

So its really nothing new, just using the same techniques already in place for all the @#)(*#) which doesn't understand EDNS0 or is behind a broken (fragment or EDNS0 denying) firewall.

And if the authority DOES crash when it receives an unknown EDNS0 option code, well, report it as a security bug to the vendor.

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 6 Sep 2011 10:28:21 -0700

> Given that, how is the client to know whether the service they are using enables

a)  Does it matter?

b)  Do a query with EDNS0 client subnet and see what happens.

---

From: Ted Hardie <[email-masked]>
Date: Tue, 6 Sep 2011 10:40:34 -0700

> On Sep 6, 2011, at 10:25 AM, Ted Hardie wrote:
(adding Marty's comment back in )

> b)  Do a query with EDNS0 client subnet and see what happens.

The upshot of this is that SM is right:  clients who do not wish to
provide a client
identifier will have to update their software to achieve this goal,
since they cannot
identify whether a service is using it without that update.

regards,

Ted Hardie

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 6 Sep 2011 11:02:15 -0700

> identify whether a service is using it without that update.

But at the same time, what information is being leaked to whom?  

Which is the only reason why a client would want to disable this at all, and the only reason to argue for "opt-in" rather than "opt-out" on the client viewpoint.  (Yes, this zombie keeps rising.) 

NO information is being leaked TO the recursive resolver, it already gets all this information.

The only information leakage is SUBNET (NOT IP address), TO the authority for the domain.  

Which would ONLY be an information leakage at all if either:

a)  The authority is NOT responsible for operating the final server the client eventually contacts 
or
b)  The client does NOT use the DNS record to contact a server belonging to the authority
or
c)  The client uses a broken tunnel, contacting the final server from a different IP from that used by DNS.

And this is ONLY necessary for out-of-path resolvers (eg, Google Public DNS, OpenDNS), where in almost all cases the user has already explicitly opted in!  

No other resolver really benefits from supporting this anyway, as most of the big nation-spanning ISPs have already gone with a distributed DNS infrastructure, so the IP address of the query to the authority is already giving the authority of the domain information roughly equivalent to what EDNS-client-subnet provides.

---

From: Ted Hardie <[email-masked]>
Date: Tue, 6 Sep 2011 11:29:08 -0700

> The only information leakage is SUBNET (NOT IP address), TO the authority for the domain.

This EDNS0 option provides data about the  address range in which the
stub resolver's IP  occurs to the authoritative DNS server (whether it
should really be called a subnet is a nit).  I think that intention is
clear in the draft, and if I said anything that indicated I didn't see
that as the intention or didn't think it was clear, please take this
as a correction.

regards,

Ted Hardie

---

From: Martin Barry <[email-masked]>
Date: Tue, 6 Sep 2011 20:53:14 +0200

$quoted_author = "Ted Hardie" ;
> Given that, how is the client to know whether the service they are using enables

You could, as Nicholas suggested, test a query with edns-client-subnet set.

However I would expect that the information these providers offer to
potential users contains advice that use of the service implies opting-in to
the forwarding of the range containing the user's IP to other services to
improve geo-IP responses. I'm sure users will read it and understand it much
like they do all the other fine print. However, I'm sure anyone who cares
about privacy to this extent is probably already too risk averse to use said
services anyway.

cheers
Marty

---

From: [email-masked]
Date: Tue, 6 Sep 2011 20:55:31 +0000

> c)  The client uses a broken tunnel, contacting the final server from a different IP from that used by DNS.

	c) - at one time was very common, most computers had multiple NICs, each with its own IP.
	     in the last decade, it became common for a single NIC with one usable IP, HOWEVER
	     these days, the NIC in my laptop has NINE IPs associated with it (thanks IPv6)...

	     So the channel my machine uses to talk to the DNS likely has little to no relationship
	     with the channel used to talk with other nodes. This is particularly true in walled
	     gardens with DNS lattice... The DNS server has no idea/concept of the topology betwen
	     my node and the target node - This proposal is trying to allow DNS service to 
	     fabricate a synthetic view of a presumed map of Internet topology and then project 
	     that fabrication on its clients.  

	     IMHO, that pretty much exceeds the remit of the DNS. :)

/bill

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 6 Sep 2011 18:26:49 -0400

Then let them break.

If people are cretinous to make that type of mistake then they are going to
see stuff break all over.

Google can fix this in a week. All they need to do is to advertise a random
EDNS0 code and the problem will go away pronto.

Seriously, this was intended to be the extension mechanism for DNS . People
should have known.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 07 Sep 2011 08:01:48 +0900

> See http://forums.opendns.com/comments.php?DiscussionID=1096 The privacy 
> threads are at 

I looked at your referral but can't see any point, which
impresses me that you are trying not to enhance performance
but to reduce users' privacy.

Then, there is no point for IETF to admit such an extension.

Or, if you want to argue something, make your point by your own
words.

> For anyone interested in privacy, there was a position paper submitted 
> by IETF participants ( 

Isn't it enough that the paper title says "improving privacy
on the Internet", where as the client subnet option actively
degrade the privacy?

> The authors of draft-vandergaast-edns-client-subnet-00 might point to 

My question is "why do you have to be bothered by client subnet?"
even though there is no need for performance enhancement.

The section of the draft says nothing about it.

						Masataka Ohta

---

From: Wilmer van der Gaast <[email-masked]>
Date: Wed, 7 Sep 2011 11:39:37 +0100

> Given that, how is the client to know whether the service they are using enables
Correct.

If there's demand for it, it shouldn't be hard to run a server
somewhere that (similar to names like self.myresolver.info and
dso.honeyd.org) will return you a response telling if there was an
edns-client-subnet option and/or what was in it.

Cheers,

---

From: SM <[email-masked]>
Date: Wed, 07 Sep 2011 09:47:57 -0700

>but to reduce users' privacy.

There seems to be a misunderstanding.  I did not author the 
proposal.  The referrals are informative.  It is left to the reader 
to form an opinion about performance enhancement and loss of user privacy.

Regards,
-sm