Guide / Tools, Infrastructure & Workflows
DNS, Hosting and SSL Are Three Different Things
Separate DNS delegation, hosting, TLS and HTTP redirects. Lessons from moving this static site from SiteGround toward its verified HostingPerTe deployment.
A domain can resolve successfully while the website is served by the wrong host. A server can contain the correct files while HTTPS fails. A valid certificate can coexist with an incorrect redirect. These outcomes are confusing only when DNS, hosting and TLS are treated as one configuration task.
Moving this site from its previous SiteGround setup toward the verified HostingPerTe deployment made those boundaries concrete. The repository could be ready, the transfer endpoint could accept files, and the public domain could still follow a different path. Each layer needed its own evidence.
A browser error at one layer does not tell you which layer created it.
The registrar is not necessarily the DNS operator
The registrar manages the domain registration relationship. The authoritative nameservers answer for the domain’s DNS zone. The same company can provide both services, but they are separate responsibilities and can be operated independently.
Changing a hosting plan does not necessarily change the domain’s authoritative nameservers. Likewise, transferring registration does not automatically move the website’s files or application. Before a migration, identify who controls each responsibility rather than assuming a single dashboard represents the whole system.
The DNS concepts in RFC 1034 describe the distributed namespace, delegation and resolution model. In practical migration work, delegation tells resolvers where to ask for authoritative answers. Editing records in a zone that is not authoritative will not change the answers most visitors receive.
For this project, earlier checks found the domain still using SiteGround nameservers while HostingPerTe deployment preparation was underway. That was a specific state to resolve, not proof that the static build or file-transfer configuration was defective.
Records describe destinations, not deployments
An A record maps a name to an IPv4 address; an AAAA record provides an IPv6 address. A CNAME identifies an alias to another name. These records help a client locate a service, but they do not upload files or establish that the destination is configured for the requested hostname.
Check the relevant names separately. The apex domain and www can have different records and behavior. A stale AAAA record can send some clients along a different path from clients using IPv4. A migration check that only inspects one record type can miss that discrepancy.
Caching also matters. Resolvers may retain answers according to their caching behavior and the records’ lifetimes. Observing one resolver’s answer does not establish that every visitor has the same view at that instant. Record which resolver and time produced the observation.
Avoid changing several unrelated DNS settings while diagnosing a single failure. Establish the intended authoritative zone and expected records, then compare actual answers. This keeps the investigation tied to evidence rather than dashboard experimentation.
Hosting determines what answers the request
Once the client reaches the destination, the web server must recognize the hostname and serve the correct document root. A shared server can host many sites on one address. Reaching that address alone does not establish which site will answer a request.
The deployment endpoint can differ from the public hostname. This site uses the technical HostingPerTe host for file transfer while public canonical URLs use https://www.sebastianodruda.it. Keeping those roles distinct avoids relying on public DNS migration state to locate the transfer service.
The verified transfer account is constrained to its configured web root. That boundary matters more than a directory name copied from a generic hosting guide. The deployment script must use the confirmed account view and preserve provider-owned files outside its manifest ownership.
A successful upload proves that files reached the account’s destination. It does not prove that public requests are served from those files. Verify a known deployed artifact through the public hostname after the transfer.
TLS authenticates the connection’s name
People often say SSL when referring to modern HTTPS configuration, although current HTTPS uses TLS. The certificate must be appropriate for the hostname the browser requests, and the connection must present a chain the client can validate.
A certificate for www does not automatically establish correct behavior for the apex name. Even if the apex immediately redirects, the HTTPS connection to it must succeed before the browser can read that redirect. Test both names when both are intended to be usable entry points.
Certificate issuance, installation and renewal are separate operational concerns from copying static files. A file-transfer credential may not have permission to manage them. Know which provider control or support process owns that layer.
Do not suppress certificate verification to make a deployment check appear successful. A request that succeeds only when verification is disabled has not established the public HTTPS behavior the visitor needs.
Redirects happen after the request reaches a server
HTTP redirects tell the client to request another URL. They can enforce HTTPS and a canonical hostname, but they depend on the server or proxy applying the expected rules. DNS itself does not perform an HTTP redirect.
Test the complete entry paths: HTTP apex, HTTP www, HTTPS apex and HTTPS www. Check the destination and the number of hops. The intended canonical page should load without a loop, and unrelated query parameters should not become an opportunity to redirect to an arbitrary external host.
A reverse proxy adds another boundary. TLS may terminate at the proxy while the origin sees a different connection. The redirect configuration must account for that arrangement without trusting a client-supplied forwarding header blindly.
Verify the path the browser actually takes, not just the configuration file you edited.
For this site, public behavior has needed separate checks from local preview behavior. Local tests establish application output; they cannot prove how a provider’s proxy interprets origin configuration.
Response headers reveal another serving layer
During this deployment work, public GET and HEAD responses did not always expose the same security headers. Apache configuration contained the intended directives, while successful static GET responses passed through a serving path that omitted them. A HEAD-only check would have hidden the difference. A fresh check on 14 October found the approved headers on both methods; the earlier discrepancy remains a useful diagnostic lesson.
That observation is a reminder to test the actual method and asset type used by the browser. Check an HTML page, a JavaScript worker, a PDF and a missing route where relevant. MIME type and caching behavior can vary across serving paths.
The PDF reader provided a concrete example: the worker needed a hosting-compatible JavaScript asset. The application’s bundled worker output could be corrected in the repository, while proxy-level response-header behavior required a different operational boundary.
The hosting architecture essay explains why renting infrastructure still leaves verification work with the site owner. A provider feature should be confirmed through the delivered behavior, not inferred from the presence of a configuration directive.
Cache policy deserves the same layered approach. Fingerprinted assets can use long-lived caching because a content change produces a new URL. HTML and discovery files need a policy compatible with publication updates. A local response header cannot establish the policy applied by an upstream static-file server. Inspect the public response and compare it with the intended asset class before assuming that a stale page is a DNS problem. DNS caching and HTTP caching affect different parts of the request path.
Diagnose from the outside inward
A disciplined migration check starts with the public name and follows the request. Confirm delegation and records, establish the connection, inspect the certificate, follow redirects and verify the served artifact. When a step fails, investigate that layer before changing unrelated settings.
Keep evidence specific: hostname, method, timestamp, status, final URL and relevant headers. Do not publish credentials or private control-panel details in the report. The goal is to make the boundary understandable enough that the right operator can act.
Finally, separate readiness from completion. A working build, a successful transfer and a verified public page are different milestones. The migration is complete only when the intended visitor path reaches the intended content with the expected transport and server behavior. Naming those layers makes the work easier to finish and much easier to troubleshoot later.