Dane/support knowledge gaps - check with SRhea before approving (#29782)

* Add cache troubleshooting for login flows

* Expand DNS troubleshooting guidance

* Expand registrar transfer troubleshooting

* Document Origin CA expiry alert limitation

* Add Cloudflare One troubleshooting details

* Add WAF rule interaction guidance

* Document AWS route issue for 523

* Add HTTP/3 troubleshooting guidance

* Fix link URL

* WAF updates

* Removed incorrect difference

* Update phase-interactions.mdx (#29831)

* [DNS] Expand negative caching troubleshooting section (#29833)

* [DNS] Expand negative caching troubleshooting for newly created records

* [DNS] Add dig example to check negative cache TTL

---------

Co-authored-by: Dane Knecht <dane@cloudflare.com>
Co-authored-by: Pedro Sousa <680496+pedrosousa@users.noreply.github.com>
Co-authored-by: danielegm <74369360+danielegm@users.noreply.github.com>
Co-authored-by: Hannes <105781579+hannes-cf@users.noreply.github.com>

Author: 5 people

src/content/docs/cache/troubleshooting/dynamic-content-and-login-issues.mdx

@@ -0,0 +1,87 @@
+---
+title: Dynamic content and login issues
+pcx_content_type: troubleshooting
+description: Troubleshoot login failures, missing session cookies, and challenge loops caused by caching dynamic content.
+sidebar:
+  order: 2
+---
+
+Dynamic pages such as login forms, checkout flows, and authenticated application routes can break when they are cached too aggressively.
+
+Common symptoms include:
+
+- Users can load the login page, but the sign-in form fails after submission.
+- Sessions do not persist after a successful sign-in.
+- The origin sends a `Set-Cookie` header, but the browser never stores the cookie.
+- A challenge page appears, but after solving it the user returns to the login page or loses form state.
+
+## Cached login page strips session cookies
+
+One common cause is a [Cache Rule](/cache/how-to/cache-rules/) or legacy Page Rule configured to cache dynamic HTML.
+
+This usually happens when all of the following are true:
+
+- The page is configured as **Eligible for cache** or **Cache Everything**.
+- The response is dynamic HTML such as `/login` or `/account`.
+- The origin sends a `Set-Cookie` header.
+- An [Edge TTL](/cache/how-to/cache-rules/settings/#edge-ttl) or status-code TTL overrides origin cache directives.
+
+In this configuration, Cloudflare can cache the response and remove the `Set-Cookie` header before the response is stored at the edge. As a result, the browser receives the login page but never gets the session cookie required for the next request.
+
+### How to confirm
+
+Check the response for the login page or other dynamic route.
+
+If you see both of the following, the page is probably cached when it should not be:
+
+- `CF-Cache-Status: HIT` or `CF-Cache-Status: EXPIRED`
+- No `Set-Cookie` header in the response, even though your origin usually sets one
+
+You may also see framework-specific failures after form submission, for example:
+
+- A redirect back to the login page
+- A `403` or `500` after sign-in
+- CSRF validation errors
+- Missing server-side session state
+
+This issue is common with frameworks that rely on a session or CSRF cookie on the first page load, including JavaServer Faces, ASP.NET, PHP session handlers, Django, Rails, and Laravel.
+
+### Resolution
+
+Do not cache login pages or other authenticated HTML.
+
+Instead:
+
+1. Restrict **Eligible for cache** or **Cache Everything** to static paths only.
+2. Add a more specific Cache Rule that bypasses or disables caching for routes such as `/login`, `/account`, `/cart`, `/checkout`, and application API paths.
+3. If the origin must control caching, remove any Edge TTL override that forces the page to be cached.
+4. Verify the fixed response now returns `CF-Cache-Status: DYNAMIC`, `MISS`, or `BYPASS`, and preserves `Set-Cookie`.
+
+For more information on cookie behavior, refer to [Interaction of Set-Cookie response header with Cache](/cache/concepts/cache-behavior/#interaction-of-set-cookie-response-header-with-cache).
+
+## Challenge loops on login or form flows
+
+Security challenges can also interrupt dynamic flows.
+
+Two common patterns are:
+
+- A challenge is triggered on the initial `GET` request for the login page. The user solves the challenge, but the application loses the original session or CSRF context.
+- A challenge is triggered on the `POST` request that submits the login form or other sensitive action. The browser may have to repeat the request after the challenge, which can break the original form submission.
+
+### How to confirm
+
+Check whether a [WAF custom rule](/waf/custom-rules/), [managed rule](/waf/managed-rules/), or [rate limiting rule](/waf/rate-limiting-rules/) applies to the login path.
+
+If the issue only affects routes such as `/login`, `/signin`, `/checkout`, or `/api/auth/*`, and the application works when the challenge is disabled for those paths, the challenge is likely interrupting the flow.
+
+### Resolution
+
+Use one of the following approaches:
+
+1. Exclude the login or form submission path from the challenge rule.
+2. Narrow the rule expression so it applies to suspicious traffic only.
+3. If you must protect the route, use a less disruptive control on the page load and apply stronger actions elsewhere in the flow.
+
+When debugging, also verify that rules are not matching Cloudflare-generated paths such as `/cdn-cgi/*`.
+
+For more information on challenge-related behavior, refer to [Rules troubleshooting](/rules/reference/troubleshooting/) and [Cloudflare WAF troubleshooting](/waf/troubleshooting/).

src/content/docs/cloudflare-one/integrations/identity-providers/one-time-pin.mdx

@@ -85,3 +85,14 @@ By design, blocked users will not receive an email. The login page will always s
 
 Access only logs an authentication attempt after the user enters a code. If the user enters their email but never submits a code, the event will not appear in your [audit logs](/cloudflare-one/insights/logs/dashboard-logs/access-authentication-logs/#authentication-logs).
 :::
+
+## OTP behavior and limits
+
+Keep the following behavior in mind when troubleshooting OTP logins:
+
+- Each PIN is single-use.
+- Requesting a new PIN invalidates the previous PIN.
+- Cloudflare only sends the email if the user is allowed by an Access policy.
+- Third-party mail security tools may consume the link before the user does, which makes the code appear already used.
+
+If users repeatedly fail to sign in, request a fresh code and verify that your mail filtering or link-scanning product is allowlisting `noreply@notify.cloudflare.com`.

src/content/docs/cloudflare-one/networks/connectors/cloudflare-tunnel/troubleshoot-tunnels/common-errors.mdx

@@ -45,6 +45,16 @@ The tunnel status only reflects the connection between `cloudflared` and the Clo
 
 Long-lived connections initiated through Cloudflare One, such as SSH sessions, can last up to eight hours. However, disruptions along the service path may result in more frequent disconnects. Often, these disconnects are caused by regularly scheduled maintenance events such as data center, server, or service updates and restarts. If you believe these events are not the cause of disconnects in your environment, collect the relevant [client logs](/cloudflare-one/team-and-resources/devices/cloudflare-one-client/troubleshooting/diagnostic-logs/) and [Tunnel logs](/cloudflare-one/networks/connectors/cloudflare-tunnel/monitor-tunnels/logs/) and contact Support.
 
+If the disconnects mainly affect idle SSH sessions, WebSocket connections, or other long-lived connections, the transport protocol may be relevant.
+
+When `cloudflared` uses QUIC, idle sessions can be more sensitive to network devices that aggressively time out UDP traffic. If idle connections drop repeatedly, try one or more of the following:
+
+- Configure application-layer keepalives, such as `ServerAliveInterval` for SSH.
+- Test with `cloudflared` set to `protocol: http2`.
+- Review local firewalls, NAT devices, and upstream network equipment for short UDP idle timers.
+
+For connection setup failures caused by blocked QUIC traffic, refer to the QUIC troubleshooting sections above.
+
 ## `ping` and `traceroute` commands do not work.
 
 To ping an IP address behind Cloudflare Tunnel, your system must allow ICMP traffic through `cloudflared`. For configuration instructions, refer to the [ICMP proxy documentation](/cloudflare-one/traffic-policies/proxy/#icmp).
@@ -61,4 +71,3 @@ If you added a [multi-level subdomain](/cloudflare-one/networks/connectors/cloud
 
 
 For more information on Tunnel errors, view your [Tunnel logs](/cloudflare-one/networks/connectors/cloudflare-tunnel/monitor-tunnels/logs/) or [contact Cloudflare Support](/support/contacting-cloudflare-support/).
-

src/content/docs/cloudflare-one/team-and-resources/users/scim.mdx

@@ -28,3 +28,13 @@ Cloudflare Access can automatically deprovision users from Zero Trust after they
 
 To set up SCIM for Zero Trust, refer to our [SSO integration](/cloudflare-one/integrations/identity-providers/) guides.
 
+## Common provider-specific issues
+
+SCIM behavior depends on the identity provider configuration as well as Cloudflare.
+
+Common issues include:
+
+- **Okta**: User sync and group sync are separate. Make sure **Push Groups** is configured if you expect groups to appear in Zero Trust policies.
+- **Microsoft Entra ID**: Group sync only occurs for groups included in the provisioning scope. The `userName` attribute should match the user's email address in Cloudflare One.
+
+If users appear but groups do not, verify the IdP-side SCIM app first before troubleshooting Cloudflare policy behavior.

src/content/docs/dns/troubleshooting/dns-issues.mdx

@@ -57,6 +57,62 @@ In rare cases, the DNS resolver in the client requesting the URL might fail to r
 
 Reload the page after a short wait to note if the problem disappears. This issue is unrelated to Cloudflare, but using [Cloudflare's DNS resolver](/1.1.1.1/setup/) may help. Contact your hosting provider for additional help with your current DNS resolver.
 
+### Newly created record still does not resolve
+
+If you recently created a DNS record and resolvers still return `NXDOMAIN` (Non-Existent Domain) or no answer, it is likely because a negative response is currently stored in the resolver's cache.
+
+When a resolver is queried for a hostname that has no DNS records yet, it caches the empty response so it does not have to ask the authoritative nameserver again immediately. This is known as negative caching.
+
+For newly created records:
+
+- The resolver might not have cached the new record yet. Instead, it is using a prior `NXDOMAIN` cache entry that says "this record does not exist," which was generated if the hostname was queried before you created the record.
+- The duration of this negative cache is determined by the `MINIMUM` field in your zone's SOA record (per [RFC 2308](https://datatracker.ietf.org/doc/html/rfc2308)), not the TTL of the record you just created. Different resolvers may cache for varying durations.
+
+This means:
+
+- Lowering the TTL on your new record will not speed up resolution if a negative cache entry already exists; the resolver will only see your new TTL after the old negative entry expires.
+- Flushing your local DNS cache only affects your specific device; the upstream recursive resolver (for example, your ISP or a public provider) still holds the negative result.
+- Propagation appears uneven because different resolvers may have queried the name at different times, apply different negative cache TTLs, or have no negative cache entry at all.
+
+The exact behavior differs per resolver, but to estimate how long you need to wait, query your zone's SOA record and look at the last value (the `MINIMUM` field). You must wait for that interval to pass since the last `NXDOMAIN` query before the new record will consistently resolve.
+
+You can check if a negative cache entry is active by querying for the non-existent (or newly created) hostname:
+
+```sh
+dig +noall +answer +authority mynewrecord.example.com
+```
+
+If the record is still negatively cached, the response will include the zone's SOA record in the authority section with a TTL indicating how many seconds remain before the entry expires:
+
+```txt
+example.com.		256	IN	SOA	...
+```
+
+In this example, the negative cache response will continue for 256 more seconds.
+
+To verify the record resolves correctly, you can purge the cache for public resolvers and query the record. If this works, other resolvers will eventually start resolving as well:
+
+- [Purge 1.1.1.1 cache](https://one.one.one.one/purge-cache/)
+- [Purge 8.8.8.8 cache](https://dns.google/cache)
+- [Query 8.8.8.8](https://dns.google/)
+- [Query and refresh OpenDNS cache](https://cachecheck.opendns.com/)
+
+#### Further debugging
+
+To verify the record was correctly created, query Cloudflare's authoritative nameservers directly:
+
+```sh
+# Find the authoritative nameservers for your zone
+dig @1.1.1.1 example.com NS +short
+```
+
+```sh
+# Query the authoritative nameserver for your new record
+dig @hera.ns.cloudflare.com mynewrecord.example.com A
+```
+
+Querying the authoritative nameserver directly bypasses resolver caching. If the record is returned, resolvers will eventually start returning it as well. If the record does not appear, verify the record exists in the Cloudflare dashboard and that the hostname matches exactly.
+
 ### Account recovery
 
 If you are locked out of the Cloudflare account that contains your DNS configuration, refer to [Account recovery](/fundamentals/user-profiles/account-recovery/).

src/content/docs/dns/troubleshooting/email-issues.mdx

@@ -35,6 +35,41 @@ Also, if `CNAME` records are not returned by the queried nameserver (sometimes n
 
 Cloudflare does not proxy traffic on port 25 (SMTP) unless [Cloudflare Spectrum](/spectrum/reference/configuration-options#smtp) is turned on and configured to proxy email traffic across Cloudflare. If you do not have Spectrum turned on, then no email traffic (SMTP) passes through Cloudflare, and Cloudflare only resolves the DNS. This also means that any DNS record used to send email traffic must be DNS-only to bypass the Cloudflare network. For more information, refer to [Identifying subdomains compatible with Cloudflare's proxy](/dns/proxy-status/).
 
+## Is your mail hostname proxied?
+
+Mail protocols such as SMTP, IMAP, and POP3 do not work through Cloudflare's standard HTTP proxy.
+
+If the hostname used for mail resolves to a Cloudflare IP address, the record is proxied and mail clients will not be able to connect correctly.
+
+Common examples include:
+
+- `mail.example.com` used for SMTP, IMAP, or POP3
+- Any hostname targeted by your `MX` record
+- Autodiscover or mail service hostnames that must return the provider's actual DNS target
+
+To fix this issue:
+
+1. Go to **DNS** > **Records**.
+2. Locate the mail-related hostname.
+3. Change the [proxy status](/dns/proxy-status/) to **DNS only**.
+
+Your `MX` record itself is always DNS-only, but the hostname it points to must also resolve to a DNS-only target.
+
+## Common provider record values
+
+If you are not sure whether the DNS content itself is correct, compare it with the values from your provider.
+
+Common examples include:
+
+| Provider | MX records | SPF record |
+| --- | --- | --- |
+| Google Workspace | `ASPMX.L.GOOGLE.COM` (priority `1`), `ALT1.ASPMX.L.GOOGLE.COM` and `ALT2.ASPMX.L.GOOGLE.COM` (priority `5`), `ALT3.ASPMX.L.GOOGLE.COM` and `ALT4.ASPMX.L.GOOGLE.COM` (priority `10`) | `v=spf1 include:_spf.google.com ~all` |
+| Microsoft 365 | `<your-domain>.mail.protection.outlook.com` (priority `0`) | `v=spf1 include:spf.protection.outlook.com -all` |
+| iCloud Mail | `mx01.mail.icloud.com` and `mx02.mail.icloud.com` (priority `10`) | `v=spf1 include:icloud.com ~all` |
+| Mailgun | `mxa.mailgun.org` and `mxb.mailgun.org` (priority `10`) | `v=spf1 include:mailgun.org ~all` |
+
+Always confirm the exact values with your provider before making changes.
+
 ## Contact your mail provider for assistance
 
 If your email does not work shortly after editing DNS records, contact your mail administrator or mail provider for further assistance in troubleshooting so that data about the issue can be provided to Cloudflare support.

src/content/docs/registrar/troubleshooting.mdx

@@ -78,6 +78,14 @@ Domains with certain WHOIS statuses cannot be transferred:
 - `redemptionPeriod` — the domain has expired and passed the grace period. You must restore and renew it at your current registrar before it can be transferred.
 - `pendingDelete` — the domain is scheduled for deletion by the registry and cannot be transferred or recovered. After deletion, the domain becomes available for anyone to register.
 
+Other common WHOIS or RDAP statuses include:
+
+- `clientTransferProhibited` — the domain is locked at the registrar.
+- `serverTransferProhibited` — the registry has applied a transfer restriction.
+- `addPeriod` — the domain is within the post-registration lock window.
+- `pendingTransfer` — the domain is already in an active transfer.
+- `clientDeleteProhibited` or `serverDeleteProhibited` — deletion is restricted.
+
 ## WHOIS privacy is blocking the transfer
 
 Most domains can be transferred with WHOIS privacy enabled. However, some registrars may prohibit transfer requests if you have WHOIS privacy services enabled. If your transfer is failing, check with your current registrar to confirm WHOIS privacy is not blocking it.
@@ -111,6 +119,16 @@ Verification is triggered when your registrant contact email differs from your v
 
 Some TLDs — including `.mx`, `.nz`, and `.ca` — may send verification through a third-party service. In these cases, the verification email will come from `noreply@emailverification.info` rather than Cloudflare. Check your spam folder if you do not receive it.
 
+For these TLDs, if verification is not completed in time, the registry may temporarily replace your nameservers with `ns1.emailverification.info` and related hostnames until the registrant email is verified.
+
+## `.uk` transfer uses an IPS tag, not an auth code
+
+`.uk`, `.co.uk`, and `.org.uk` domains do not use the standard auth-code transfer flow.
+
+Instead, the losing registrar changes the domain's IPS tag to the gaining registrar. If you are transferring a `.uk` family domain to Cloudflare and cannot find an auth-code field, this behavior is expected.
+
+If the transfer does not proceed, contact the current registrar and confirm that they have updated the IPS tag correctly.
+
 ## Restart your transfer
 
 :::note

src/content/docs/speed/optimization/protocol/troubleshooting/protocol-troubleshooting.mdx

@@ -33,3 +33,25 @@ These errors do not necessarily indicate a protocol-level issue. Follow these st
 3. If the issue does not persist, analyze netlogs for HTTP/2 or HTTP/3-specific issues.
 
 For more information, refer to [Chromium URL Request Header](https://chromium.googlesource.com/chromium/src/+/HEAD/net/url_request/url_request.h).
+
+## Chrome stalls or fails only on HTTP/3
+
+If the issue reproduces only in Chrome over HTTP/3 and disappears when HTTP/3 is disabled, the problem may be related to a browser-side QUIC handling issue rather than your origin server.
+
+Symptoms can include:
+
+- Large downloads stall unexpectedly.
+- Pages with many concurrent requests hang for one to three minutes and then fail.
+- Chrome reports `ERR_QUIC_PROTOCOL_ERROR` or another QUIC-related browser error after the connection stops making progress.
+
+### How to isolate the issue
+
+1. Temporarily disable HTTP/3 for the zone.
+2. Test the same request again over HTTP/2.
+3. If the issue disappears over HTTP/2, capture a NetLog for Chrome and compare the behavior.
+
+### Resolution
+
+If the issue is limited to specific hostnames, you can test a more targeted workaround such as removing the `Alt-Svc` header with a [response header transform rule](/rules/transform/response-header-modification/). However, proxied hostnames can also advertise HTTP/3 through generated HTTPS records. Disabling HTTP/3 for the zone is the most reliable way to force HTTP/2 while you troubleshoot.
+
+After changing `Alt-Svc`, remember that browsers may cache the advertised alternative service for up to 24 hours.

src/content/docs/ssl/origin-configuration/origin-ca/index.mdx

@@ -35,6 +35,10 @@ Refer to [Troubleshooting](/ssl/origin-configuration/origin-ca/troubleshooting/#
 Using Cloudflare origin CA certificates does not prevent you from using [delegated DCV](/ssl/edge-certificates/changing-dcv-method/methods/delegated-dcv/).
 :::
 
+:::note[Known limitation]
+Cloudflare does not currently send expiration notifications for origin CA certificates. If you rely on long-lived origin CA certificates, track their expiration in your own certificate inventory or monitoring system.
+:::
+
 ---
 
 ## Deploy an Origin CA certificate