Update content/en/docs/concepts/workloads/controllers/statefulset.md

Co-authored-by: Tim Bannister <[email protected]>

Author: jayunit100

content/en/docs/concepts/workloads/controllers/statefulset.md

@@ -141,11 +141,16 @@ As each Pod is created, it gets a matching DNS subdomain, taking the form:
 `$(podname).$(governing service domain)`, where the governing service is defined
 by the `serviceName` field on the StatefulSet.
 
-Note initial availability of stable DNS name's responsiveness:  The initial reachability of a Pod via its DNS
-depends on the settings of your DNS provider.  It may be 30 seconds before the DNS name for your Pod
-is reachable from another Pod in your cluster.   For StatefulSets which need to come online via a quorum
-in a very short (< 30s) time period, consider tuning your DNS settings
-or another mechanism (such as querying the Kubernetes endpoints directly for IP addresses).
+{{< note >}}
+Depending on how DNS is configured in your cluster, you may not be able to look up the DNS
+name for a newly-run Pod immediately. This behavior can occur when other clients in the
+cluster have already sent queries for the hostname of the Pod before it was created.
+Negative caching (normal in DNS) means that the results of previous failed lookups are
+remembered and reused, even after the Pod is running, for at least a few seconds.
+
+If you need to discover Pods promptly after they are created, consider querying the
+Kubernetes API directly (for example, using a watch) rather than relying on DNS lookups.
+{{< /note >}}
 
 As mentioned in the [limitations](#limitations) section, you are responsible for
 creating the [Headless Service](/docs/concepts/services-networking/service/#headless-services)
@@ -285,4 +290,3 @@ StatefulSet will then begin to recreate the Pods using the reverted template.
 * Follow an example of [running a replicated stateful application](/docs/tasks/run-application/run-replicated-stateful-application/).
 
 
-