idnits 2.17.1 draft-song-yeti-testbed-experience-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 19 instances of too long lines in the document, the longest one being 19 characters in excess of 72. == There are 21 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 27, 2015) is 3041 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1035' is defined on line 815, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 7626 (Obsoleted by RFC 9076) Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force L. Song 3 Internet-Draft S. Kerr 4 Intended status: Informational D. Liu 5 Expires: June 29, 2016 Beijing Internet Institute 6 December 27, 2015 8 Experiences from Root Testbed in the Yeti DNS Project 9 draft-song-yeti-testbed-experience-01 11 Abstract 13 This document reports and discusses issues in DNS root services, 14 based on experiences from the experiments in the Yeti DNS project. 15 These issues include IPv6-only operation, the root DNS server naming 16 scheme, DNSSEC KSK rollover, root server renumbering, multiple root 17 zone signer, and so on. This project was founded in May 2015 and has 18 since built a live root DNS server system testbed with volunteer root 19 server and resolver operations. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on June 29, 2016. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Yeti Testbed and Experiment Setup . . . . . . . . . . . . . . 4 58 3.1. Distribution Master . . . . . . . . . . . . . . . . . . . 6 59 3.1.1. Yeti root zone SOA SERIAL . . . . . . . . . . . . . . 6 60 3.1.2. Timing of Root Zone Fetch . . . . . . . . . . . . . . 7 61 3.1.3. Information Synchronization . . . . . . . . . . . . . 7 62 3.2. Yeti Root Servers . . . . . . . . . . . . . . . . . . . . 8 63 3.3. Yeti Resolvers and Experimental Traffic . . . . . . . . . 10 64 4. Experiments in Yeti Testbed . . . . . . . . . . . . . . . . . 10 65 4.1. Naming Scheme and Glue Issue . . . . . . . . . . . . . . 11 66 4.2. Multiple-Signers with Multi-ZSK . . . . . . . . . . . . . 13 67 4.3. Root Renumbering Issue and Hint File Update . . . . . . . 14 68 4.4. DNS Fragments . . . . . . . . . . . . . . . . . . . . . . 15 69 4.5. The KSK Rollover Experiment in Yeti . . . . . . . . . . . 15 70 5. Other Technical findings and bugs . . . . . . . . . . . . . . 16 71 5.1. IPv6 fragments issue . . . . . . . . . . . . . . . . . . 16 72 5.2. Root compression issue . . . . . . . . . . . . . . . . . 17 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 74 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 78 1. Introduction 80 [RFC1034] says the domain name space is a tree structure. The top 81 level of the tree for the unique identifier system is the DNS root 82 system. It has been operational for 25+ years. It is pivotal to 83 making the current Internet useful. So it is considered somewhat 84 ossified for stability reasons. It is hard to test and implement new 85 ideas evolving to a more advanced level to counter challenges like 86 IPv6-only operation, DNSSEC key/algorithm rollover[RFC4986], scaling 87 issues, and so on. In order to make the test more practical, it is 88 also necessary to involve users' environments which are highly 89 diversified, in order to study the effect of the changes in question. 91 To benefit Internet development as a whole, the Yeti Project was 92 proposed to build a parallel, experimental, live IPv6 DNS root system 93 to discover the limits of DNS root name service and deliver useful 94 technical output. Possible research agenda will be explored on this 95 testbed, covering several aspects (but not limited to): 97 o IPv6-only operation 99 o DNSSEC key rollover 101 o Renumbering issues 103 o Scalability issues 105 o Multiple zone file signers 107 Starting from May 2015, three coordinators began to build this live 108 experimental environment and called for participants. At the time of 109 writing, there are 14 Yeti root servers with 13 operators, and 110 experimental traffic from volunteers, universities, DNS vendors, 111 mirrored traffic non-Yeti traffic, and RIPE Atlas probes. Some 112 experiments have been proposed and have been verified in lab tests. 114 Note that the Yeti DNS project has complete fealty to IANA as the DNS 115 name space manager. All IANA top-level domain names will be 116 precisely expressed in the Yeti DNS system, including all TLD data 117 and meta-data[Root-Zone-Database]. So, the Yeti DNS project is not 118 an "alternative root" in the usual sense of that term. It is 119 expected to inform the IANA community by peer-reviewed science as to 120 future possibilities to consider for the IANA root DNS system. 122 In order to let people know the technical activities in Yeti DNS 123 project, this document reports and discusses issues on root DNS 124 services, based on experiences so far from the experiments in the 125 Yeti DNS project. 127 2. Problem Statement 129 Some problems and policy concerns over the DNS Root Server system 130 stem from centralization from the point of view of DNS content 131 consumers. These include external dependencies and surveillance 132 threats. 134 o External Dependency. Currently, there are 12 DNS Root Server 135 operators for the 13 Root Server letters, with more than 500 136 instances deployed globally. Yet compared to the number of 137 connected devices, AS networks, and recursive DNS servers, the 138 number of root instances is far from sufficient. Connectivity 139 loss between one autonomous network and the IANA root name servers 140 usually results in loss of local service within the local network, 141 even when internal connectivity is perfect 143 o Surveillance risk. Even when one or more root name server anycast 144 instances are deployed locally or in a nearby network, the queries 145 sent to the root servers carry DNS lookup information which 146 enables root operators or other parties to analyze the DNS query 147 traffic. This is a kind of information leakage[RFC7626] which is 148 to some extent not acceptable to some policy makers 150 People are often told that the current root system with 13 root 151 servers is not able to be extended to alleviate the above concerns, 152 because it is limited to 13 by the current DNS protocol[ROOT-FAQ]. 153 To the best of author's knowledge, there is no scientific evidence to 154 support this assertion. It remains an open question. 156 There are some technical issues in the areas of IPv6 and DNSSEC, 157 which were introduced to the DNS root server system after it was 158 created. Renumbering DNS root servers also creates some technical 159 issues. 161 o IPv6-only capability. Currently some DNS servers including root 162 which support both A and AAAA (IPv4 and IPv6) records still do not 163 respond to IPv6 queries. IPv6 introduces larger IP packet MTU 164 (1280 bytes) and a different fragmentation model[RFC2460]. It is 165 not clear whether DNS can survive without IPv4 (in an IPv6-only 166 environment), or what the impact of IPv6-only environment 167 introduces to current DNS operations especially in the DNS root 168 server system. 170 o KSK rollover. Currently, IANA rolls the ZSK every six weeks but 171 the KSK has never been rolled as of writing. Is the 512 bytes DNS 172 packet size limitation still observed? Is RFC5011 [RFC5011] 173 widely supported by resolvers? How about longer key with 174 different encryption algorithm? There are many issues still 175 unknown. 177 o Renumbering issue. It is likely that root operators may change 178 their IP addresses for root servers as well. There is no dynamic 179 update mechanism to inform resolvers and other Internet 180 infrastructure relying on root service of such changes. 182 3. Yeti Testbed and Experiment Setup 184 To use the Yeti testbed operationally, the information that is 185 required for correct root name service is a matching set of the 186 following: 188 o a root "hints file" 190 o the root zone apex NS record set 192 o the root zone's signing key 193 o root zone trust anchor 195 Although Yeti DNS project publishes strictly IANA information for TLD 196 data and meta-data, it is necessary to use a special hint file and 197 replace the apex NS RRset with Yeti authority name servers, which 198 will enable the resolves to find and stick to the Yeti root system. 199 In addition, unless IANA was to help Yeti sign its root zone with a 200 different root set, it is necessary to use a different ZSK and KSK 201 (the DNSSEC trust anchor) in Yeti system. 203 Below is a figure to demonstrate the topology of Yeti and the basic 204 data flow, which consists of the Yeti distribution master, Yeti root 205 server, and Yeti resolver: 207 +------------------------+ 208 | IANA Root Zone via | 209 +-+ F.root-servers.net +--+ 210 | +-----------+------------+ | 211 +-----------+ | | | IANA Root.Zone 212 | Yeti | | | | 213 | Traffic | +--v---+ +---v--+ +-----v+ 214 | Collection| | BII | | WIDE | | TISF | 215 | | | DM | | DM | | DM | 216 +---+----+--+ +------+ +-+----+ +---+--+ 217 ^ ^ | | | 218 | | | | | Yeti Root.Zone 219 | v v v 220 | 221 | +------+ +------+ +------+ 222 +- -+ Yeti | | Yeti | ..... | Yeti | 223 | | Root | | Root | | Root | 224 +---+--+ +---+--+ +--+---+ 225 | | | | 226 pcap ^ ^ ^ TLD lookup 227 | upload | | | 229 | +--------------------------+ 230 +- - - - - - - - - -+ Yeti Resolvers | 231 | (with Yeti Hint) | 232 +--------------------------+ 234 Figure 1. The topology of Yeti testbed 236 3.1. Distribution Master 238 As shown in figure 1, the Yeti Root system takes the IANA root zone 239 and performs minimal changes needed to serve the zone from the Yeti 240 root servers instead of the IANA root servers. In Yeti, this 241 modified root zone is generated by the Yeti Distribution Masters 242 (DM), which provide it to the Yeti root servers. 244 So the generation process is: 246 o DM downloads the latest IANA root zone at a certain time 248 o DM makes modifications to change from the IANA to Yeti root 249 servers 251 o DM signs the new Yeti root zone 253 o DM publishes the new Yeti root zone to Yeti root servers 255 While in principle this could be done by a single DM, Yeti uses a set 256 of three DMs to avoid any sense that the Yeti project is run by a 257 single organization. The three Distribution Masters (DMs) can 258 independently fetch the root zone from IANA, sign it and publish the 259 latest zone data to Yeti root servers. 261 In the same while, these DMs coordinate their work so that the 262 resulting Yeti root zone is always consistent. There are two aspects 263 of coordination between three DMs: timing and information 264 synchronization. 266 3.1.1. Yeti root zone SOA SERIAL 268 Consistency with IANA root zone except the top level apex record is 269 one of most important point for the project. As part of Yeti DM 270 design, the Yeti SOA SERIAL which reflect the changes of yeti root 271 zone is one factor to be considered. 273 Currently IANA SOA SERIAL number for root zone is in the form of 274 YYYYMMDDNN, like 2015111801. In Yeti root system, IANA SOA SERIAL is 275 directly copied in to Yeti SOA SERIAL. So once the IANA root zone 276 has changed with a new SOA SERIAL, a new version of the Yeti root 277 zone is generated with the same SOA SERIAL. 279 There is a case of Yeti DM operation that when a new Yeti root server 280 added, DM operator change the Yeti root zone without change the SOA 281 SERIAL which introduces inconsistency of Yeti root system. To avoid 282 inconsistency, the DMs hold on every changes to Yeti apex record and 283 only new IANA SOA SERIAL will trigger the operation of adding these 284 changes to Yeti root zone. 286 A analysis of IANA convention shows IANA SOA SERIAL change 2 times 287 every day (NN=00, 01). And that since October 2007 the maximum of NN 288 was 03 while 13 times it is observed that the versions with NN=02. 289 So in the worst case, the changes of Yeti apex record is updated into 290 Yeti root zone in less than 12 hours. 292 3.1.2. Timing of Root Zone Fetch 294 Yeti root system operators do not receive notify message from IANA 295 when IANA root zone updates with a new SOA serial number. So Yeti 296 DMs check the root zone periodically. At the time of writing, each 297 Yeti DM checks to see if the IANA root zone has changed hourly, on 298 the following schedule: 300 +-------------+---------+ 301 | DM Operator | Time | 302 +-------------+---------+ 303 | BII | hour+00 | 304 | WIDE | hour+20 | 305 | TISF | hour+40 | 306 +-------------+---------+ 308 Note that Yeti DMs can check IANA root zone more frequently (every 309 minute for example). A test done by Yeti participant shows that the 310 delay of IANA root zone update from the first IANA root server to 311 last one is around 20 minute. Once a Yeti DM fetch the new root 312 zone, it will notify all the Yeti root server with a new SOA serial 313 number. So normally yeti root server will be notified in less than 314 20 minute after new IANA root zone generated. Ideally, if IANA DM 315 notifies the Yeti DMs, Yeti root zone will be updated more timely. 317 3.1.3. Information Synchronization 319 Given three DMs operational in Yeti root system, it is necessary to 320 prevent any inconsistency caused by human mistakes in operation. The 321 straight method is to share the same parameters to produce the Yeti 322 root zone. There parameters includes following set of files: 324 o the list of Yeti root servers, including: 326 * public IPv6 address and host name 328 * IPv6 addresses originating zone transfer 330 * IPv6 addresses to send DNS notify to 332 o the ZSKs used to sign the root 334 o the KSK used to sign the root 336 o the SERIAL when this information is active 338 The theory of operation is that each DM operator runs a Git 339 repository, containing files with the information needed to produce 340 the Yeti root zone. When a change is desired (such as adding a new 341 server or rolling the ZSK), a DM operator updates the local Git 342 repository. A SOA SERIAL in the future is chosen for when the 343 changes become active. The DM operator then pushes the changes to 344 the Git repositories of the other two DM operators. When the SOA 345 SERIAL of the root zone passes the number chosen, then the new 346 version of the information is used. 348 3.2. Yeti Root Servers 350 In Yeti Root system, authoritative servers donated and operated by 351 Yeti volunteers are configured as a slave to the Yeti DM. As the 352 time of writing, there are 14 Yeti root servers distributed around 353 the world. As one of operational research goal, all authoritative 354 servers are required to work in an IPv6-only environment. In 355 addition, until the IANA root, Yeti root server only serve the Yeti 356 root zone, other than root-servers.org zone and .arpa zone. 358 . 3600000 IN NS bii.dns-lab.net 359 bii.dns-lab.net 3600000 IN AAAA 240c:f:1:22::6 360 . 3600000 IN NS yeti-ns.tisf.net 361 yeti-ns.tisf.net 3600000 IN AAAA 2001:559:8000::6 362 . 3600000 IN NS yeti-ns.wide.ad.jp 363 yeti-ns.wide.ad.jp 3600000 IN AAAA 2001:200:1d9::35 364 . 3600000 IN NS yeti-ns.as59715.net 365 yeti-ns.as59715.net 3600000 IN AAAA 2a02:cdc5:9715:0:185:5:203:53 366 . 3600000 IN NS dahu1.yeti.eu.org 367 dahu1.yeti.eu.org 3600000 IN AAAA 2001:4b98:dc2:45:216:3eff:fe4b:8c5b 368 . 3600000 IN NS ns-yeti.bondis.org 369 ns-yeti.bondis.org 3600000 IN AAAA 2a02:2810:0:405::250 370 . 3600000 IN NS yeti-ns.ix.ru 371 yeti-ns.ix.ru 3600000 IN AAAA 2001:6d0:6d06::53 372 . 3600000 IN NS yeti.bofh.priv.at 373 yeti.bofh.priv.at 3600000 IN AAAA 2a01:4f8:161:6106:1::10 374 . 3600000 IN NS yeti.ipv6.ernet.in 375 yeti.ipv6.ernet.in 3600000 IN AAAA 2001:e30:1c1e:1::333 376 . 3600000 IN NS yeti-dns01.dnsworkshop.org 377 yeti-dns01.dnsworkshop.org 3600000 IN AAAA 2001:1608:10:167:32e::53 378 . 3600000 IN NS yeti-ns.conit.co 379 yeti-ns.conit.co 3600000 IN AAAA 2607:ff28:2:10::47:a010 380 . 3600000 IN NS dahu2.yeti.eu.org 381 dahu2.yeti.eu.org 3600000 IN AAAA 2001:67c:217c:6::2 382 . 3600000 IN NS yeti.aquaray.com 383 yeti.aquaray.com 3600000 IN AAAA 2a02:ec0:200::1 384 . 3600000 IN NS yeti-ns.switch.ch 385 yeti-ns.switch.ch 3600000 IN AAAA 2001:620:0:ff::29 387 Figure 2. the Yeti root server in hint file 389 Since Yeti is a scientific research project, it needs to capture DNS 390 traffic sent for later analysis. Today some servers use dnscap, 391 which is a DNS-specific tool to produce pcap files. There are 392 several versions of dnscap floating around; some people use the 393 Verisign one. Since dnscap loses packets in some cases (tested on a 394 Linux kernel), some people use pcapdump. It requires the patch 395 attached to this bug report [dnscap-bug-report] 397 System diversity is also a requirement and observed for current 14 398 Yeti root server. Here are the results of a survey regarding the 399 machine, operation system and DNS software: 401 o Machine: 11 out of 14 root server operator are using a VPS to 402 provide service. 404 o OS: 6 operators use Linux (including Ubuntu, Debian, CentOS). 5 405 operators use FreeBSD and 1 NetBSD. 2 other servers are unknown. 407 o DNS software: 8 our of 14 root server use BIND (varying from 9.9.7 408 to 9.10.3). 4 of them use NSD (4.10 and 4.15). The other 2 409 servers use Knot (2.0.1 and 2.1.0). 411 3.3. Yeti Resolvers and Experimental Traffic 413 In client side of Yeti project, there are DNS resolvers with IPv6 414 support, updated with Yeti "hints" file to use the Yeti root servers 415 instead of the IANA root servers and using Yeti KSK as trust anchor. 416 Since the DNSSEC key of the Yeti root (the KSK) changes often 417 (typically every three months), it is required that resolver operator 418 to configure your resolver compliant to RFC 5011 for automatic 419 update. For Yeti resolver, it is also Interesting to try some 420 mechanism end-system resolvers to signal to a server about their 421 DNSSEC key status, like [I-D.wessels-edns-key-tag] and 422 [I-D.wkumari-dnsop-trust-management] mentioned. 424 Participants and volunteers are expected from individual researchers, 425 labs of universities, companies and institutes, and vendors (for 426 example, the DNS software implementers), developers of CPE devices & 427 IoT devices, and middle box developers who can test their product and 428 connect their own testbed into Yeti testbed. Resolvers donated by 429 Yeti volunteers are required to be configured with Yeti hint file and 430 Yeti DNSSEC KSK. It is required that Yeti resolver can speak both 431 IPv4 and IPv6, given that not all the stub resolver and authoritative 432 servers on the Internet are IPv6 capable. 434 At the time of writing several universities and labs have joined us 435 and contributed certain amount of traffic to Yeti testbed. But it is 436 far from the desired volume of experiment traffic. So Yeti adopts 437 two alternative ways to increase the experimental traffic in the Yeti 438 testbed and check the functionality of Yeti root system. 440 One approach is to mirror the real traffic by off-path method and 441 reply it into Yeti testbed; this is implemented by one of the Yeti 442 root server operators. Another approach is to use some traffic 443 generating tool such as RIPE Atlas probes to generate specific 444 queries against Yeti servers. 446 4. Experiments in Yeti Testbed 448 The main goal of Yeti DNS Project is to act as an experimental 449 network. Experiments will be conducted on this network. In order to 450 make the findings that result from these experiments more rigorous, 451 an experiment protocol is proposed. 453 A Yeti experiment goes through four phases: 455 o Proposal. The first step is to make a proposal. It is discussed 456 and if accepted by the Yeti participants then it can proceed to 457 the next phase. 459 o Lab Test. The next phase is to run a version of the experiment in 460 a controlled environment. The goal is to check for problems such 461 as software crashes or protocol errors that may cause failures on 462 the Yeti network, before putting onto the experimental network. 464 o Yeti Test. The next phase actually running the experiment on the 465 Yeti network. Details of this will depend on the experiment. It 466 must be coordinated with the Yeti participants. 468 o Report of Findings. When completed, a report of the findings of 469 the experiment should be made. It need not be an extensive 470 document. 472 In this section, we are going to introduce some experiments 473 implemented and planned in Yeti project. 475 4.1. Naming Scheme and Glue Issue 477 In root server history, the naming scheme for individual root servers 478 was not fixed. Current IANA Root server adopt [a-m].root-servers.net 479 to represent 13 servers which are labeled with letter from A to M. 480 For example, L root operated by ICANN uses l.root-servers.net to 481 represent their server as NS. One reason behind this naming scheme 482 is that the common suffix 'root-servers.net' can be compressed in DNS 483 message to produce a smaller DNS response. 485 Different from the IANA root naming scheme, the Yeti root system uses 486 separate and normal domains for root servers (shown in figure 2). 487 The motivation of this naming scheme in Yeti is that it intentionally 488 produces larger packets for priming responses. Note that currently, 489 the Yeti root has a priming response which is almost the same size as 490 the IANA root. Yeti has no compression, and has one more name 491 server, but it also has no IPv4 addresses. 493 the change of name scheme not only affects the size of priming 494 response, but also changes the content in additional section of the 495 response.When a resolver bootstraps, it sends a 'NS-for-dot' query to 496 one of the root servers that it knows about, which is called a 497 priming query. It looks like this with the "dig" command: 499 $ dig @a.root-servers.net -t ns +norecurse +edns +nodnssec 500 Normally in the IANA root system the priming response contains the 501 _names_ of the root servers in the answer section and the _addresses_ 502 of the root servers in the additional section. The additional 503 section data is what the resolvers need to actually perform 504 recursion. Shown as below: 506 In priming response : 508 Answer Section: 509 --------------- 510 . 518400 IN NS a.root-servers.net. 511 . 518400 IN NS b.root-servers.net. 512 ... 513 . 518400 IN NS m.root-servers.net. 515 Addtional section: 516 ------------------ 517 a.root-servers.net. 3600000 IN A 198.41.0.4 518 b.root-servers.net. 3600000 IN A 192.228.79.201 519 ... 520 m.root-servers.net. 3600000 IN AAAA 2001:dc3::35 522 In IANA root system, all the root server returns the "a.root- 523 servers.net" addresses in the additional section, because root 524 servers not only answer for root zone, but also answer for "root- 525 servers.net" zone. Note that BIND will not behave like this if it is 526 not configured for the "root-servers.net" zone. NSD and Knot happily 527 return such "glue" in the additional section, whether configured for 528 the "root-servers.net" zone or not. 530 The Yeti root naming scheme uses separate and independent domain for 531 individual root servers. It this case, the priming response from 532 Yeti root servers will only contain the A & AAAA records of that 533 responding server in BIND 9. However it is desired that the Yeti 534 root servers respond to priming queries with the addresses of all 535 Yeti root servers in the additional section. This will make them 536 operate as similar to the IANA root servers as possible. 538 In Yeti root system, there are two approaches adopted in different 539 root servers. One is to patch BIND 9 so that it includes the glue 540 addresses in the additional section. The other one is to add a zone 541 file for each root server and answer for all of them at each Yeti 542 server. That means each Yeti root server would have a small zone 543 file for "bii.dns-lab.net", "yeti-ns.wide.ad.jp", "yeti-ns.tisf.net", 544 and so on. 546 4.2. Multiple-Signers with Multi-ZSK 548 According to the Problem statement of Yeti DNS project, more 549 independent participants and operators of root system is desirable. 550 As the name implies, multi-ZSK mode will introduce different ZSKs 551 sharing a single unique KSK, as opposed to the IANA root system 552 (which uses a single ZSK to sign the root zone). On the condition of 553 good availability and consistency on root system, the Multi-ZSK 554 proposal is designed to give each DM operator enough room to manage 555 their own ZSK, by choosing different ZSK, length, duration, and so 556 on; even the encryption algorithm may vary. 558 According to the Yeti experiment protocol, a lab test was done to 559 verify the concept and validity of Multi-ZSK. The purpose of the 560 test is two-fold: 1) To test whether this proposal can be implemented 561 by current DNS protocol & software (to see if there should be some 562 extra modification to protocol or software), and 2) To demonstrate 563 the impact of Multi-ZSK proposal to the current root system. 565 The experiment is run like this: build a test topology like figure 3, 566 with 2 Root servers and a resolver (BIND 9). The hint file of this 567 test only contains the two DM servers. In the first time slot, Root 568 A is up and Root B is turned off. Let resolver bootstrap from Root A 569 and query a certain signed TLD (or a junk query). For the second 570 time slot, turn off Root A and turn on Root B. Let resolver shift to 571 Root B to look up another TLD (or a junk query). The test result of 572 different time slot is compared to see whether the resolver can 573 validate the DNSSEC signature. 575 +---------------+ +---------------+ 576 | Root A | | Root B | 577 | (ZSK A) | | (ZSK B) | 578 +-------+-------+ +--------+------+ 579 | | 580 --------+------------+--------------+-------- 581 | 582 +---------+----------+ 583 | | 584 | Resolver | 585 +--------------------+ 587 Figure 3. Multi-ZSK lab test topology 589 There are two cases in this test: 591 o Case 1: Assign one ZSK to the smart sign process on each DM, which 592 means the root zone only contain one single ZSK. 594 o Case 2: Assign both ZSK A and ZSK B to the smart sign process on 595 each DM, which means the root zone contains two ZSK. In this 596 case, it is required that Root A and Root B to share their public 597 ZSK to each other before root zone is signed. 599 In case 1 SERVFAIL is received during switching because the resolver 600 can not validate the signature signed by Root B after switching. In 601 case 2 NOERROR is received. It is the actual demonstration of how 602 Multi-ZSK works by adding multiple ZSK to the root zone. As a 603 result, the resolver will cache the key sets instead of single ZSK to 604 validate the data no matter it is signed by Root A or Root B. As 605 follow-up test, Unbound also passed the test with more than 10 DMs 606 and 10 ZSKs. 608 Although more DM and ZSK can be added into the test, adding more ZSKs 609 to root zone enlarges the DNS response size for DNSKEY queries which 610 may be a concern given the limitation of DNS packet size. Current 611 IANA root server operators are inclined to keep the packets size as 612 small as possible. So the number of DM and ZSK will be parameter 613 which is decided based on operation experience. In the current Yeti 614 root testbed, there will be 3 DMs, each with a separate ZSK. 616 4.3. Root Renumbering Issue and Hint File Update 618 With the nearing renumbering of H root Server's IP address, there is 619 a discussion of ways that resolvers can update their hint file. 620 Traditional ways include using FTP protocol by doing a wget and using 621 dig to get the servers' addresses manually. Each way would depend on 622 operators manual operation. As a result, there are many old machines 623 that have not updated their hint files. As a proof, after done 624 renumbering for thirteen years, there is an observation that the "Old 625 J-Root" can still receive DNS query traffic [Renumbering-J-Root]. 627 This experiment proposal aims to find an automatic way for hint-file 628 updating. The already-completed work is a shell script tool which 629 provides the function that update a hint-file in file system 630 automatically with DNSSEC and trust anchor validation. 632 The methodology is straightforward. The tool first queries the NS 633 list for "." domain and queries A and AAAA record for every domain on 634 the NS list. It requires DNSSEC validation for both signature and 635 trust anchor for all the answers. After getting all the answers, the 636 tool compares the new hint file to the old one. If there is a 637 difference, it renames the old one with a time-stamp and replaces the 638 old one with the new one. Otherwise the tool deletes the new hint 639 file and nothing will be changed. 641 Note that in current IANA root system the servers named in the root 642 NS record are not signed due to lack of incentive. So the tool can 643 not fully work in the production network. In Yeti root system some 644 of the names listed in the NS record are signed, which provides a 645 test environment for such a proposal. 647 4.4. DNS Fragments 649 In consideration of new DNS protocol and operation, there is always a 650 hard limit on the DNS packet size. Take Yeti for example: adding 651 more root servers, using the Yeti naming scheme, rolling the KSK, and 652 Multi-ZSK increase the packet size. The fear of large DNS packets 653 mainly stem from two aspects: one is IP-fragments and the other is 654 frequently falling back to TCP. 656 In Yeti testbed, a mechanism is implemented which supports larger DNS 657 packet working around the IP-layer fragment caused by middle box 658 misbehavior (in IPv4) and IPv6 MTU limitation by splitting a single 659 DNS message across multiple UDP datagrams. This DNS fragments 660 mechanism is documented in [I-D.muks-dns-message-fragments] as an 661 experimental IETF draft. 663 4.5. The KSK Rollover Experiment in Yeti 665 The Yeti project provides a good basis to conduct a real-world 666 experiment of a root KSK roll. It is not a perfect analogy to the 667 IANA root because all of the resolvers to the Yeti experiment are 668 "opt-in", and are presumably run by administrators who are interested 669 in the DNS and knowledgeable about it. Still, it can inform the IANA 670 root KSK roll. 672 The IANA root KSK has not been rolled. ICANN put together a design 673 team to analyze the problem and make recommendations. The design 674 team put together a proposal[ICANN-ROOT-ROLL]. Whether this proposal 675 or a different one is adopted, the Yeti project can use it as a basis 676 for an experimental KSK roll. The experiment may not be identical, 677 since the time-lines laid out in the current IANA plan are very long, 678 and the Yeti project would like to conduct the experiment in a 679 shorter time. 681 The Yeti project would also like to conduct an experiment to try 682 rolling the root KSK using a straightforward method, such as a 683 double-DS approach outlined in [RFC6781]. If this ends up being 684 adopted for the IANA root, then only a single Yeti experiment will 685 need to be conducted. 687 < < It's worthwhile to mention that in Yeti testbed there is a lesson 688 when the KSK rollover was implemented at the first time. It lasted 689 for one month and has been held off afterwards. In the first trial, 690 it make old KSK inactive in one week after new key created, and 691 delete it in another week, which is totally unaware of RFC5011. 692 Because the hold-down timer is not correctly set in the server side, 693 some clients(unbound) SERVFAILs (like dig without +cd) because the 694 new key is still in AddPend state when old key is inactive . The 695 lesson from the first KSK trial is that both server and client should 696 compliant to RFC5011 to set proper timer. The question is how can 697 authority server know the resolver is ready for RFC5011？ some 698 drafts [I-D.wessels-edns-key-tag] and 699 [I-D.wkumari-dnsop-trust-management] try to address the problem. >> 701 5. Other Technical findings and bugs 703 Besides the experiments with specific goal and procedures, some 704 unexpected bugs have been reported. It is worthwhile to record them 705 as technical findings from Yeti DNS Project. Hopefully, these 706 experiences can share and help. 708 5.1. IPv6 fragments issue 710 There are two cases in Yeti testbed reported that some Yeti root 711 servers on VPS failed to pull the zone from Distribution Master via 712 AXFR/IXFR. Two facts have been revealed in both client side and 713 server side after trouble shooting. 715 One fact in client side is that some operation system on VPS can not 716 handle IPv6 fragments correctly which causes failure when they are 717 doing AXRF/IXFR in TCP. The bug covers several OS and one VM 718 platform (listed below). 720 +-----------------------+-----------------+ 721 | OS | VM | 722 +-----------------------+-----------------+ 723 | NetBSD 6.1 and 7.0RC1 | VMware ESXI 5.5 | 724 | FreeBSD10.0 | | 725 | Debian 3.2 | | 726 +-----------------------+-----------------+ 728 Another fact is from server side in which one TCP segment of AXRF/ 729 IXFR is fragmented in IP layer resulting in two fragmented packets. 730 This weird behavior has been documented IETF 731 draft[I-D.andrews-tcp-and-ipv6-use-minmtu]. It reports a situation 732 that some implementations of TCP running over IPv6 neglect to check 733 the IPV6_USE_MIN_MTU value when performing MSS negotiation and when 734 constructing a TCP segment. It will cause TCP MSS option set to 1440 735 bytes, but IP layer will limit the packet less than 1280 bytes and 736 fragment the packets which finally result two fragmented packets. 738 The latter is not a technical error though, but it will cause the 739 error in the former fact which deserves much attention in IPv6 740 operation when VPS is already widely used. 742 5.2. Root compression issue 744 [RFC1035]specifies DNS massage compression scheme which allows a 745 domain name in a message to be represented as either: 1) a sequence 746 of labels ending in a zero octet, 2) a pointer, 3) or a sequence of 747 labels ending with a pointer. It is designed to save more room of 748 DNS packet. 750 However in Yeti testbed, it is found that Knot 2.0 server compresses 751 even the root. It means in a DNS message the name of root (a zero 752 octet) is replaced by a pointer of 2 octets. As well, it is legal 753 but breaks some tools (Go DNS lib in this bug report) which does not 754 expect such name compression for root. Now both Knot and Go DNS lib 755 have fixed that bug. 757 6. IANA Considerations 759 This document requires no action from the IANA. 761 7. Acknowledgements 763 The editors fully acknowledge that this memo is based on works and 764 discussions with Paul Vixie and Akira Kato in Yeti DNS 765 project[Yeti-DNS-Project]. Thanks to Antonio Prado and Stephane 766 Bortzmeyer who helped to review the document and give many editing 767 suggestions 769 Acknowledgment to all the Yeti participant and volunteers who make 770 the experimental testbed become functional and workable. 772 8. References 774 [dnscap-bug-report] 775 Bortzmeyer, S., "pcaputils: IWBN to have an option to run 776 a program after file rotation in pcapdump", 2009, 777 . 780 [I-D.andrews-tcp-and-ipv6-use-minmtu] 781 Andrews, M., "TCP Fails To Respect IPV6_USE_MIN_MTU", 782 draft-andrews-tcp-and-ipv6-use-minmtu-04 (work in 783 progress), October 2015. 785 [I-D.muks-dns-message-fragments] 786 Sivaraman, M., Kerr, S., and D. Song, "DNS message 787 fragments", draft-muks-dns-message-fragments-00 (work in 788 progress), July 2015. 790 [I-D.wessels-edns-key-tag] 791 Wessels, D., "The EDNS Key Tag Option", draft-wessels- 792 edns-key-tag-00 (work in progress), July 2015. 794 [I-D.wkumari-dnsop-trust-management] 795 Kumari, W., Huston, G., Hunt, E., and R. Arends, 796 "Signalling of DNS Security (DNSSEC) Trust Anchors", 797 draft-wkumari-dnsop-trust-management-01 (work in 798 progress), October 2015. 800 [ICANN-ROOT-ROLL] 801 "Root Zone KSK Rollover Plan", 2015, 802 . 805 [Renumbering-J-Root] 806 Wessels, D., "Thirteen Years of "Old J-Root"", 2015, 807 . 811 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 812 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 813 . 815 [RFC1035] Mockapetris, P., "Domain names - implementation and 816 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 817 November 1987, . 819 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 820 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 821 December 1998, . 823 [RFC4986] Eland, H., Mundy, R., Crocker, S., and S. Krishnaswamy, 824 "Requirements Related to DNS Security (DNSSEC) Trust 825 Anchor Rollover", RFC 4986, DOI 10.17487/RFC4986, August 826 2007, . 828 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 829 Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, 830 September 2007, . 832 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 833 Operational Practices, Version 2", RFC 6781, 834 DOI 10.17487/RFC6781, December 2012, 835 . 837 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 838 DOI 10.17487/RFC7626, August 2015, 839 . 841 [ROOT-FAQ] 842 Karrenberg, D., "DNS Root Name Server FAQ", 2007, 843 . 845 [Root-Zone-Database] 846 "Root Zone Database", 847 . 849 [Yeti-DNS-Project] 850 "Website of Yeti DNS Project", . 852 Authors' Addresses 854 Linjian Song 855 Beijing Internet Institute 856 2508 Room, 25th Floor, Tower A, Time Fortune 857 Beijing 100028 858 P. R. China 860 Email: songlinjian@gmail.com 861 URI: http://www.biigroup.com/ 863 Shane Kerr 864 Beijing Internet Institute 865 2/F, Building 5, No.58 Jinghai Road, BDA 866 Beijing 100176 867 CN 869 Email: shane@biigroup.cn 870 URI: http://www.biigroup.com/ 871 Dong Liu 872 Beijing Internet Institute 873 2508 Room, 25th Floor, Tower A, Time Fortune 874 Beijing 100028 875 P. R. China 877 Email: dliu@biigroup.com 878 URI: http://www.biigroup.com/