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