This is a short summary for the people who are interested but not able to attend the workshop. The audio record on youtube
(1) The first speech was given by Paul Vixie(from 0:15:00 of the youtube record). The slides link
He is one of the founder of Yeti. He introduced his 10+ Years of Responsible Alternate Rootism, as a track of the time that lead to Yeti. He admitted he has been in the center of constrovercy of DNS and root system for years.
Paul Vixie’s presentation talked about the evolution of his involvement with the root system, starting from the concept& his experience of root system, anycasting, his idea of alternative rootism, ultimately leading up to the Yeti project. He insisted many times that to keep one namespace is not necessary to keep one set of root servers where the root zone is served. He proposed IANA to sign another zone parallelely to helped get IDN, DNSSEC and IPv6 out there faster. But it is viewed controversial and failed.
As note writer observed, it is true that due to DNSSEC encryption technology, the signed data can be authenticated by the data itself not necessary to the authority who publish it. So in Yeti project today, Paul and people with same interest turn to use its own key to sign the zone for a testbed instead asking IANA to sign the alternative zone.
(2)The second speaker is Keith Mitchell who is the president of DNS OARC. He was invited to speak about AS112 Operations. (from 00:48:00) The slides link
There was some discussion about researching using DNAME in the same way that AS112 uses DNAME, by adding a DNAME delegation representing a name from the special-use registry. While an interesting idea, there seemed to be consensus that this was slightly risky because it would actually be changing the contents of the root zone.
(3) Davey Song is one of the founders of the Yeti project, and he presented the current status of the Yeti DNS Project（from 01:09:00) The slides link
There is a informational draft song-yeti-testbed-experience to record the Yeti experience gained from the project which covers the most part of Davey’s presentation.
There was a lot of discussion about the DM model and the details of the process. This is documented and the source code published on the GitHub repository, but people still wanted clarification.
There was discussion about using Yeti in an IPv4 scenario.There was discussion about the duration of the project - 3 years.
The limitations of emergency fixes in the root zone was discussed. This is not much worse in the Yeti system than in the IANA root. If it becomes a problem, we can synchronize much more closely with the IANA root.
(4) Shane Kerr works for BII, one of the Yeti DM. He presented the current experiment situation in the Yeti project and activities in BII lab(from 02:32：00). The slides link
He first introduced in detail how Yeti DM model works and followed with a Multi-ZKS experiment for Yeti DM model. He then briefed us the KSK plan by ICANN and what is expected in Yeti testbed. There are also other related topics about hint management and DNS layer fragment.
One point of concern was with updating hints files, since that could allow an attacker (or operational mistake) to prevent a system from ever using the real root servers. DNSSEC validation makes this less scary. One suspicion was that broken resolvers were the problem, and that no amount of improving working resolvers would help much.
Regarding the DNS layer fragment, there is a joint document by BII and ISC. https://tools.ietf.org/html/draft-muks-dns-message-fragments-00
A proposal to investigate TCP-only root service was made, and a discussion around that.
(5) Stephane Boryzmeyer is a DNS expert, and has been actively involved with the Yeti project since its inception. He presented his observations from monitoring Yeti and introduction of various monitoring tool for Yeti (from 03:13:00). The slides link
Currently, Yeti testbed is operational, but lack of monitoring and fine-grained measurement for the dos quality of Yeti. Apparently, dig from time to time is not enough. From Stephane’s presentation he encouraged us try to use automatic tools for Yeti monitoring even thought it’s not for production usage.
He briefed us the state of art of DNS monitoring tools from his experience, varying from Icinga, Check_dig, Zonemaster, DNSmon, DNSviz and finally the RIPE Atlas. He suggested us using those tools for improving the system monitoring & measurement going forward.For example, providing a status page on the Yeti web page that could be used to update monitoring results.
(6) Dmitrii Kovalenko is a DNS operator at MSK-IX, and was an early Yeti participant. Recently MSK-IX set up a mirroring of resolver traffic, and Dmitrii was asked to present this(from 03：50). The slides link
There was discussion of possible additional work that might be interesting on the resolver query duplication.
Also noted that we should make it clearer how to submit a trouble ticket, as there were some issues during Dmitrii’s work that should have been tracked.
There was a discussion of investigating ways to shutdown the project. Certainly we need to encourage resolver operators to join the mailing lists.
We discussed future workshop plans. Currently there are none.
We discussed the timeline of experiments. Currently there is none, but this will be proposed soon.
Everyone should configure all of their resolvers to use Yeti! :)