DIINER Exerimental Documentation

This page summarizes how to carry out experiments on the DIINER testbed.

Goals

Our goal is to provide a realistic environment in which DNS servers can be tested against either live traffic or against replayed traces. In both cases, the traffic will be real-world data. Optionally, traffic can be mutated on input (to test other scenarios), and the output can ve validated to see how it compares to a reference.

In addition to using real traffic (live or stored), our architecture also allows for artificial traffic from tools such as dnsperf.

Scenarios

Live Traffic

DIINER Test for Experiments with Live Traffic

The above figure shows how experiments with live traffic are handled: a fraction of the traffic is duplicated and diverted to the experimental node. That traffic can be optionally modified by first passing through a query mutator (see below about mutation).

Since the traffic derived from live traffic, it should reflect all the noise and variation seen in normal DNS traffic.

Trace Replay

DIINER Test for Experiments with Trace Replay

The above figure shows how experiments with trace replay are handled: stored traffic is replayed from a replay engine.

As with live traffic, experimenters can opt to pre-mutate the traffic to explore other scenarios (see below about mutation).

We have several different trace replay engines.

  • LDplayer can replay saved packet captures. It handles TCP queries and approximates the RTT to the sender.
  • tcpreplay (tbd?)
  • dnsperf: artificial DNS traffic

Traffic Mutation (TBD)

We plan to support traffic multation for both live and replayed traffic.

Potential mutations:

  • change the transport protocol of the query (from UDP to TCP, TLS, or HTTP)
  • emulate the correct response, round-trip-time, and address affinity of replayed TCP-based queries (or other queries over connection-oriented transport protocols)
  • enable DNSSEC’s DO bit for all queries
  • mix in additional traffic, such as a DDoS attack traffic, covert traffic, or packets with errors

Currently we support mutating traffic in offline traces for replay.

In the past we have demonstrated DNSSEC and UDP->TCP and UDP->TLS conversions for replayed traces on prior instantiations of our trace replay system. We plan to add them to our testbed as future work (please contact us if this capability is important to your use-case).

Output Validation

Our development roadmap plans includes plans for generating a output diagnostic tools allowing researchers to compare the differences in results from a production system, and to validate the resulting data and packets.

Using the testbed

Please see our testbed documentation.