RE: Update on RFC7871 - Client Subnet in DNS Support

2017-06-06 Thread Eric Friedrich (efriedri) 
I should also add this will be disabled by default. Even if enabled it will not 
change TR behavior unless the resolver includes the ECS field 

From: Steve Malenfant [smalenf...@gmail.com]
Sent: Tuesday, June 6, 2017 5:03 PM
To: dev@trafficcontrol.incubator.apache.org
Subject: Re: Update on RFC7871 - Client Subnet in DNS Support

I've been able to start some discussions internally and looks like it would
be considered for certain domains (Like the one served by Traffic Routers).
We definitevely have cache groups which are not associated with some local
caching DNS.

On Tue, Jun 6, 2017 at 2:50 PM, Eric Friedrich (efriedri) <
efrie...@cisco.com> wrote:

> Thanks Ryan-
>We will certainly have the option to disable use of this if you don’t
> want to use it.
>
> This is useful feedback though and I’ll be sure to push on the caching
> aspects of our specific use case more.
>
> —Eric
>
> > On Jun 6, 2017, at 2:43 PM, Durfey, Ryan 
> wrote:
> >
> > FYI, I followed up with one of our staff informally about implementation
> of RFC7871 and got similar feedback.  They ran a test and found a lot of
> impacts at scale.
> >
> > Feedback:
> > We found that EDNS0 Client Subnet, as currently standardized and
> implemented, doesn't work well with our distribution/scale.  Could actually
> increase the number of upstream queries and memory required to store
> responses by 1000x.
> >
> > Ryan DurfeyM | 303-524-5099
> >
> >
> > From: Steve Malenfant 
> > Reply-To: "dev@trafficcontrol.incubator.apache.org" <
> dev@trafficcontrol.incubator.apache.org>
> > Date: Monday, June 5, 2017 at 6:15 AM
> > To: "dev@trafficcontrol.incubator.apache.org" <
> dev@trafficcontrol.incubator.apache.org>
> > Subject: Re: Update on RFC7871 - Client Subnet in DNS Support
> >
> > +1.  We have a hard time convincing our DNS team to enable EDNS0 in our
> > caching DNS (because of the caching implications). I do see great
> benefits
> > to localize DNS DS.
> >
> > On Sun, Jun 4, 2017 at 5:29 AM, Ori Finkelman > wrote:
> >
> > +1
> > This will also work nicely with the effort to have a localized TR DNS
> > selection.
> > If Traffic Routers are selected the same way a traffic server is
> selected,
> > by the client proximity from CZF or Geo, then using EDNS0 client-subnet
> > will enable this choice to be more accurate based on real client subnet
> > rather than DSN resolver.
> >
> >
> >
> > On Fri, Jun 2, 2017 at 10:46 PM, David Neuman  mailto:david.neuma...@gmail.com>>
> > wrote:
> >
> >> +1, excited to see this one come through.
> >>
> >> On Fri, Jun 2, 2017 at 12:15 PM, Eric Friedrich (efriedri) <
> >> efrie...@cisco.com> wrote:
> >>
> >>> We are planning to add support for RFC7871 to Traffic Router. Here is a
> >>> brief description of the feature. Comments appreciated!
> >>>
> >>> Background
> >>> Clients do not make DNS requests directly to TR. Typically TR requests
> >>> come from DNS resolvers within the infrastructure. Today, Cache Group
> >>> selection for DNS Delivery Services is based on the IP address of the
> > DNS
> >>> resolver making the request to TR. RFC7871 includes the client subnet
> > in
> >> an
> >>> EDNS0 option within the DNS query. When the ECS OPT is present (and the
> >>> feature is enabled via a TR parameter), Traffic Router will use this IP
> >> in
> >>> place of the source IP of the DNS packet (the IP of the resolver). This
> >> IP
> >>> will be used in the CZF and maxmind lookups.
> >>>
> >>> Requirements
> >>>
> >>>  1.  If DNS query includes ECS option in the Optional Record, Traffic
> >>> Router will use the IP address included in the ECS option as the client
> >>> address for Cache Group Selection
> >>>  2.  If there are multiple ECS options in the Optional Record, the one
> >>> with the longest IP prefix - i.e. the ECS option with largest Source
> > Net
> >>> Mask will be used
> >>>  3.  If DNS query includes ECS Option, then DNS response from Traffic
> >>> Router will also include the ECS Option. In the response the Scope Net
> >> Mask
> >>> is set to be same as the Source Net Mask. This is required by RFC 7871
> >> for
> >>> DNS caching to work properly.
> >>>  4.  It is assumed that customers/operators will ensure that Source
> > Net
> >>> Mask for a subnet specified in the ECS is at greater than or equal to
> > the
> >>> net mask for the corresponding subnet entry in the CZF file. e.g. if
> > ECS
> >>> Option has 192.168.10.0/8, then 192.168.0.0/16 in CZF will work, but
> >>> 192.168.10./28 will not work.
> >>>  5.  Add a TR parameter to disable use of ECS field even when present
> >>>
> >>> Design
> >>>
> >>> To support this feature new logic will be added to NameServer.query()
> >>> function. The new logic will be responsible for parsing ECS option in
> > the
> >>> OptionalRecord of the incoming DNS Request, and retrieving the

