shane-kerr / ymmv Goto Github PK

We should have the option to use PcapParser to get an input stream where we can also compare TCP delivered queries and so on.

Suggestion from Kato:

Prior to the release of your program to tap a DNS query to one of
IANA root servers and to send its copy to some/many/all of Yeti
servers, I would suggest to "mark" the copied DNS queries so that
we can identify the copied traffic and "natural" traffic.

When we are to test dynamic features (I mean timing issue is involved
such as a proposed experiment where significant number of Yeti Root
servers intentionally become blackholes to see the performance
degradation to the end customers), the copied packets don't comply
with usual timeout characteristics implemented in every DNS server
(full resolver) implementation.

One of the ways to mark the packet is to change the EDNS packet size
negotiation parameter to a strange number such as 3852 (this is just a
random but it rarely be seen in regular traffic and should not induce
fragments).

This should be easy enough to do.

The output should be something appealing to an administrator. Ideally we want something nice logged to the screen, maybe with curses, as well as some CSV output that can be used for graph/chart generation.

We should have pre-built binaries available for people who do not wish to build the software themselves.

Currently handling multiple interfaces is a bit clunky, since we use pcap2ymmv and there is no support for processing multiple pcap streams.

We should periodically update the NS RRset for the root zone, and then look up the AAAA records for each name server there. We can even use the TTL and do this "properly".

A long running version of ymmv grew to several hundred megabytes. Probably there is a memory leak!

We need a way to tell the tool to e-mail results periodically if desired.

There are two ways to do this:

1. The "normal" Unix way, asking the local MTA to send the mail, usually by invoking /usr/sbin/sendmail.
2. Directly via SMTP.

This issue is for the sendmail version. Here's a StackOverflow tip:

https://stackoverflow.com/questions/35520804/how-to-send-emails-in-golang-without-any-smtp-server/35521846#35521846

We should implement something like SRTT for server selection.

In addition to the EDNS0 buffer size mentioned in issue #1, we can also set the source port on lookups to something predictable.

Unfortunately with the Go DNS library we are using this is non-trivial. It is of course possible, but since it is hard we will give it a low priority.

With the code now we generate the queries based on the replies. We can do better, and actually remember which queries are sent and then map them to replies. This will mean we need to keep a map of queries, assign replies to them, handle replies without queries, and also handle timeouts for queries that do not get replies.

Probably we can do this by only using (source IP, source port, destination IP, query ID) - at least at the 99.9% level which is good enough for our research purposes.

Something for pcap2ymmv to check for... answers arriving before query. This can happen with pcap!

We need an option to partially hide the QNAME. In this case, we use a random label that we expect to get the same answer as the IANA servers.

So, for example if a user was querying for WWW.EXAMPLE.ORG we would send a query for random + .YMMV.EXAMPLE.ORG.

This is only a partial solution since the TLD is still in the query, but we need that for the comparison.

We need a way to tell the tool to e-mail results periodically if desired.

There are two ways to do this:

1. The "normal" Unix way, asking the local MTA to send the mail, usually by invoking /usr/sbin/sendmail.
2. Directly via SMTP.

This issue is for the SMTP version. We can use the Go language package for this:

https://golang.org/pkg/net/smtp/

It requires a bit more work in terms of setting up a hostname/port plus username/authentication, plus handling failures, and so on. But it may be useful to users in some cases.