Custom Hostname Security & DNS Delegation

This page is for security, infrastructure, and DNS teams reviewing the Custom Hostname setup. It explains exactly what is delegated, what Verisoul publishes in the delegated zone, how certificates are issued, and how you retain control at all times.

​

What you are delegating

You delegate a single subdomain label — for example js.example.com — by adding four NS records at that name in your existing zone. That is the entire footprint of the change. Delegation is scoped by the DNS hierarchy itself: a delegated child zone has no ability to create, read, or modify records in the parent zone. Verisoul cannot touch anything at example.com or any of its other subdomains.

​

You stay in control

The four NS records that make the delegation work live in your zone at your DNS provider. Verisoul never holds credentials to your DNS account and has no mechanism to keep the delegation alive without those records. To revoke, delete the four NS records. The delegation is dead as soon as resolvers see the change — nothing Verisoul holds (the delegated zone, the certificates) can restore it or keep traffic flowing to us afterward. No ticket, no contract change, no coordination with Verisoul required.

​

What Verisoul publishes in the delegated zone

The delegated zone contains only the records needed to serve the SDK:

• Geolocated A records for the hostname, pointing to Verisoul’s regional infrastructure so users connect to the nearest region.
• An _acme-challenge record used for certificate issuance and renewal (see Certificates below).
• A sandbox.<hostname> subdomain (for example sandbox.js.example.com), created automatically so you can test against the sandbox environment. You do not need to add anything for it — it lives inside the delegated zone.

As a concrete example, here is what the delegated zone for js.example.com looks like: This is the documentation of record for what the delegated zone contains. If SDK functionality requires additional records in the future, this page will be updated to reflect them.

​

Certificates

• Certificates are issued by Let’s Encrypt using the DNS-01 challenge, scoped to your exact hostname and its sandbox subdomain. No wildcard for your domain is ever requested.
• Issuance is publicly auditable: every certificate appears in Certificate Transparency logs. You can monitor exactly what has been issued for your hostname at any time, for example via crt.sh (https://crt.sh/?q=js.example.com).
• You can constrain issuance with CAA: a CAA record on your parent zone lets you restrict which certificate authorities may issue for your domains. If you already enforce a CAA policy, make sure it allows letsencrypt.org for the delegated hostname — otherwise certificate issuance will fail.
• Renewal is fully automated inside the delegated zone. You are never asked to add or rotate validation records.

​

Why NS delegation

A natural question from DNS teams is why the integration uses NS delegation rather than a simple alias record. The design follows from what the feature has to guarantee:

• Fully first-party resolution. Ad blockers and privacy extensions do not just look at the hostname in your script tag — many follow the full DNS resolution chain, and if any step in that chain resolves through a blocklisted name such as verisoul.ai, the request is classified as third-party and blocked regardless of the hostname you used. An alias record always leaves a vendor-owned name in the chain for blockers to match on. With NS delegation, resolution terminates entirely within your own hostname: every lookup returns records under js.example.com, and no Verisoul-owned name appears anywhere in the chain.
• Automated certificate lifecycle. Operating the zone lets Verisoul complete DNS-01 validation and renew certificates on schedule without ever asking your team to place validation records — no recurring DNS tickets, no expiry risk from a missed renewal handoff.
• Geo-routed performance. Verisoul publishes geolocated A records so each user connects to the nearest region. A static alias cannot do this and adds resolution hops, which means measurably higher latency on every SDK load.

It is also worth being precise about what delegation does and does not change from a trust perspective. The security-relevant capability — Verisoul serving content on js.example.com — is inherent to serving the SDK from your subdomain, however the DNS is wired. Delegation only determines where the DNS records for that one label are hosted. It grants no capability at your parent domain beyond what pointing the subdomain at Verisoul already grants.

​

If your policy does not allow delegation

Some organizations have a blanket policy against delegating subdomains of their primary corporate domain. In that case, delegate a subdomain of a secondary domain you own instead — your primary domain’s zone is never involved. For example, if your site runs on makerewards.com and policy forbids delegating its subdomains, you could register or reuse make-rewards.com and delegate js.make-rewards.com. Because many blockers work by keying on vendor names like verisoul anywhere in the request or resolution chain, serving the SDK from a neutral domain you own avoids that match entirely. A hostname on a different registrable domain is not fully first-party — some stricter extensions may still block it — but it retains most of the benefit and is meaningfully better than loading from a Verisoul-owned hostname. Prefer a secondary domain your users already visit (a product or regional domain) when you have one.

​

FAQ

If your security team has a question this page does not answer, reach out through your Verisoul support channel and we will address it directly.