Subject: [DNSOP] I-D Action: draft-ietf-dnsop-edns-client-subnet-02.txt

From: [email-masked]
Date: Mon, 06 Jul 2015 15:06:40 -0700

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           : Client Subnet in DNS Queries
        Authors         : Carlo Contavalli
                          Wilmer van der Gaast
                          David C Lawrence
                          Warren Kumari
	Filename        : draft-ietf-dnsop-edns-client-subnet-02.txt
	Pages           : 27
	Date            : 2015-07-06

Abstract:
   This draft defines an EDNS0 extension to carry information about the
   network that originated a DNS query, and the network for which the
   subsequent response can be cached.

IESG Note

   [RFC Editor: Please remove this note prior to publication ]

   This informational document describes an existing, implemented and
   deployed system.  A subset of the operators using this is at
   http://www.afasterinternet.com/participants.htm . The authors believe
   that it is better to document this system (even if not everyone
   agrees with the concept) than leave it undocumented and proprietary.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-client-subnet/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dnsop-edns-client-subnet-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-edns-client-subnet-02

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/

---

From: "Mark Delany" <[email-masked]>
Date: 16 Jul 2015 14:15:53 +0000

> 	Filename        : draft-ietf-dnsop-edns-client-subnet-02.txt

I was under the (perhaps mistaken) impression that there was a plan to
rewrite this spec in light of actually implementation experiences. Is
this draft that rewrite? I ask as this seems to be more a clean-up of
the original draft.

If it is the former then one issue I raised with the previous draft
remains undiscussed and unchanged. That being the notion of
caches/resolvers using white lists to constrain which servers should
be sent the ECS option.

We all know a white-list doesn't scale for an internet protocol and my
limited experience of hunting down owners, exchanging emails and
agreeing on a white list format is pretty broken and brittle.

I would think that if we're to proceed with this protocol then the
white list requirement should be removed from the spec.

Mark.

---

From: Dave Lawrence <[email-masked]>
Date: Thu, 16 Jul 2015 11:56:22 -0400

> this draft that rewrite? I ask as this seems to be more a clean-up of

There is a plan to rewrite the spec, but not in this draft.  The
existing deployed base meant that no meaningful changes to the
protocol under the current option code could be made without
significant pain.  There is no will among the providers currently
using it to assume that pain.  So yes, this draft is just a cleanup
addressing the existing implementations.

> white list requirement should be removed from the spec.

I don't see language in the current draft that makes a whitelist a
requirement.  The language I do see doesn't even use 2119
capitalization, so it's even softer than usual.  If there is a
statement in there that you think mandates whitelists, I am amenable
to modifying it.  I see that as an endpoint operational policy issue,
not a core protocol issue.

---

From: "Mark Delany" <[email-masked]>
Date: 16 Jul 2015 16:09:41 +0000

On 16Jul15, Dave Lawrence allegedly wrote:
> statement in there that you think mandates whitelists

True, there is no mandate, but all implementations that I'm aware of,
have implemented a white list. While the language is softer in -02, is
it necessary at all as it will only continue to encourage white list
behavior just as the previous language did.

IOWs, why not remove 11.2 completely?

Mark.

---

From: Dave Lawrence <[email-masked]>
Date: Thu, 16 Jul 2015 14:30:20 -0400

> behavior just as the previous language did.

The reality is that at least one major provider of authoritative ECS
service has realistically no chance at all of removing its whitelist
in the visible future.  At least one major recursive implementer has
found that they must use a whitelist for sending ECS as well or they
pay a significant penalty on first hit to a server that mishandles it.

That is not to say that I disagree with your basic point.  Whitelists
are a pain to accurately maintain, of that there is no doubt.  They
are, however, also reality.

> IOWs, why not remove 11.2 completely?

In my opinion, it is important to make the reader aware that such
whitelisting does exist and that ECS won't just work out of the box
between any two ECS-supporting recursive/authoritative instances.