Today, LemonadeLXP uses Cloudflare’s web application firewall (WAF) and advanced DDoS attack protection services to ramp up security, and the Cloudflare network and managed DNS service to achieve better speed and performance.

We have three setup options, all of which stand on Cloudflare and AWS. It's important to note that none of these packages are "security upgrades" to one another; they are simply different ways of wiring the connection.

There are exactly two supported ways to wire a LemonadeLXP hostname, and they are architecturally different — not two flavors of the same thing. The approach depends on the package you select:

In Package One and Two you hand the hostname over to Cloudflare's nameservers. In Package Three you keep it and point it at Cloudflare's proxy. These are Cloudflare's own full and partial zone setups respectively, and your DNS team can read Cloudflare's documentation for either under those names.

Nothing else is supported. Specifically, the following will not work, even if they appear to work at first:

These look similar and are not interchangeable. This is the single most common source of misconfiguration we see.

The .ns.cloudflare.com hostnames are shared across an enormous number of unrelated Cloudflare zones. That is precisely why none of them can be authorised to serve your specific hostname over HTTPS, and why pointing a web record at one produces Error 1034 — Edge IP Restricted.

Quick test before you save a record: if you are creating a CNAME and the target ends in .ns.cloudflare.com, stop. That value belongs in an NS record, or you are on the wrong package.

A configuration pointing a web record at a nameserver may return your site correctly for a period of time. It is still incorrect, and it will fail without warning. We have seen this happen.

Our standard package provides Cloudflare Secure SSL. If you would like to personalize your SSL certificate, we must complete all of the steps in package one, plus:

This package incurs additional costs per domain:

If you have internal red tape that prohibits NS delegation, we can resort to a more complex CNAME setup. This is Cloudflare's partial zone setup, also called CNAME setup in their documentation. You remain the authoritative DNS provider for your domain and proxy only the LemonadeLXP hostname through Cloudflare.

We will guide you through the process; this type of setup adds 2–3 days to the onboarding procedure.

Two records are required at your authoritative DNS provider:

Also note:

This package supports Custom SSL.

This package incurs additional costs per domain:

This section applies to most banks and credit unions. Please read it even if your external DNS is already configured.

If your organization runs internal DNS that is authoritative for your own domain — commonly an Active Directory–integrated zone — then machines on your corporate network do not use public DNS to resolve your domain. They use your internal zone. Public DNS being correct does not help them.

This means:

For Active Directory environments, follow our step-by-step guide: Zone Delegation with Microsoft DNS.

If your internal DNS team cannot sub-delegate the hostname, forwarding that specific hostname to a public resolver is an acceptable alternative — a conditional forwarder in Windows DNS, or a zone "<hostname>" { type forward; ... }; stanza in BIND. Tell us if you plan to do this so we can note it on your account.

Please run these checks after making the change, and send us the output. We verify delegation as part of onboarding and will ask for it.

Each check is given for both Windows DNS and BIND/Linux environments. Run whichever matches your platform.

A correct change that appears not to work is almost always a stale cache. Clear the resolver cache before concluding anything.

Windows — on each domain controller, then on a test workstation:

BIND / Linux — on the DNS server, then on a test client:

Note that a CNAME or A record you are replacing may have been cached downstream with a long TTL. Allow for the original record's TTL to expire before escalating.

This is the definitive check. It reads the record as configured, with no resolver caching or fallback behaviour in the way.

Windows — on a domain controller:

BIND / Linux — query the authoritative server itself, bypassing recursion:

+norecurse matters — without it the server may return a cached or recursively resolved answer rather than what your zone actually contains. You can also inspect the zone file directly, or dump it with rndc dumpdb -zones.

Expected result. Packages One and Two: NS records listing both nameservers we assigned. Package Three: a single CNAME to {your-hostname}.cdn.cloudflare.net.

Anything else — particularly an A record, or a CNAME to .ns.cloudflare.com — is a finding.

Windows:

Linux / macOS:

-DnsOnly on Windows skips the hosts file, LLMNR, and NetBIOS, so you see the DNS answer rather than a local override. dig never consults those sources, so no equivalent flag is needed.

Windows:

Linux / macOS:

If this succeeds and check 2 does not, the problem is in your internal zone rather than in public DNS (assuming that your internal network permits connections to Cloudflare NS on port 53, TCP).

If you chose a package with Custom SSL, there are a few things to be aware of:

