# Use a custom DNS name for SQL access

A custom DNS name is an address used by clients. It does not change a Coordinator DB database name or create a new listener. Configure the DNS record in the service responsible for your network, then make sure its destination reaches the intended native or HTTP address.

## Test from the client network

Use the same hostname and port the application will use. Confirm name resolution first, then check `/ping` and an authenticated SQL request. If an external TLS proxy terminates HTTPS, its certificate must cover the client-facing hostname and its upstream must reach the server.

Coordinator DB does not terminate TLS itself. Do not treat a DNS alias as encryption. Native client addresses include both host and port through `--addr`.

## Browser-specific checks

Browser requests require matching Origin and Host, and the server emits no CORS headers. Empty-password users are restricted to IP hosts or localhost. A custom hostname can therefore expose an authentication or origin restriction that a localhost command did not encounter.

Keep database credentials out of the DNS record and URL. If a name change fails, compare the resolved address, proxy route and HTTP response status before changing SQL settings.

See [HTTP browser access](https://coordinatordb.com/docs/concepts/features/interfaces/http), [native client](https://coordinatordb.com/docs/concepts/features/interfaces/client) and [listener configuration](https://coordinatordb.com/docs/reference/settings/server-settings/settings/listen).