Cause: The DNS Operator configures the cluster DNS service to use topology-aware hints when it determines that the conditions for enabling topology-aware hints are met. Using topology-aware hints for the cluster DNS service improves the reliability and latency of DNS lookups, in that it causes DNS queries to be routed to a DNS pod in the same availability zone as the client pod when possible. However, the Operator did not properly check one of those conditions. Specifically, the Operator did not verify that the cluster had nodes in at least two availability zones. Also, the DNS daemon set did not use surge for rolling updates, and so a rolling update of DNS pods would delete the old DNS pod on each node before creating the new DNS pod on that node. Consequence: Clusters in which all nodes were in the same availability zone would repeatedly emit "TopologyAwareHintsDisabled" events for the cluster DNS service. In addition, during upgrades, there was an increased risk of disruption or latency for DNS lookups from client pods on a node between the time when the old DNS pod on that node was deleted and when the new DNS pod on that node became ready. Fix: The Operator now checks that the cluster has nodes in at least two availability zones before enabling topology-aware hints for the cluster DNS service. In addition, the Operator enables surge for the DNS daemon set, so that a rolling update of DNS pods creates new pods before deleting old pods. Result: The "TopologyAwareHintsDisabled" events are no longer emitted on clusters that do not have nodes in multiple availability zones. In addition, the cluster DNS service is more reliable during upgrades on clusters that have topology-aware hints or the equivalent functionality to prefer local DNS pods.