Re: Update on RFC7871 - Client Subnet in DNS Support

2017-06-06 Thread Steve Malenfant 
I've been able to start some discussions internally and looks like it would
be considered for certain domains (Like the one served by Traffic Routers).
We definitevely have cache groups which are not associated with some local
caching DNS.

On Tue, Jun 6, 2017 at 2:50 PM, Eric Friedrich (efriedri) <
efrie...@cisco.com> wrote:

> Thanks Ryan-
>We will certainly have the option to disable use of this if you don’t
> want to use it.
>
> This is useful feedback though and I’ll be sure to push on the caching
> aspects of our specific use case more.
>
> —Eric
>
> > On Jun 6, 2017, at 2:43 PM, Durfey, Ryan 
> wrote:
> >
> > FYI, I followed up with one of our staff informally about implementation
> of RFC7871 and got similar feedback.  They ran a test and found a lot of
> impacts at scale.
> >
> > Feedback:
> > We found that EDNS0 Client Subnet, as currently standardized and
> implemented, doesn't work well with our distribution/scale.  Could actually
> increase the number of upstream queries and memory required to store
> responses by 1000x.
> >
> > Ryan DurfeyM | 303-524-5099
> >
> >
> > From: Steve Malenfant 
> > Reply-To: "dev@trafficcontrol.incubator.apache.org" <
> dev@trafficcontrol.incubator.apache.org>
> > Date: Monday, June 5, 2017 at 6:15 AM
> > To: "dev@trafficcontrol.incubator.apache.org" <
> dev@trafficcontrol.incubator.apache.org>
> > Subject: Re: Update on RFC7871 - Client Subnet in DNS Support
> >
> > +1.  We have a hard time convincing our DNS team to enable EDNS0 in our
> > caching DNS (because of the caching implications). I do see great
> benefits
> > to localize DNS DS.
> >
> > On Sun, Jun 4, 2017 at 5:29 AM, Ori Finkelman > wrote:
> >
> > +1
> > This will also work nicely with the effort to have a localized TR DNS
> > selection.
> > If Traffic Routers are selected the same way a traffic server is
> selected,
> > by the client proximity from CZF or Geo, then using EDNS0 client-subnet
> > will enable this choice to be more accurate based on real client subnet
> > rather than DSN resolver.
> >
> >
> >
> > On Fri, Jun 2, 2017 at 10:46 PM, David Neuman  mailto:david.neuma...@gmail.com>>
> > wrote:
> >
> >> +1, excited to see this one come through.
> >>
> >> On Fri, Jun 2, 2017 at 12:15 PM, Eric Friedrich (efriedri) <
> >> efrie...@cisco.com> wrote:
> >>
> >>> We are planning to add support for RFC7871 to Traffic Router. Here is a
> >>> brief description of the feature. Comments appreciated!
> >>>
> >>> Background
> >>> Clients do not make DNS requests directly to TR. Typically TR requests
> >>> come from DNS resolvers within the infrastructure. Today, Cache Group
> >>> selection for DNS Delivery Services is based on the IP address of the
> > DNS
> >>> resolver making the request to TR. RFC7871 includes the client subnet
> > in
> >> an
> >>> EDNS0 option within the DNS query. When the ECS OPT is present (and the
> >>> feature is enabled via a TR parameter), Traffic Router will use this IP
> >> in
> >>> place of the source IP of the DNS packet (the IP of the resolver). This
> >> IP
> >>> will be used in the CZF and maxmind lookups.
> >>>
> >>> Requirements
> >>>
> >>>  1.  If DNS query includes ECS option in the Optional Record, Traffic
> >>> Router will use the IP address included in the ECS option as the client
> >>> address for Cache Group Selection
> >>>  2.  If there are multiple ECS options in the Optional Record, the one
> >>> with the longest IP prefix - i.e. the ECS option with largest Source
> > Net
> >>> Mask will be used
> >>>  3.  If DNS query includes ECS Option, then DNS response from Traffic
> >>> Router will also include the ECS Option. In the response the Scope Net
> >> Mask
> >>> is set to be same as the Source Net Mask. This is required by RFC 7871
> >> for
> >>> DNS caching to work properly.
> >>>  4.  It is assumed that customers/operators will ensure that Source
> > Net
> >>> Mask for a subnet specified in the ECS is at greater than or equal to
> > the
> >>> net mask for the corresponding subnet entry in the CZF file. e.g. if
> > ECS
> >>> Option has 192.168.10.0/8, then 192.168.0.0/16 in CZF will work, but
> >>> 192.168.10./28 will not work.
> >>>  5.  Add a TR parameter to disable use of ECS field even when present
> >>>
> >>> Design
> >>>
> >>> To support this feature new logic will be added to NameServer.query()
> >>> function. The new logic will be responsible for parsing ECS option in
> > the
> >>> OptionalRecord of the incoming DNS Request, and retrieving the Client
> > IP
> >>> address and the associated Source Net Mask (Scope Net Mask must be 0 in
> >> the
> >>> incoming Request per RFC 7871). Please note that the underlying DNS
> >> library
> >>> xbill/dnsjava already has support for parsing the ECS Options. These
> >>> functions from the library will be leveraged.
> >>>
> >>>  1.