[DNS] Advanced NS - network groups and wildcard records (#25094)

* Adjust network groups explanation to consider three groups

* Fix wildcard behavior described for advaced nameservers

* Disambiguate Cloudflare Registrar role in update-nameservers.mdx

* Apply suggestions from PM review

* Further clarify empty non-terminal and descendant logic

* Explicitly state wildcards are supported

Author: RebeccaTamachiro

src/content/docs/dns/foundation-dns/advanced-nameservers.mdx

@@ -19,25 +19,25 @@ Also, [some behaviors are different](/dns/foundation-dns/setup/#differences-from
 
 ## Anycast network groups
 
-To increase resiliency, advanced nameserver IPs are advertised by only one of two <GlossaryTooltip term="anycast">anycast</GlossaryTooltip> network groups.
+To increase resiliency, the advertisement of advanced nameserver IPs is organized into three <GlossaryTooltip term="anycast">anycast</GlossaryTooltip> network groups.
 
-The two groups consist of data centers that are geographically equally distributed.
+Two groups consist of IPs advertised from geographically distributed data centers, and a third group consists of IPs advertised from all data centers in the Cloudflare network.
 
 <Details header="United Kingdom example">
 
 | IPs             | Group | Data centers         |
 | --------------- | ----- | -------------------- |
 | `108.162.198.1` | A     | London and Edinburgh |
 | `172.64.40.1`   | B     | Manchester           |
-| `162.159.60.1`  | A     | London and Edinburgh |
+| `162.159.60.1`  | C     | Manchester, London, and Edinburgh |
 
 </Details>
 
 In DNS resolution, a resolver eventually acquires a list of all IPs where authoritative nameservers for a domain can be reached, and will then usually prefer the IP with the best resolution performance.
 
-When, instead of advertising all IPs in all data centers, this group logic is applied, resiliency is improved because, if one of the data centers experiences a localized issue, the resolver can fall back to an IP advertised by the next closest data center.
+When, instead of advertising all IPs in all data centers, this group logic is applied, resiliency is improved because, if one of the data centers experiences a localized issue, the resolver can fall back to an IP advertised by the next closest data center. The third group adds another layer of redundancy, further enhancing resiliency.
 
-Refer to [our blog post](https://blog.cloudflare.com/foundation-dns-launch) for an in-depth explanation.
+Refer to [our blog post](https://blog.cloudflare.com/foundation-dns-launch) for an in-depth explanation of the distributed groups logic.
 
 ## Dedicated release process
 

src/content/docs/dns/foundation-dns/setup.mdx

@@ -27,7 +27,25 @@ Before opting in for advanced nameservers, consider the following:
 
 Some behaviors are different from standard Cloudflare nameservers:
 
-- Wildcard records: if moving from standard Cloudflare nameservers to Foundation DNS advanced nameservers, make sure to explicitly create records for subdomains currently covered by wildcard records (`*.example.com`).
+- Wildcard records are still supported but, with advanced nameservers, a wildcard record (`*.example.com`) will not apply to a subdomain that is an empty non-terminal. An empty non-terminal is a node in the DNS tree that has no records associated with it but has descendants that do, as exemplified below.
+
+<Details header="Example">
+
+<Example>
+
+DNS management for **example.com**
+
+| **Type** | **Name** | **Content** |
+| -------- | -------- | ------------------------- |
+| A | * | `192.0.2.1` |
+| A | a.b | `192.0.2.5` |
+
+</Example>
+
+In this example, `a.b.example.com` is a descendant of `b.example.com`, and `b.example.com` is an empty non-terminal. This means that the wildcard `*.example.com` will not apply to `b.example.com`.
+
+</Details>
+
 - Subdomain delegation: once a subdomain is delegated via NS records, Cloudflare will not serve any other records (such as A, TXT, or CNAME) on that subdomain from the parent zone, even if those records exist.
 
 <Details header="Example">
@@ -84,4 +102,4 @@ To enable advanced nameservers on an existing zone:
      :::caution
 
      Make sure the values for your assigned nameservers are copied exactly.
-     :::
+     :::

src/content/docs/dns/nameservers/update-nameservers.mdx

@@ -11,9 +11,11 @@ To use Cloudflare DNS as an authoritative DNS provider - be it in a [primary (fu
 
 ## Specific processes
 
-Although Cloudflare will [provide you the nameservers](/dns/nameservers/#authoritative-nameservers-offering) or allow you to create your own [custom nameservers](/dns/nameservers/custom-nameservers/), the final step to make Cloudflare an authoritative DNS provider for your domain may have to be done outside of Cloudflare.
+Although Cloudflare will [provide you the nameservers](/dns/nameservers/#authoritative-nameservers-offering) or allow you to create your own [custom nameservers](/dns/nameservers/custom-nameservers/), the final step to make Cloudflare an authoritative DNS provider for your domain may have to be done outside of Cloudflare. If you are not using [Cloudflare Registrar](/registrar/), consider which of the following sections correspond to your use case.
 
-Unless you are using [Cloudflare Registrar](/registrar/), consider which of the following sections correspond to your use case.
+:::note[Custom or advanced nameservers]
+If you are using Cloudflare Registrar with [custom nameservers](/dns/nameservers/custom-nameservers/) or [advanced nameservers](/dns/foundation-dns/setup/), note that you must [reach out to support](/support/contacting-cloudflare-support/) to have the nameservers updated accordingly.
+:::
 
 ### Your domain uses a different registrar