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

@@ -18,16 +18,16 @@ Let's connect to Grafana using Teleport Application Access in three steps:
 - A Docker installation, which we will use to launch Grafana in a container. Alternatively, if you have another web application you'd like to protect with Application Access, you can use that instead.
 - A host where you will run the Teleport Application Service.
 
-We will assume your Teleport cluster is accessible at `teleport.example.com` and `*.teleport.example.com`. You can substitute the address of your Teleport Proxy Service. (For Teleport Cloud customers, this will be similar to `mytenant.teleport.sh`.)
-
-<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>
-
 <Admonition type="tip" title="Not yet a Teleport user?">
 If you have not yet deployed the Auth Service and Proxy Service, you should follow one of our [getting started guides](../getting-started.mdx).
 </Admonition>
 
+We will assume your Teleport cluster is accessible at `teleport.example.com` and `*.teleport.example.com`. You can substitute the address of your Teleport Proxy Service. (For Teleport Cloud customers, this will be similar to `mytenant.teleport.sh`.)
+
+<Admonition type="note" title="Application Access and DNS">
+(!docs/pages/includes/dns-app-access.mdx!)
+</Admonition>
+
 ## Step 1/3. Start Grafana
 
 We've picked Grafana for this tutorial since it's very easy to run with zero

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

@@ -90,10 +90,8 @@ using Let's Encrypt.
 
 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>
 
 ### Start Teleport

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/includes/dns.mdx

@@ -1,10 +1,8 @@
 Set up two `A` DNS records: `tele.example.com` for all traffic and `*.tele.example.com`
 for web apps using Application Access.
 
-<Details opened={false} title="Why wildcard subdomains for 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 opened={false} title="Why are we using wildcard subdomains for Application Access?">
+(!docs/pages/includes/dns-app-access.mdx!)
 </Details>
 
 <Details title="DNS instructions for cloud providers" opened={false}>

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

@@ -316,10 +316,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

@@ -360,10 +360,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>