Stories
Slash Boxes
Comments

SoylentNews is people

Submission Preview

DNS RTT Analysis Reinforced

Rejected submission by upstart at 2021-05-31 10:07:47
News

████ # This file was generated bot-o-matically! Edit at your own risk. ████

DNS RTT analysis reinforced [pages.nic.cz]:

Introduction

Network latency is an important parameter that influences end-user’s experience for most interactive Internet applications, notably web browsing. In virtually all cases, a share of the overall latency budget can be attributed to DNS. Browser vendors invested a lot of effort into minimizing latency, and DNS latency in particular, at the client side [2].

Operators of top-level DNS domains (TLD), such as CZ.NIC, may improve the latency for their clients – DNS resolvers – either by tuning BGP parameters that control anycast routing, or by deploying new DNS servers in regions with suboptimal latency. The latter is often not a trivial undertaking, in terms of both expenses and logistics. Therefore, it has to be carefully planned based on the assessment of actual latency.

In 2019 we presented a method for passive analysis of DNS round-trip time (RTT) [1] based on estimating RTT from the TCP handshake between a DNS client and server. The advantage of this approach is that RTT estimates can be obtained directly from the existing DNS traffic. On the other hand, a potential drawback is that the prevalent transport protocol for DNS is UDP, and TCP is used only for a small fraction of DNS traffic. Moreover, this “natural” TCP traffic may be biased in the sense that the originating resolvers are not a representative sample of all resolvers in terms of RTT. One can expect, for example, to observe TCP connections mostly from DNSSEC-validating resolvers, and worldwide penetration of DNSSEC is still far from homogeneous [4].

One possibility for convincing more resolvers to send DNS queries over TCP is provided by the DNS protocol itself: it is the TC (TrunCation) bit in the DNS header, which is normally used by a DNS server for indicating to the resolver that the response exceeds the maximum size permitted for UDP, and is therefore truncated. An idea of artificially increasing the volume of DNS-over-TCP traffic by replying with random TC responses to a small fraction of DNS queries was proposed as a logical continuation of our study [1], and we first shared it with the CENTR community members interested in doing TCP-based RTT analysis. The same approach was also proposed later by a group of DNS researchers who conducted similar passive RTT analysis for the ccTLD of The Netherlands [3].

Knot DNS [knot-dns.cz] has the optional noudp [knot-dns.cz] module that was originally intended as a simpler alternative to the RRL mechanism [5], which is supported by all major DNS server implementations. We used the noudp module for replying with the TC response to a preset (small) fraction of received UDP queries. In order to be able to do so, we added in cooperation with Knot DNS developers the udp-truncate-rate [knot-dns.cz] configuration parameter. It allows us to set the desired rate of artificial TC responses. For example, udp-truncate-rate: N means every Nth UDP response is truncated.

The work described in this report had the following objectives:

  1. Test and evaluate the activation of the noudp module on a production TLD DNS server with different settings of the udp-truncate-rate parameter.

  2. Analyse the expected increase in TCP traffic but also RTT coverage – a measure indicating how big a part of DNS traffic originated from DNS resolvers with known estimates of RTT.

  3. Determine whether RTT estimates obtained with the aid of the noudp module differ significantly from those obtained from natural DNS-over-TCP traffic.


Original Submission