300x100-logo-wedos-wh-1

DNS Management

We offer free DNS records for all domains.

The system allows you to manage primary and secondary domain records.

A primary domain is a domain, for which DNS records are registered in our system. Our system behaves like a primary DNS server for this domain. This is a typical solution.

A secondary domain is a domain, for which we do not register DNS records, but we download them from a different DNS  server through AXFR. The system then behaves like a secondary DNS server. For this domain, only an IP adress is set so that the records can be downloaded from it. The donwload period  is based on the data in the SOA record of the specific domain (REFRESH, RETRY).

Our DNS servers fully support IPv6.

Supported DNS Record Types

Information about DNS record type A to specify an IPv4 address for a given domain name.

The record of this type contains an IP adress of the IPv4 protocol. These adresses are maintained in a form that people can read (however, in the DNS protocol, they are passed as a 32-bit number ).

An example of record setup for a domain and all sub-domains:
Name | TTL | Type | Data
(empty name) | 1800 | A | 81.2.199.30
* | 1800 | A | 81.2.199.30

Information about DNS record type AAA to specify an IPv6 address for a given domain name.

It is an IPv6 IP adress.

An exampe of a record setup for a domain and all sub-domains:
Name | TTL | Type | Data
(empty name) | 1800 | AAAA | 2a02:2b88:1:4::40
* | 1800 | AAAA | 2a02:2b88:1:4::40

Information about DNS record type NS, by which we delegate a subdomain to another DNS server.

This record type is used to report a list of authoritative DNS servers for a specific domain. Server names (ie their domain names), not IP addresses, are listed. If a device wants to connect to an authoritative DNS server of a domain, it first detects all the NS type records for the searched domain on the higher-level DNS server, selects one of them and finds the IP address to it, only then can it communicate via the DNS.

Information about DNS record type NS, by which we delegate a subdomain to another DNS server.

This record type is used to report a list of authoritative DNS servers for a specific domain. Server names (ie their domain names), not IP addresses, are listed. If a device wants to connect to an authoritative DNS server of a domain, it first detects all the NS type records for the searched domain on the higher-level DNS server, selects one of them and finds the IP address to it, only then can it communicate via the DNS.

Information about the MX DNS record type for listing servers to which electronic post for a specific domain should be sent to.

The record specifies the domain name of the mailserver to which mail should be delivered for a domain. Prior to the server name, its priority is listed, which is important if there are several MX records for one name. In this case, the servers are tested according to the increasing priority number (ie the server with the lowest number has the highest priority). If the server does not respond, we try another one. The second and each additional server, if present, serve as backup mailservers.

A Setup Example of 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

To protect against misuse of the domain name against SPAM, it is advisable to set a SPF record.

Detailed description and instructions can be found in the Knowledge Base.

Information about the SRV DNS record type, which servers for listing servers that obtain different services for a specific domain. An example of this can be directing telephone calls with an SIP protocol.

SRV records have many other uses. E.g. Microsoft Windows uses them to find a domain controller and other protocols (XMMP, Kerberos, LDAP, etc.) use them.

An Example of the Setup of a SRV Record:

Name | TTL | Type | Data (priority, importance, port number, host)
_sip._udp.domain.tld | 1800 | SRV | 10 100 5060 sip.domain.tld

Information about the CAA (Certification Authority Authorization) record type that allows the specification of which certification authority can issue a certificate for a domain name.

In other words, if no CAA record is set for the domain, any CA can issue a certificate for the domain without restrictions. Otherwise, only the CA listed in the CAA record may issue a certificate for the domain.

Example:
Name| TTL | Type | Data
domain.tld | 1800 | CAA | 0 issue „letsencrypt.org“

TXT records for different text values (eg, SPF rule writing) are written without quotation marks at the beginning and 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“

Information on the DANE / TLSA type record (DNS-Based Authentication).

The DANE protocol, which introduces a TLSA-type DNS record, was created to increase security when verifying the origin of a server-provided certificate. The DNS TLSA record specifies a service certificate for a combination of data – FQDN, protocol, and port, which together form a record prefix. The TLSA record makes it possible to verify that the certificate has not been altered between the recipient and the sender.

Futher information about the TLSA record type can be found in the Knowledge Base.

Information about the SSHFP record type. The record is used to authenticate the server’s public key after a connection is established using the SSH protocol.

When establishing a connection to the server using the SSH protocol, authentication between the client and the server occurs by the server passing the fingerprint of its public key to the client after the connection is started so that the client can authenticate the server.

The credibility and security of a connection depends on whether the user actually performs the server-provided fingerprint with the expected public key fingerprint of the server.

By introducing the DNS SSHFP record (RFC 4255), a new way of authentication is created for SSH clients by comparing the fingerprint provided by the server against the fingerprint that is stored in the DNS zone of the domain for the FQDN of the server. During the comparison, all SSHFP record parameters must match – the algorithm used to generate the key, the algorithm used to generate the keyprint, and finally the keyprint itself.

Using the SSHFP DNS only makes sense if this record is signed by DNSSEC technology, which ensures that the record cannot be forged.

More information about the SSHFP record type and its setup can be found in the Knowledge Base.

Advanced System Functions

  • complete change history – changes in settings, adding, changing and erasing records
  • adjustable permission/prohibition of downloading zones through AXFR (outgoing AXFR) with the option of listing specific IP adresses that can dowload the zone of the domain
  • importing data when transfering from other DNS servers – downloading through AXFR from a different server, upload of a zone file or manual input
  • copying domains – you can easily create a new domain by copying another (with all records and settings)
  • reverse record management (for customers of our server hosting services)

Coming Soon

  • DNSSEC support for generic domains. (we currently only offer it for CZ and EU domains)

The Most Inexpensive Domains

Register and prolong domains with an accredited registrar, who sells for purchase prices! We belong to the biggest registrars in Czechia. We grow the fastest on the market.

We currently operate 418010 domains!