[DNSOP] call to work on edns-client-subnet

[Joe Abley]

Hi all,

I'm seeing increasing discussion about edns-client-subnet (most recently 
documented, I think, in the expired document 
draft-vandergaast-edns-client-subnet-02), both in commercial and open source 
venues (there's an active thread on the unbound-users mailing list right now, 
for example).

Google DNS supports edns-client-subnet, which by recent GIH+GGM count means 
10%+ of all client queries now trigger queries to authority servers with that 
option included.

On the authority side, support for this option has a potential impact on query 
load. On the recursive side, support for this option has a potential impact on 
cache size.

With multiple implementations, there are interop issues.

If I recall the history of draft-vandergaast-edns-client-subnet-02, it stalled 
because various persuasive people in IETF working groups reacted to the vomity 
taste it left in their mouths (by which I refer to the concept, not the quality 
of the documentation). I may well have been one of them.

However, I now feel that regardless of any vomity taste, what we are looking at 
is a proposal that has been implemented in multiple code bases (and hence must 
interoperate), has seen significant deployment and the use of which has 
operational consequences. Both the protocol changes and the impact on 
operations should be documented.

I think dnsop should pick up some or all of this work. I think not picking up 
this work will result in implementation and operational problems. (I am 
reminded of the consequences of not standardising NAT, for example.)

I would be happy to contribute reviews and/or text.

Thoughts?


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] call to work on edns-client-subnet

[Tim Wicinski]

On 5/6/14, 1:18 PM, Joe Abley wrote:

Hi all,

I'm seeing increasing discussion about edns-client-subnet (most recently 
documented, I think, in the expired document 
draft-vandergaast-edns-client-subnet-02), both in commercial and open source 
venues (there's an active thread on the unbound-users mailing list right now, 
for example).

Google DNS supports edns-client-subnet, which by recent GIH+GGM count means 
10%+ of all client queries now trigger queries to authority servers with that 
option included.

On the authority side, support for this option has a potential impact on query 
load. On the recursive side, support for this option has a potential impact on 
cache size.

With multiple implementations, there are interop issues.

If I recall the history of draft-vandergaast-edns-client-subnet-02, it stalled 
because various persuasive people in IETF working groups reacted to the vomity 
taste it left in their mouths (by which I refer to the concept, not the quality 
of the documentation). I may well have been one of them.

However, I now feel that regardless of any vomity taste, what we are looking at 
is a proposal that has been implemented in multiple code bases (and hence must 
interoperate), has seen significant deployment and the use of which has 
operational consequences. Both the protocol changes and the impact on 
operations should be documented.

I think dnsop should pick up some or all of this work. I think not picking up 
this work will result in implementation and operational problems. (I am 
reminded of the consequences of not standardising NAT, for example.)

I would be happy to contribute reviews and/or text.

Thoughts?


Joe,

The Chairs have been discussing this as recently as yesterday, with the 
advent of what appears to be the acceptance of our new charter.  We were 
going to reach out and restart that discussion.


Our initial thought was that with all the EDNS extensions that once they 
are given their IANA codepoint, any documentation that can be provided 
is an added bonus.   We were thinking that these would be relatively 
easy to move these along as 'Informational' level and not 'Standards 
Track'.  We're wondering what the working group thinks.


The Chairs were waiting to bring this once some of the older work has 
moved through our system, to not overwhelm the members.


(This also includes Paul's drafts which also need a more formal 
conversation).


tim

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] call to work on edns-client-subnet

[Doug Barton]

On 05/06/2014 10:18 AM, Joe Abley wrote:

I think not picking up this work will result in implementation and operational 
problems.


Those of us who still have the vomity taste would like the problems with 
interop and implementation to continue.


Just because we _can_ make something work better doesn't mean we _should_.

Doug

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] call to work on edns-client-subnet

[Joe Abley]

On 6 May 2014, at 13:27, Doug Barton  wrote:

