[Yeti DNS Discuss] Current status of Yeti DNS Project

Davey Song(宋林健) ljsong at biigroup.cn
Tue Sep 20 09:44:28 UTC 2016


Hi folks, 

 

I would like to brief what we (coordinators) are working on recently, since
it has been quite a while we do not have public meeting with Yeti
participants. It is expected to make Yeti activities more public and
transparent. Yeti need the support and participation from the community.

 

1)       Traffic mirroring & software development

Since the beginning of this year, it has been a concerns that there is not
enough traffic on Yeti testbed. Once 25 servers had been collected as early
planned, we start outreaching and calling for more traffic to Yeti testbed,
outage-tolerant live real traffic. But we gained very little increase in the
first 6 months. So we decide to mirror traffic to Yeti as a better and
promising approach. There is some work we have done and we are doing. 

a)         DNSDIST :
http://yeti-dns.org/yeti/blog/2016/06/15/Mirroring-traffic-using-dnsdist.htm
l 

b)         Yeti Many Mirror Verifier(YmmV):
https://github.com/shane-kerr/ymmv 

c)         Defragment IPv6 DNS packets (used by YmmV):
http://www.dnsv6lab.net/2016/09/06/DNS-pcap-fragments/ 

Now Shane are leading the YmmV software development, currently focusing on
issues like performance comparison, privacy consideration and tagging the
mirror traffic from the real one. 

 

**It will be great appreciated if you can persuade some resolver operators
to mirror traffic to us. If anyone who are interested with this software
work, please contact us.**

 

2)       Yeti data analysis.

Since the beginning of the project, BII is responsible to collect traffic
from each root server. Now it reaches more than 1T pcap data. We realized
that we need have fine-grained analysis and study on the Yeti traffic in
order to deliver more useful information. For example, as the experiments
goes on, we observe the packet size continuously increase. Although there is
no obvious error report from mailing list, it is not confident to say there
is no impact for root services during some experiment, especially regarding
IPv6 fragmentations, DNS Retries and TCP-fallbacks. 

 

Since we do not have experiences in DNS traffic analysis(at lease for BII
lab), this work make slow progress. Just recently we are begin to use the
open source platform Entrada (http://entrada.sidnlabs.nl/ ) as the tool for
Yeti traffic analysis. I try the QuickStart VM versionof Entrada, I think it
can fulfill our goal to deliver some useful information. 

 

**The current plan is that we are going to call for volunteers for Yeti data
analysis, the people who are interested and have experience dealing with DNS
traffic data** 

 

3)       Yeti experience draft

We update the draft to 03 version
(https://github.com/BII-Lab/yeti-testbed-experience ), and plan to send mail
to Independent Submissions Editor and pursuit IETF publication through
independent submission. I once hesitated for quite a while because I thought
the draft is not done until our Yeti project is finished, but my colleague
encourage me to go ahead and there are lots of useful experiences which are
worthwhile being published.

 

4)       Manage unstable Yeti server

There is a ticket dealing with unstable yeti servers. The basic idea is to
dynamically remove and add the server according to the server’s health. The
current plan is that if a server is down/unstable for more than 5 days, it
will be put into inactive status automatically which means it will not be
included in the yeti root zone and hint file temporally . When it recovered
and continuously work for 30 days. It will become active again. 

 

5)       RIPE atlas & Yeti monitoring page

Yeti monitoring page relies on RIPE Atlas tool called DomainMon. In order to
keep monitoring 25 servers every hour, it consumes a large amount of
credits. Another issue with DomainMon is we cannot choose health probes.
There are probes with ipv6-capable tag but not work probably. After
discussion with RIPE atlas people, we finally got some help on credit for
the Yeti monitoring and possibility that we can have a interface to choose
right probes. Cheers! **Thanks for Kaveh and other RIPE colleagues.**

 

6)       Yeti workshop in Seoul

Now we secure the time and meeting room for the workshop. A full agenda will
be published in advance.

Date:      2016-11-12 (Saturday before IETF 97)

Time:      13:00-18:00 
        Location: Conrad Seoul, Studio 7-6F (IETF 97 venue)

**Now we are calling for participants and also speakers in DNS and Root
field as we did last workshop in Yokohama.*

Best regards,

Davey 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yeti-dns.org/pipermail/discuss/attachments/20160920/aa01846b/attachment.html>


More information about the discuss mailing list