Connect without changing nameservers

Don’t want to move your DNS? You don’t have to. Nameservers stay where they are, and only the names you need are connected to WebShield: www, blog, the domain itself. Protection, caching, statistics, static sites and redirects work exactly as they do for a delegated domain.

What you won’t get: the DNS records section and DNSSEC from us. Your provider still runs the zone.

Add the domain

1. Control panel → Domains → Add domain.
2. Enter the domain itself, for example example.com. Not www.example.com: www, blog and the root are connected inside the domain, sharing one plan and one set of statistics.
3. Choose Keep your DNS and add records.

The panel opens the Hosts section, where names are connected.

Connect a name

Press Add a name and pick what runs on it:

• Protect my server: traffic flows through WebShield to your server. You’ll need its public address, an IP or a hostname, with a port if needed. Site on Vercel, Netlify, Heroku, Render or Tilda? Use the platform address and add your name to the project on the platform as a custom domain: that’s how the platform finds the project.
• Host a static site: the files live with us, no server of your own.
• Redirect: for example, from example.com to www.example.com.

Each name gets its own unique target like k7q2….sites.webshield.pro. Then come three steps, and the order matters.

1. Confirm the name is yours

Add the record from the card at your DNS provider:

_acme-challenge.www.example.com.  CNAME  <target from the card>

Press Check. Just added the record and the check doesn’t see it? Give DNS a couple of minutes.

Keep this record afterwards. Certificate renewal depends on it, and it’s how we know the name is still yours.

2. Wait for the certificate

Right after confirmation we request a Let’s Encrypt certificate. It usually takes a couple of minutes; the card shows the status.

If the domain has CAA records, one of them must allow letsencrypt.org, or issuance fails:

example.com.  CAA  0 issue "letsencrypt.org"

3. Switch traffic

Only once the certificate is ready, point the name itself at the same target:

www.example.com.  CNAME  <target from the card>

Visitors land on working HTTPS straight away, with no certificate error in between. We’ll email you once traffic flows through us.

The root of the domain

A bare example.com can’t be a CNAME; that’s how DNS works. Use an ALIAS, ANAME or CNAME flattening record pointing to the same target. Cloudflare, DNSimple, NS1, Bunny DNS and many others support it.

A few caveats:

• Route 53 supports ALIAS only for AWS resources, so the root can’t be connected there: redirect it to www with your registrar or hosting tools.
• Your provider resolves the target from its own location, so the edge node nearest to the visitor is picked less precisely for the root than for www.
• Some providers return only IPv4 for such records.

If you have the choice, keep the main site on www and redirect the root to it.

If the record goes missing

We check the _acme-challenge record regularly. If it disappears, the site keeps working and you get an email, one per day until the record is back.

If the record doesn’t come back within 7 days, the name is disconnected and its target stops working. Settings and static site files are kept: add the name again, point the records at the new target, and you’re back.

Disconnecting on purpose? Delete the name in Hosts and the emails stop.

A name in another account

A name can’t work in two WebShield accounts at once. If another account confirms it (its _acme-challenge record now points to that account’s target), the name is disconnected in the previous account right away, and the owner gets an email. That’s how a name moves between accounts. An email you didn’t expect is a reason to check who has access to your DNS provider.

API and CLI

Names are connected with the external-hosts methods (see the API reference): create a name, read its target, call verify. The token needs the domains scope. In the CLI, the webshield hosts group does the same.