IP boundaries limit select DNS responses to clients within certain IP blocks. Clients outside those boundaries may be given a fallback response or no response at all.
IP boundary determinations should be considered imprecise as they’re sometimes missing and an interim resolver’s IP is substituted. As such, they are always best effort. Nonetheless, boundaries can be quite useful for guiding a majority of users to the preferred destination.
Start by configuring one or more boundary routing definitions at Routing -> Boundaries -> Add IP Addresses.
Name: a name for this boundary
IPs: one or more IP addresses or CIDR blocks (space separated)
; Configured boundary: Name: AWS us-west IPs : 198.51.100.0/24 2001:db8:0:f::/64
Next, assign your boundaries to host records.
; Configured host: www.your-domain.com A 192.0.2.1 Boundary=AWS us-west www.your-domain.com A 198.51.100.1 Boundary=(not set)
With the above configuration, clients in AWS us-west will be routed to 192.0.2.1. Everyone else will be routed to 198.51.100.1, which is the fallback record.
Under most circumstances, a fallback record is required. If your configuration doesn’t benefit from a fallback record, you can use a dummy record of 0.0.0.0 (A) or ::0 (AAAA).
www.your-domain.com A 192.0.2.1 Boundary=AWS us-west www.your-domain.com A 0.0.0.0 Boundary=(not set)
Only rarely can fallback records be skipped without negative consequences. Usually both the IP boundary IPs /and/ the A or AAAA records will be non-routable or private IPs (eg: 10.x.y.z). See notes at the bottom and reach out to us with questions or to double-check your situation.
Overlapping IP blocks within a single IP boundary will be merged. For example, 192.0.2.0/24 and 192.0.2.0/25 will be treated as just 192.0.2.0/24.
Overlapping IP blocks on separate IP boundaries must not be assigned to the same hostname. Doing so may result in inconsistent results due to how DNS caches queries.
Some DNS resolvers do not scope their cache for “no response” answers. Using boundaries without a fallback deliberately returns “no response”, which can then trigger odd results. If the host records are intended to be queried using broadly available DNS resolvers, it is strongly recommended to add a dummy fallback record (eg:
www.your-domain.com A 0.0.0.0 Boundary=(not set)). On the other hand, if the boundary is used to constrain access to a known and limited set of resolvers (eg: a corporate office), then no dummy fallback record is required.
Boundaries may be assigned to A, AAAA, and ALIAS host record types.
IP and geo boundary routing are processed together. A client that matches both an IP boundary and a geo boundary will see both records. A fallback record is only used if neither an IP boundary nor a geo boundary match.
IP and geo boundaries are processed before Geo-closest.