> ## Documentation Index > Fetch the complete documentation index at: https://docs.verisoul.ai/llms.txt > Use this file to discover all available pages before exploring further. # Custom Hostname Security & DNS Delegation This page is for security, infrastructure, and DNS teams reviewing the [Custom Hostname](/integration/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. | | Who controls it | | --------------------------------------------------------------------- | ------------------------------------------------------ | | `example.com` zone (apex, `www`, MX, SPF/DKIM, every existing record) | **You** — unchanged and unreachable by Verisoul | | The four `NS` records at `js.example.com` | **You** — they live in your zone, at your DNS provider | | Records inside the delegated `js.example.com` zone | Verisoul — limited to the record inventory below | 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.` 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: | Name | Type | Value | Purpose | | -------------------------------- | ------------ | ---------------------------- | --------------------------------------------------------------------- | | `js.example.com` | `NS` / `SOA` | Google Cloud DNS nameservers | Standard zone records — present in any DNS zone | | `js.example.com` | `A` | `34.36.xx.xx` | One of many geolocated records; users resolve the one nearest to them | | `_acme-challenge.js.example.com` | `CNAME` | ACME validation target | Certificate issuance and renewal | | `sandbox.js.example.com` | `A` | `34.36.xx.xx` | Sandbox environment for testing | 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) (`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 No. Verisoul operates only the delegated child zone for the single hostname you configured. The parent zone — including all existing records, mail configuration, and every other subdomain — is invisible to and unreachable by Verisoul. Verisoul automatically creates `sandbox.` inside the delegated zone so you can test against the sandbox environment with your sandbox project ID. It requires no action on your side — it exists entirely within the zone you already delegated. The hostname immediately stops resolving to Verisoul, so the certificates stop mattering in practice: they cannot be used to serve traffic on a hostname that no longer points at Verisoul infrastructure. They also cannot be renewed, since renewal requires the DNS-01 validation records in the delegated zone, and age out at the end of their (90-day) validity. No. Your backend continues to call Verisoul's APIs directly. The custom hostname affects only how the browser loads and communicates with the Web SDK. The zone contents are limited to the record inventory above. If future SDK functionality requires additional records, this page is the documentation of record and will be updated to reflect them. 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.