Blog

Categories:

27. 4. 2026

Security Cryptography

Cryptography in name resolution protocols

One of the basic services required for the operation of the Internet is the DNS (Domain Name System) protocol. It is used to resolve domain names and translate them into IP addresses, or to translate IP addresses back into domain names. Without this protocol, today's Internet would not be able to work as we are used to.

Security issues

The basic security issue with the DNS protocol is zero protection. Its content has no confidentiality or integrity protection, nor can it be guaranteed authenticity. In the case of a query, text communication is at least visible directly in the packets, but it does not contain any control over whether the content has been changed. What is worse, the UDP protocol is used for these queries, and here the first-come, first-served rule applies. So if someone responds, say with a spoofed IP address, this response is automatically accepted. This brings a lot of interesting possibilities for attackers and, from a security perspective, a heavy sleep for administrators.

Communication used between different DNS servers

Protocol	Technology	Description
udp/53	DNS/DNSSEC	Standard queries
tcp/53	DNS/DNSSEC	Zone transfer (AXFR/IXFR), queries over TCP, fallback to TCP for large responses
tcp/853	DoT (DNS over TLS)	Standard communication port
tcp/443	DoH (DNS over HTTPS)	Standard communication port
tcp/853	DoQ (DNS over QUIC)	Standard port for communication
udp/5353	mDNS (Multicast DNS)	Standard port for communication, local network only

DNS has been around since 1984, but it was not suitable for all purposes. That is why DNSSEC began to be prepared, the first standards were created in 1997. Apple had different requirements, which created Apple Bonjour around 2000, which was standardized as Multicast DNS about 13 years later. In the meantime, the first implementations of DNSSEC began to occur around 2005. Then DoT, or DNS over TLS, came around 2015. In 2018, the aforementioned group of protocols was expanded to include the DoH protocol, again as an abbreviation for DNS over HTTPS, and as the latest addition, the DoQ protocol appeared in 2023, which this time stands for DNS over QUIC. What do these protocols actually offer us?

DNS

A basic protocol that has been used for more than 40 years. It has no protection of the confidentiality of the transmitted data, no protection of integrity, no protection of authenticity. Its setup and use are easy. Perhaps too easy. From today's perspective, it is considered to be a security problem, because it is impossible to verify whether the information provided has not been forged. Such manipulation can get users from a given organization to servers where the attacker wants them.

DNSSEC

An extension of the original DNS protocol that does not ensure the confidentiality of data, but does address its integrity and authenticity. Digital signatures of records and domains are used for this procedure. Each DNS record that is marked as RRSET (i.e. for each type or name of record) is assigned a digital signature RRSIG. This record contains signatures generated using ZSK (Zone Signing Key). The public key is stored as a DNSKEY record directly in the domain, the private key is available to the authoritative name server. The value parameter for the key then determines whether it is a ZSK (Zone Signing Key = 256) or a KSK (Key Signing Key = 257). Self-signing within the domain can then use two methods:

Continuous signing (suitable for dDNS/Dynamic DNS, domains with frequent changes or some NSEC3 responses), the key must be available to the authoritative name server
Batch signing, where the zone is signed at once. The key can be offline, which increases the security of the domain

The trust of records depends on a demonstrable relationship from a trusted anchor to a specific queried record. A trusted anchor can be imagined as a root certification authority. Root servers are proven using a trusted anchor. The anchor as such is an accessible record, it is a public key allowing to verify the digital signature in the response. The DNSKEY itself on the root domain provides a digital signature of the public key for its verification. Since root servers do not change information very often, the private key can be stored securely. Its leak could threaten the security of the entire Internet. At the same time, root servers hold DS records for subordinate domains, these records are always signed with the private key for this domain. In the case of the root domain, they are signed with the private key corresponding to the trusted anchor. The DS records contain the hash of the KSK (Key Signing Key) of the next-level domain, corresponding to the RRSIG then the digital signature of the KSK using the private key of the root domain. The next-level domain then contains specific representations of the public keys KSK and ZSK, which allow to verify the content. It is better to use a specific example to illustrate.

If a query is made for a specific DOMAIN.TLD domain and its records, DNSSEC will handle the following cryptograms to establish trust. The first is a query to the root servers, which verifies the content of the records on the root servers and the content of the corresponding key material. The cryptograms used to create the records are formed as follows:


    TrustedAnchor = PublicKey_{.root KSK}

    DNSKEY_{.root ZSK} = { PublicKey_{.root ZSK}}

    DNSKEY_{.root KSK} = { PublicKey_{.root KSK}}

    RRSIG_{.root DNSKEY ZSK} = Sign( PrivateKey_.rootKSK, DNSKEY_{.root ZSK})

    RRSIG_{.root DNSKEY KSK} = Sign( PrivateKey_.rootKSK, DNSKEY_{.root KSK})

