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

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.

Details

Creating an account

To get an account, send mail to diiner-ops at ant.isi.edu. (We plan to deploy a web portal to automate this in the future.)

To use the system, please include tehse details in your mail to diiner-ops:

A few-word project name
A short description of what experiments you expect to be performing
Any requirements you have for your experiment
How long you think you will need on the platform to complete your work
What [DNS datasets] you will need access too

Please include a copy of the public part of your ssh key so we can set up secure, key-based remote access.

Accessing the infrastructure

To access the device, after obtaining an account you may:

log into b1-brr.b.isi.edu
Run your (modified) DNS server on the standard DNS port (53)

Starting Traffic

Live traffic

on b1-brr: /usr/local/bin/brr-route decoder
on e1-brr: /usr/local/bin/brr-live start
on e1-brr: /usr/local/bin/brr-resolver <knot named>

[xxx: should add web interface to control access]

Replay traffic

on e1-brr: /usr/local/bin/brr-live stop
on b1-brr: /usr/local/bin/brr-route replay
on e1-brr: /usr/local/bin/brr-resolver <knot named>
run replay tool of choice