Chose your color

Frequently visited

Frequently asked questions

  • I am looking for a domain name registrant. Where can I look it up?

    The Whois is an easy-to-use tool for checking the availability of a .nl domain name. If the domain name is already taken, you can see who has registered it.

    On the page looking up a domain name you will find more information about what a domain name is, how the Whois works and how the privacy of personal data is protected. Alternatively, you can go straight to look for a domain name via the Whois.

  • I would like to transfer my domain name to another registrar. What is the procedure?

    To get your domain name transferred, you need the token (unique ID number) for your domain name. Your existing registrar has the token and is obliged to give it to you within five days, if you ask for it. The procedure for changing your registrar is described on the page transferring your domain name.

  • The details registered about me/my company are incorrect or out of date. How can I get them updated?

    To update the contact details associated with your domain name, you need to contact your registrar. Read more about updating contact details.

  • Why is my domain name in quarantine?

    When a domain name is cancelled, we aren't told the reason, so we can't tell you. You'll need to ask your registrar. The advantage of quarantine is that, if a name's cancelled by mistake, you can always get it back.

    One common reason is that the contract between you and your registrar says you've got to renew the registration every year. If you haven't set up automatic renewal and you don't renew manually, the registration will expire.

  • Ik heb een klacht over mijn provider/registrar. Kan ik daarvoor bij SIDN terecht?

    Wanneer je een klacht hebt over of een geschil met je registrar dan zijn er verschillende mogelijkheden om tot een oplossing te komen. Hierover lees je meer op pagina klacht over registrar. SIDN heeft geen formele klachtenprocedure voor het behandelen van een klacht over jouw registrar.

  • What conditions do I have to meet as a registrar?

    Would you like to be able to register domain names for customers or for your own organisation by dealing directly with SIDN? If so, you can become a .nl registrar. Read more about the conditions and how to apply for registrar status on the page becoming a registrar.

More frequently asked questions

New DNS over QUIC protocol makes encrypted DNS traffic faster and more efficient

First major implementations in progress

  • Thursday 25 August 2022

This spring, DNS over QUIC (DoQ) was standardised in RFC 9250. The new protocol makes the benefits of native QUIC – rapid response times and high efficiency – directly available for encrypted DNS transport. It therefore represents a major improvement on DNS over HTTPS/2 and DNS over TLS, both of which rely on TCP. DoQ is also slightly more efficient than UDP-based DNS over HTTPS/3.

This article explains the working and benefits of the QUIC transport protocol, which was previously used exclusively as part of HTTP/3. The article concludes with a discussion of the new native DNS on QUIC mapping.

TCP/2

QUIC was developed to replace TCP, particularly for use on HTTP(S) connections. It resolves the problem of a network connection being (temporarily) blocked if a TCP packet is lost or delayed in transit. Unlike UDP packets, TCP packets are always delivered to the endpoint intact and in sequence, so there is a truly continuous data connection.

That is achieved by use of the 'sliding window' mechanism in TCP. The sender sends ahead a certain number of bytes, starting from the final byte (number) whose receipt has been acknowledged. The recipient places the incoming data in a buffer and issues an ACK message to the sender confirming receipt and stating the last byte (number) not received. In the event of packet loss, any as yet unacknowledged segment is resent at the end of window (i.e. once the maximum permitted number of unacknowledged bytes has been reached), so that the recipient can complete the incoming data stream.

Visualization of the TCP sliding window mechanism.

Multiplexing and HOL blocking

Although that mechanism works well with a single data stream, it is problematic with a multiplex connection, where multiple combined data streams are sent via a single connection. With a multiplex connection, if the recipient is waiting for a particular segment of a particular data stream, segments of the other data streams continue arriving. The processing of data in all the streams, including any unaffected by the packet loss, then has to be paused until the relevant segment is resent, because, at the TCP level, the recipient doesn't know which data stream an individual segment belongs to (an inherent consequence of separation of the transport layer and application layer). The preceding segments are simply indistinguishable elements of the same window as the lost packet.