Packages one and two take approximately 2 business days to setup past the point of domain resolution. Our systems need for the domain to resolve before we can complete our setup.

For package three, please plan for about 4-5 days of setup time with your DNS team on standby to handle small DNS record creation requests.

No. There are two independent reasons, and both must be satisfied.

Reason one — our origin addresses are dynamic. When you access a LemonadeLXP domain:

Behind the scenes, the ALB does the same thing: it receives a hostname request and translates traffic to the right application fleet and its private subnets. IP addresses, in other words, change very often and can't be used as a beacon. Because there are two layers of dynamic addressing across two private networks, address translation can't meet connection requirements. We also prohibit traffic that is not signed from Cloudflare, and the rotating IP addresses of the fleet appliances sit in a private network. Direct addressing cannot solve this requirement.

Reason two — Cloudflare validates hostnames against edge addresses. Independently of the above, Cloudflare checks that the hostname in an incoming request is authorised on the specific edge address that request arrived at. A request sent to an address that does not serve your hostname is rejected at the edge with Error 1034 — Edge IP Restricted, before it reaches us at all.

This second reason is why an A record can appear to work and then stop. If you pointed at an address that happened to serve your hostname, the request succeeded. When that stops being true — and it will — every request fails at once, with no change on your side and nothing in our logs. Delegation is the only configuration immune to this.

No. This is a common and understandable mistake, so it is worth being explicit.

The hostnames ending in .ns.cloudflare.com are authoritative nameservers. Their job is to answer DNS queries about your hostname. They are not web servers, they do not serve your site, and they are shared across a very large number of unrelated Cloudflare zones — which is precisely why none of them can be authorised to serve your specific hostname over HTTPS.

Pointing a CNAME or an A record at one produces Error 1034 — Edge IP Restricted, either immediately or at some unpredictable point in the future.

If you are on Package One or Two, those hostnames belong in NS records and nowhere else. If you are on Package Three, you will not use them at all — your CNAME target is {your-hostname}.cdn.cloudflare.net, which is a proxy endpoint scoped to your specific hostname and is an entirely different system.

Tell us, and we will work through it with you. Depending on your environment:

What we ask is that you not improvise a substitute. Every failure of this kind we have investigated originated in a well-intentioned workaround that appeared to work.

No — records are required in both places, and for different reasons.

The hostnames used in the request are a core component of instance identification. Where an internal record satisfies humans accessing the application servers, many microservice callbacks that depend on resolution would fail if the records weren't public. For example, if Lambda attempts to leverage a reprocessing callback for the target instance, it will get DNS resolution failures when trying to invoke any instance-level APIs.

Conversely, external records alone will not serve your corporate users, because machines on your network resolve your domain through your internal zone rather than public DNS.

If the intention is to limit access to employees, we can use Cloudflare rules to restrict access to specific ingress points. It remains that the domain name must be visible to all parts of our infrastructure. Let us know if you'd like to explore this approach.

Yes. Under this circumstance, every learner that accesses Academy will need to register into LemonadeLXP, and visit the academy internally through the LemonadeLXP header. In this type of setup, we do not need to complete the DNS component that yields the standard public view.

Unfortunately that wouldn't be an option. We need to govern our firewall rules as the application evolves. We also need to manage the firewall in response to threat events in realtime, and to be able to corroborate firewall data to SIEM data. Losing this corroboration would significantly compromise our security posture.

We're open to adding IP-based rules to conform to your organization's needs if you'd like to limit IP access, but we must govern the security appliance that protects our infrastructure.

No. Our implementation requires us to maintain control of the WAF (Web Application Firewall) and ingress points for all our tenants. This is a crucial security requirement that allows us to provide consistent protection and management across our entire platform (and is also a component for SOC). It's necessary for your tenant zone to exist under our purview.

The short answer is: it's required.

The longer answer is that after an exhaustive and careful review of all available cloud-based security appliances, we chose Cloudflare to be an integral component of our network security stack. Beyond being what we believe is the best WAF on the market, it also provides a breadth of network optimization features that we've enmeshed with our service stack.

The combination of Cloudflare, AWS Shield, and AWS GuardDuty is integral to our security posture. Protecting your instance and data is of the utmost importance. Cloudflare's principal tasks are to:

That's just the tip of the iceberg — it does so much more, such as connection resumption, lossless image compression, automatic minification, 0-RTT, and HTTP/2 prioritization.