Working with custom resolvers
A private DNS custom resolver extends IBM Cloud® DNS Services's capability to meet the needs of a hybrid cloud environment by enabling resolution of the IBM Cloud VPC hostnames from on-premises DNS resolvers and enables the resolution of on-premises hostnames from the IBM Cloud.
Key features of the custom resolver:
- Extends DNS resolutions to resolvers residing on-premises
- Allows for resolution fallback to a secondary resolver location (if one is configured) when the primary resolver location is not available
Custom resolver overview
To get started using a custom resolver, you must create a custom resolver and then add forwarding rules to it.
It is expected that the custom resolver is configured for High Availability by default. Follow the steps in Creating a custom resolver without high availability if you do not want a highly available configuration.
After you create the custom resolver and configure its forwarding rules, the resolver can be enabled for the VPC. This results in the DHCP option for the resolver changing to the custom resolver IP addresses.
Reserved IP for custom resolvers
Virtual appliances are created for custom resolvers to serve DNS queries, or for global load balancer health checks to send probes to your origin servers that monitor their health status. The virtual appliance is fully managed by DNS Services, however, you can go to the Subnets for VPC dashboard and view the details of a subnet to see the reserved IPs of that subnet. You can see which IP address is bound to the network interface on the virtual appliance managed by DNS Services.
From the Targeted resource column, you can view which reserved IP is bound to a DNS service instance that has a virtual appliance connected to your subnet. It is recommended that you keep Auto-release enabled (the default setting). With Auto-release, this IP address automatically releases to the IP address pool after the virtual appliance is deleted, as part of the deletion process for custom resolvers and global load balancer pools.
Disabling Auto-release can disrupt DNS Services recovery operations.
Custom resolver addresses propagation to compute instances
The reserved IP addresses for each custom resolver location are collectively referred to as the custom resolver addresses. When you have multiple locations enabled in a custom resolver, the propagation of these custom resolver addresses to compute instances on the VPC takes account of any proximity and load balancing optimization rules.
The proximity rule is considered the preferred rule to determine primary DNS server for compute instances, and then load balancing optimization is considered when an availability zone doesn't have a location. The following example describes the rules for determining primary DNS server assignment to compute instances in each availability zone.
Example 1: Three locations in different availability zones
In this example, each availability has exactly one custom resolver location.
Custom resolver: R:
- location-1 in us-south-1 has address:
A1 - location-2 in us-south-2 has address:
A2 - location-3 in us-south-3 has address:
A3
Proximity is the sole policy to determine the primary DNS servers for compute instances in each availability zone:
- us-south-1:
A1(primary),A2,A3. - us-south-2:
A2(primary),A1,A3. - us-south-3:
A3(primary),A1,A2.
Example 2: Two of three locations in the same availability zone
In this example, two of three locations are in the same availability zone us-south-1, but there are no locations in us-south-3.
Custom resolver: R:
- location-1 in us-south-1 has address:
A1 - location-2 in us-south-1 has address:
A2 - location-3 in us-south-3 has address:
A3
The proximity rule is applied first to determine primary DNS servers for us-south-1 and us-south-3 because these two availability zones have locations. Next, the load balancing optimization rule is used to select
the location-2 as the primary server for us-south-2. Consequently, the resultant DNS servers for compute instances in each availability zone will be:
- us-south-1:
A1(primary),A2,A3. - us-south-3:
A3(primary),A1,A2. - us-south-2:
A2(primary),A1,A3.
Example 3: All 3 locations are in the same availability zone
In this example, all locations are in the same availability zone us-south-1, but there are no locations in us-south-2 and us-south-3.
Custom resolver: R:
- location-1 in us-south-1 has address:
A1 - location-2 in us-south-1 has address:
A2 - location-3 in us-south-1 has address:
A3
The proximity rule selects location-1 as the primary DNS server for us-south-1. Then, the load balancing optimization rule assigns a primary DNS server for us-south-2 and us-south-3 to location-2 and
location-3, respectively. The resultant DNS servers for compute instances in each availability zone are:
- us-south-1:
A1(primary),A2,A3. - us-south-2:
A2(primary),A1,A3. - us-south-3:
A3(primary),A1,A2.
Example 4: Number of custom resolver locations is less than 3
In this example, the custom resolver has fewer than 3 locations.
Custom resolver: R:
- location-1 in us-south-1 has address:
A1 - location-2 in us-south-2 has address:
A2
In this case, at least one location is used as the primary DNS server for two availability zones. After following the aforementioned rules, the resultant DNS servers for compute instances in each availability zone will be:
- us-south-1:
A1(primary),A2. - us-south-2:
A2(primary),A1. - us-south-3:
A1(primary),A2.
Custom resolver status
The status of a newly-created custom resolver is initially Critical because the resolver location is not fully provisioned. The status changes to Healthy after the resolver location changes to Up.
The following status definitions apply to the resolver locations:
- Up - when the resolver location is functioning.
- Down - when the resolver location is not functioning.
The following status definitions apply to the custom resolver:
- Healthy - when all resolver locations are
Up, the status isHealthy. - Degraded - when there is more than one resolver location, and one is
Upbut another isDown, then the status changes toDegraded. - Critical - when all resolver locations are
Down, the status changes toCritical.
Custom resolver limits
The following limits exist for the custom resolvers feature.
- Each VPC can have a maximum of one custom resolver.
- Each custom resolver can have a maximum of 3 locations, either within the same subnet or in different subnets.
- You cannot delete the subnet that is used for the custom resolver.
- You must manually add rules to your security groups to allow traffic from your virtual server instance to the resolver location's virtual server instance.