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 (not the actual IP blocks)
Next, assign your boundaries to host records.
; Configured host: www.your-domain.com A 192.0.2.1 Boundary=AWS us-west
With the above configuration, clients in AWS us-west will be routed to 192.0.2.1. Everyone else will receive “domain not found” because there is no fallback.
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)
Here, clients in AWS us-west will continue to be routed to 192.0.2.1 but now everyone else will be routed to 198.51.100.1. That’s because there is both a boundary and non-boundary record for the same name/type (
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.
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.