Therefore, it is possible to verify the compliance of keys on the domain based on the verification of signatures and information about the trusted anchor. In order to continue to the TLD domain, it is necessary to obtain the corresponding records for checking the trustworthiness of the next-level domain.

DS_{TLD KSK} = Hash(PublicKey_{TLD KSK})

    RRSIG_{TLD KSK} = Sign(PrivateKey_{.root ZSK}, DS_{TLD KSK})

Now it is possible to retrieve records from the next-level domain, i.e. the TLD domain.

DS_{DNSKEY_{TLD KSK} = { PublicKey_{TLD KSK} }

    DNSKEY_{TLD ZSK} = { PublicKey_{TLD ZSK} }

    RRSIG_{TLD KSK} = Sign(PrivateKey_{TLD KSK}, DNSKEY_{TLD ZSK})

    RRSIG_{TLD ZSK} = Sign(PrivateKey_{TLD KSK}, DNSKEY_{TLD ZSK})}

Based on this data, it is possible to verify any records available in this domain that have a matching RRSIG. In order to proceed to the DOMAIN.TDL domain, it is necessary to obtain the corresponding trust record again.

DS_{DS_{DOMAIN.TLD KSK} = Hash(PublicKey_{DOMAIN.TLD KSK})

    RRSIG_{DOMAIN.TLD KSK} = Sign(PrivateKey_{TLD ZSK}, DS_{TLD KSK})}

Then it is possible to retrieve records from the next-level domain, i.e. the DOMAIN.TLD domain.

DS_{DNSKEY_{DOMAIN.TLD KSK} = { PublicKey_{DOMAIN.TLD KSK} }

    DNSKEY_{DOMAIN.TLD ZSK} = { PublicKey_{DOMAIN.TLD ZSK} }

    RRSIG_{DOMAIN.TLD KSK} = Sign(PrivateKey_{DOMAIN.TLD KSK}, DNSKEY_{DOMAIN.TLD ZSK})

    RRSIG_{DOMAIN.TLD ZSK} = Sign(PrivateKey_{DOMAIN.TLD KSK}, DNSKEY_{DOMAIN.TLD ZSK})}

Based on this data, it is possible to verify any records available in this domain, which have the corresponding RRSIG, including any records about specific names servers or services, identification of authoritative name servers of text records and other information.

Thanks to the verification of the trust status, it is possible for the domain of a given level, and under certain circumstances even for a specific record, to obtain one of the following ratings:

SECURE, the trust relationship up to the trusted anchor has been verified. Thus, the entire cryptographic signature verification chain is in order and we are not aware of any disruptions.
BOGUS, i.e. a situation where the digital signature does not match the record (RRSIG does not match RRSET), the DNSKEY hash does not match the DS in the higher-order domain record, the signature is missing, the signature is expired, or an algorithm not supported by the validator is used (unknown algorithm).
INSECURE. This situation occurs if the higher-order domain does not have a corresponding DS record for the lower-order domain (the DNSKEY hash containing the KSK is missing). At such a moment, this interruption is considered intentional, i.e. usually the subordinate domain does not support DNSSEC.
INDETERMINATE is a specific situation where the validator does not have the necessary data for verification. For example, a trusted anchor is not available or defined.

DNSSEC currently uses a set of asymmetric algorithms that are not resistant to attack by quantum computers. These algorithms will need to be changed by 2035 at the latest. Since the selection is currently taking place, the outcome is being watched with considerable impatience. Three approaches are considered in the selection, which can be divided into:

Conservative approach, supporting only standardized schemes: ML-DSA (FIPS-204), SHL-DSA (FIPS-205), FN-DSA (FIPS-206), XMSS, LMS.
A proposal with low operational impact, where the mentioned algorithms have not yet been standardized, for these reasons the result of standardization efforts is awaited: MAYO, SNOVA
Specific modes, such as MTL (Merkle Tree Ladder) for SHL-DSA.

At this time, a successor for the current asymmetric cryptography and this selection must be given adequate time. For this reason, it is also possible to classify current algorithms according to IANA registries roughly as follows.

