DNS Management

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 the 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 SIP protocl.

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, as 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.