DNS Management

We offer everyone FREE management of primary and secondary DNS records for domains.

A primary domain is a domain whose DNS records are kept in our system. Our system therefore essentially acts as the primary DNS server for that domain. This is the usual solution.

A secondary domain is a domain whose DNS records are not kept by us; instead we download them from another DNS server via AXFR. For such a domain the system acts as a secondary DNS server. For this domain you only set the IP address from which the records are to be downloaded. The download interval is governed by the values in the SOA record of the relevant domain (REFRESH, RETRY).

Our DNS servers fully support IPv6.

Supported DNS record types

Information about the A-type DNS record used to specify the IPv4 address for a given domain name.
A record of this type contains an IPv4 protocol IP address. These addresses are kept in a human-readable form (although in the DNS protocol they are transmitted as a 32-bit number).
Example of the configuration 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-type DNS record used to specify the IPv6 address for a given domain name.
This is an IPv6 IP address.
Example of the configuration 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-type DNS record used to delegate a subdomain to another DNS server.
This type of record is used to provide the list of authoritative DNS servers for a given domain. Server names (i.e. their domain names) are listed, not IP addresses. When a device wants to connect to the authoritative DNS server of a domain, it first looks up all NS records for the requested domain on a higher-level DNS server, selects one of them and finds its IP address; only then can a communication connection via the DNS protocol take place.

CNAME

Information about the CNAME-type DNS record used to set up an alias for another domain name.
A CNAME record announces that the given domain is an alias of another domain in the sense that they share DNS records (not shared website content, etc.).
Example of a CNAME record configuration:
Name | TTL | Type | Data
www1.domena.tld | 1800 | CNAME | cilovadomena.tld

Information about the MX-type DNS record used to specify the servers to which email for a given domain should be delivered.
The record specifies the domain name of the mail server to which mail for this domain should be delivered. A priority is given before the server name, which matters when there are several MX records for one name. In that case the servers are tried in ascending order of the priority number (i.e. the server with the lowest number has the highest priority). If a server does not respond, we try the next one. The second and every further server, if present, serve as backup mail servers.
Example configuration 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 the domain name against misuse for SPAM it is advisable to set up an SPF record.
A detailed description with a guide can be found in our база знань.

SRV

Information about the SRV-type DNS record used to specify the 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 locate a domain controller, and they are used by other protocols (XMPP, Kerberos, LDAP, etc.).
Example of an SRV record configuration:
Name | TTL | Type | Data (priority, weight, port number, host)
_sip._udp.domena.tld | 1800 | SRV | 10 100 5060 sip.domena.tld

CAA

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

TXT

TXT records for various text values (e.g. writing SPF rules); they are entered without quotation marks at the beginning or the 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 record (DNS-Based Authentication of Named Entities/TLS Association).
The DANE protocol, which introduces the TLSA-type DNS record, was created to increase security when verifying the origin of a certificate provided by a server. A DNS TLSA record specifies the service certificate for a combination of data – FQDN, protocol and port – which together form the record prefix. Using a TLSA record it is therefore possible to verify whether the certificate was altered on the way between the recipient and the sender.
You can find more information about the TLSA-type record in our knowledge base.

SSHFP

Information about the SSHFP-type record. The record is used to verify the fingerprint of the server’s public key 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 the connection is initiated, the server sends the client the fingerprint of its public key so that the client can verify the server’s identity.
The trustworthiness and security of the connection thus depend 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) gives SSH clients a new way of authentication by comparing the fingerprint provided by the server with the fingerprint stored in the domain’s DNS zone for the server’s FQDN. During the comparison 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.
Using DNS SSHFP only makes sense if this record is signed with DNSSEC technology, thereby guaranteeing that the record cannot be spoofed.
You can find more information about the SSHFP record and how to set it up in our knowledge base.

Advanced system features

complete change history – changes in settings, adding, editing and deleting records
configurable allow/deny of zone transfers via AXFR (outgoing AXFR) with the option to specify particular IP addresses that may download the zone of the given domain
data import when migrating from other DNS servers – download via AXFR from another server, uploading a zone file, or manual entry
domain copying – you can easily create a new domain by copying another one (with all records and settings)
management of reverse records (for customers of our server hosting services)

Незабаром

support for DNSSECon generic domains. (For now we offer DNSSEC only for CZ and EU domains)

For more information, see our knowledge base: VEDOS DNS