TeamDrive Name Server (TDNS)¶
The TeamDrive Name Server (TDNS) is used to manage a distributed network of TeamDrive Registration Servers and Services. For this purpose TDNS stores directories of hashed and encrypted information about the Registration Servers, Providers, Domains, Services/Endpoints and Users in a TeamDrive network.
Primarily, TDNS is used to do the following:
- Ensure that usernames and registration emails are network-wide unique.
- Allow users to be directed to the appropriate Registration Server or External Authentication Service on login.
- Enable invitations to Spaces can be directed to the Registration Server associated with a selected user.
- Manage the creation of Providers on Registration Servers.
- Register and reserve email domains belonging to customers for their exclusive usage in TeamDrive.
- Control which systems (endpoints) are able to access the Registration Server API’s.
With one exception, TDNS may only be accessed from a Registration Server. In particular, callers must identify themselves as a Provider (a Registration Server Tenant), and the information they are able to access or modify depends on this identity. The identity is determined using the IP address of the caller and the “Checksum Key” of the Provider. The Checksum Key is generated by TDNS when a Provider is added to a Registration Server. See TDNS and adding Providers for details.
Besides the Registration Server, an External Authentication Service must contact TDNS in order to complete initial setup. In order to confirm the configuration of an External Authentication Service the service must make a lookup using the service name to load and check the identity of service’s Registration Server and Provider. Once this has been done, no further calls to TDNS are required.
To enable access to the global TeamDrive instance of TDNS you must allow
outgoing access to the HTTPS port 443 for domain tdns.teamdrive.net.
User data privacy on TDNS¶
User data are not stored in plain text on TDNS. All usernames and email addresses are hashed by the Registration Servers before upload to TDNS.
This ensures that, although Registration Servers are a component of a greater TeamDrive Network, user data (username and email address) remains private and limited to the scope of the Registration Server with which the user is registered.
In addition lookups of this data is only possible from Registration Servers that has identified themselves by IP address and Checksum Key as described above. This means it is not possible to call TDNS directly to determine if a given username or email address is in use by the TeamDrive network, even if the hashing method is known.
General Workflow Between Client, Registration Server and TDNS¶
The TeamDrive Client/App requires access to the TDNS user directory during login and authentication and when sending an invitation to a Space.
In general the client proceeds by first contacting its preferred or default Registration Server, providing either a username or email address.
The Registration Server will first make a local lookup of the user. If the user is not found, the Registration Server will perform a TDNS lookup. TDNS returns the name of the Registration Server and the Provider Code associated with the user. The Registration Server redirects the TeamDrive Client to new Registration Server.
When redirected, the TeamDrive Client contacts the new Registration Server and sends the original request to this server.
If a user is not already registered on a TeamDrive Registration Server, then the domain name of the email address is used to perform the redirect as required. Domain names can be registered for this purpose as described here: Domains and Services.
Blacklisting and Whitelisting Registration Servers¶
As an administrator of a Registration Server you are able to determine which of the Registration Servers in the TeamDrive network you trust, and which can be contacted by the your users. This is done using a Blacklist or a Whitelist (see Manage Servers for more details). This information is stored on TDNS.
Users are restricted from sending and receiving Space invitations to and from users on a distrusted Registration Server.
By default all Registration Servers are trusted, and a Blacklist is used to specify the Registration Servers by name that are not trusted.
This can be changed to Whitelisting whereby the default is then that all Registration Servers are distrusted, and you have to explicitly place all trusted Registration Servers, by name, on a Whitelist.