DNS Server

Enter the 6-digit code you see in your authenticator app.
0 zones
# Zone Type DNSSEC Status Serial Expiry Last Modified
0 zones
technitium.com

                                                
technitium.com

                                                
technitium.com

                                                
Installed Apps
Total Apps: 0
Name Description
Section User Permissions Group Permissions
Enable to allow Single Sign-On (SSO) with OpenID Connect (OIDC).
The OpenID Connect (OIDC) Authority URL.
The OpenID Connect (OIDC) Client ID.
The OpenID Connect (OIDC) Client Secret.
The OpenID Connect (OIDC) metadata discovery URL to be used instead of the default one. Configure this option only if the Single Sign-On (SSO) provider uses a different discovery URL.
Scope Name
Enter the scopes to be sent to the Single Sign-On (SSO) provider. The scopes openid and profile are mandatory and will be automatically added if missing. Add the scope email if you want to use email address as the username for all SSO users that sign up for an account.
Enable to allow automatically provisioning of user accounts for new users signing in via Single Sign-On (SSO). Keep this option disabled if you do not expect new SSO users to sign up.
Enable to allow a new user to sign up via Single Sign-On (SSO) only when the user is a member of at least one Remote Group that is mapped to a Local Group in the Group Map option below. This option allows SSO administrators to restrict SSO users to control who can sign up and get access based on their group memberships.
Remote Group Local Group
Map Remote Groups at Single Sign-On (SSO) provider to Local Groups for both new and existing users signed up via Single Sign-On (SSO). A SSO user's group membership will be automatically synced to the mapped Local Groups each time they log in. If your SSO provider does not include group membership claim by default then you will have to add groups or roles scope in the Scopes option above as required by the SSO provider.

Note! The Single Sign-On (SSO) uses /sso/callback as the callback path. Thus, your SSO Redirect URI for this DNS Server should be http://localhost:5380/sso/callback which needs to be configure with the SSO provider.

Note! Single Sign-On (SSO) will be enabled only when all of the required parameters are configured correctly. If SSO does not work for any reason, check the Logs section on the panel and search for related error logs.

Note! When a Single Sign-On (SSO) user signs up with the DNS Server, an account for the user is created which uses the email address as the username. If email address is not available, the preferred username is used instead. If you do not wish to use email address as the username, you can remove the email scope from the Scopes option above.

Note! The Single Sign-On (SSO) user's Display Name and Username are managed via the SSO provider and they are automatically synced each time a user logs in.

Note! When Group Map is configured, the Single Sign-On (SSO) user's group membership cannot be managed locally and any group membership changes must be configured at the SSO provider itself. SSO users need to relogin so that any group membership changes made at SSO provider are applied to their user accounts. The Group Map thus allows managing user access centrally via the SSO provider. Keep the Group Map empty if group membership management for SSO users is required to be managed via the DNS Server itself.

Note! The Web Service will be automatically restarted to apply these changes thus there is no need to restart the DNS Server manually.

Note! When using a reverse proxy with the Web Service, you need to add X-Forwarded-Proto and X-Forwarded-Host headers to proxy request to allow the Web Service to correctly form the SSO Redirect URI. If the reverse proxy is setup to use a path prefix then make sure to add the X-Forwarded-Prefix header to proxy request too. These headers will be read only if the reverse proxy IP address is configured to be allowed in the Reverse Proxy Addresses option in Settings > Web Service section. For example, if you are using nginx as the reverse proxy with a path prefix of /dns, then you should add the following headers: proxy_set_header X-Forwarded-Proto $scheme;, proxy_set_header X-Forwarded-Host $host;, proxy_set_header X-Forwarded-Prefix /dns;, and proxy_redirect / /dns/;

Note! Domain names in all of the URLs configured above will be resolved by the DNS Server internally only. Thus, make sure that the DNS Server is able to resolve the domain name in the URL. Adding hosts file entries in the host OS will not work.

Warning! All URLs configured above must use https URL scheme for production environments. Using http URL scheme is not secure and should be used only for testing purposes.

