DNS management

We offer FREE primary and secondary DNS record management for domains to everyone.

The primary domainis the domain for which DNS records are stored in our system. Our system therefore essentially acts as the primary DNS server for this domain. This is the usual solution.

A secondary domainis a domain for which we do not maintain DNS records ourselves, but download them from another DNS server via AXFR. The system therefore acts as a secondary DNS server for this domain. For this domain, only the IP address from which the records are to be downloaded is set. The download period is governed by the data in the SOA record of the relevant domain (REFRESH, RETRY).

Our DNS servers fully supportIPv6.

Supported DNS record types

Information about the A DNS record for specifying the IPv4 address for a given domain name.
This type of record contains the IPv4 protocol IP address. These addresses are maintained in human-readable form (but are transmitted as a 32-bit number in the DNS protocol).
Example of settings for a domain and all subdomains:
Name | TTL | Type | Data
(empty name) | 1800 | A | 81.2.199.30
* | 1800 | A | 81.2.199.30

AAAA

Information about the AAAA DNS record for specifying the IPv6 address for a given domain name.
This is an IPv6 IP address.
Example of settings for a domain and all subdomains:
Name | TTL | Type | Data
(empty name) | 1800 | AAAA | 2a02:2b88:1:4::40
* | 1800 | AAAA | 2a02:2b88:1:4::40

Information about the NS DNS record, which we use to delegate a subdomain to another DNS server.
This type of record is used to communicate a listof authoritative DNS serversfor a given domain. The names of the servers (i.e., their domain names) are listed, not their IP addresses. If a device wants to connect to the authoritative DNS server of a domain, it first finds all NS records for the domain on a higher-level DNS server, selects one of them, and finds its IP address. Only then can communication via the DNS protocol take place.

CNAME

Information about a CNAME DNS record, which is used to set up an alias for another domain name.
A CNAMErecord indicates that a given domain isan alias foranother domain in the sense that they share DNS records (but not website content, etc.).
Example of CNAME record settings:
Name | TTL | Type | Data
www1.domain.tld | 1800 | CNAME | targetdomain.tld

Information about the MX DNS record for specifying the servers to which e-mail for a given domain should be delivered.
The record specifies the domain nameof the mail server to which mail for this domain should be delivered. The server name is preceded bya priority, which is important if there are multiple MX records for a single name. In such a case, the servers are tried in ascending order of priority (i.e., the server with the lowest number has the highest priority). If the server does not respond, we try the next one. The second and each subsequent server, if present, serve asbackup mail servers.
Example settings for our mail servers:
Name | TTL | Type | Data
(empty name) | 1800 | MX | 1 wes1-mx1.wedos.net
(empty name) | 1800 | MX | 1 wes1-mx2.wedos.net
(empty name) | 1800 | MX | 10 wes1-mx-backup.wedos.net

SPF

To protect against misuse of your domain name for SPAM, it is advisable to set up an SPF record
. A detailed description with instructions can be found in the knowledge base.

SRV

Information about the SRV DNS record, which is used to list servers that provide certain services for a given domain. An example is the routing of telephone calls using the SIP protocol.
SRV records have many other uses. For example, Microsoft Windows uses them to find domain controllers, and other protocols (XMMP, Kerberos, LDAP, etc.) also use them.
Example of SRV record settings:
Name | TTL | Type | Data (priority, weight, port number, host)
_sip._udp.domain.tld | 1800 | SRV | 10 100 5060 sip.domain.tld

CAA

Information about the CAA (Certification Authority Authorization) record, which allows you to specify which certification authorities can issue a certificate for a domain name.
In other words, if no CAA record is set for a domain, any CA can issue a certificate for that domain without restriction. Otherwise, only the CA specified in the CAA record can issue a certificate for the domain.
Example:
Name | TTL | Type | Data
domain.tld | 1800 | CAA | 0 issue "letsencrypt.org"

TXT

TXT records for various text values (e.g., SPF rule entries) are written without quotation marks at the beginning or end.
Example:
Name | TTL | Type | Data
(empty name) | 1800 | TXT | "v = spf1 IP4: 64.170.98.0/26 IP6: 2001: 1890: 1112: 1 :: 0/64 -all"

TLSA

Information about the DANE/TLSA (DNS-Based Authentication of Named Entities/TLS Association) record type.
The DANE protocol, which introduces the TLSA DNS record type, was created to increase security when verifying the origin of a certificate provided by a server. The DNS TLSA record specifies the service certificate for a combination of data – FQDN, protocol, and port, which together form the record prefix. Using the TLSA record, it is therefore possible to verify that the certificate has not been altered between the recipient and the sender.
For more information about the TLSA record type, see our knowledge base.

SSHFP

Information about the SSHFP record type. The record is used to verify the server's public key fingerprint after establishing a connection using the SSH protocol.
When establishing a connection to a server using the SSH protocol, authentication between the client and the server takes place in such a way that, after initiating the connection, the server sends the client its public key fingerprint so that the client can verify the server's identity.
The trustworthiness and security of the connection thus depends on whether the user actually compares the fingerprint provided by the server with the expected fingerprint of the server's public key.
The introduction of the DNS SSHFP record (RFC 4255) creates a new method of authentication for SSH clients by comparing the fingerprint provided by the server with the fingerprint stored in the DNS zone of the domain for the server's FQDN. When comparing, all parameters of the SSHFP record must match – the algorithm used to generate the key, the algorithm used to generate the key fingerprint, and finally the key fingerprint itself.
The use of DNS SSHFP only makes sense if this record is signed with DNSSEC technology, thus ensuring that the record cannot be forged.
For more information about the SSHFP record and how to set it up, see our knowledge base.

Advanced system features

Complete history of changes– changes in settings, additions, modifications, and deletions of records
Adjustable permission/prohibitionof zone downloads via AXFR (outgoing AXFR)with the option of specifying specific IP addresses that can download the zone of a given domain
data importwhen switching from other DNS servers – download via AXFR from another server, upload of zone file, or manual entry
domain copying– you can easily create a new domain by copying another one (with all records and settings)
reverse recordmanagement (for customers of our server hosting services)

Coming soon

DNSSECsupportforgeneric domains. (We currently offer DNSSEC only for CZ and EU domains.)

For more information, see the knowledge base:VEDOS DNS