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