Respond to PR feedback

- Move information into a partial
- Mention that you can create a DNS A record for each application-
  specific subdomain

docs/pages/application-access/getting-started.mdx

@@ -17,8 +17,8 @@ Let's connect to Grafana using Teleport Application Access in three steps:
 - We will use Docker to launch Grafana in a container. Alternatively, if you have another web application you'd like to protect with App Access, you can use that instead.
 - We will assume your Teleport cluster is accessible at `teleport.example.com` and `*.teleport.example.com`. Configured DNS records are required to automatically fetch a [Let's Encrypt](https://letsencrypt.org) certificate. 
 
-<Admonition type="note" title="Teleport and Wildcard Certificates">
-Teleport assigns a subdomain to each application you have configured for Application Access (e.g., `grafana.teleport.example.com`), so you need to create a DNS A record with a wildcard subdomain (e.g., `*.teleport.example.com`). This way, Let's Encrypt can issue a wildcard certificate, enabling clients to verify your Teleport hosts regardless of the application they are accessing.
+<Admonition type="note" title="Application Access and DNS">
+(!docs/pages/includes/dns-app-access.mdx!)
 </Admonition>
 
 ## Step 1/3. Start Grafana
@@ -45,10 +45,6 @@ using Let's Encrypt [ACME](https://letsencrypt.org/how-it-works/) protocol.
 We will assume that you have configured DNS records for `teleport.example.com`
 and `*.teleport.example.com` to point to the Teleport node.
 
-<Admonition type="note" title="Why do I need a wildcard certificate?">
-Teleport assigns a subdomain to each application you have configured for Application Access (e.g., `grafana.teleport.example.com`), so the wildcard certificate enables clients to verify your Teleport hosts regardless of application.
-</Admonition>
-
 (!docs/pages/includes/permission-warning.mdx!)
 
 Let's generate a Teleport config with ACME enabled:

docs/pages/application-access/guides/connecting-apps.mdx

@@ -54,8 +54,8 @@ applications. When setting up Teleport, the minimum requirement is a certificate
 for the proxy and a wildcard certificate for its sub-domain. This is where
 everyone will log into Teleport.
 
-<Admonition type="note" title="Why do I need a wildcard certificate?">
-Teleport assigns a subdomain to each application you have configured for Application Access (e.g., `grafana.teleport.example.com`), so the wildcard certificate enables clients to verify your Teleport hosts regardless of application.
+<Admonition type="tip" title="Application Access and DNS">
+(!docs/pages/includes/dns-app-access.mdx!)
 </Admonition>
 
 In our example:

docs/pages/database-access/getting-started.mdx

@@ -85,10 +85,8 @@ using Let's Encrypt [ACME](https://letsencrypt.org/how-it-works/) protocol.
 
 We will assume that you have configured a DNS record for `teleport.example.com` to point to the node where you're launching Teleport.
 
-<Details opened={false} title="Using Application Access?">
-Teleport assigns a subdomain to each application you have configured for Application Access (e.g., `grafana.teleport.example.com`), so you need to create a DNS A record with a wildcard subdomain (e.g., `*.teleport.example.com`). This way, Let's Encrypt can issue a wildcard certificate, enabling clients to verify your Teleport hosts regardless of the application they are accessing.
-
-[Learn more about Teleport Application Access](../application-access/getting-started.mdx)
+<Details title="Using Application Access?">
+(!docs/pages/includes/dns-app-access.mdx!)
 </Details>
 
 Let's generate a Teleport config with ACME enabled:

docs/pages/getting-started/linux-server.mdx

@@ -32,10 +32,8 @@ Take a look at the [Installation Guide](../installation.mdx) for more options.
 
 Teleport uses TLS to provide secure access to its Proxy Service and Auth Service, and this requires a domain name that clients can use to verify Teleport's certificate. To get started, set up a DNS `A` record for `tele.example.com` pointing to the IP/FQDN of the machine with Teleport installed.
 
-<Details opened={false} title="Using Application Access?">
-Teleport assigns a subdomain to each application you have configured for Application Access (e.g., `grafana.teleport.example.com`), so you will also need to create a DNS A record with a wildcard subdomain (e.g., `*.tele.example.com`). This way, Let's Encrypt can issue a wildcard certificate, enabling clients to verify your Teleport hosts regardless of the application they are accessing.
-
-[Learn more about Teleport Application Access](../application-access/getting-started.mdx)
+<Details title="Using Application Access?">
+(!docs/pages/includes/dns-app-access.mdx!)
 </Details>
 
 <Admonition

docs/pages/includes/database-access/start-auth-proxy.mdx

@@ -18,15 +18,7 @@ Download the latest version of Teleport for your platform from our
 installation [instructions](../../installation.mdx).
 
 <Details opened={false} title="Using Application Access?">
-Teleport assigns a
-subdomain to each application you have configured for Application Access (e.g.,
-`grafana.teleport.example.com`), so you will also need to create a DNS A record
-with a wildcard subdomain (e.g., `*.tele.example.com`).
-
-This way, Let's Encrypt can issue a wildcard certificate, enabling clients to
-verify your Teleport hosts regardless of the application they are accessing.
-
-[Learn more about Teleport Application Access](../../application-access/getting-started.mdx)
+(!docs/pages/includes/dns-app-access.mdx!)
 </Details>
 
 Generate a Teleport configuration file with ACME enabled:

docs/pages/includes/dns-app-access.mdx

@@ -0,0 +1,4 @@
+Teleport assigns a subdomain to each application you have configured for Application
+Access (e.g., `grafana.teleport.example.com`), so you will need to ensure that a DNS A record exists for each application-specific subdomain so clients can access your applications via Teleport. 
+
+You should create either a separate DNS A record for each subdomain or a single record with a wildcard subdomain such as `*.teleport.example.com`. This way, your certificate authority (e.g., Let's Encrypt) can issue a certificate for each subdomain, enabling clients to verify your Teleport hosts regardless of the application they are accessing.

docs/pages/kubernetes-access/getting-started/cluster.mdx

@@ -133,10 +133,8 @@ to create a public IP for Teleport.
 
 You will also need to create a DNS A record for `tele.example.com` so clients can verify the TLS certificate of your Teleport hosts.
 
-<Details opened={false} title="Using Application Access?">
-Teleport assigns a subdomain to each application you have configured for Application Access (e.g., `grafana.teleport.example.com`), so you will also need to create a DNS A record with a wildcard subdomain (e.g., `*.tele.example.com`). This way, Let's Encrypt can issue a wildcard certificate, enabling clients to verify your Teleport hosts regardless of the application they are accessing.
-
-[Learn more about Teleport Application Access](../../application-access/getting-started.mdx)
+<Details title="Using Application Access?">
+(!docs/pages/includes/dns-app-access.mdx!)
 </Details>
 
 <Tabs>

docs/pages/kubernetes-access/helm/guides/aws.mdx

@@ -304,10 +304,8 @@ $ kubectl --namespace teleport get all
 
 You'll need to set up a DNS `A` record for `teleport.example.com`. In our example, this record is an alias to an ELB.
 
-<Details opened={false} title="Using Application Access?">
-Teleport assigns a subdomain to each application you have configured for Application Access (e.g., `grafana.teleport.example.com`), so you will also need to create a DNS A record with a wildcard subdomain (e.g., `*.tele.example.com`). This way, Let's Encrypt can issue a wildcard certificate, enabling clients to verify your Teleport hosts regardless of the application they are accessing.
-
-[Learn more about Teleport Application Access](../../../application-access/getting-started.mdx)
+<Details title="Using Application Access?">
+(!docs/pages/includes/dns-app-access.mdx!)
 </Details>
 
 Here's how to do this in a hosted zone with AWS Route 53:

docs/pages/kubernetes-access/helm/guides/gcp.mdx

@@ -348,10 +348,8 @@ $ kubectl --namespace teleport get all
 
 You'll need to set up a DNS `A` record for `teleport.example.com`.
 
-<Details opened={false} title="Using Application Access?">
-Teleport assigns a subdomain to each application you have configured for Application Access (e.g., `grafana.teleport.example.com`), so you will also need to create a DNS A record with a wildcard subdomain (e.g., `*.tele.example.com`). This way, Let's Encrypt can issue a wildcard certificate, enabling clients to verify your Teleport hosts regardless of the application they are accessing.
-
-[Learn more about Teleport Application Access](../../../application-access/getting-started.mdx)
+<Details title="Using Application Access?">
+(!docs/pages/includes/dns-app-access.mdx!)
 </Details>
 
 Here's how to do this using Google Cloud DNS:

docs/pages/kubernetes-access/helm/reference.mdx

@@ -46,7 +46,9 @@ This reference details available values for the `teleport-cluster` chart.
 
   You will need to manually add a DNS A record pointing `teleport.example.com` to either the IP or hostname of the Kubernetes load balancer.
 
-  If you are using Teleport Application Access, you will also need to add a DNS A record for `*.teleport.example.com`. This is because Teleport assigns a subdomain to each application you have configured for Application Access (e.g., `grafana.teleport.example.com`), so the wildcard enables clients to verify your Teleport hosts regardless of application.
+<Details title="Using Application Access?">
+(!docs/pages/includes/dns-app-access.mdx!)
+</Details>
 
   If you are not using ACME certificates, you may also need to accept insecure warnings in your browser to view the page successfully.
 </Admonition>