Dane/support knowledge gaps - check with SRhea before approving - #29782
Merged
Conversation
TownLake
requested review from
a team,
Maddy-Cloudflare,
RebeccaTamachiro,
codyanthony850,
dcpena,
nikitacano,
pedrosousa and
ranbel
as code owners
April 12, 2026 13:40
github-actions
Bot
added
product:cloudflare-one
product:registrar
Contributor
|
This pull request requires reviews from CODEOWNERS as it changes files that match the following patterns:
|
TownLake
changed the title
Contributor
nikitacano
approved these changes
Apr 13, 2026
pedrosousa
reviewed
Apr 13, 2026
danielegm
reviewed
Apr 13, 2026
danielegm
reviewed
Apr 13, 2026
|
|
||
| ## Skip and Allow do not behave the same way | ||
|
|
||
| In the custom rules phase, **Allow** and **Skip** solve different problems. |
Collaborator
There was a problem hiding this comment.
This is incorrect. Allow was used in Firewall Rules (deprecated and almost all customers migrated over to the Custom RUles). Skip is the new allow but for custom rules
Collaborator
There was a problem hiding this comment.
IP Access Rules has allow though, and that is still valid
hannes-cf
reviewed
Apr 13, 2026
Comment on lines
+62
to
+72
| If you recently created a DNS record and resolvers still return `NXDOMAIN` or no answer, the previous negative response may still be cached. | ||
|
|
||
| For new records, many resolvers use the zone's negative caching TTL rather than the new record's TTL. This negative cache duration is typically taken from the `MINIMUM` field in the zone's `SOA` record, as described in [RFC 2308](https://datatracker.ietf.org/doc/html/rfc2308). | ||
|
|
||
| This means: | ||
|
|
||
| - Lowering the TTL on the new record does not clear an existing negative cache entry. | ||
| - Flushing your local DNS cache only affects your own device. | ||
| - Different recursive resolvers may recover at different times depending on when they cached the negative answer. | ||
|
|
||
| To confirm, query the zone's `SOA` record and check the negative caching value. Then wait for that interval to expire before testing again. |
Collaborator
There was a problem hiding this comment.
Suggested change
| If you recently created a DNS record and resolvers still return `NXDOMAIN` or no answer, the previous negative response may still be cached. | |
| For new records, many resolvers use the zone's negative caching TTL rather than the new record's TTL. This negative cache duration is typically taken from the `MINIMUM` field in the zone's `SOA` record, as described in [RFC 2308](https://datatracker.ietf.org/doc/html/rfc2308). | |
| This means: | |
| - Lowering the TTL on the new record does not clear an existing negative cache entry. | |
| - Flushing your local DNS cache only affects your own device. | |
| - Different recursive resolvers may recover at different times depending on when they cached the negative answer. | |
| To confirm, query the zone's `SOA` record and check the negative caching value. Then wait for that interval to expire before testing again. | |
| 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. | |
| 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 |
# Query the authoritative nameserver for your new record
dig @hera.ns.cloudflare.com mynewrecord.example.com AQuerying 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.
Collaborator
There was a problem hiding this comment.
The original text was a bit confusing in my opinion. So here is a revised and more technically accurate suggestion, partly written by Gemini, partly with input from the team.
There was a problem hiding this comment.
can I suggest that we include a dig command that will reveal if it is being cached? Giving them lots of words doesn't help.
$ dig +noall +answer +authority asdf.walmart.com
walmart.com. 256 IN SOA ..
In this example, the negative cache response will continue for 256s
* [DNS] Expand negative caching troubleshooting for newly created records * [DNS] Add dig example to check negative cache TTL
cferike
reviewed
Apr 14, 2026
cferike
left a comment
cferike
left a comment
Collaborator
There was a problem hiding this comment.
SSL section looks good to me. The Origin CA expiry note is accurate, there is no notification type for Origin CA certificate expiration today.
For reference:
- SECENG-4047 (https://jira.cfdata.org/browse/SECENG-4047) has tracked this gap since 2017
- SHIP-9043 (https://jira.cfdata.org/browse/SHIP-9043) (Origin CA rebuild) includes expiration notifications as a planned feature
Good addition, customers hit 526 errors with no warning when these expire.
TownLake
enabled auto-merge (squash)
April 15, 2026 08:36
TownLake
disabled auto-merge
April 15, 2026 08:46
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
13 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Screenshots (optional)
Documentation checklist