> For the complete documentation index, see [llms.txt](https://docs.datasentinel.io/manual/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.datasentinel.io/manual/ai-connector/troubleshooting/sign-in-unknown-host.md).

# Sign-in fails on an unknown host name

The sign-in fails with "getaddrinfo ENOTFOUND" or another DNS error on a name you never typed. Set DS\_MCP\_PUBLIC\_URL on the datasentinel\_mcp service to fix it.

**Applies to:** a self-hosted Datasentinel MCP server (the `datasentinel_mcp` service) whose sign-in fails before the login page opens. For a sign-in that stalls or loops after the login page, see [Sign-in problems](/manual/ai-connector/troubleshooting/sign-in-problems.md). For certificate errors, see [Self-signed and untrusted TLS certificates](/manual/ai-connector/troubleshooting/ssl-certificates.md).

{% hint style="info" %}
Throughout this page, replace `datasentinel.example.com` with the public name of your platform: the name you gave the assistant, and the name on the TLS certificate. `ds-host` stands for the platform machine's own name.
{% endhint %}

## Symptom

You add the server under its public name, and the sign-in fails at once. In Claude Code:

```
$ claude mcp add --transport http datasentinel https://datasentinel.example.com/mcp
$ claude mcp login datasentinel
Couldn't complete authentication for "datasentinel": SDK auth failed: getaddrinfo ENOTFOUND ds-host
```

The name in the error is not the one you typed. It is usually the platform machine's short name, with no domain. Claude Desktop, Visual Studio Code, Cursor and the other assistants fail the same way. The wording varies: `ENOTFOUND`, *Name or service not known*, *could not resolve host*, or a generic *cannot connect*. The login page never opens.

## Cause

The assistant does not sign in at the address you typed. It first asks the MCP server where to sign in. The server answers with two discovery documents. They name the issuer, the login page and the token endpoints. The assistant then follows those URLs.

The server builds those URLs from one setting, its **public URL**. When the `DS_MCP_PUBLIC_URL` variable is not set, the server uses `https://` followed by the machine's own name. That default is right only when the machine's name is the public name. Behind NAT, a load balancer or a DNS alias, it is not. The server then sends the assistant to `https://ds-host/`, which only the platform machine itself can resolve.

```mermaid
flowchart TD
    A["Assistant"] -->|"1. https://datasentinel.example.com/mcp"| B["MCP server"]
    B -->|"2. sign in at https://ds-host/"| A
    A -->|"3. https://ds-host/authorize"| C["DNS: ENOTFOUND ds-host"]
    linkStyle 0 stroke:#2f9e44,stroke-width:2px
    linkStyle 2 stroke:#e03131,stroke-width:2px
```

## Confirm the diagnosis

Read the discovery documents from any machine:

```bash
curl -s https://datasentinel.example.com/.well-known/oauth-protected-resource/mcp
curl -s https://datasentinel.example.com/.well-known/oauth-authorization-server
```

Look at `resource`, `authorization_servers` and `issuer`. They must use the public name:

```json
{"resource":"https://ds-host/mcp","authorization_servers":["https://ds-host/"], ...}
{"issuer":"https://ds-host/","authorization_endpoint":"https://ds-host/authorize", ...}
```

Here they name `ds-host`, so the diagnosis is confirmed.

On the platform host, the health check reports it too:

```bash
/datasentinel/soft/datasentinel_backend/scripts/mcp_check.sh
```

```
Public URL          : https://ds-host (from machine name)
...
Public name (ds-host)
  Resolves to       : NOTHING - Name or service not known
  Name              : FAILED - 'ds-host' is a bare machine name (from machine name), not a DNS name
  -> The OAuth discovery documents send the assistants to https://ds-host/. Other machines cannot
     resolve it: the sign-in fails with 'getaddrinfo ENOTFOUND ds-host' (Claude Code, Claude Desktop)
     or a DNS error, although the assistant reached the server under its public name.
  -> Set the public name clients connect to (the name on the certificate) and restart:
       sudo systemctl edit datasentinel_mcp
         [Service]
         Environment=DS_MCP_PUBLIC_URL=https://datasentinel.example.com
       sudo systemctl restart datasentinel_mcp
```

The check reads the name on the nginx certificate and puts it in the suggested command.

## Fix

The fix is on the platform host. Nothing changes in the assistant's configuration.

{% stepper %}
{% step %}

#### Set `DS_MCP_PUBLIC_URL`

Its value is the public HTTPS origin: the scheme and the name on the certificate. Add no path. Add a port only if clients connect on one.

Use a systemd drop-in. It survives upgrades and reinstallations:

```bash
sudo systemctl edit datasentinel_mcp
```

In the editor that opens, add:

```ini
[Service]
Environment=DS_MCP_PUBLIC_URL=https://datasentinel.example.com
```

Save, then restart the service:

```bash
sudo systemctl restart datasentinel_mcp
systemctl show datasentinel_mcp -p Environment
```

Do not set the variable with `export` in your shell. The service does not read your shell's environment.
{% endstep %}

{% step %}

#### Check the discovery documents

```bash
curl -s https://datasentinel.example.com/.well-known/oauth-authorization-server
```

`issuer` must now be `https://datasentinel.example.com/`. Run `mcp_check.sh` again: the *Public name* section must report `OK`.
{% endstep %}

{% step %}

#### Sign in again

In Claude Code, run `claude mcp login datasentinel` again, or choose **Authenticate** in `/mcp`. You do not need to add the server again.

Other assistants may keep the failed attempt. If the sign-in still fails, remove the connector and add it again.
{% endstep %}
{% endstepper %}

## Related cases

* **The tool calls fail with *****Hostname mismatch***** instead.** The same missing setting also breaks the server's own calls to the Datasentinel API. See [TLS hostname mismatch on API calls](/manual/ai-connector/troubleshooting/tls-hostname-mismatch.md).
* **The public name is right but private.** A local assistant on the same network resolves it. A cloud assistant such as Claude.ai, ChatGPT or Microsoft Copilot does not. See [MCP servers on a private network](/manual/ai-connector/troubleshooting/private-network-mcp-servers.md).
* **The sign-in loops instead of failing.** The assistant uses another name than the advertised one, for example an IP address or an alias. Register the server under the name in `DS_MCP_PUBLIC_URL`. See [Sign-in problems](/manual/ai-connector/troubleshooting/sign-in-problems.md).

## Check that the server uses the new value

The MCP server logs its settings at every start, in `/datasentinel/log/mcp.log` on the platform host. Each variable has one `environment` line. After the restart, look for the last `DS_MCP_PUBLIC_URL` line:

```bash
grep 'environment DS_MCP_PUBLIC_URL' /datasentinel/log/mcp.log | tail -1
```

It must show the public URL you set, with the time of your restart:

```
2026-10-05 14:02:11 - mcp - INFO - session=- - environment DS_MCP_PUBLIC_URL='https://datasentinel.example.com'
```

`not set (default)` or `empty (default)` means the server still uses the machine name. Then the drop-in was not applied: check it with `systemctl cat datasentinel_mcp`, and restart the service again. An old timestamp means the service was not restarted.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.datasentinel.io/manual/ai-connector/troubleshooting/sign-in-unknown-host.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.