> On 05/06/2014 10:18 AM, Joe Abley wrote:
>> I think not picking up this work will result in implementation and 
>> operational problems.
> 
> Those of us who still have the vomity taste would like the problems with 
> interop and implementation to continue.
> 
> Just because we _can_ make something work better doesn't mean we _should_.

As a matter of principle, I don't think people who never plan to use an 
extension should stand in the way of those who do. The IETF doesn't exist to 
stop people doing things.

(And again, see NAT.)


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] call to work on edns-client-subnet

[David Conrad]

On May 6, 2014, at 10:30 AM, Joe Abley  wrote:
> On 6 May 2014, at 13:27, Doug Barton  wrote:
>> On 05/06/2014 10:18 AM, Joe Abley wrote:
>>> I think not picking up this work will result in implementation and 
>>> operational problems.
>> 
>> Those of us who still have the vomity taste would like the problems with 
>> interop and implementation to continue.
>> 
>> Just because we _can_ make something work better doesn't mean we _should_.
> 
> As a matter of principle, I don't think people who never plan to use an 
> extension should stand in the way of those who do. The IETF doesn't exist to 
> stop people doing things.
> 
> (And again, see NAT.)

+1 (actually, +∞, but not sure that's interoperable)

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] call to work on edns-client-subnet

[Paul Wouters]

On Tue, 6 May 2014, Joe Abley wrote:


I think dnsop should pick up some or all of this work. I think not picking up 
this work will result in implementation and operational problems. (I am 
reminded of the consequences of not standardising NAT, for example.)

I would be happy to contribute reviews and/or text.


I reluctantly agree, and I'm willing to review and contribute as well.
This has to be handled carefully to avoid privacy/tracking issues,
but clearly we also want to stimulate a more de-centralised resolver
infrastructure that can still deal with geolocation and CDN's.

Paul

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] call to work on edns-client-subnet

[Ralf Weber]

Moin!

On 06 May 2014, at 19:18, Joe Abley  wrote:
> Google DNS supports edns-client-subnet, which by recent GIH+GGM count means 
> 10%+ of all client queries now trigger queries to authority servers with that 
> option included.
> 
> On the authority side, support for this option has a potential impact on 
> query load. On the recursive side, support for this option has a potential 
> impact on cache size.
> 
> With multiple implementations, there are interop issues.
Probably, but we don't know as so far everybody implementing has implemented 
both sides of it and used that. The only "interop" experiences I know of where 
researchers using the option to find out about CDNs utilising it.

[...]

> I think dnsop should pick up some or all of this work. I think not picking up 
> this work will result in implementation and operational problems. (I am 
> reminded of the consequences of not standardising NAT, for example.)
> 
> I would be happy to contribute reviews and/or text.
> 
> Thoughts?
Fully agree.

So long
-Ralf

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] call to work on edns-client-subnet

[Colm MacCárthaigh]

On Tue, May 6, 2014 at 10:18 AM, Joe Abley  wrote:

> On the authority side, support for this option has a potential impact on
> query load. On the recursive side, support for this option has a potential
> impact on cache size.
>

Just to add some limited data; CloudFront (a large CDN) has been using
EDNS0 client subnet for a few months now, and publically announced a month
ago. In general, the uptick on the authority side has been surprisingly
modest.


> With multiple implementations, there are interop issues.
>

We've noticed some inconsistency around the subnet lengths being required
in responses, but nothing unmanageable. In general, it's been pretty smooth!

The biggest operational problem is probably a lack of support in diagnostic
tools, with an RFC, I'm hopeful we could get a patch into the standard
version of dig - which would be useful for debugging and so on.

There might also be a place for an informational document/rfc on
source-dependent answers in general. For example, even for those who
believe that source dependent answers has a place, having source-dependent
NS, DS records or delegation paths can be just plain unworkable.


-- 
Colm
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] call to work on edns-client-subnet

[Jiankang Yao]

