Check guest name resolution
Compare address connectivity with lookups for a known name and the affected name from the same guest before editing its resolver.
Use this guide when an authorised guest can reach a known endpoint by address over an agreed protocol but cannot resolve its name. Record the error, time and hostname; one successful ping does not prove all network paths work. If address-level access also fails, use the wider network guide.
Confirm the actual operating system and whether the guest uses a resolver you may inspect. Ubuntu documentation below explains one possible installation, not every Novasean VPS. On a managed VPS, the agreed operator owns guest settings unless the service terms expressly delegate them; collect only authorised read-only evidence and ask the operator to make any change. Do not assume a customer panel exposes root access.
Compare a known name with the affected name
From the authorised guest session, test a known valid public hostname and the affected application hostname using a resolver tool already installed or an application lookup. Record the full query, whether it fails or returns an unexpected address, and whether the known name behaves differently. A failure for one domain can be a public authoritative-zone problem; a failure for many unrelated valid names points more strongly toward the guest’s client resolver or its upstream path. Compare the same affected name from an independent authorised network if available, without sending private internal names to a public tool.
Use an address-level test to the known endpoint through the relevant service where permitted; avoid equating ICMP reachability with working DNS, HTTPS or mail. Do not install troubleshooting packages or change firewall, routing or upstream DNS during this diagnosis. If the guest has no usable address or route, stop here and use the no-network guide.
Illustrative split: a known public name resolves, but the affected domain returns an unexpected address from the guest and another trusted network. Review that domain's authoritative records before altering the guest resolver.
Read the active resolver only when its implementation is known
If the confirmed guest is Ubuntu using systemd-resolved and your account may read its state, resolvectl status can show the active DNS servers and domains, while a read-only lookup through the installed resolver can show whether a name resolves. Ubuntu explains that Netplan and systemd-resolved may determine the effective client DNS settings; the visible /etc/resolv.conf may be a generated link rather than the configuration owner. Inspect what is present, not what a generic tutorial expects. On another OS or resolver, use that installation’s documentation or hand the symptom to its operator.
Record server addresses only in an authorised support channel. Compare any resolver errors or missing upstreams with the known-good configuration supplied by the operator, if available. A local hosts-file entry or search-domain suffix can affect one name differently from a fully qualified public name. Do not infer that a failing application necessarily uses the same lookup path as a diagnostic command.
The diagnostic lookup and the application may use different resolver paths or caches; test the application again after any resolver repair.
Ask the responsible operator for a scoped repair
Send Novasean support or the contracted guest operator the VPS identifier, confirmed OS and resolver, time, affected and control names, observed address-level test, read-only resolver status and any recent approved change. Omit credentials and confidential internal names from public tickets. Ask which layer owns the fault: guest client configuration, upstream resolver reachability or the affected domain’s authoritative DNS. The operator can plan an in-scope change with a saved configuration and rollback path.
This guide does not instruct you to edit /etc/resolv.conf, replace a symlink, start a resolver service, change Netplan, install BIND, disable DNSSEC or switch to public DNS servers. Each would assume installation and authority that this evidence has not established. Do not reboot or reinstall a VPS just because one lookup fails.
Recheck both name resolution and the application
After the authorised owner reports a correction, repeat the same known and affected hostname lookups from the guest and the agreed address-level test. Then test the original application operation, because a resolver answer alone does not prove that the application can connect. Note the result and time. If the problem returns, pass the before-and-after observations and change reference to the operator rather than applying an unreviewed second DNS setting.
Frequently asked questions
Does pinging an IP prove the VPS network is healthy? No. It establishes only that one ICMP exchange worked at that time.
Should I put a public resolver in resolv.conf? Not from this symptom alone. The guest may use generated client settings, private zones or an operator-managed upstream.
Could only one hostname be broken? Yes. Compare a known valid name and check that domain’s authoritative DNS before changing the guest resolver.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.