+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 <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. 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
