Our Filter Chain technology provides you with many options for managing traffic by shipping users to different datacenter facilities, CDNs, or other endpoints. For example, customers using our GEOFENCE family of filters can easily send traffic in specific geographies to targeted CDNs, or customers using NETFENCE_PREFIX can get really precise by returning specific DNS answers to users within specified IP address networks.
Another useful NETFENCE filter solution is to target DNS answers for particular providers or networks. For example, you might have some data showing CDN A performs particularly well for Verizon and Comcast customers, and CDN B performs generally better for everyone else. The NETFENCE_ASN filter allows you to fence whole networks to specific answers based on the Autonomous System number (ASN) of the network from which we get a DNS query.
Example 1: Using NETFENCE_ASN to sort DNS answers by AS number
Sprint Network users will be fenced to Datacenter A (IP address 1.1.1.1). All other users will be sent to Datacenter B (IP address 2.2.2.2).
To set up this Filter Chain do the following:
1. Create an A record with two IP addresses, one for the load balancer at each Datacenter.
2. Add the NETFENCE_ASN filter to the Filter Chain (select the “remove answers without ASN list on any match” option)
3. Add the Sprint Network ASN (AS1239) to the metadata for the load balancer in Datacenter A.
4. Using What’s My DNS to do a lookup from a bunch of networks, we see the following:
The Sprint node is fenced as expected.
NETFENCE_ASN can make use of EDNS(0) CLIENT-SUBNET (ECS) from resolvers that send it. In general we’d recommend enabling EDNS(0) CLIENT-SUBNET for use with NETFENCE_ASN so you can properly fence users of Google Public DNS and OpenDNS.
Another good use case for NETFENCE_ASN is to restrict queries to a particular network. Maybe only users in your corporate ASN should get back an A record for a specific domain. Add DNS answers to your record with the corporate ASN in their metadata. If someone outside the corporate network queries the domain, we’ll refuse to answer.
Example 2: A more advanced use case for the NETFENCE_ASN filter
Users on Verizon in the Eastern US get better performance from CDN A, but everyone else in the Eastern US gets better performance from CDN B, and in the rest of the world we want to use CDN C. By combining the filters we’ll create a more complex routing setups.
Here’s a Filter Chain that will fence first based on geography (GEOFENCE_REGIONAL), and then do network fencing (NETFENCE_ASN):
We’ve added 3 A records, one each for CDN A (1.1.1.1), CDN B (2.2.2.2), and CDN C (3.3.3.3)
CDN A: set Geographic Region to US-EAST and add 701 (Verizon’s ASN) to the AS list
CDN B: set Geographic Region to US-EAST and leave other metadata blank
- CDN C: leave all metadata blank
Now, when the Filter Chain executes for users in the US-EAST region, it will apply the filter rules as follows:
Discard CDN C answer (per GEOFENCE_REGIONAL, US-EAST region users are handled by CDN A and CDN B)
If they are in Verizon’s network (ASN 701), it will discard CDN B answer and return CDN A (per NETFENCE ASN Verizon network users are handled by CDN A)
If they’re not in ASN 701 (Verizon), it will discard CDN A answer and return CDN B (per NETFENCE_ASN non-Verizon network US-EAST users are handled by CDN B).
You can imagine extending this approach to multiple regions and networks to very precisely control which users are sent to which CDN.