Warning! Any DNS related failure may cause Single Sign-On (SSO) to fail to work making it impossible for SSO users to log in to fix the DNS issue due to circular dependency. Thus, it is recommended to maintain a local administrator user account for such scenarios.

Enable to allow users from an LDAP directory (Active Directory, OpenLDAP, etc.) to log in using their directory credentials.
Domain name or IP address of the LDAP server.
(default 389 for plain LDAP/StartTLS; default 636 for LDAPS)
The Distinguished Name (DN) or User Principal Name (UPN) of a service account used to search the directory. Leave empty for anonymous bind.
The password for the above bind service account.
The base Distinguished Name (DN) used to search for user entries.
The LDAP search filter used to find the user. Use {0} as a placeholder for the username. Use default (sAMAccountName={0}) for Active Directory and (uid={0}) for OpenLDAP. Use (userPrincipalName={0}) if usernames in the directory are stored under 'userPrincipalName' attribute.
The user attribute listing group memberships. Use default memberOf for Active Directory.
Enable to allow automatically provisioning of user accounts for new users signing in via LDAP. Keep this option disabled if you do not expect new LDAP users to sign up.
Enable to allow a new user to sign up via LDAP only when the user is a member of at least one Remote Group that is mapped to a Local Group in the Group Map option below. This option allows LDAP administrators to restrict LDAP users to control who can sign up and get access based on their group memberships.
Remote Group (CN) Local Group
Map Remote Groups (CN) at directory service to Local Groups for both new and existing users signed up via LDAP. A LDAP user's group membership will be automatically synced to the mapped Local Groups each time they log in.

Note! LDAP authentication works by binding to the directory with a service account to locate the user, then re-binding as that user to validate credentials.

Note! LDAP authentication will work only when all of the required parameters are configured correctly. If it does not work for any reason, check the Logs section on the panel and search for related error logs.

Note! A LDAP user wont be able to sign up if it's username is already taken by an existing local or SSO user.

Note! LDAP users can enable Two-Factor Authentication (2FA) such that credentials are validated by the directory service while 2FA is validated by the DNS Server on each login.

Note! The LDAP user's Display Name is managed via the directory service and it is automatically synced each time a user logs in.

Note! When Group Map is configured, the LDAP user's group membership cannot be managed locally and any group membership changes must be configured at the directory service itself. LDAP users need to relogin so that any group membership changes made at the directory service are applied to their user accounts. The Group Map thus allows managing user access centrally via the directory service. Keep the Group Map empty if group membership management for LDAP users is required to be managed via the DNS Server itself.

Note! The domain name used for LDAP Server above will be resolved by the DNS Server internally only. Thus, make sure that the DNS Server is able to resolve the configured domain name. Adding hosts file entries in the host OS will not work.

Warning! The Ignore SSL Certificate Errors option is not secure and should be used only for testing purposes.

Warning! Any DNS related failure may cause LDAP authentication to fail to work making it impossible for LDAP users to log in to fix the DNS issue due to circular dependency. Thus, it is recommended to maintain a local administrator user account for such scenarios.

Node Name IP Address URL Type State Up Since Last Seen Last Synced
20171012
Technitium Logo

Technitium DNS Server

Version

Server up since

Copyright (C) 2026 Shreyas Zare (shreyas@technitium.com)
This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions.

Source code available under GNU General Public License v3.0 on  GitHub

What's New?

Read the change log to know what's new in this release.

API Documentation

The DNS Server HTTP API allows any 3rd party app or script to configure the DNS Server. The HTTP API is used by this web console and thus all the actions that this web console does can be performed via the API. Read the HTTP API documentation for complete details.

Help Topics

Read the latest online help topics which contains the DNS Server user manual and covers frequently asked questions.

Support

For support, send an email to support@technitium.com.

Follow @technitium@mastodon.social on Mastodon.
Checkout Technitium Blog.

Join /r/technitium on Reddit.

Donate

Make a contribution to Technitium and help making new software, updates, and features possible.

Donate Now!