idnits 2.17.1 draft-ietf-dnsop-edns-tcp-keepalive-04.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 20, 2015) is 3104 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 7320 (Obsoleted by RFC 8820) == Outdated reference: A later version (-09) exists of draft-ietf-dprive-dns-over-tls-01 == Outdated reference: A later version (-06) exists of draft-ietf-dnsop-5966bis-03 -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dnsop P. Wouters 3 Internet-Draft Red Hat 4 Intended status: Standards Track J. Abley 5 Expires: April 22, 2016 Dyn, Inc. 6 S. Dickinson 7 Sinodun 8 R. Bellis 9 ISC 10 October 20, 2015 12 The edns-tcp-keepalive EDNS0 Option 13 draft-ietf-dnsop-edns-tcp-keepalive-04 15 Abstract 17 DNS messages between clients and servers may be received over either 18 UDP or TCP. UDP transport involves keeping less state on a busy 19 server, but can cause truncation and retries over TCP. Additionally, 20 UDP can be exploited for reflection attacks. Using TCP would reduce 21 retransmits and amplification. However, clients commonly use TCP 22 only for fallback and servers typically use idle timeouts on the 23 order of seconds. 25 This document defines an EDNS0 option ("edns-tcp-keepalive") that 26 allows DNS servers to signal a variable idle timeout. This 27 signalling facilitates a better balance of UDP and TCP transport 28 between individual clients and servers, reducing the impact of 29 problems associated with UDP transport and allowing the state 30 associated with TCP transport to be managed effectively with minimal 31 impact on the DNS transaction time. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 22, 2016. 50 Copyright Notice 52 Copyright (c) 2015 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 69 3. The edns-tcp-keepalive Option . . . . . . . . . . . . . . . . 5 70 3.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 5 71 3.2. Use by DNS Clients . . . . . . . . . . . . . . . . . . . 6 72 3.2.1. Sending Queries . . . . . . . . . . . . . . . . . . . 6 73 3.2.2. Receiving Responses . . . . . . . . . . . . . . . . . 6 74 3.3. Use by DNS Servers . . . . . . . . . . . . . . . . . . . 6 75 3.3.1. Receiving Queries . . . . . . . . . . . . . . . . . . 6 76 3.3.2. Sending Responses . . . . . . . . . . . . . . . . . . 7 77 3.4. TCP Session Management . . . . . . . . . . . . . . . . . 7 78 3.5. Non-Clean Paths . . . . . . . . . . . . . . . . . . . . . 8 79 3.6. Anycast Considerations . . . . . . . . . . . . . . . . . 8 80 4. Intermediary Considerations . . . . . . . . . . . . . . . . . 9 81 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 83 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 84 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 85 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 86 8.2. Informative References . . . . . . . . . . . . . . . . . 10 87 Appendix A. Editors' Notes . . . . . . . . . . . . . . . . . . . 11 88 A.1. Abridged Change History . . . . . . . . . . . . . . . . . 11 89 A.1.1. draft-ietf-dnsop-edns-tcp-keepalive-04 . . . . . . . 11 90 A.1.2. draft-ietf-dnsop-edns-tcp-keepalive-03 . . . . . . . 11 91 A.1.3. draft-ietf-dnsop-edns-tcp-keepalive-02 . . . . . . . 12 92 A.1.4. draft-ietf-dnsop-edns-tcp-keepalive-01 . . . . . . . 12 93 A.1.5. draft-ietf-dnsop-edns-tcp-keepalive-00 . . . . . . . 12 94 A.1.6. draft-wouters-edns-tcp-keepalive-01 . . . . . . . . . 12 95 A.1.7. draft-wouters-edns-tcp-keepalive-00 . . . . . . . . . 13 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 98 1. Introduction 100 DNS messages between clients and servers may be received over either 101 UDP or TCP [RFC1035]. Historically, DNS clients used API's that only 102 facilitated sending and receiving a single query over either UDP or 103 TCP. New APIs and deployment of DNSSEC validating resolvers on hosts 104 that in the past were using stub resolving only is increasing the DNS 105 client base that prefer using long lived TCP connections. Long-lived 106 TCP connections can result in lower request latency than the case 107 where UDP transport is used and truncated responses are received, 108 since clients that have fallen back to TCP transport in response to a 109 truncated response typically only uses the TCP session for a single 110 (request, response) pair, continuing with UDP transport for 111 subsequent queries. Clients wishing to use other stream-based 112 transport protocols for DNS would also benefit from the set-up 113 amortisation afforded by long lived connections. 115 UDP transport is stateless, and hence presents a much lower resource 116 burden on a busy DNS server than TCP. An exchange of DNS messages 117 over UDP can also be completed in a single round trip between 118 communicating hosts, resulting in optimally-short transaction times. 119 UDP transport is not without its risks, however. 121 A single-datagram exchange over UDP between two hosts can be 122 exploited to enable a reflection attack on a third party. Response 123 Rate Limiting [RRL] is designed to help mitigate such attacks against 124 authoritative-only servers. One feature of RRL is to let some amount 125 of responses "slip" through the rate limiter. These are returned 126 with the TC (truncation) bit set, which causes legitimate clients to 127 re-query using TCP transport. 129 [RFC1035] specified a maximum DNS message size over UDP transport of 130 512 bytes. Deployment of DNSSEC [RFC4033] and other protocols 131 subsequently increased the observed frequency at which responses 132 exceed this limit. EDNS0 [RFC6891] allows DNS messages larger than 133 512 bytes to be exchanged over UDP, with a corresponding increased 134 incidence of fragmentation. Fragmentation is known to be problematic 135 in general, and has also been implicated in increasing the risk of 136 cache poisoning attacks [fragmentation-considered-poisonous]. 138 TCP transport is less susceptible to the risks of fragmentation and 139 reflection attacks. However, TCP transport as currently deployed has 140 expensive overhead. 142 The overhead of the three-way TCP handshake for a single DNS 143 transaction is substantial, increasing the transaction time for a 144 single (request, response) pair of DNS messages from 1 x RTT to 2 x 145 RTT. There is no such overhead for a session that is already 146 established, however, and the overall impact of the TCP setup 147 handshake when the resulting session is used to exchange N DNS 148 message pairs over a single session, (1 + N)/N, approaches unity as N 149 increases. 151 With increased deployment of DNSSEC and new RRtypes containing 152 application specific cryptographic material, there is an increase in 153 the prevalence of truncated responses received over UDP with fallback 154 to TCP. 156 (It should perhaps be noted that the overhead for a DNS transaction 157 over UDP truncated due to RRL is 3x RTT, higher than the overhead 158 imposed on the same transaction initiated over TCP.) 160 The use of TCP transport requires state to be retained on DNS 161 servers. If a server is to perform adequately with a significant 162 query load received over TCP, it must manage its available resources 163 to ensure that all established TCP sessions are well-used, and idle 164 connections are closed after an appropriate amount of time. 166 This document proposes a signalling mechanism between DNS clients and 167 servers that provides a means to better balance the use of UDP and 168 TCP transport (thereby helping to manage the impact of problems 169 associated with UDP), whilst constraining the impact of TCP on 170 response times and server resources to a manageable level. 172 This mechanism will be of benefit both for stub-resolver and 173 resolver-authoritative TCP connections. In the latter case the 174 persistent nature of the TCP connection can provide improved defence 175 against attacks including DDoS. 177 The reduced overhead of this extension adds up significantly when 178 combined with other EDNS0 extensions, such as [CHAIN-QUERY] and 179 [DNS-over-TLS]. For example, the combination of these EDNS0 180 extensions make it possible for hosts on high-latency mobile networks 181 to natively and efficiently perform DNSSEC validation and encrypt 182 queries. 184 2. Requirements Notation 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 188 document are to be interpreted as described in [RFC2119]. 190 3. The edns-tcp-keepalive Option 192 This document specifies a new EDNS0 [RFC6891] option, edns-tcp- 193 keepalive, which can be used by DNS clients and servers to signal a 194 willingness to keep an idle TCP session open for a certain amount of 195 time to conduct future DNS transactions. This specification does not 196 distinguish between different types of DNS client and server in the 197 use of this option. 199 3.1. Option Format 201 The edns-tcp-keepalive option is encoded as follows: 203 1 2 3 204 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 205 +-------------------------------+-------------------------------+ 206 ! OPTION-CODE ! OPTION-LENGTH ! 207 +-------------------------------+-------------------------------+ 208 | TIMEOUT ! 209 +-------------------------------+ 211 where: 213 OPTION-CODE: the EDNS0 option code assigned to edns-tcp-keepalive, 214 TBD1 216 OPTION-LENGTH: the value 0 if the TIMEOUT is omitted, the value 2 217 if it is present; 219 TIMEOUT: an idle timeout value for the TCP connection, specified in 220 units of 100 milliseconds, encoded in network byte order. 222 3.2. Use by DNS Clients 224 3.2.1. Sending Queries 226 DNS clients MUST NOT include the edns-tcp-keepalive option in queries 227 sent using UDP transport. 229 DNS clients MAY include the edns-tcp-keepalive option in the first 230 query sent to a server using TCP transport to signal their desire to 231 keep the connection open when idle. 233 DNS clients MAY include the edns-tcp-keepalive option in subsequent 234 queries sent to a server using TCP transport to signal their 235 continued desire to keep the connection open when idle. 237 Clients MUST specify an OPTION-LENGTH of 0 and omit the TIMEOUT 238 value. 240 3.2.2. Receiving Responses 242 A DNS client that receives a response using UDP transport that 243 includes the edns-tcp-keepalive option MUST ignore the option. 245 A DNS client that receives a response using TCP transport that 246 includes the edns-tcp-keepalive option MAY keep the existing TCP 247 session open when it is idle. It SHOULD honour the timeout and 248 initiate close of the connection before the timeout expires. 250 A DNS client that receives a response that includes the edns-tcp- 251 keepalive option with a TIMEOUT value of 0 SHOULD send no more 252 queries on that connection and initiate closing the connection as 253 soon as it has received all outstanding responses. 255 A DNS client that sent a query containing the edns-keepalive-option 256 but receives a response that does not contain the edns-keepalive- 257 option should assume the server does not support keepalive and behave 258 following the guidance in [DRAFT-5966bis]. This holds true even if a 259 previous edns-keepalive-option exchange occurred on the existing TCP 260 connection. 262 3.3. Use by DNS Servers 264 3.3.1. Receiving Queries 266 A DNS server that receives a query using UDP transport that includes 267 the edns-tcp-keepalive option MUST ignore the option. 269 A DNS server that receives a query using TCP transport that includes 270 the edns-tcp-keepalive option MAY modify the local idle timeout 271 associated with that TCP session if resources permit. 273 3.3.2. Sending Responses 275 A DNS server that receives a query sent using TCP transport that 276 includes an OPT RR MAY include the edns-tcp-keepalive option in the 277 response to signal the expected idle timeout on a connection. 278 Servers MUST specify the TIMEOUT value that is currently associated 279 with the TCP session. It is reasonable for this value to change 280 according to local resource constraints or in consideration of 281 intermediary behaviour (for example TCP middleboxes or NATs). The 282 DNS server SHOULD send a edns-tcp-keepalive option with a timeout of 283 0 if it deems its local resources are too low to service more TCP 284 keepalive sessions, or if it wants clients to close currently open 285 connections. 287 3.4. TCP Session Management 289 Both DNS clients and servers are subject to resource constraints 290 which will limit the extent to which TCP sessions can persist. 291 Effective limits for the number of active sessions that can be 292 maintained on individual clients and servers should be established, 293 either as configuration options or by interrogation of process limits 294 imposed by the operating system. Servers that implement edns-tcp- 295 keepalive should also engage in TCP connection management by 296 recycling existing connections when appropriate, closing connections 297 gracefully and managing request queues to enable fair use. 299 In the event that there is greater demand for TCP sessions than can 300 be accommodated, servers may reduce the TIMEOUT value signalled in 301 successive DNS messages to minimise idle time on existing sessions. 302 This also allows, for example, clients with other candidate servers 303 to query to establish new TCP sessions with different servers in 304 expectation that an existing session is likely to be closed, or to 305 fall back to UDP. 307 Based on TCP session resources servers may signal a TIMEOUT value of 308 0 to request clients to close connections as soon as possible. This 309 is useful when server resources become very low or a denial-of- 310 service attack is detected and further maximises the shifting of 311 TIME_WAIT state to well-behaved clients. 313 However it should be noted that RCF6891 states: 315 Lack of presence of an OPT record in a request MUST be taken as an 316 indication that the requestor does not implement any part of this 317 specification and that the responder MUST NOT include an OPT 318 record in its response. 320 Since servers must be faithful to this specification even on a 321 persistent TCP connection it means that (following the initial 322 exchange of timeouts) a server may not be presented with the 323 opportunity to signal a change in the idle timeout associated with a 324 connection if the client does not send any further requests 325 containing EDNS0 OPT RRs. This limitation makes persistent 326 connection handling via an initial idle timeout signal more 327 attractive than a mechanism that establishes default persistence and 328 then uses a connection close signal (in a similar manner to HTTP 1.1 329 [RFC7320]). 331 If a client includes the edns-tcp-keepalive option in the first 332 query, it SHOULD include an EDNS0 OPT RR periodically in any further 333 messages it sends during the TCP session. This will increase the 334 chance of the client being notified should the server modify the 335 timeout associated with a session. The algorithm for choosing when 336 to do this is out of scope of this document and is left up to the 337 implementor and/or operator. 339 DNS clients and servers MAY close a TCP session at any time in order 340 to manage local resource constraints. The algorithm by which clients 341 and servers rank active TCP sessions in order to determine which to 342 close is not specified in this document. 344 3.5. Non-Clean Paths 346 Many paths between DNS clients and servers suffer from poor hygiene, 347 limiting the free flow of DNS messages that include particular EDNS0 348 options, or messages that exceed a particular size. A fallback 349 strategy similar to that described in [RFC6891] section 6.2.2 SHOULD 350 be employed to avoid persistent interference due to non-clean paths. 352 3.6. Anycast Considerations 354 DNS servers of various types are commonly deployed using anycast 355 [RFC4786]. 357 Changes in network topology between clients and anycast servers may 358 cause disruption to TCP sessions making use of edns-tcp-keepalive 359 more often than with TCP sessions that omit it, since the TCP 360 sessions are expected to be longer-lived. Anycast servers MAY make 361 use of TCP multipath [RFC6824] to anchor the server side of the TCP 362 connection to an unambiguously-unicast address in order to avoid 363 disruption due to topology changes. 365 4. Intermediary Considerations 367 It is RECOMMENDED that DNS intermediaries which terminate TCP 368 connections implement edns-tcp-keepalive. An intermediary that does 369 not implement edns-tcp-keepalive but sits between a client and server 370 that both support edns-tcp-keepalive might close idle connections 371 unnecessarily. 373 5. Security Considerations 375 The edns-tcp-keepalive option can potentially be abused to request 376 large numbers of sessions in a quick burst. When a DNS Server 377 detects abusive behaviour, it SHOULD immediately close the TCP 378 connection and free the resources used. 380 Servers could choose to monitor client behaviour with respect to the 381 edns-tcp-keepalive option to build up profiles of clients that do not 382 honour the specified timeout. 384 Readers are advised to familiarise themselves with the security 385 considerations outlined in [DRAFT-5966bis] 387 6. IANA Considerations 389 The IANA is directed to assign an EDNS0 option code for the edns-tcp- 390 keepalive option from the DNS EDNS0 Option Codes (OPT) registry as 391 follows: 393 +-------+--------------------+----------+-----------------+ 394 | Value | Name | Status | Reference | 395 +-------+--------------------+----------+-----------------+ 396 | TBD1 | edns-tcp-keepalive | Optional | [This document] | 397 +-------+--------------------+----------+-----------------+ 399 7. Acknowledgements 401 The authors acknowledge the contributions of Jinmei TATUYA and Mark 402 Andrews. Thanks to Duane Wessels for detailed review and the many 403 others who contributed to the mailing list discussion. 405 8. References 407 8.1. Normative References 409 [RFC1035] Mockapetris, P., "Domain names - implementation and 410 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 411 November 1987, . 413 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 414 Requirement Levels", BCP 14, RFC 2119, 415 DOI 10.17487/RFC2119, March 1997, 416 . 418 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 419 Rose, "DNS Security Introduction and Requirements", 420 RFC 4033, DOI 10.17487/RFC4033, March 2005, 421 . 423 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 424 Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, 425 December 2006, . 427 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 428 for DNS (EDNS(0))", STD 75, RFC 6891, 429 DOI 10.17487/RFC6891, April 2013, 430 . 432 [RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, 433 RFC 7320, DOI 10.17487/RFC7320, July 2014, 434 . 436 8.2. Informative References 438 [CHAIN-QUERY] 439 Wouters, P., "Chain Query requests in DNS", draft-ietf- 440 dnsop-edns-chain-query (work in progress), October 2015. 442 [DNS-over-TLS] 443 Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 444 and P. Hoffman, "TLS for DNS: Initiation and Performance 445 Considerations", draft-ietf-dprive-dns-over-tls-01 (work 446 in progress), October 2015. 448 [DRAFT-5966bis] 449 Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and 450 D. Wessels, "DNS Transport over TCP - Implementation 451 Requirements", draft-ietf-dnsop-5966bis-03 (work in 452 progress), September 2015. 454 [fragmentation-considered-poisonous] 455 Herzberg, A. and H. Shulman, "Fragmentation Considered 456 Poisonous", arXiv 1205.4011, May 2012. 458 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 459 "TCP Extensions for Multipath Operation with Multiple 460 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 461 . 463 [RRL] Vixie, P. and V. Schryver, "DNS Response Rate Limiting 464 (DNS RRL)", ISC-TN 2012-1-Draft1, April 2012. 466 Appendix A. Editors' Notes 468 A.1. Abridged Change History 470 [Note to RFC Editor: please remove this section prior to 471 publication.] 473 A.1.1. draft-ietf-dnsop-edns-tcp-keepalive-04 475 Adding wording to sections 3.2.1 and 3.4 to clarify client behaviour 476 on subsequent queries on a TCP connection. 478 Changed the should to a SHOULD in section 3.2.2 480 Changed Nameserver to DNS server in section 5. 482 Updated references. 484 Changed reference to RFC6824 to be informative. 486 Corrected reference to requested EDNS0 option code to be 'TBD1'. 488 A.1.2. draft-ietf-dnsop-edns-tcp-keepalive-03 490 Clarified that a response to a query with any OPT RR may contain the 491 ends-tcp-keepalive option. 493 Corrected TIMEOUT length from 4 to 2 in the diagram. 495 Updated references, including name change of STARTTLS -> DNS-over-TLS 496 and adding reference for cache poisoning. 498 Updated wording in section on Intermediary Considerations. 500 Updated wording describing RRL. 502 Added paragraph to security section describing client behaviour 503 profiles. 505 Added wording to introduction on use case for stub/resolver/ 506 authoritative. 508 A.1.3. draft-ietf-dnsop-edns-tcp-keepalive-02 510 Changed timeout value to idle timeout and re-phrased document around 511 this. 513 Changed units of timeout to 100ms to allow values less than 1 second. 515 Change specification to remove use of the option over UDP. This is 516 potentially confusing, could cause issues with ALG's and adds only 517 limited value. 519 Changed semantics so the client no longer sends a timeout. The 520 client timeout is of limited value as servers should be managing 521 connections based on their view of their resources, not on client 522 requests as this is open to abuse. Additionally this identifies 523 cases were the option is simply being reflected back. 525 Changed semantics for the meaning of a server sending a timeout of 0. 526 The maximum timeout value of 6553.5s (~1.8h) is already large and a 527 distinct 'connection close'-like signal is potentially more useful. 529 Added more detail on server side requirements when supporting 530 keepalive in terms of resource and connection management. 532 Added discussion of EDNS0 per-message limitation and implications of 533 this. 535 Added reference to STARTTLS draft and RFC7320. 537 A.1.4. draft-ietf-dnsop-edns-tcp-keepalive-01 539 Version bump with no changes 541 A.1.5. draft-ietf-dnsop-edns-tcp-keepalive-00 543 Clarifications, working group adoption. 545 A.1.6. draft-wouters-edns-tcp-keepalive-01 547 Also allow clients to specify KEEPALIVE timeout values, clarify 548 motivation of document. 550 A.1.7. draft-wouters-edns-tcp-keepalive-00 552 Initial draft. 554 Authors' Addresses 556 Paul Wouters 557 Red Hat 559 Email: pwouters@redhat.com 561 Joe Abley 562 Dyn, Inc. 563 470 Moore Street 564 London, ON N6C 2C2 565 Canada 567 Phone: +1 519 670 9327 568 Email: jabley@dyn.com 570 Sara Dickinson 571 Sinodun Internet Technologies 572 Magdalen Centre 573 Oxford Science Park 574 Oxford OX4 4GA 575 UK 577 Email: sara@sinodun.com 578 URI: http://sinodun.com 580 Ray Bellis 581 Internet Systems Consortium, Inc 582 950 Charter Street 583 Redwood City CA 94063 584 USA 586 Phone: +1 650 423 1200 587 Email: ray@isc.org 588 URI: http://www.isc.org