ID	Algorithm name	DNSSEC	Notes
1	RSA/MD5	must not implement	This signature is weak, MD5 is broken
3	DSA/SHA-1	must not implement	This signature is weak, DSA is historical
5	RSA/SHA-1	not recommended	This signature is weak, SHA1 is broken
6	DSA-NSEC3-SHA1	must not implement	This signature is weak, DSA is historical
7	RSASHA1-NSEC3-SHA1	legacy	This signature is weak, SHA1 is broken
8	RSA/SHA-256	recommended	Current until 2035, key length must be longer than 3072b
10	RSA/SHA-512	allowed	Current until 2035, key length must be longer than 3072b
12	GOST R 34.10-2001	optional/rare	Russian standard, currently considered weak
13	ECDSA P-256/SHA-256	recommended	Current until 2035
14	ECDSA P-384/SHA-384	optional	Current until 2035
15	Ed25519	recommended	Current until 2035
16	Ed448	optional	Current until 2035
17	SM2SM3	registry entry	Chinese standards SM2 and SM3, only until 2035. Not supported in our country.
23	GOST R 34.10-2012	registry entry	Updated Russian standard, after a year 2035 insufficient.
252	Indirect Key	special	Indirect Keys
253	Private Algorithm	implementation defined
254	Private OID	implementation defined
255	Reserved	reserved

Also interesting is the view on algorithm support by individual DNS servers. This view will be significantly changed in the case of support for quantum-resistant cryptography, but currently it looks approximately as follows. Unfortunately, since I have no experience with some resolvers, the information may not be completely accurate.

DNSSEC Algorithm	BIND	Unbound	Knot Resolver	PowerDNS Recursor	Microsoft DNS	systemd-resolved	dnsmasq
RSA/SHA2-256 (8)	9.5+	With DNSSEC support	With DNSSEC support	4.0+	Windows Server 2008 R2+	Experimental	Forwarding
RSA/SHA2-512 (10)	9.5+	With DNSSEC support	With DNSSEC support	4.0+	generally	Yes	Yes
ECDSA P-256 (13)	9.9+ (ECSDA support)	1.6+	GnuTLS 3.0+	not specified	Windows Vista/Server 2008+	Yes	Yes
ECDSA P-384 (14)	9.9+	1.6+	GnuTLS 3.4.8+	not specified	CNG	Yes	Yes
Ed25519 915)	OpenSSL/GnuTLS Dependent	1.6.4+	Knot 2.6 and GnuTLS 3.6.0+	4.0.5+ and libsodium	CNG	Limited	Forwarding
Ed448 (16)	Dependent on OpenSSL/GnuTLS	unspecified	GnuTLS 3.6.12+	unspecified	CNG	No	No

DNS over TLS (DoT)

This protocol provides transport protection for queries using the TLS layer. All DNS queries are encapsulated in the specified channel and directed to the corresponding port, communication is not transported using other mechanisms. In the case of using mTLS and an adequate version of the protocol this ensures strong protection of confidentiality and integrity of communication. If the DNSSEC protocol is also used for queries, it is possible to ensure appropriate proof of authenticity. Currently, at least the TLS 1.2 protocol should be used for DNS over TLS (no later than 2030), preferably the TLS 1.3 protocol.

If a client uses DoT to resolve domains on the Internet, it bypasses any internal resolver. This can lead to security problems, including internal name leaks, and also to availability problems regarding addresses that DoT tries to resolve in the wrong places. For this reason, it is advisable to offer your own DoT server and centrally manage DNS communication. The DoT server itself allows you to control access and forward only accepted queries.

DNS over HTTPS (DoH)

Instead of targeting the DNS server, a regular DNS query is processed into a GET or POST HTTP query and then transferred to port 443. In most cases, the rule applies when HTTP/2 is carried out over HTTPS on port tcp/443, but HTTP/3 goes over the QUIC protocol on UDP. Data is currently encrypted at least using TLS 1.2, but is gradually being transitioned to TLS 1.3. In the case of QUIC, cryptographic protection based on DTLS 1.2 or DTLS 1.3 is used. The key material used corresponds to the given channel, i.e. one key material for connection protection, the second key material for DNSSEC (if used).

The actual decision whether to use GET or POST depends on the application server itself, which evaluates DNS responses. The GET method encodes the query in the form of a Base64 URL in the query string, the POST method uses the query in the request body (binary wire format DNS). On the application server responsible for resolving the DNS or DNSSEC requests are evaluated and the entire response is sent back to the requester.

If the client uses DoH to resolve domains on the Internet, it bypasses any internal resolver. This can cause security problems including internal name leaks, as well as accessibility problems regarding addresses that DoH tries to resolve in the wrong places. For this reason, it is necessary to use appropriate system settings, or better yet, your own DoH server. This allows you to control access and forward only accepted queries.

