Private workspace DNS: names your team can use without publishing them.

A teammate asks for the reporting server’s address. Someone pastes a private IP into chat. A month later the server moves, and three scripts still use the old address.

Private workspace DNS (Domain Name System) gives team resources maintained internal names through an approved resolver arrangement. It tells a client which address to use; it does not create a route, grant access or authenticate the application. Assign owners to the record and resolver, then verify that the supported client can resolve the name and reach only the resources it is permitted to use.

How a private DNS lookup reaches an authorized resource

Consider the illustrative name reports.team.example.com, under a domain an organization would control in a real deployment. In this hypothetical workspace it points to 10.74.2.18. A supported client needs the approved workspace resolver arrangement to obtain the private answer, then an authorized route to reach the server.

The DNS record does the naming job. It does not carry the application request, create the route or log the user into the reporting application. A correct answer followed by a timeout is therefore possible without a broken DNS record.

Fibmesh private workspace DNS belongs within Networks. It is a workspace-scoped naming capability, separate from a public authoritative DNS service or a public recursive resolver product. Verify the supported resolver behavior for the endpoint and deployed release before relying on it.

Separate authoritative records from client resolvers

The authoritative service holds the intended record for a zone. A resolver helps a client obtain an answer and may cache it. These are different roles even when an implementation combines them. RFC 1034 describes the DNS naming, server and caching model.

Assign an owner to the name and the target. Someone should know when reports changes from a test server to a production server, and whether that change also requires new permissions or a different gateway route.

Give the resolver arrangement an owner too. On supported clients, workspace-specific queries should reach the intended private naming path. Ordinary internet names need their appropriate resolution path. An application that uses its own resolver may behave differently from the operating system’s resolver; test the application people actually use.

Define split DNS and workspace resolver selection

A company can present private answers inside an approved context and different answers outside it. RFC 9499 describes split DNS as differing answers depending on the query context. Routing only selected names to a workspace resolver is a related client configuration concern, and the two should not be assumed identical.

Write the intended behavior explicitly: which suffix is private, which resolver should answer it, and what an outside client should observe. An outside lookup might receive no record, while an inside lookup gets a private address. That is a naming design to verify, not a promise that the hostname is impossible to discover.

Keep network authorization in place even if somebody already knows the address. A name hidden from public DNS does not make a listening service safe, revoke a credential or prevent an approved but compromised device from attempting access.

Choose an internal namespace without .local conflicts

Choose the supported workspace naming scheme and document it. In a custom-domain design, use a domain you control. Avoid casually inventing suffixes that collide with existing uses.

For example, .local has special multicast DNS behavior described in RFC 6762. It should not be treated as a convenient generic suffix for every routed private workspace. Link-local discovery and workspace DNS are separate mechanisms.

Use full names in operational notes and automation where possible. A short name such as reports can depend on a search suffix, which may change when someone switches workspace or network. Fibmesh currently uses one active workspace profile; do not plan simultaneous name resolution for several workspace profiles without verified support.

A private name still needs a valid application identity

An HTTPS client checks the name it connects to against the server’s certificate. DNS returning a private address does not satisfy that check. Plan an appropriate certificate and trust arrangement for the name, using the supported application configuration.

Do not teach people to ignore certificate errors because the service is internal. Also retain individual application accounts and permissions. The DNS answer identifies a network destination, while application authentication and authorization govern the work allowed there.

Update DNS records and routes together

When the hypothetical server moves from 10.74.2.18 to 10.74.3.18, update its approved path and record as a coordinated change. Caches can retain a previous answer until its applicable lifetime expires; changing the authoritative record is not evidence every client has changed instantly.

Test the normal client resolver, the real application and an outside-workspace lookup. Check allowed and denied access separately. Then remove the obsolete route or record through the supported operating process.

A useful private name is a maintained relationship between a role, an answer and an authorized destination. Put those owners in the same worksheet and you will spend less time deciding whether the next failure belongs to naming, networking or the application.