refine custom domain page

Author: 2color

docs/how-to/websites-on-ipfs/custom-domains.md

@@ -14,9 +14,9 @@ By default, when you deploy a static web application to IPFS, it will be address
 To make your website or app easier to access, you can link a custom domain for your website or web app using two approaches that can be used in combination:
 
 - [CID signaling with DNSLink](#cid-signaling-with-dnslink): allowing users to access your website from IPFS Gateways using the custom domain, e.g. `https://ipfs.io/ipns/docs.ipfs.tech` (note that it will redirect to a subdomain gateway `https://docs-ipfs-tech.ipns.dweb.link/` to ensure origin isolation). With this approach, you can access your website from a local IPFS Gateway or the Service Worker Gateway, benefiting from local verification and all the other benefits of IPFS like peer-to-peer retrieval and censorship resistance.
-- [Access via a custom domain](#access-via-a-custom-domain) - Access your website via a custom domain name, e.g. `https://docs.ipfs.tech`.
+- [Access via a custom domain](#access-via-a-custom-domain) - Access your website via a custom domain name, e.g. `https://docs.ipfs.tech`. This is the common way for static websites to be deployed. Note that this approach does not benefit from the benefits of IPFS like peer-to-peer retrieval and censorship resistance if done without configuring DNSLink.
 
-The main difference between the two options is that CID signaling with DNSLink is mainly concerned with resolving a memorable domain name to a CID, while access via a custom domain is mainly concerned with accessing your website via a custom domain name, and in many cases, you can use both approaches together.
+The main difference between the two options is that CID signaling with DNSLink is mainly concerned with resolving a memorable domain name to a CID, while access via a custom domain is mainly concerned with accessing your website via a custom domain name. For most use cases, you probably want to use both approaches together or at the very least, use DNSLink to signal the CID for your website.
 
 This guide will walk you through the nuances of each of these options, and how to configure them for your app.
 
@@ -34,12 +34,13 @@ Loading the site this way ties the website's cookies, storage, and Web API permi
 
 ## Access via a custom domain
 
-In the previous section, we discussed how DNSLink can be used to signal the CID for a domain name, while leaving it up to the user how to retrieve the content, be it a local node, service worker gateway or any other [public recursive gateway](https://docs.ipfs.tech/concepts/ipfs-gateway/#recursive-vs-non-recursive-gateways). In this instance, the user provides the domain name as input, instead of the CID.
+In the previous section, we discussed how DNSLink can be used to signal the CID for a domain name, while leaving it up to the user how to retrieve the content, be it a local node, service worker gateway or any other [public recursive gateway](https://docs.ipfs.tech/concepts/ipfs-gateway/#recursive-vs-non-recursive-gateways).
+
+With this approach, users can access your website via a custom domain name, e.g. `https://docs.ipfs.tech` but you can't easily verify the content, or load the site from a local node. Hence, it is recommended to use this as a complement to CID signaling with DNSLink.
 
 To provide access to the app directly via the custom domain, you have the following options:
 
 1. Self-host both the IPFS provider (e.g. [Kubo](https://github.com/ipfs/kubo)) and the HTTP gateway (e.g. [Kubo](https://github.com/ipfs/kubo) or [Rainbow](https://github.com/ipfs/rainbow/)). Deploy an IPFS Gateway that supports DNSLink resolution and point the `CNAME`/`A` DNS record for your custom domain to it and  update the `TXT` record on `_dnslink` subdomain to match CID of your website. Set up CI automation to update TXT record every time your CID changes. You will likely want to also configure TLS with a reverse proxy like Caddy or use a CDN like Cloudflare for TLS termination.
-2. Use a service like Fleek (HTTP + TLS + CDN + [automatic DNSLink management](https://fleek.xyz/docs/platform/domains/#dnslink)).
-3. Deploy the site to a web hosting service like [Cloudflare Pages](https://pages.cloudflare.com/) or [GitHub Pages](https://pages.github.com/), and point the `CNAME`/`A` record for your main domain and `TXT` record with CID on `_dnslink` subdomain, essentially getting the benefits of both IPFS and traditional web hosting. Remember to set up CI automation to update TXT record every time your CID changes.
+2. Use a service like Fleek which ecompasses both DNSLink and traditional web hosting (HTTP + TLS + CDN + [automatic DNSLink management](https://fleek.xyz/docs/platform/domains/#dnslink)).
+3. Deploy the site to a web hosting service like [Cloudflare Pages](https://pages.cloudflare.com/) or [GitHub Pages](https://pages.github.com/) with a custom domain (pointing and configuring the `CNAME`/`A` record for your custom domain on the web hosting service), while managing the DNSLink `TXT` record on `_dnslink` subdomain separately, essentially getting the benefits of both IPFS and traditional web hosting. Remember to set up CI automation to update the DNSLink `TXT` record for every deployment that changes the CID.
 
-Access via a custom domain is useful if you want to serve your app via a domain name that you own, for example, `app.example.com`.