The multiplexing of separate data streams is one of the main features of HTTP/2, the current HTTP standard. The protocol is therefore susceptible to the 'head-of-line (HOL) blocking' problem described above. Multiplexing was actually introduced to prevent HOL blocking at the application level, in HTTP/1.1. When a browser opens a web page, it retrieves not only the HTML code but also numerous images and JavaScript files. Prior to the advent of multiplexing, once the maximum permitted number of outbound connections had been reached, the browser had to wait until new downloads could be started. Multiplexing, where all the connections to a given server are combined, was therefore introduced to make the HTTP protocol faster and more efficient. However, the effect has not been to eliminate the HOL blocking problem altogether. Although the problem's impact has been greatly reduced, it has merely been shifted from the application layer to the transport layer.

Shared TLS handshake

Like the Google-devised HTTP/2, QUIC involves the transport-layer re-separation of the data streams that HTTP/2 combines on the application level. QUIC is not a standalone protocol that operates alongside TCP and UDP, but uses UDP for data packet transport. In addition, while enabling multiple data streams to be combined to form a single connection (instead of being treated as individual data streams, as in the past), QUIC requires only a single TLS handshake for all the combined data streams. QUIC therefore builds on the speed gains of multiplexing in HTTP/2 (SPDY) by further boosting the speed of HTTP connections.

Broadly speaking, if you combine the HTTP/2 protocol and TLS version 1.3 with QUIC, you get HTTP/3, the version of HTTP that is now taking off.

DNS over QUIC

Although QUIC was developed with HTTP(S) in mind, it is a generic protocol that can be used by wide variety of application protocols. The standardisation of DNS over QUIC (DoQ) in RFC 9250 is an example of that.

DoQ has the same basic purpose as DNS over HTTPS (DoH) and DNS over TLS (DoT), both of which are now rapidly gaining ground: to safeguard the confidentiality of DNS traffic. DoQ's key benefit is that it restores much of the speed that DNS traffic had prior to the introduction of DNSSEC and fully UDP-based transport encryption. Another important feature is the inclusion of source address verification in the QUIC handshake procedure. The original DNS over UDP had no such feature, and was therefore vulnerable to, for example, IP address spoofing and amplification attacks.

Native mapping

DoQ can be used for various forms of secure DNS communication: between stub and recursive resolver, between recursive resolver and authoritative name server, and for zone transfers between name servers. You may well be thinking that, in principle, DoQ is no different to DoH over HTTP/3 (now supported in Android 11). However, the RFC's authors argue that "lean" native mapping directly from DNS to QUIC is justified on efficiency grounds. Protection of the end user's privacy is another reason for excluding HTTP.

Like HTTP(S) over QUIC (HTTP/3), DoQ involves individual DNS queries being sent via separate data streams over an established TLS connection. That prevents the HOL blocking of DNS responses that is liable to occur with DoT/DoH. The protocol uses the familiar UDP port number 853 (as does DoT, which uses only the TCP input). The mapping of DNS on QUIC, as described in the RFC, is otherwise straightforward.

Implementations

As a new technology, DoQ is not yet widely supported by DNS and browser software. Nevertheless, we are already seeing implementations. In that context, AdGuard [1, 2] has been particularly proactive. DoQ was incorporated into their public DNS service, their Home resolver and their apps/plugins eighteen months ago. However, while DoQ was under development, AdGuard had DoT enabled by default, with the result that only 1 per cent of inbound traffic to their servers made use of DoQ. Now that standardisation is complete, the firm intends to soon enable DoQ by default. Unfortunately, AdGuard's use of the Go programming language for most of its software means that their implementations are unlikely to be widely used by others.

Another DNS server that already supports DoQ is NextDNS. NextDNS's name servers have recently been upgraded to the definitive DoQ standard.

According to Senior PowerDNS Engineer Peter van Dijk, the first step will be to incorporate (outbound) DoQ in the dnsdist load balancer [1, 2], which operates in front of the PowerDNS server software in most cases. That will happen this autumn as part of Google's Summer of Code (GSoC 2022). Inbound DoQ for dnsdist and Recursor support will be enabled later. Where Recursor support is concerned, the developers are dependent on implementation in the nghttp/ngtcp2 library [1, 2], which will soon replace the h2o library [1, 2] on the PowerDNS servers, now that the latter library is no longer being actively updated. Although the library change is necessary, it has the drawback that everyone in the DNS world will be using the same nghttp/ngtcp2 library. Because clients communicate directly with the library software, the lack of diversity will amplify the repercussions of any leak that might occur.

Meanwhile, NLnet Labs are currently working to add DoQ support to the Unbound resolver.