Name	Type	Version
BIND	Authoritative+recursive resolver	9.18+
Knot Resolver	Recursive resolver	3.0.0.+ and doh module
PowerDNS Recursor	Recursive resolver	4.3+ and doh module
Unbound	Recursive resolver	1.9+
dnsdist	Forwarder (DoH frontend)	dnsdist + web server

DNS over QUIC (DoQ)

This protocol provides transport protection for queries using DTLS. All DNS queries are encapsulated in the specified channel and directed to the corresponding port, communication is not transported using other mechanisms. If the DNSSEC protocol is also used for queries, it is possible to provide appropriate proof of authenticity. Currently, only the DTLS 1.3 protocol on udp/853 is supported for establishing a connection. As with DoT, the specified communication takes place directly and, unlike DoH, is not encapsulated in the HTTPS protocol.

If a DoQ client uses the DoQ to resolve domains on the Internet, it bypasses any internal resolver. This can lead to security problems, including internal name leaks, and also to availability problems related to addresses that DoQ tries to resolve in the wrong places. For this reason, it is advisable to offer your own DoQ server and centrally manage DNS communication. The DoQ server allows you to control access and forward only accepted queries.

Name	Type	Version
Knot Resolver	Recursive resolver	3.0.0.+ and doh module
PowerDNS Recursor	Recursive resolver	Experimental, requires dnsdist
Unbound	Recursive resolver	Experimental for now

Multicast DNS (mDNS)

This is a system for local name translation without a central server, the query format is the same as in the case of DNS. It uses the so-called Multicast for communication, a message sent to a specific address, which other machines receive as a form of special communication. For IPv4, this is the address 224.0.0.251 on udp/5353 and for IPv6, the address ff02::fb on udp/5353. All machines on the network supporting this service listen and respond only if their names and services are involved.

This protocol was created for small networks in order to ensure the ability to evaluate names. here is no protection for this protocol, so the first answer applies. For this reason, it is very easy to subvert such communication. It is possible to use Avahi/Bonjour for implementation, but from a security point of view this is a very problematic solution.

DNS is an extremely important protocol. Since its misuse cannot be detected, it is necessary to offer clients the opportunity to verify the records managed by us using appropriately configured digital signature methods. If it is important, it is possible to create resolvers capable of offering additional services according to organizational rules and, most importantly, encrypting the transmitted data using additional layers. However, it is necessary to realize that these layers protect the transport, but only DNSSEC still ensures authenticity.

Reference:

RFC Index
Zdroj: https://www.rfc-editor.org/

Autor článku:

Jan Dušátko

Jan Dušátko has been working with computers and computer security for almost a quarter of a century. In the field of cryptography, he has cooperated with leading experts such as Vlastimil Klíma or Tomáš Rosa. Currently he works as a security consultant, his main focus is on topics related to cryptography, security, e-mail communication and Linux systems.

1. Introductory Provisions

1.1. These General Terms and Conditions are, unless otherwise agreed in writing in the contract, an integral part of all contracts relating to training organised or provided by the trainer, Jan Dušátko, IČ 434 797 66, DIČ 7208253041, with location Pod Harfou 938/58, Praha 9 (next as a „lector“).
1.2. The contracting parties in the general terms and conditions are meant to be the trainer and the ordering party, where the ordering party may also be the mediator of the contractual relationship.
1.3. Issues that are not regulated by these terms and conditions are dealt with according to the Czech Civil Code, i.e. Act No.89/2012 Coll.
1.4. All potential disputes will be resolved according to the law of the Czech Republic.

2. Creation of a contract by signing up for a course

2.1. Application means unilateral action of the client addressed to the trainer through a data box with identification euxesuf, e-mailu with address register@cryptosession.cz or register@cryptosession.info, internet pages cryptosession.cz, cryptosession.info or contact phone +420 602 427 840.
2.2. By submitting the application, the Client agrees with these General Terms and Conditions and declares that he has become acquainted with them.
2.3. The application is deemed to have been received at the time of confirmation (within 2 working days by default) by the trainer or intermediary. This confirmation is sent to the data box or to the contact e-mail.
2.4. The standard time for registration is no later than 14 working days before the educational event, unless otherwise stated. In the case of a natural non-business person, the order must be at least 28 working days before the educational event.
2.5. More than one participant can be registered for one application.
2.6. If there are more than 10 participants from one Client, it is possible to arrange for training at the place of residence of the intermediary or the Client.
2.7. Applications are received and processed in the order in which they have been received by the Provider. The Provider immediately informs the Client of all facts. These are the filling of capacity, too low number of participants, or any other serious reason, such as a lecturer's illness or force majeure. In this case, the Client will be offered a new term or participation in another educational event. In the event that the ordering party does not agree to move or participate in another educational event offered, the provider will refund the participation fee. The lack of participants is notified to the ordering party at least 14 days before the start of the planned term.
2.8. The contract between the provider and the ordering party arises by sending a confirmation from the provider to the ordering party.
2.9. The contract may be changed or cancelled only if the legal prerequisites are met and only in writing.

