Domain Dictionary · Application Risk
A WAF only sees what your DNS sends it
You put a filtering layer in front of the site, and then one leftover record hands attackers a way around it.
The short answer
A WAF is a filter that reads the content of incoming web requests and refuses the ones matching known attack patterns — injected SQL, injected script, probes for published exploits — before your application ever runs. The part nobody mentions is that a WAF is only in the path because a DNS record put it there, so which requests it inspects is decided in your zone.
That makes zone hygiene a security control rather than a housekeeping chore, and it is where most bypasses come from.
By the Hosting & Domains team · Reviewed 18 August 2026
0
Terms used before they are defined
100+
Entries, all cross-referenced
Real
Examples, out of the queue
Free
To read, and no sign-up
There are two places a WAF can live. At server level it sits underneath the application on the same machine, which is where the Imunify360 rules on our protected plans operate: every request to that account passes through it because there is no way in that does not. In front of the origin, as part of a proxy service, it only sees what the proxy is sent — and that is entirely a matter of where your records point.
The rules themselves are somebody's maintained catalogue of attack shapes, refreshed as new vulnerabilities become public. How quickly those updates land is the actual product you are buying.
The record that walks around the filter
Say you point example.com and www at a filtering proxy. The zone still holds mail.example.com, cpanel.example.com, ftp.example.com and an old staging record from two years ago, every one of them an A record naming the origin address directly. Anyone who reads your zone — and it is public — now has the address the filter was meant to hide, and can address the origin without the filter in the way.
The fix is a zone audit rather than a WAF setting. Open the Zone Editor, read every record, and for each one decide whether it needs to name the origin at all. Records for services you have stopped using come out; records that must exist get the narrowest name you can give them.
Historical records outlive their usefulness
Old DNS data does not evaporate. Passive-DNS collections keep the answers your zone once gave, and Certificate Transparency logs publish every hostname anybody has ever requested a certificate for. If dev.example.com existed for a fortnight two years ago and pointed at the same box you use now, that pairing is still on the record.
This is why 'we will just not publish it' is a weak plan. Treat every hostname you create as permanently public, and make the protection something an attacker cannot route around rather than something they have to fail to notice.
Three things a WAF is structurally unable to see
It reads HTTP. So it does not read DNS queries, which arrive at your nameservers over a different protocol entirely and never touch it. It does not read SMTP, which is why a WAF is no part of your mail defence and spam filtering is a separate product. And it does not read your registrar account, so a stolen client-area password stays a stolen client-area password.
Being clear about that boundary is useful in both directions. It stops you expecting a WAF to fix a mail problem, and it stops you treating a WAF as the reason your name is safe.
False positives, and the exception that keeps the shield up
Now and again a legitimate submission looks like an attack — a contact form carrying a code snippet, a CMS field holding an apostrophe in an awkward place. The remedy is a narrow exception: that rule, that path, nothing wider. Our desk writes those in a few minutes. Switching the WAF off to rescue one form is a trade nobody should take.
One case deserves a mention here because it is ours by territory: an overzealous rule occasionally interferes with the file-based check a certificate authority uses to validate control of a name. Where that happens, the DNS-record method of validation goes around the problem without loosening anything.
What we send readers instead of a knowledge-base link
These began as replies in our domain queue. The good ones got edited, cross-referenced and published, and this is what came out.
Support answers at any hour, and the remit covers the awkward domain questions other registrars hand straight back.
- Registry, registrar, reseller and host kept distinct
- The email consequence spelled out, never implied
- No invented figures, anywhere on the page
- Recognise-level and operate-level marked apart
Why Hosting & Domains
Standard on every plan
This term, pinned down
Web Application Firewall defined, placed in the layer that owns it, and shown going wrong — recognise-level after one read.
Failure modes, not only definitions
Each entry names the way the thing goes wrong, on the grounds that a fault is usually what sent you looking it up.
Panel screens named outright
Where a setting exists, we say which screen it is on — Zone Editor, the domain list, the client area — instead of describing it in the abstract.
One idea to an entry
No entry tries to be a manual. It defines the term, shows it doing its job, and points at the term you will need next.
Registry and registrar kept apart
Every entry says which company owns the thing being described, because that is the difference between fixing it yourself and reporting it to somebody else.
Cross-referenced, never a cul-de-sac
Neighbouring entries are linked at the foot of the page, so one lookup tends to leave you holding three terms instead of one.
Quick Start
Order placed to site online
- 1
Open the zone and read it
cPanel's Zone Editor lists every record answering for your name. Five minutes reading your own zone teaches more than an hour of reading about zones.
- 2
Note down what each record is for
One line beside the zone — this TXT verifies Google, that CNAME serves the newsletter — is what stops a tidy-up killing a working integration.
- 3
Confirm the default instead of assuming it
The platform ships this set sensibly. Looking anyway is the whole difference between knowing how your account is configured and hoping about it.
Built In
Fitted to every plan
- DNS records you edit yourself, in cPanel's Zone Editor
- Free SSL on every plan, reissued before the old one lapses
- DDoS filtering absorbed at the network edge
- Spam and virus screening standing in front of every mailbox
- cPanel, the panel most of the industry already runs
- A daily copy, restored from the panel without a ticket
- People on the support desk at every hour of the day
- Softaculous one-click installs, WordPress included
- Upgrades applied in place, with no migration when the plan changes
- No set-up fee, and nothing charged for joining
Frequently Asked
Questions we field again and again
If my site sits behind a filtering proxy, does the rest of my zone matter?
It matters a great deal, and it is the commonest way that protection turns out to be decorative. Any record still naming the origin address directly — mail, panel, ftp, an old staging host — is a route that does not pass through the filter. Read the whole zone in the Zone Editor, decide record by record, and delete what belongs to a service you no longer run.
Does a WAF do anything for my email?
Nothing at all, and expecting otherwise leaves a real gap. A WAF reads web requests; mail arrives over SMTP and is never inspected by one. Mail protection is a separate stack: filtering in front of the mailboxes, and SPF, DKIM and DMARC records in your zone so receivers can tell your mail from somebody's forgery of it.
Can a WAF rule stop my certificate renewing?
Occasionally, yes. The usual file-based validation involves the authority fetching a specific path over HTTP, and a rule that blocks unfamiliar request shapes can eat it. You will see it as a renewal failure on a name whose DNS is plainly correct. Either exempt that one path, or validate by TXT record instead — on our plans the certificate issues and reissues itself, so this mostly bites people running the process by hand.
Where does the WAF sit on a Hosting & Domains plan?
At server level, underneath your application, on the plans carrying Imunify360. That placement is deliberate: it means the filter cannot be sidestepped by addressing the origin, because from the request's point of view there is no route in that avoids the machine it lives on. Nothing about it needs a change to your zone.
Keep reading
Plesk Reseller Hosting
Plesk-based reseller accounts, for teams who would rather not learn a second panel.
DirectAdmin Reseller Hosting
A lighter DirectAdmin reseller tier at a lower monthly figure.
Changing provider? Work through this checklist beforehand.
A straightforward running order for a migration your visitors never spot: which files travel first, how to bring the mail across without dropping a single message, the right moment to repoint DNS, and the two errors that sit behind almost every outage we get called in to fix.
Get the record right the first time.
Renewal figures printed beside registration figures, WHOIS privacy wherever the registry allows it, and DNS records you edit yourself.
View Plesk Reseller Hosting plans