idnits 2.17.00 (12 Aug 2021) /tmp/idnits50570/draft-muks-dnsop-message-fragments-00.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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 177: '... MUST maintain a timeout when waitin...' RFC 2119 keyword, line 179: '...essage fragments MUST be able to reass...' RFC 2119 keyword, line 182: '... The client MAY save information abo...' RFC 2119 keyword, line 183: '...If saved, this information MUST have a...' RFC 2119 keyword, line 192: '...sent, the server MUST NOT use DNS mess...' (9 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (20 April 2022) is 30 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 353 -- Looks like a reference, but probably isn't: '255' on line 353 == Unused Reference: 'RFC1123' is defined on line 538, but no explicit reference was found in the text == Outdated reference: draft-ietf-dnsop-cookies has been published as RFC 7873 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Sivaraman 3 Internet-Draft Internet Systems Consortium 4 Intended status: Experimental S. Kerr 5 Expires: 22 October 2022 L. Song 6 H. Yu 7 Beijing Internet Institute 8 20 April 2022 10 DNS message fragments 11 draft-muks-dnsop-message-fragments-00 13 Abstract 15 This document describes a method to transmit DNS messages over 16 multiple UDP datagrams by fragmenting them at the application layer. 17 The objective is to allow authoriative servers to successfully reply 18 to DNS queries via UDP using multiple smaller datagrams, where larger 19 datagrams may not pass through the network successfully. 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 https://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 22 October 2022. 38 Copyright Notice 40 Copyright (c) 2022 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 (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Revised BSD License text as 49 described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Revised BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. DNS Message Fragmentation Method . . . . . . . . . . . . . . 4 58 2.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 4 59 2.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 5 60 2.3. Other Notes . . . . . . . . . . . . . . . . . . . . . . . 6 61 3. The ALLOW-FRAGMENTS EDNS(0) Option . . . . . . . . . . . . . 7 62 3.1. Wire Format . . . . . . . . . . . . . . . . . . . . . . . 7 63 3.2. Option Fields . . . . . . . . . . . . . . . . . . . . . . 7 64 3.2.1. Maximum Fragment Size . . . . . . . . . . . . . . . . 7 65 3.3. Presentation Format . . . . . . . . . . . . . . . . . . . 7 66 4. The FRAGMENT EDNS(0) Option . . . . . . . . . . . . . . . . . 8 67 4.1. Wire Format . . . . . . . . . . . . . . . . . . . . . . . 8 68 4.2. Option Fields . . . . . . . . . . . . . . . . . . . . . . 8 69 4.2.1. Fragment Identifier . . . . . . . . . . . . . . . . . 8 70 4.2.2. Fragment Count . . . . . . . . . . . . . . . . . . . 8 71 4.3. Presentation Format . . . . . . . . . . . . . . . . . . . 8 72 5. Network Considerations . . . . . . . . . . . . . . . . . . . 8 73 5.1. Background . . . . . . . . . . . . . . . . . . . . . . . 8 74 5.2. Implementation Requirements . . . . . . . . . . . . . . . 9 75 6. Open Issues and Discussion . . . . . . . . . . . . . . . . . 9 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 78 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 Appendix A. Change History (to be removed before publication) . 13 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 83 1. Introduction 85 1.1. Background 87 [RFC1035] describes how DNS messages are to be transmitted over UDP. 88 A DNS query message is transmitted using one UDP datagram from client 89 to server, and a corresponding DNS reply message is transmitted using 90 one UDP datagram from server to client. 92 The upper limit on the size of a DNS message that can be transmitted 93 thus depends on the maximum size of the UDP datagram that can be 94 transmitted successfully from the sender to the receiver. Typically 95 any size limit only matters for DNS replies, as DNS queries are 96 usually small. 98 As a UDP datagram is transmitted in a single IP, in theory the size 99 of a UDP datagram (including various lower internet layer headers) 100 can be as large as 64 KiB. But practically, if the datagram size 101 exceeds the path MTU, then the datagram will either be fragmented at 102 the IP layer, or worse dropped, by a forwarder. In the case of IPv6, 103 DNS packets are fragmented by the sender only. If a packet's size 104 exceeds the path MTU, it must be fragmented. Except for the first 105 fragmented package, other fragmented packages do not include a UDP or 106 TCP header, and do not know the port number of the IP package, and 107 the subsequent IP slice pack is filtered off. A Packet Too Big (PTB) 108 ICMP message will be received by sender without any clue to the 109 sender to reply again with a smaller sized message, due to the 110 stateless feature of DNS. In addition, IP-level fragmentation caused 111 by large DNS response packet will introduce risk of cache poisoning 112 [Fragment-Poisonous], in which the attacker can circumvent some 113 defense mechanisms (like port, IP, and query randomization 114 [RFC5452]). 116 As a result, a practical DNS payload size limitation is necessary. 117 [RFC1035] limited DNS message UDP datagram lengths to a maximum of 118 512 bytes. Although EDNS(0) [RFC6891] allows an initiator to 119 advertise the capability of receiving lager packets (up to 4096 120 bytes), it leads to fragmentation because practically most packets 121 are limited to 1500 byte size due to host Ethernet interfaces, or 122 1280 byte size due to minimum IPv6 MTU in the IPv6 stack [RFC3542]. 124 According to DNS specifications [RFC1035], if the DNS response 125 message can not fit within the packet's size limit, the response is 126 truncated and the initiator will have to use TCP as a fallback to re- 127 query to receive large response. However, not to mention the high 128 setup cost introduced by TCP due to additional roundtrips, some 129 firewalls and middle boxes even block TCP/53 which cause no responses 130 to be received as well. It becomes a significant issue when the DNS 131 response size inevitably increases with DNSSEC deployment. 133 In this memo, DNS message fragmentation attempts to work around 134 middle box misbehavior by splitting a single DNS message across 135 multiple UDP datagrams. Note that to avoid DNS amplification and 136 reflection attacks, DNS cookies [I-D.ietf-dnsop-cookies] is a 137 mandatory requirement when using DNS message fragments. 139 1.2. Motivation 141 It is not a new topic regarding large DNS packets(>512B) issue 142 [I-D.ietf-dnsop-respsize], starting from introduction of IPv6, 143 EDNS(0) [SAC016], and DNSSEC deployment [SAC035]. In current 144 production networks, using DNSSEC with longer DNSKEYs (ZSK>1024B and 145 KSK>2048B) will result in response packets no smaller than 1500B 146 [T-DNS]. Especially during the KSK rollover process, responses to 147 the query of DNSKEY RRset will be enlarged as they contain both the 148 new and old KSK. 150 When possible, we should avoid dropped packets as this means the 151 client must wait for a timeout, which incurs a high cost. For 152 example, a validator behind a firewall suffers waiting till the 153 timeout with no response, if the firewall drops large EDNS(0) packets 154 and IP fragments. It may even cause disaster when the validator can 155 not recieve response for new trust anchor KSK due to the extreme case 156 of bad middle boxes which also drop TCP/53. 158 Since UDP requires fewer packets on the wire and less state on 159 servers than TCP, in this memo we propose continuing to use UDP for 160 transmission but fragment the larger DNS packets into smaller DNS 161 packets at the application layer. We would like the fragments to 162 easily go through middle boxes and avoid falling back to TCP. 164 2. DNS Message Fragmentation Method 166 2.1. Client Behavior 168 Clients supporting DNS message fragmentation add an EDNS option to 169 their queries, which declares their support for this feature. 171 If a DNS reply is received that has been fragmented, it will consist 172 of multiple DNS message fragments (each transmitted in a respective 173 UDP packet), and every fragment contain an EDNS option which says how 174 many total fragments there are, and the identifier of the fragment 175 that the current packet represents. The client collects all of the 176 fragments and uses them to reconstruct the full DNS message. Clients 177 MUST maintain a timeout when waiting for the fragments to arrive. 179 Clients that support DNS message fragments MUST be able to reassemble 180 fragments into a DNS message of any size, up to the maximum of 64KiB. 182 The client MAY save information about what sizes of packets have been 183 received from a given server. If saved, this information MUST have a 184 limited duration. 186 Any DNSSEC validation is performed on the reassembled DNS message. 188 2.2. Server Behavior 190 Servers supporting DNS message fragmentation will look for the EDNS 191 option which declares client support for the feature. If not 192 present, the server MUST NOT use DNS message fragmentation. The 193 server MUST check that DNS cookies are supported. [**FIXME**] 194 Implementation of the first request case, where no existing 195 established cookie is available needs discussion; we want to avoid 196 additional round-trips here. Shane: don't cookies already handle 197 this case? 199 The server prepares the response DNS message normally. If the 200 message exceeds the maximum UDP payload size specified by the client, 201 then it should fragment the message into multiple UDP datagrams. 203 Each fragment contains an identical DNS header with TC=1, possibly 204 varying only in the section counts. Setting the TC flag in this way 205 insures that clients which do not support DNS fragments can fallback 206 to TCP transparently. 208 As many RR are included in each fragment as are possible without 209 going over the desired size of the fragment. An EDNS option is added 210 to every fragment, that includes both the fragment identifier and the 211 total number of fragments. 213 The server needs to know how many total fragments there are to insert 214 into each fragment. A simple approach would be to generate all 215 fragments, and then count the total number at the end, and update the 216 previously-generated fragments with the total number of fragments. 217 Other techniques may be possible. 219 The server MUST limit the number of fragments that it uses in a 220 reply. (See "Open Issues and Discussion" for remaining work.) 222 The server MUST NOT exceed the maximum fragment size requested by a 223 client. 225 The server should use the following sizes for each fragment in the 226 sequence in IPv4: 228 +=============+=================================+ 229 | Fragment ID | Size | 230 +=============+=================================+ 231 | 1 | min(512, client_specified_max) | 232 +-------------+---------------------------------+ 233 | 2 | min(1460, client_specified_max) | 234 +-------------+---------------------------------+ 235 | 3 | min(1480, client_specified_max) | 236 +-------------+---------------------------------+ 237 | N | min(1480, client_specified_max) | 238 +-------------+---------------------------------+ 240 Table 1 242 The rationale is that the first packet will always get through, since 243 if a 512 octet packet doesn't work, DNS cannot function. We then 244 increase to sizes that are likely to get through. 1460 is the 1500 245 octet Ethernet packet size, minus the IP header overhead and enough 246 space to support tunneled traffic. 1480 is the 1500 octet Ethernet 247 packet size, minus the IP header overhead. [**FIXME**] Why not add 248 1240 here? Shane answers: 1280 is not any kind of limit in IPv4, as 249 far as I know. 251 The server should use the following sizes for each packet in the 252 sequence in IPv6: 254 +=============+=================================+ 255 | Fragment ID | Size | 256 +=============+=================================+ 257 | 1 | min(1240, client_specified_max) | 258 +-------------+---------------------------------+ 259 | 2 | min(1420, client_specified_max) | 260 +-------------+---------------------------------+ 261 | 3 | min(1460, client_specified_max) | 262 +-------------+---------------------------------+ 263 | N | min(1460, client_specified_max) | 264 +-------------+---------------------------------+ 266 Table 2 268 Like with IPv4, the idea is that the first packet will always get 269 through. In this case we use the IPv6-mandated 1280 octets, minus 270 the IP header overhead. We then increase to 1420, which is the 1500 271 octet Ethernet packet size, minus the IP header overhead and enough 272 space to support tunneled traffic. 1460 is the 1500 octet Ethernet 273 packet size, minus the IP header overhead. 275 2.3. Other Notes 277 * The FRAGMENT option MUST NOT be present in DNS query messages, 278 i.e., when QR=0. If a DNS implementation notices the FRAGMENT 279 option in a DNS query message, it MUST ignore it. 281 * In DNS reply messages, the FRAGMENT option MUST NOT be present in 282 datagrams when truncation is not done, i.e., when TC=0. If a DNS 283 implementation notices the FRAGMENT option in a DNS reply message 284 fragment datagram that is not truncated, i.e, when TC=0, it MUST 285 drop all DNS reply message fragment datagrams received so far 286 (awaiting assembly) for that message's corresponding question 287 tuple (server IP, port, message ID) without using any data from 288 them. [**FIXME**] Dropping fragments to be received yet will be 289 problematic for implementations, but dropping fragments received 290 so far ought to be sufficient. 292 * More than one FRAGMENT option MUST NOT be present in a DNS reply 293 message fragment datagram. If a DNS implementation notices 294 multiple FRAGMENT options in a DNS reply message fragment 295 datagram, it MUST drop all reply datagrams received for that 296 message's corresponding question tuple (server IP, port, message 297 ID) without using any data from them. [**FIXME**] Dropping 298 fragments to be received yet will be problematic for 299 implementations, but dropping fragments received so far ought to 300 be sufficient. 302 3. The ALLOW-FRAGMENTS EDNS(0) Option 304 ALLOW-FRAGMENTS is an EDNS(0) [RFC6891] option that a client uses to 305 inform a server that it supports fragmented responses. [**FIXME**] 306 Why not simply use the FRAGMENT option here with count=0, 307 identifier=ignored and avoid using another option code? Shane: There 308 are no shortage of options. Plus, if we want to include a maximum 309 fragment size value in the ALLOW-FRAGMENTS then we really need a 310 separate option. 312 3.1. Wire Format 314 TBD. 316 3.2. Option Fields 318 3.2.1. Maximum Fragment Size 320 The Maximum Fragment Size field is represented as an unsigned 16-bit 321 integer. This is the maximum size used by any given fragment the 322 server returns. [**FIXME**] This field's purpose has to be explained. 323 Shane: discussed in the discussion section now. 325 3.3. Presentation Format 327 As with other EDNS(0) options, the ALLOW-FRAGMENTS option does not 328 have a presentation format. 330 4. The FRAGMENT EDNS(0) Option 332 FRAGMENT is an EDNS(0) [RFC6891] option that assists a client in 333 gathering the various fragments of a DNS message from multiple UDP 334 datagrams. It is described in a previous section. Here, its syntax 335 is provided. 337 4.1. Wire Format 339 TBD. 341 4.2. Option Fields 343 4.2.1. Fragment Identifier 345 The Fragment Identifier field is represented as an unsigned 8-bit 346 integer. The first fragment is identified as 1. Values in the range 347 [1,255] can be used to identify the various fragments. Value 0 is 348 used for signalling purposes. 350 4.2.2. Fragment Count 352 The Fragment Count field is represented as an unsigned 8-bit integer. 353 It contains the number of fragments in the range [1,255] that make up 354 the DNS message. Value 0 is used for signalling purposes. 356 4.3. Presentation Format 358 As with other EDNS(0) options, the FRAGMENT option does not have a 359 presentation format. 361 5. Network Considerations 363 5.1. Background 365 TCP-based application protocols co-exist well with competing traffic 366 flows in the internet due to congestion control methods such as in 367 [RFC5681] that are present in TCP implementations. 369 UDP-based application protocols have no restrictions in lower layers 370 to stop them from flooding datagrams into a network and causing 371 congestion. So applications that use UDP have to check themselves 372 from causing congestion so that their traffic is not disruptive. 374 In the case of [RFC1035], only one reply UDP datagram was sent per 375 request UDP datagram, and so the lock-step flow control automatically 376 ensured that UDP DNS traffic didn't lead to congestion. When DNS 377 clients didn't hear back from the server, and had to retransmit the 378 question, they typically paced themselves by using methods such as a 379 retransmission timer based on a smoothed round-trip time between 380 client and server. 382 Due to the message fragmentation described in this document, when a 383 DNS query causes multiple DNS reply datagrams to be sent back to the 384 client, there is a risk that without effective control of flow, DNS 385 traffic could cause problems to competing flows along the network 386 path. 388 Because UDP does not guarantee delivery of datagrams, there is a 389 possibility that one or more fragments of a DNS message will be lost 390 during transfer. This is especially a problem on some wireless 391 networks where a rate of datagrams can continually be lost due to 392 interference and other environmental factors. With larger numbers of 393 message fragments, the probability of fragment loss increases. 395 5.2. Implementation Requirements 397 TBD. 399 6. Open Issues and Discussion 401 1. Resolver behavior 403 We need some more discussion of resolver behavior in general, at 404 least to the point of making things clear to an implementor. 406 2. The use of DNS fragments mechanism 408 Is this mechanism designed for all DNS transactions, or only 409 used in some event or special cases like a key rollover process? 410 If the mechanism is designed for general DNS transactions, when 411 is it triggered and how is it integrated with existing patterns? 413 One option is that DNS fragments mechanism works as a backup 414 with EDNS, and triggered only when a larger packet fails in the 415 middle. It will be orthogonal with TCP which provide additional 416 context that TC bit will be used in server side. 418 3. What is the size of fragments? 420 Generally speaking the number of fragment increases if fragment 421 size is small (512 bytes, or other empirical value), which makes 422 the mechanism less efficient. If the size can changed 423 dynamically according to negotiation or some detection, it will 424 introduce more cost and round trip time. 426 4. What happens if a client that does not support DNS fragments 427 receives an out-of-order or partial fragment? 429 We need to consider what happens when a client that does not 430 support DNS fragments gets a partial response, possibly even out 431 of order. 433 5. We should explain risk of congestion, packet loss, etc. when 434 introducing the limit on the number of fragments. We might also 435 set specific upper limits for number of fragments. 437 6. EDNS buffer sizes vs. maximum fragmentation sizes 439 Mukund: We need further discussion about the sizes; also an 440 upper limit for each *fragment* has to be the client's UDP 441 payload size as it is the driver and it alone knows the ultimate 442 success/failure of message delivery. So if it sets a maximum 443 payload size of 1200, there's no point in trying 1460. Clients 444 that support DNS message fragments (and signal support using the 445 EDNS option) should adapt their UDP payload size discovery 446 algorithm to work with this feature, as the following splits on 447 sizes will assist PMTU discovery. 449 Shane: I think we need to separate the EDNS maximum UDP payload 450 size from the maximum fragment size. I think that it is quite 451 likely that (for example) we will want to restrict each fragment 452 to 1480 bytes, but that the EDNS buffer size might remain at 4 453 kibibytes. 455 7. TSIG should be addressed 457 We need to document how to handle TSIG, even though this is not 458 likely to be a real-world issue. Probably each fragment should 459 be TSIG signed, as this makes it harder for an attacker to 460 inject bogus packets that a client will have to process. 462 8. RR splitting should be addressed 464 We need to document whether or not RR can be split. Probably it 465 makes sense not to allow this, although this will reduce the 466 effectiveness of the fragmentation, as the units that can be 467 packed into each fragment will be bigger. 469 9. We need to document that some messages may not be possible to 470 split. 472 Some messages may be too large to split. A trivial example is a 473 TXT record that is larger than the buffer size. Probably the 474 best behavior here is to truncate. 476 10. DNSSEC checks 478 DNSSEC checks should be done on the final reassembled packet. 479 This needs to be documented. 481 11. Name compression 483 Name compression should be done on the each fragment separately. 484 This needs to be documented. 486 12. OPT-RR 488 Some OPT-RR seem to be oriented at the entire message, others 489 make more sense per packet. This needs to be sorted out. Also 490 we need to investigate the edge case where fragments have 491 conflicting options (Mukund thinks that we can copy the approach 492 in the EDNS specification and use the same rules about 493 conflicting OPT-RR that it uses.) 495 7. Security Considerations 497 To avoid DNS amplification or reflection attacks, DNS cookies 498 [I-D.ietf-dnsop-cookies] must be used. The DNS cookie EDNS option is 499 identical in all fragments that make up a DNS message. The 500 duplication of the same cookie values in all fragments that make up 501 the message is not expected to introduce a security weakness in the 502 case of off-path attacks. 504 8. IANA Considerations 506 The ALLOW-FRAGMENTS and FRAGMENT EDNS(0) options require option codes 507 to be assigned for them. 509 9. Acknowledgements 511 Thanks to Stephen Morris, JINMEI Tatuya, Paul Vixie, Mark Andrews, 512 and David Dragon for reviewing a pre-draft proposal and providing 513 support, comments and suggestions. 515 10. References 517 [Fragment-Poisonous] 518 Herzberg, A. and H. Shulman, "Fragmentation Considered 519 Poisonous", 2012. 521 [I-D.ietf-dnsop-cookies] 522 Eastlake, D. and M. Andrews, "Domain Name System (DNS) 523 Cookies", Work in Progress, Internet-Draft, draft-ietf- 524 dnsop-cookies-04, 1 July 2015, . 527 [I-D.ietf-dnsop-respsize] 528 Vixie, P., Kato, A., and J. Abley, "DNS Referral Response 529 Size Issues", Work in Progress, Internet-Draft, draft- 530 ietf-dnsop-respsize-15, 14 February 2014, 531 . 534 [RFC1035] Mockapetris, P., "Domain names - implementation and 535 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 536 November 1987, . 538 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 539 Application and Support", STD 3, RFC 1123, 540 DOI 10.17487/RFC1123, October 1989, 541 . 543 [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, 544 "Advanced Sockets Application Program Interface (API) for 545 IPv6", RFC 3542, DOI 10.17487/RFC3542, May 2003, 546 . 548 [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More 549 Resilient against Forged Answers", RFC 5452, 550 DOI 10.17487/RFC5452, January 2009, 551 . 553 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 554 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 555 . 557 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 558 for DNS (EDNS(0))", STD 75, RFC 6891, 559 DOI 10.17487/RFC6891, April 2013, 560 . 562 [SAC016] ICANN Security and Stability Advisory Committee, "Testing 563 Firewalls for IPv6 and EDNS0 Support", 2007. 565 [SAC035] ICANN Security and Stability Advisory Committee, "DNSSEC 566 Impact on Broadband Routers and Firewalls", 2008. 568 [T-DNS] Zhu, L., Hu, Z., and J. Heidemann, "T-DNS: Connection- 569 Oriented DNS to Improve Privacy and Security (extended)", 570 2007, . 572 Appendix A. Change History (to be removed before publication) 574 * draft-muks-dns-message-fragments-00 576 Initial draft. 578 Authors' Addresses 580 Mukund Sivaraman 581 Internet Systems Consortium 582 950 Charter Street 583 Redwood City, CA 94063 584 United States of America 585 Email: muks@isc.org 586 URI: http://www.isc.org/ 588 Shane Kerr 589 Beijing Internet Institute 590 2/F, Building 5, No.58 Jinghai Road, BDA 591 Beijing 592 100176 593 China 594 Email: shane@biigroup.cn 595 URI: http://www.biigroup.com/ 597 Linjian Song 598 Beijing Internet Institute 599 2/F, Building 5, No.58 Jinghai Road, BDA 600 Beijing 601 100176 602 China 603 Email: songlinjian@gmail.com 604 URI: http://www.biigroup.com/ 606 Haisheng Yu 607 Beijing Internet Institute 608 2/F, Building 5, No.58 Jinghai Road, BDA 609 Beijing 610 100176 611 China 612 Email: hsyu@biigroup.cn 613 URI: http://www.biigroup.com/