3. Termination of the contract by cancellation of the application

3.1. The application may be cancelled by the ordering party via e-mail or via a data mailbox.
3.2. The customer has the right to cancel his or her application for the course 14 days before the course takes place without any fees. If the period is shorter, the subsequent change takes place. In the interval of 7-13 days, an administrative fee of 10% is charged, cancellation of participation in a shorter interval than 7 days then a fee of 25%. In case of cancellation of the application or order by the customer, the possibility of the customer's participation in an alternative period without any additional fee is offered. The right to cancel the application expires with the implementation of the ordered training.
3.3. In case of cancellation of the application by the trainer, the ordering party is entitled to a full refund for the unrealized action.
3.4. The ordering party has the right to request an alternative date or an alternative training. In such case, the ordering party will be informed about all open courses. The alternative date cannot be enforced or enforced, it depends on the current availability of the course. If the alternative training is for a lower price, the ordering party will pay the difference. If the alternative training is for a lower price, the trainer will return the difference in the training prices to the ordering party.

4. Price and payment terms

4.1. By sending the application, the ordering party accepts the contract price (hereinafter referred to as the participation fee) indicated for the course.
4.2. In case of multiple participants registered with one application, a discount is possible.
4.3. The participation fee must be paid into the bank account of the company held with the company Komerční banka č. 78-7768770207/0100, IBAN:CZ5301000000787768770207, BIC:KOMBCZPPXXX. When making the payment, a variable symbol must be provided, which is indicated on the invoice sent to the client by the trainer.
4.4. The participation fee includes the provider's costs, including the training materials. The provider is a VAT payer.
4.5. The client is obliged to pay the participation fee within 14 working days of receipt of the invoice, unless otherwise stated by a separate contract.
4.6. If the person enrolled does not attend the training and no other agreement has been made, his or her absence is considered a cancellation application at an interval of less than 7 days, i.e. the trainer is entitled to a reward of 25% of the course price. The overpayment is returned within 14 days to the sender's payment account from which the funds were sent. Payment to another account number is not possible.
4.7. An invoice will be issued by the trainer no later than 5 working days from the beginning of the training, which will be sent by e-mail or data box as agreed.

5. Training conditions

5.1. The trainer is obliged to inform the client 14 days in advance of the location and time of the training, including the start and end dates of the daily programme.
5.2. If the client is not a student of the course, he is obliged to ensure the distribution of this information to the end participants. The trainer is not responsible for failure to comply with these terms and conditions.
5.2. By default, the training takes place from 9 a.m. to 5 p.m. at a predetermined location.
5.3. The trainer can be available from 8 a.m. to 9 a.m. and then from 17 a.m. to 6 p.m. for questions from the participants, according to the current terms and conditions.
5.4. At the end of the training, the certificate of absorption is handed over to the end users.
5.5. At the end of the training, the end users evaluate the trainer's approach and are asked to comment on the evaluation of his presentation, the manner of presentation and the significance of the information provided.

6. Complaints

6.1. If the participant is grossly dissatisfied with the course, the trainer is informed of this information.
6.2. The reasons for dissatisfaction are recorded in the minutes in two copies on the same day. One is handed over to the client and one is held by the trainer.
6.3. A statement on the complaint will be submitted by e-mail within two weeks. A solution will then be agreed within one week.
6.4. The customer's dissatisfaction may be a reason for discontinuing further cooperation, or financial compensation up to the price of the training, after deduction of costs.

7. Copyright of the provided materials

7.1. The training materials provided by the trainer in the course of the training meet the characteristics of a copyrighted work in accordance with Czech Act No 121/2000 Coll.
7.2. None of the training materials or any part thereof may be further processed, reproduced, distributed or used for further presentations or training in any way without the prior written consent of the trainer.

8. Liability

8.1. The trainer does not assume responsibility for any shortcomings in the services of any third party that he uses in the training.
8.2. The trainer does not assume responsibility for injuries, damages and losses incurred by the participants in the training events or caused by the participants. Such costs, caused by the above circumstances, shall be borne exclusively by the participant in the training event.

9. Validity of the Terms

9.1 These General Terms and Conditions shall be valid and effective from 1 October 2024.