Ugrás a tartalomra
Ország Hungary
Silurian az Ön országábanVálassza ki a szolgáltatási régióját

A termékek, a számlázás és az elérhetőség a kiválasztott országtól függhet.

Kapcsolatfelvétel a Silurian-nal

Silurian Docs

All documentation Web hosting and Site Studio

Hosting domains, DNS and TLS

Map one or more domains to website folders, change public DNS without unnecessary nameserver moves, and put every public hostname behind a valid TLS certificate.

Public guideReviewed 2026-09-02
01

Plan the hostname mappings

List every hostname visitors will use, including the apex domain, www and application subdomains. Assign a separate document root to each independent site. Point aliases to the same root only when they must display the same application. One hosting plan can serve several domains within its plan limit and is not permanently tied to the domain mentioned on its original order.

02

Attach a domain without moving its DNS

Attach the complete hostname and choose its document root. This creates a hosting mapping only: it does not transfer the domain, change its registrant or replace its authoritative nameservers. Keep an externally managed DNS zone where it is unless a separate DNS migration is actually required.

03

Publish the correct DNS records

For an apex domain, create the exact A record and, if IPv6 will be used, AAAA record shown for the hosting. For a subdomain, use the supplied address records or an appropriate CNAME. Remove conflicting records for the same hostname. During a migration, keep email-related MX and TXT records unchanged unless the email service is also moving.

04

Check propagation before cutover

Query the public DNS result from more than one network and compare it with the hosting destination. Cached answers remain until their time to live expires, so a correct change may not be visible everywhere immediately. Keep the previous site available during that interval and avoid making unrelated nameserver changes to force propagation.

05

Issue the TLS certificate

Enable TLS for every attached hostname that will serve HTTPS. Certificate issuance requires the hostname to resolve correctly and answer the validation request. Wait until coverage includes the apex and www names separately, then test each HTTPS URL. Only after that should the application or .htaccess enforce a permanent redirect from HTTP.

06

Avoid common HTTPS failures

A certificate-name error means the requested hostname is missing from certificate coverage. A redirect loop usually means the application, .htaccess and a proxy are all trying to force HTTPS differently. Mixed content means an HTTPS page still loads scripts, styles or media over HTTP. Fix the application URLs rather than disabling TLS.

07

Use cache and firewall controls deliberately

A cache purge removes stored responses but not source files; use it when a confirmed deployment still serves stale content. The application firewall filters suspicious web requests but does not replace application updates. If a legitimate request is blocked, reproduce it, change only the affected protection and restore the protection after testing.

08

Detach a hostname

First identify whether another hostname shares its document root and whether public DNS still sends traffic to it. Detaching removes only the hosting mapping. It does not delete the domain registration, DNS records, website files, database or mailboxes; remove those separately only when their retention has been decided.