[1.1.1.1] ELI5 on /Infrastructure/ (#30509)

* [1.1.1.1] ELI5 simplification for infrastructure pages

Add inline definitions, context, and cross-links to infrastructure
reference pages to improve accessibility for mixed audiences:

- sla-and-support: define SLA, clarify Gateway offering, explain
  multi-tenant
- ipv6-networks: define DNS64, NAT64, AAAA/A records, DNSSEC;
  add cross-links to encryption docs
- extended-dns-error-codes: explain what EDE codes solve, define
  DNSSEC, add dig usage guidance
- network-operators: define recursive DNS, cache hit rates,
  DHCP/PPP, last-mile, SERVFAIL, authoritative nameservers;
  describe resolver filtering levels; fix typo

* Apply suggestion from @Oxyjun

* Apply suggestion from @Oxyjun

* Update src/content/docs/1.1.1.1/infrastructure/ipv6-networks.mdx

Author: Oxyjun

src/content/docs/1.1.1.1/infrastructure/extended-dns-error-codes.mdx

@@ -9,9 +9,13 @@ sidebar:
 slug: 1.1.1.1/infrastructure/extended-dns-error-codes
 ---
 
-[Extended DNS Error Codes](https://www.rfc-editor.org/rfc/rfc8914.html) is a method to return additional information about the cause of DNS errors. As there are many reasons why a DNS query might fail, it became necessary to provide additional information on the exact cause of an error.
+[Extended DNS Error Codes](https://www.rfc-editor.org/rfc/rfc8914.html) (defined in RFC 8914) is a method to return additional information about the cause of DNS errors. When a DNS query fails, the standard response code (such as `SERVFAIL`) often does not explain _why_ it failed. Extended DNS Error Codes solve this by attaching a more specific error code and descriptive text to the response, so you can identify the exact cause without guesswork.
 
-1.1.1.1 supports Extended DNS Error Codes. Below is a list of error codes 1.1.1.1 returns, what they mean, and steps you may want to take to resolve the issue.
+1.1.1.1 supports Extended DNS Error Codes. Below is a list of error codes 1.1.1.1 returns, what they mean, and steps you may want to take to resolve the issue. Many of these errors relate to DNSSEC (DNS Security Extensions) — the set of protocols that add cryptographic signatures to DNS records to prevent tampering. Extended DNS Error Codes appear automatically in the `OPT PSEUDOSECTION` of a `dig` response when the server includes them, for example:
+
+```sh
+dig @1.1.1.1 example.com A
+```
 
 {/* prettier-ignore */}
 <table>

src/content/docs/1.1.1.1/infrastructure/ipv6-networks.mdx

@@ -11,21 +11,21 @@ sidebar:
 slug: 1.1.1.1/infrastructure/ipv6-networks
 ---
 
-While network infrastructure is shifting towards IPv6-only networks, providers still need to support IPv4 addresses. Dual-stack networks are networks in which all nodes have both IPv4 and IPv6 connectivity capabilities, and can therefore understand both IPv4 and IPv6 packets.
+While network infrastructure is shifting towards IPv6-only networks, providers still need to support IPv4 addresses. Dual-stack networks (networks in which all nodes have both IPv4 and IPv6 connectivity capabilities) can understand both IPv4 and IPv6 packets. However, not all networks are dual-stack, and IPv6-only networks need a translation mechanism to reach IPv4 resources.
 
-1.1.1.1 supports DNS64, a mechanism that synthesizes AAAA records from A records when no AAAA records exist. DNS64 allows configuring a DNS resolver to synthesize IPv6 addresses from IPv4 answers.
+1.1.1.1 supports DNS64, a mechanism that synthesizes AAAA records (DNS records that map domain names to IPv6 addresses) from A records (DNS records that map domain names to IPv4 addresses) when no AAAA records exist. This allows IPv6-only clients to receive a usable IPv6 address for destinations that only have an IPv4 address, so the client can still connect through the network's NAT64 gateway.
 
 :::note
 
-You should only enable DNS64 if you are managing or using an IPv6-only network. While the resolver can synthesize IPv6 addresses, it cannot synthesize their record signatures for domains using DNSSEC, so a DNS client that is able to revalidate signatures would reject these extra records without signatures.
+You should only turn on DNS64 if you are managing or using an IPv6-only network. While the resolver can synthesize IPv6 addresses, it cannot synthesize their record signatures for domains using DNSSEC (DNS Security Extensions, which add cryptographic signatures to DNS records to verify their authenticity). A DNS client that revalidates signatures would reject these synthesized records because they lack valid signatures.
 
-A good tradeoff is to use a secure protocol such as DNS over TLS, or DNS over HTTPS between the client and the resolver to prevent tampering.
+A good tradeoff is to use a secure protocol such as [DNS over TLS](/1.1.1.1/encryption/dns-over-tls/) or [DNS over HTTPS](/1.1.1.1/encryption/dns-over-https/) between the client and the resolver to prevent eavesdropping and tampering on the connection to the resolver.
 
 :::
 
 ## Configure DNS64
 
-DNS64 is specifically for networks that already have NAT64 support. If you are a network operator who has NAT64, you can test our DNS64 support by updating it to the following IP addresses:
+DNS64 is specifically for networks that already have NAT64 (Network Address Translation from IPv6 to IPv4) support. NAT64 translates IPv6 traffic to IPv4 at the network level, while DNS64 provides the corresponding translated addresses through DNS. If you are a network operator who has NAT64, you can test our DNS64 support by updating it to the following IP addresses:
 
 ```txt
 2606:4700:4700::64
@@ -41,6 +41,6 @@ Some devices use separate fields for all eight parts of IPv6 addresses and canno
 
 ## Test DNS64
 
-After your configuration, visit an IPv4 only address to check if you can reach it. For example, you can visit [https://ipv4.google.com](https://ipv4.google.com).
+After your configuration, visit an IPv4-only address to check if you can reach it over your IPv6-only network. For example, you can visit [https://ipv4.google.com](https://ipv4.google.com). If the page loads, DNS64 and NAT64 are working together to translate your connection.
 
 Visit [http://test-ipv6.com/](http://test-ipv6.com/) to test if it can detect your IPv6 address. If you receive a `10/10`, your IPv6 is configured correctly.

src/content/docs/1.1.1.1/infrastructure/network-operators.mdx

@@ -9,11 +9,11 @@ sidebar:
 slug: 1.1.1.1/infrastructure/network-operators
 ---
 
-Network operators, including Internet Service Providers (ISPs), device manufacturers, public Wi-Fi networks, municipal broadband providers, and security scanning services can use [1.1.1.1](/1.1.1.1/setup/) in place of operating their own recursive DNS infrastructure.
+Network operators, including Internet Service Providers (ISPs), device manufacturers, public Wi-Fi networks, municipal broadband providers, and security scanning services can use [1.1.1.1](/1.1.1.1/setup/) in place of operating their own recursive DNS infrastructure — DNS servers that resolve queries on behalf of clients by querying authoritative nameservers across the internet.
 
 Cloudflare also partners with ISPs and network equipment providers to make [1.1.1.1 for Families](/1.1.1.1/setup/#1111-for-families) available within their offerings. Refer to our [blog post](https://blog.cloudflare.com/safer-resolver/) for details.
 
-Using 1.1.1.1 can improve performance for end-users due to Cloudflare's extensive [global network](https://www.cloudflare.com/network/), as well as provide higher overall cache hit rates due to our regional caches.
+Using 1.1.1.1 can improve performance for end-users due to Cloudflare's extensive [global network](https://www.cloudflare.com/network/), as well as provide higher overall cache hit rates (the percentage of DNS queries answered from cache rather than requiring a new upstream lookup) due to our regional caches.
 
 The 1.1.1.1 resolver was designed with a privacy-first approach. Refer to our [data and privacy policies](/1.1.1.1/privacy/public-dns-resolver/) for what is logged and retained by 1.1.1.1.
 
@@ -22,10 +22,10 @@ The 1.1.1.1 resolver was designed with a privacy-first approach. Refer to our [d
 There are multiple ways to use 1.1.1.1 as an operator:
 
 - Including a [DNS over HTTPS](/1.1.1.1/encryption/dns-over-https/) or [DNS over TLS](/1.1.1.1/encryption/dns-over-tls/) proxy on end-user routers or devices (best for privacy).
-- Pushing 1.1.1.1 to devices via DHCP/PPP within an operator network (recommended; most practical).
-- Having a DNS proxy on a edge router make requests to 1.1.1.1 on behalf of all connected devices.
+- Pushing 1.1.1.1 to devices via DHCP/PPP (the protocols operators use to automatically assign network settings, including DNS servers, to devices) within an operator network (recommended; most practical).
+- Having a DNS proxy on an edge router make requests to 1.1.1.1 on behalf of all connected devices.
 
-Where possible, we recommend using encrypted transports (DNS over HTTPS or TLS) for queries, as this provides the highest degree of privacy for users over last-mile networks.
+Where possible, we recommend using encrypted transports (DNS over HTTPS or TLS) for queries, as this provides the highest degree of privacy for users over last-mile networks (the final segment of connectivity between the operator and the end user).
 
 ## Available Endpoints
 
@@ -37,7 +37,7 @@ If you require additional controls over our public 1.1.1.1 resolver, [contact us
 
 :::
 
-The publicly available endpoints for 1.1.1.1 are detailed in the following table:
+The publicly available endpoints for 1.1.1.1 are detailed in the following table. Each resolver variant serves a different filtering level: the unfiltered resolver performs standard DNS resolution with no content blocking, the Malware variant blocks queries to domains associated with malware and phishing, and the Adult Content + Malware variant blocks adult content in addition to malware and phishing.
 
 | Resolver                                 | IPv4 address               | IPv6 <br /> address                                  | DNS over <br /> HTTPS endpoint                  | DNS over <br /> TLS endpoint  |
 | ---------------------------------------- | -------------------------- | ---------------------------------------------------- | ----------------------------------------------- | ----------------------------- |
@@ -54,7 +54,7 @@ Operators using 1.1.1.1 for typical Internet-facing applications and/or users sh
 Best practices include:
 
 - Avoiding tunneling or proxying all queries from a single IP address at high rates. Distributing queries across multiple public IPs will improve this without impacting cache hit rates (caches are regional).
-- A high rate of "uncacheable" responses (such as `SERVFAIL`) against the same domain may be rate limited to protect upstream, authoritative nameservers. Many authoritative nameservers enforce their own rate limits, and we strive to avoid overloading third party infrastructure where possible.
+- A high rate of "uncacheable" responses (such as `SERVFAIL`, a DNS response code indicating the server failed to complete the query) against the same domain may be rate limited to protect upstream, authoritative nameservers (the DNS servers that hold the official records for a domain). Many authoritative nameservers enforce their own rate limits, and we strive to avoid overloading third party infrastructure where possible.
 
 ## Help
 

src/content/docs/1.1.1.1/infrastructure/sla-and-support.mdx

@@ -14,6 +14,6 @@ As you use 1.1.1.1 in your infrastructure or service, note that dedicated techni
 
 You are subject to the [Cloudflare Website and Online Services Terms of Use](https://www.cloudflare.com/website-terms/) and no service level agreements (SLAs) are provided.
 
-If you need SLAs and dedicated support, consider using [Cloudflare Gateway](/cloudflare-one/traffic-policies/) instead.
+If you need SLAs and dedicated support, consider using [Cloudflare Gateway](/cloudflare-one/traffic-policies/) instead. Gateway adds policy-based DNS filtering and management.
 
-Gateway includes other advanced options such as domain categories, customized filtering, and scheduling capabilities. For example, if you are a device manufacturer or network operator, you can use a multi-tenant environment to allow your customers to configure their own individual filters.
+Gateway includes other advanced options such as domain categories, customized filtering, and scheduling capabilities. For example, if you are a device manufacturer or network operator, you can use a multi-tenant environment — where a single deployment serves multiple separate customers — to allow your customers to configure their own individual filters.