Published: 2026-08-07 Status: Resolved — root cause identified and confirmed
On 7 August 2026, users at several customer organisations were unable to reach their LemonadeLXP environment from their corporate networks, receiving a Cloudflare error page reading "Error 1034 — Edge IP Restricted." The same users could reach the same addresses normally from mobile devices, home networks, or any connection outside their employer's network.
Our investigation found a single clear dividing line between the organisations that failed and those that did not.
Organisations whose internal DNS uses a static record — a manually created A or CNAME entry — for their LemonadeLXP hostname failed. Organisations using the nameserver (NS) delegation specified during onboarding did not.
The LemonadeLXP platform was healthy throughout. No changes were made to our platform, our Cloudflare configuration, or our origin infrastructure. Public DNS resolution was correct at all times, which is why access from outside the corporate network continued to work normally. No data was lost, exposed, or corrupted.
Every organisation that reported a failure and whose configuration we were able to inspect had the same class of problem: inside their own internal DNS — the authoritative zone their corporate network uses for their own domain — someone had created a fixed record for the LemonadeLXP hostname instead of delegating it.
We observed two variants:
CNAME pointing at one of the Cloudflare nameservers assigned during onboarding, andA record pointing at an IP address that one of those nameservers resolves to.Both terminate at the same place. Cloudflare nameservers answer DNS queries; they are not web endpoints for customer hostnames. In the second case, the record had evidently been created by resolving the nameserver by hand and pinning the resulting address.
Organisations that implemented the NS delegation were unaffected, including organisations on the same infrastructure, in the same industry, with equally locked-down corporate networks. The delegation method was the only variable that mattered.
Our architecture has two layers of dynamic addressing, and neither can be expressed as a fixed address.
When a browser requests a LemonadeLXP hostname:
Addresses at both layers rotate as a matter of routine operation. They are not stable identifiers and were never intended to be treated as such. A static record cannot track them.
Delegation is what allows resolution to follow those changes automatically. This is why our setup documentation specifies NS delegation and states that A records cannot be used under any circumstance, and why organisations with both internal and external DNS are directed to create the delegation in both places.
Reference: Connecting your domain to LXP Learn · Zone Delegation with Microsoft DNS
This is the part that matters most for understanding the incident, because the affected organisations changed nothing. Their records had been in place and functioning for an extended period, and then stopped working overnight without anyone touching them.
There are two reasons a static record survived as long as it did.
The proxy absorbed the origin-side dynamism. The reason our documentation prohibits static addressing is the rotating load balancer addresses described above. But a customer's static record never pointed at the load balancer — it pointed at Cloudflare. Cloudflare handled the constantly changing origin addresses on its own side of the connection. The static record was therefore insulated from precisely the instability it was warned about. The requirement was correct, but the consequence of ignoring it was invisible.
Cloudflare's edge routed by hostname, not by address. Cloudflare operates an anycast network that has historically matched incoming web requests using the hostname carried in the request rather than the address the request was sent to. Under that behaviour, a request arriving at effectively any Cloudflare address with the right hostname was matched to the right site and served. The destination address was largely incidental to routing.
Taken together: a record pointing at a Cloudflare nameserver address still returned the correct site, because the nameserver address terminated at a Cloudflare edge node that read the hostname and served accordingly, while Cloudflare independently managed the real origin behind it.
The configuration was wrong the entire time. It simply never produced a visible symptom — for us or for the customer.
Error 1034 is the enforcement of a stricter rule: the hostname in a request must be authorised on the specific edge address that request arrived at. Requests that fail this check are rejected at the edge before reaching any customer's infrastructure.
Where this validation now applies to the nameserver address ranges involved, every configuration of this type fails at once — across unrelated organisations, with no action by any party. That is consistent with what we observed: multiple independent organisations reporting within the same window, none of whom had made a change.
Because the rejection happens before a request is associated with a customer zone, these requests do not appear in our logs. Customers who reported the Ray ID from the error page found it could not be located, as did we. That is expected for this error class and is not evidence of a spoofed page.
We raised this with Cloudflare, who concurred that internal DNS records pointing at nameservers rather than delegating to them account for the Error 1034 behaviour our customers experienced. The precise trigger for the change in timing was not established, and we are not able to state definitively why these configurations failed on this particular date rather than an earlier one.
What is established, and what matters for remediation, is that they fail now and will continue to. A static record of this kind is not a supported configuration and cannot be relied on going forward.
You are not affected if your organisation implemented the NS delegation supplied during onboarding and maintains no separate manual record for that hostname in internal DNS. You are also not affected if your LemonadeLXP hostname is a subdomain of lemonadelxp.com rather than of your own corporate domain.
You may be affected if your hostname sits beneath your own corporate domain, your organisation runs internal DNS authoritative for that domain — commonly Active Directory–integrated, sometimes called split-brain DNS — and a manual A or CNAME record exists for that hostname.
To check, run this on a domain controller:
Get-DnsServerResourceRecord -ZoneName <yourdomain> -Name <lemonade-hostname-label>
The expected result is NS records pointing to the two Cloudflare nameservers assigned during your onboarding. An A or CNAME record is a finding.
Please check even if you have had no reports. A misconfigured organisation whose users have not recently attempted access will not have seen a failure yet. The configuration is already broken; the symptom is waiting on traffic.
Inside the affected internal DNS zone:
A or CNAME record for the LemonadeLXP hostname.NS delegation for that hostname to both Cloudflare nameservers assigned during onboarding. Organisations on our CNAME package should apply the CNAME target supplied during their onboarding instead.Clear-DnsServerCache) and on a test workstation (ipconfig /flushdns).Do not substitute a fixed IP address. Any address you pin today will eventually stop working for the same underlying reason.
The root cause is established and confirmed: static internal DNS records standing in place of the required nameserver delegation. Every organisation we inspected that experienced this failure had such a record, and no organisation using the prescribed delegation was affected.
Neither open point changes the remediation. If your internal DNS holds a static record for your LemonadeLXP hostname, it needs to be replaced with an NS delegation regardless of whether you have seen a failure.
If your users encountered this error, or the check above returns something unexpected, contact your Customer Success Manager or our support team and we will work directly with your IT team.
This report reflects our findings as of publication.