DNS Management

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

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

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

Our DNS servers fully support IPv6.

Supported DNS record types

Information about the DNS Type A record for specifying the IPv4 address for the domain name.
This type of record contains the IPv4 IP address. These addresses are maintained in human-readable form (but are passed as a 32-bit number in DNS).
Example of a settings entry 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

DNS record information of type AAAA to specify the IPv6 address for the domain name.
This is the IPv6 address.
Example of a settings entry 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 a DNS record of type NS that delegates a subdomain to another DNS server.
This record type is used to communicate a list of authoritative DNS servers for the domain. The names of the servers (i.e., their domain names) are provided, not IP addresses. If a device wants to connect to an authoritative DNS server for a domain, it first looks up all the NS-type records for the domain it is looking for on the higher-level DNS server, selects one of them, and finds the IP address for it before the DNS communication connection can take place.

CNAME

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

Information about the DNS record of type MX to indicate the servers to which mail for the domain is to be delivered.
The record indicates the domain name of the mailserver to which mail for the domain is to be delivered. The server name is preceded by a priority, which is significant if there are multiple MX records for a single name. In this case, the servers are tried in order of increasing priority number (i.e., the server with the lowest number has the highest priority). If a server does not respond, we try another one. The second and every other server, if present, serve as backup mailservers.
Example settings for our mailservers:
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 your domain name against SPAM abuse, it is advisable to set up an SPF record
For a detailed description with instructions, please refer to the knowledge base.

SRV

Information about an SRV DNS record that is used to list the servers that provide certain services for the domain. An example is SIP phone call routing.
SRV records have many other uses. For example, Microsoft Windows uses it to find a domain controller and other protocols (XMMP, Kerberos, LDAP, etc.) use it.
Example of an SRV record setup:
Name | TTL | Type | Data (priority, weight, port number, host)
_sip._udp.domena.tld | 1800 | SRV | 10 100 5060 sip.domena.tld

CAA

Information about a Certification Authority Authorization (CAA) record that allows you to specify which CAs 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 the domain without restriction. Otherwise, only the CA listed 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 entries for different text values (e.g. SPF rule entries), they are written without quotes at the beginning and at 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

For information about the DNS-Based Authentication of Named Entities/TLS Association (DANE/TLSA) record.
The DANE protocol, which introduces a DNS TLSA record, was created to improve security when verifying the origin of a server-provided certificate. A DNS TLSA record specifies a service certificate for a combination of data - FQDN, protocol, and port - that together comprise the record prefix. Thus, the TLSA record can be used to verify that the certificate has not been tampered with on the path between the sender and the receiver.
For more information about the TLSA record, see our knowledge base.

SSHFP

Information about the SSHFP record type. The record is used to authenticate the server's public key fingerprint after a connection is established using the SSH protocol.
When a connection is established with a server using the SSH protocol, authentication occurs between the client and the server so that the server passes its public key fingerprint to the client after the connection is established so that the client can verify the server's identity.
Thus, the trustworthiness and security of the connection depends on the user actually comparing the server-provided fingerprint with the server's expected public key fingerprint.
The introduction of the DNS SSHFP record(RFC 4255) creates a new way for SSH clients to authenticate by comparing the server-provided fingerprint against the fingerprint that is stored in the DNS domain zone 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.
Using DNS SSHFP only makes sense if the record is signed with DNSSEC technology, thus guaranteeing that the record cannot be spoofed.
For more information on SSHFP records and how to set them up, see our knowledge base.

Advanced system features

complete history of changes - changes in settings, adding, changing and deleting records
Configurable enable/disable zone downloads via AXFR (outbound AXFR) with the ability to specify specific IP addresses that can download a zone of a given domain
importing data when switching from other DNS servers - downloading via AXFR from another server, uploading a zone file or manual entry
copying domains - you can easily create a new domain by copying another domain (with all records and settings)
reverse log management (for customers of our server hosting services)

Forthcoming

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

For more information, please visit the VEDOS DNS knowledge base.