RE: Update on RFC7871 - Client Subnet in DNS Support
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 o...@qwilt.com>> 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<mailto: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 assum
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 o...@qwilt.com>> 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<mailto: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 > >>
Re: Update on RFC7871 - Client Subnet in DNS Support
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" > > Date: Monday, June 5, 2017 at 6:15 AM > To: "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 > mailto:o...@qwilt.com>> 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<mailto: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. Message.getOPT().getOptions(EDNSOption.Code.CLIENT_SUBNET) will &g
Re: Update on RFC7871 - Client Subnet in DNS Support
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" Date: Monday, June 5, 2017 at 6:15 AM To: "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 mailto:o...@qwilt.com>> 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<mailto: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. Message.getOPT().getOptions(EDNSOption.Code.CLIENT_SUBNET) will > > return list of ClientSubnetOption for the incoming Request (Message) > > 2. ClientSubnetOption has public methods to retrieve netmask and > Client > > IP address: getSourceNetmask(), getAddress() > > > > If ECS option is present, then the IP address retrieved from the ECS > > option, and will be passed as the Client IP address to the Traffic Router > > (through getZone call) for CZF/geo lookup > > > > If ECS option is present, then ClientSubnetOption will be created and > > included in the DNS response. In the Response the Scope Net Mask of the > > ClientSubnetOption is set as the Source Net Mask > > > > Testing > > We’ll test against all of the various CZF, National, Regional, VPN > > Blocking features and will do our best to check with DNSSEC > > > > —Eric > > > > > > > > > > > > > -- *Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | o...@qwilt.com<mailto:o...@qwilt.com>
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 > 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. Message.getOPT().getOptions(EDNSOption.Code.CLIENT_SUBNET) will > > > return list of ClientSubnetOption for the incoming Request (Message) > > > 2. ClientSubnetOption has public methods to retrieve netmask and > > Client > > > IP address: getSourceNetmask(), getAddress() > > > > > > If ECS option is present, then the IP address retrieved from the ECS > > > option, and will be passed as the Client IP address to the Traffic > Router > > > (through getZone call) for CZF/geo lookup > > > > > > If ECS option is present, then ClientSubnetOption will be created and > > > included in the DNS response. In the Response the Scope Net Mask of the > > > ClientSubnetOption is set as the Source Net Mask > > > > > > Testing > > > We’ll test against all of the various CZF, National, Regional, VPN > > > Blocking features and will do our best to check with DNSSEC > > > > > > —Eric > > > > > > > > > > > > > > > > > > > > > > > > -- > > *Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | > o...@qwilt.com >
Re: Update on RFC7871 - Client Subnet in DNS Support
+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 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. Message.getOPT().getOptions(EDNSOption.Code.CLIENT_SUBNET) will > > return list of ClientSubnetOption for the incoming Request (Message) > > 2. ClientSubnetOption has public methods to retrieve netmask and > Client > > IP address: getSourceNetmask(), getAddress() > > > > If ECS option is present, then the IP address retrieved from the ECS > > option, and will be passed as the Client IP address to the Traffic Router > > (through getZone call) for CZF/geo lookup > > > > If ECS option is present, then ClientSubnetOption will be created and > > included in the DNS response. In the Response the Scope Net Mask of the > > ClientSubnetOption is set as the Source Net Mask > > > > Testing > > We’ll test against all of the various CZF, National, Regional, VPN > > Blocking features and will do our best to check with DNSSEC > > > > —Eric > > > > > > > > > > > > > -- *Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | o...@qwilt.com
Re: Update on RFC7871 - Client Subnet in DNS Support
+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. Message.getOPT().getOptions(EDNSOption.Code.CLIENT_SUBNET) will > return list of ClientSubnetOption for the incoming Request (Message) > 2. ClientSubnetOption has public methods to retrieve netmask and Client > IP address: getSourceNetmask(), getAddress() > > If ECS option is present, then the IP address retrieved from the ECS > option, and will be passed as the Client IP address to the Traffic Router > (through getZone call) for CZF/geo lookup > > If ECS option is present, then ClientSubnetOption will be created and > included in the DNS response. In the Response the Scope Net Mask of the > ClientSubnetOption is set as the Source Net Mask > > Testing > We’ll test against all of the various CZF, National, Regional, VPN > Blocking features and will do our best to check with DNSSEC > > —Eric > > > > > >
Update on RFC7871 - Client Subnet in DNS Support
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. Message.getOPT().getOptions(EDNSOption.Code.CLIENT_SUBNET) will return list of ClientSubnetOption for the incoming Request (Message) 2. ClientSubnetOption has public methods to retrieve netmask and Client IP address: getSourceNetmask(), getAddress() If ECS option is present, then the IP address retrieved from the ECS option, and will be passed as the Client IP address to the Traffic Router (through getZone call) for CZF/geo lookup If ECS option is present, then ClientSubnetOption will be created and included in the DNS response. In the Response the Scope Net Mask of the ClientSubnetOption is set as the Source Net Mask Testing We’ll test against all of the various CZF, National, Regional, VPN Blocking features and will do our best to check with DNSSEC —Eric