Section 3.1.1.  Responses Tailored to the Originator in the 
draft-iab-dns-applications-07 
has some related discussion to this topic.

From the IAB draft, it seems that IAB does not prefer to tailor dns response 
based on the originator.





Jiankang Yao

From: Joe Abley
Date: 2014-05-07 01:18
To: DNSOP WG
Subject: [DNSOP] call to work on edns-client-subnet
Hi all,

I'm seeing increasing discussion about edns-client-subnet (most recently 
documented, I think, in the expired document 
draft-vandergaast-edns-client-subnet-02), both in commercial and open source 
venues (there's an active thread on the unbound-users mailing list right now, 
for example).

Google DNS supports edns-client-subnet, which by recent GIH+GGM count means 
10%+ of all client queries now trigger queries to authority servers with that 
option included.

On the authority side, support for this option has a potential impact on query 
load. On the recursive side, support for this option has a potential impact on 
cache size.

With multiple implementations, there are interop issues.

If I recall the history of draft-vandergaast-edns-client-subnet-02, it stalled 
because various persuasive people in IETF working groups reacted to the vomity 
taste it left in their mouths (by which I refer to the concept, not the quality 
of the documentation). I may well have been one of them.

However, I now feel that regardless of any vomity taste, what we are looking at 
is a proposal that has been implemented in multiple code bases (and hence must 
interoperate), has seen significant deployment and the use of which has 
operational consequences. Both the protocol changes and the impact on 
operations should be documented.

I think dnsop should pick up some or all of this work. I think not picking up 
this work will result in implementation and operational problems. (I am 
reminded of the consequences of not standardising NAT, for example.)

I would be happy to contribute reviews and/or text.

Thoughts?


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] call to work on edns-client-subnet

[Colm MacCárthaigh]

On Tue, May 6, 2014 at 6:04 PM, Jiankang Yao  wrote:

>   Section 
> 3.1.1.
> Responses Tailored to the Originator in the draft-iab-dns-applications-07
> has some related discussion to this topic.
>
> From the IAB draft, it seems that IAB does not prefer to tailor dns
> response based on the originator.
>

3.1.1 reads pretty neutral to me, even saying that it "introduces little
harm" (for web portals) and that it has broad adoption in the field.  It
just notes that it doesn't have much support in the community.

But it clearly has broad support on the internet. At this point a majority
of DNS responses are likely based on the originator (that's my guess based
on local data, but it'd be interesting to see real data).

-- 
Colm
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] call to work on edns-client-subnet

[Jiankang Yao]

One view about this issue based on the previous discussion years ago is that 
the dns implementors may choose to tailor the dns response in their own way, 
but ietf is unlikely to standardize it.




Jiankang Yao

From: Colm MacCárthaigh
Date: 2014-05-07 09:14
To: yaojk
CC: Joe Abley; dnsop
Subject: Re: [DNSOP] call to work on edns-client-subnet


On Tue, May 6, 2014 at 6:04 PM, Jiankang Yao  wrote:

Section 3.1.1.  Responses Tailored to the Originator in the 
draft-iab-dns-applications-07

has some related discussion to this topic.

From the IAB draft, it seems that IAB does not prefer to tailor dns response 
based on the originator.


3.1.1 reads pretty neutral to me, even saying that it "introduces little harm" 
(for web portals) and that it has broad adoption in the field.  It just notes 
that it doesn't have much support in the community. 


But it clearly has broad support on the internet. At this point a majority of 
DNS responses are likely based on the originator (that's my guess based on 
local data, but it'd be interesting to see real data).


-- 
Colm ___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] I-D Action: draft-ietf-dnsop-rfc6598-rfc6303-01.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Domain Name System Operations Working Group 
of the IETF.

Title   : Add 100.64.0.0/10 prefixes to IPv4 Locally-Served DNS 
Zones Registry.
Author  : M. Andrews
Filename: draft-ietf-dnsop-rfc6598-rfc6303-01.txt
Pages   : 5
Date: 2014-05-06

Abstract:
   RFC6598 specified that: "Reverse DNS queries for Shared Address Space
   addresses [100.64.0.0/10] MUST NOT be forwarded to the global DNS
   infrastructure."

   This document formally directs IANA to add the associated zones to
   the "IPv4 Locally-Served DNS Zones Registry" to prevent such queries
   accidently leaking to the global DNS infrastructure.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc6598-rfc6303/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dnsop-rfc6598-rfc6303-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rfc6598-rfc6303-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] call to work on edns-client-subnet

[Doug Barton]

On 05/06/2014 10:30 AM, Joe Abley wrote:


On 6 May 2014, at 13:27, Doug Barton  wrote:


On 05/06/2014 10:18 AM, Joe Abley wrote:

I think not picking up this work will result in implementation and operational 
problems.


Those of us who still have the vomity taste would like the problems with 
interop and implementation to continue.

Just because we _can_ make something work better doesn't mean we _should_.


As a matter of principle, I don't think people who never plan to use an 
extension should stand in the way of those who do. The IETF doesn't exist to 
stop people doing things.


Would you feel the same way about a protocol that made it easier for the 
NSA to trace users? Or make it easier for China to firewall the West? Or 
for some other theoretical government to hunt down and kill dissidents 
that post criticisms of that government?


You could say that I'm arguing 'ad absurdum' here, but I'm not. There 
really are such things as bad ideas, and it's perfectly reasonable for 
the IETF to decide that something is a bad idea, and shouldn't be done. 
Or at least, shouldn't be made easier to do.



(And again, see NAT.)


So NAT is an interesting case, since there's no doubt that the IETF 
dropped the ball on that. But the problem there was not that the IETF 
chose not to act in order to not support NAT, the problem there was that 
the collective decision process failed by determining that NAT was a bad 
idea.


The remedy to that error is not to swing the pendulum all the way in the 
other direction, and support every idea no matter how bad. The answer is 
to make better decisions.


Doug

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] call to work on edns-client-subnet

[Jewforice]

Tencent has been supporting edns client subnet for nearly a year . On the 
authority side , we benifit so much from ECS for the extra accuracy  of user 
geo-location identification ,which helps a lot for our users' network access 
optimization and our access traffic scheduling at a totally tolerable increased 
query load. The shift process is smooth and nothing goes wrong in the 
production environment .

According to my operation experience with ECS, I think ECS is good for Internet 
Content Providers, CDN vendors and cloud service providers who schedule their 
access traffic based on DNS resolution and making ECS a standard track may help 
them a lot to guide the implementation for both the authority side and the 
recursive side.

Weijian Liao

> 在 2014年5月7日，5:51，Colm MacCárthaigh  写道：
> 
> 
>> On Tue, May 6, 2014 at 10:18 AM, Joe Abley  wrote:
>> On the authority side, support for this option has a potential impact on 
>> query load. On the recursive side, support for this option has a potential 
>> impact on cache size.
> 
> Just to add some limited data; CloudFront (a large CDN) has been using EDNS0 
> client subnet for a few months now, and publically announced a month ago. In 
> general, the uptick on the authority side has been surprisingly modest. 
>  
>> With multiple implementations, there are interop issues.
> 
> We've noticed some inconsistency around the subnet lengths being required in 
> responses, but nothing unmanageable. In general, it's been pretty smooth!
> 
> The biggest operational problem is probably a lack of support in diagnostic 
> tools, with an RFC, I'm hopeful we could get a patch into the standard 
> version of dig - which would be useful for debugging and so on.
> 
> There might also be a place for an informational document/rfc on 
> source-dependent answers in general. For example, even for those who believe 
> that source dependent answers has a place, having source-dependent NS, DS 
> records or delegation paths can be just plain unworkable. 
> 
> 
> -- 
> Colm
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop