idnits 2.17.1 draft-barwood-dnsext-dns-transport-18.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 (7 April 2010) is 5126 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'NACL' ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNS Extensions Working Group G. Barwood 3 Internet-Draft 4 Intended status: Standards Track 7 April 2010 6 DNS Transport 7 draft-barwood-dnsext-dns-transport-18 9 Abstract 11 This document describes a new transport protocol for DNS. 12 IP fragmentation is avoided, blind spoofing, amplification attacks 13 and other denial of service attacks are prevented. Latency for a 14 typical DNS query is a single round trip, after a setup handshake. 15 No per-client server state is required between transactions. 16 Packets may optionally be encrypted and authenticated. 17 The protocol may have other applications. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on October 7, 2010. 42 Copyright Notice 44 Copyright (c) 2010 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions 52 with respect to this document. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Definitions and Objectives . . . . . . . . . . . . . . . . . . 3 60 2.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3.2 Setup request . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.3 Setup response . . . . . . . . . . . . . . . . . . . . . . 5 72 3.4 Initial request . . . . . . . . . . . . . . . . . . . . . . 5 74 3.5 Server response : single page . . . . . . . . . . . . . . . 6 76 3.6 Server response : multi page . . . . . . . . . . . . . . . 6 78 3.7 Follow-up request . . . . . . . . . . . . . . . . . . . . . 7 80 3.8 Encryption and Authentication . . . . . . . . . . . . . . . 7 82 3.9 Congestion control . . . . . . . . . . . . . . . . . . . . 8 84 3.10 Status codes . . . . . . . . . . . . . . . . . . . . . . . 9 86 3.11 EDNS Tunnel . . . . . . . . . . . . . . . . . . . . . . . 10 88 3.12 Signalling . . . . . . . . . . . . . . . . . . . . . . . . 10 90 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 92 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 94 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 96 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 98 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 11 100 7.2 Informative References . . . . . . . . . . . . . . . . . . . 11 102 Appendix A. Implementation of Cookies . . . . . . . . . . . . . . 12 104 Appendix B. Anycast considerations . . . . . . . . . . . . . . . 12 106 Authors Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 108 1. Introduction 110 DNSSEC implies that DNS responses may be large, possibly larger than the 111 de facto ~1500 byte internet MTU. 113 Large responses are a challenge for DNS transport. EDNS [RFC2671] was 114 introduced in 1999 to allow larger responses to be sent over UDP, 115 previously DNS/UDP was limited to a 512 bytes. 117 EDNS is problematic for several reasons: 119 (1) It allows amplification attacks against 3rd parties. DNS/UDP has 120 always been susceptible to these attacks, but EDNS has increased the 121 amplification factor by an order of magnitude. 123 (2) The IP protocol specifies a means by which large IP packets are 124 split into fragments and then re-assembled. However fragmented UDP 125 responses are undesirable for several reasons: 127 o Fragments may be spoofed. The DNS ID and port number are only 128 present in the first fragment, and the IP ID may be easy for an 129 attacker to predict. 131 o In practice fragmentation is not reliable, and large UDP packets may 132 fail to be delivered. 134 o If a single fragment is lost, the entire response must be re-sent. 136 o Re-assembling fragments requires buffer resources, which opens 137 up denial of service attacks [GONT]. 139 Instead, it is possible to use TCP, but this is undesirable, as TCP 140 imposes increased latency and significant server state that may be 141 vulnerable to denial of service attack. 143 Nearly all current DNS traffic is carried by UDP with a maximum size 144 of 512 bytes, and relying on TCP is a risk for the deployment of DNSSEC. 146 Therefore a new protocol is proposed, with mnenomic QRP, to stand for 147 "Quick Response Protocol". 149 2. Definitions and Objectives 151 2.1 Definitions 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in [RFC2119]. 157 DNS Payload A DNS Message [RFC1035], not including the 16-bit ID 158 field. For AXFR, the response messages are concatenated 159 without ID fields, to form a single DNS payload. 161 Transaction A transaction is initiated by a client request packet 162 and the server responds with one or more response packets. 163 All the packets in a transaction have the same REQUESTID. 165 Transfer The requested transfer of a DNS Payload, using one or more 166 transactions as described in sections 3.6 and 3.7. 168 2.2 Objectives 170 Fragmentation must not occur provided the actual path MTU is at least 171 the MTU sent by the client or 600 bytes, whichever is larger. 173 Blind spoofing attacks must be prevented. Amplification attacks 174 against third parties must be prevented. 176 No per-client server state must be needed between transactions. 178 Each Transfer ( for moderate response sizes ) is performed in a single 179 round trip, after setup. 181 The protocol should be efficient : only lost IP packets should be 182 re-transmitted. 184 3. Protocol 186 3.1 Overview 188 Communication is over UDP [RFC768] in two stages. First a long-lived 189 SERVERTOKEN is acquired by the client. Subsequent queries are protected 190 against amplification attacks by the SERVERTOKEN. 192 Each UDP packet starts with a 16 bit OPCODE, followed by a 12 byte 193 REQUESTID that identifies the transaction. These fields are not shown in 194 the packet diagrams. 196 Fixed length field sizes are as shown in the packet diagrams. All 197 numbers are unsigned integers, with the first bit being the most 198 significant. 200 Variable length reserved areas MUST be omitted by the sender. 202 Fixed length reserved areas MUST be set to zero by the sender. 204 All reserved areas MUST be ignored by the receiver. 206 Parameters are stored in DS records, as described in section 3.12. 208 3.2 Setup request 210 The client acquires a SERVERTOKEN for a given Server IP address by 211 sending a packet with OPCODE 1, format : 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 \ RESERVED \ 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 3.3 Setup response 219 The server response has OPCODE 1, format : 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | SERVERTOKEN | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | STATUS | RESERVED \ 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 where : 229 SERVERTOKEN is a 32 bit value computed as a secure hash of the 230 client IP Address and a long term server secret. 231 Servers MUST change the long term secret at least 232 once every 4 weeks. 234 STATUS is an 8 bit status code, see section 3.10. 236 The client associates SERVERTOKEN, and the client IP address 237 ( for multi-homed clients ) with the Server IP address. 239 3.4 Initial request 241 To make a DNS request, a packet is sent with OPCODE 2, format: 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | SERVERTOKEN | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | MTU | COUNT | RESERVED | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 \ DATA \ 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 where : 253 SERVERTOKEN is a copy of SERVERTOKEN from the setup response. 255 MTU limits the size in bytes of the IP packets used to 256 send the response. MUST be at least 600. 258 COUNT limits the number of pages the server will send. 260 DATA is the DNS payload. 262 3.5 Server response : single page 264 The server checks SERVERTOKEN, and obtains the DNS response payload. 265 If the requested MTU is less than 600 bytes, the server SHOULD set 266 MTU to 600 bytes. If the path MTU is known to be less than the value 267 supplied by the client, MTU is reduced to that value ( but not to 268 less than 600 bytes ). 270 If the DNS payload size plus IP/UDP/QRP overhead is not greater than 271 MTU, the server sends a single page response, OPCODE 2, format : 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 \ DATA \ 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 where DATA is the DNS payload. The client uses DATA as the normal DNS 278 response. 280 3.6 Server response : multi page 282 Otherwise, the server divides the DNS payload into equal size pages 283 ( except for the last page which may be smaller ), so that each IP 284 response packet does not exceed MTU, and sends multiple packets, each 285 with OPCODE 3 and format : 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 \ DATA \ 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | TOTAL | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | COOKIE | 293 | | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | COUNT | PAGE | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | PAGESIZE | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 where : 302 DATA is part of the DNS payload. 304 TOTAL is the size of the complete DNS payload. 306 COOKIE is a 64-bit value used to request further pages. 308 COUNT is the number of pages sent. 310 PAGE is the 24-bit zero-based number of this page. 312 PAGESIZE is the size into which the DNS payload has been divided. 314 The client allocates an assembly buffer of TOTAL bytes (if not already 315 allocated), and copies DATA into it at offset PAGE x PAGESIZE. 317 Clients SHOULD impose limits on the maximum size response (TOTAL) they 318 will accept, to prevent attacks by malicious servers. 320 Servers MAY send a smaller number of pages than requested, for 321 policy reasons, or if there is local congestion. The pages sent have 322 numbers 0 .. COUNT-1. 324 3.7 Follow-up request 326 If the client does not receive a page, due to not all pages being sent, 327 or packet loss (with the former having priority), it sends a packet 328 with OPCODE 3, format : 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | SERVERTOKEN | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | COOKIE | 334 | | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | COUNT | PAGE | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | PAGESIZE | \ 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ 340 \ DATA \ 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 where : 345 SERVERTOKEN is a copy of the SERVERTOKEN from the setup response. 347 COOKIE is a copy of COOKIE from the server response. 349 COUNT is the number of pages to be sent. 351 PAGE is the number of the first page to be sent. 353 PAGESIZE is a copy of PAGESIZE from the server response. 355 DATA is a copy of DATA from the initial request. 357 The server response is the same as in section 3.6. 359 Once a client has received all pages, it processes the complete 360 assembled response as normal. 362 If the server encounters an error condition, such as an invalid 363 SERVERTOKEN or COOKIE, it sends a setup response (section 3.3), 364 and the client retries with a new initial request (section 3.4). 366 If a server has more than one IP address, a client MAY attempt to use a 367 SERVERTOKEN it has previously acquired from another IP address. A client 368 MAY also attempt to re-use a COOKIE to continue a failed transfer on an 369 alternate server IP address or an alternative server. 371 3.8 Encryption and Authentication. 373 OPCODE 4 is used to optionally encrypt and authenticate packets using 374 the algorithms described in [NACL]. Public keys are 255 bits. The wire 375 format is 32 bytes, with the unused first bit set to zero. Public key 376 tags are the first 4 bytes of the wire format public key. 378 For client requests, the OPCODE is followed by 380 o The 12 byte REQUESTID ( which is the NACL client nonce ). 381 o The 4 byte SERVERTOKEN. 382 o A 32 byte client public key. 383 o A 4 byte server public key tag. 384 o A cryptographic box containing a 16 byte MAC and the encrypted packet. 386 SERVERTOKEN is sent in the clear ( and not in the encrypted packet ) 387 to allow servers to check client identity before performing public key 388 operations. Setup packets ( OPCODE 0 ) are not encrypted. 390 For server responses, the OPCODE is followed by 392 o The 12 byte REQUESTID ( copied from the request ). 393 o A 12 byte server nonce. 394 o A cryptographic box containing a 16 byte MAC and the encrypted packet. 396 In both cases the 12 byte REQUESTID is omitted from the unencrypted 397 packet, which starts with the underlying OPCODE. 399 3.9 Congestion control 401 The number of pages requested but not received or lost (INFLIGHT) MUST 402 be limited to a value (INFLIGHTMAX) so that undue network congestion 403 is avoided. Packets are deemed lost if they do not arrive within 404 TIMEOUT milli-seconds of being requested. 406 For current DNS purposes (excluding AXFR) a simple method is to set 407 INFLIGHTMAX = 4 and TIMEOUT = 1500 milli-seconds. 409 Alternatively, the following control algorithm MAY be used to allow 410 higher performance. Set 412 INFLIGHTMAX = 4 + 3 * ( RTT / PT ) * ( RTT / RTT_RECENT ) 414 TIMEOUT = INFLIGHTHIGH * PT + 2 * RTT_MAX 416 where 418 RTT is the observed minimum round trip time based on a 419 long sampling period. 421 PT is the smoothed observed time to transmit a full size 422 packet based on a long sampling period. 424 RTT_RECENT is the smoothed observed round trip time, based 425 on a short sampling period. 427 INFLIGHTHIGH is the highest value of INFLIGHT for the current 428 transfer. 430 RTT_MAX is the maximum round trip time observed over a 431 long sampling period. 433 The intention is that the the number of in-flight packets is quickly 434 reduced in response to an increase in latency. 436 Sampling periods and smoothing filters need to be determined and tuned 437 based on operational experience. "A long sampling period" might be the 438 last 8 transfers. RTT_RECENT might be updated when a packet arrives by 439 setting 441 RTT_RECENT = ALPHA * TRIP + (1-ALPHA) * RTT_RECENT 443 where 445 TRIP is the round trip time for the packet. 447 ALPHA is 0.1 if PACKETS > 10, otherwise 1.0 / PACKETS. 449 PACKETS is the number of packets received. 451 Other control algorithms MAY be employed, provided they do not cause a 452 significant increase in latency ( round trip time ). Algorithms that 453 increase INFLIGHT until packets are lost MUST NOT be used. Explicit 454 Congestion Notification [RFC3168] MAY be used. 456 3.10 Status Codes 458 The following values are defined: 460 0 No error 461 1 Invalid SERVERTOKEN 462 2 Invalid COOKIE 464 11 Invalid OPCODE 465 12 End of packet error 466 13 Other format error 468 31 Invalid PAGESIZE 469 32 Invalid PAGE 471 41 Invalid Public Key Tag 472 42 Authentication error 474 Only codes 0-2 will occur if the protocol is correctly implemented, 475 in the absence of network errors or attacks. 477 Servers MAY optionally generate status codes greater than 10. Such 478 responses MAY be logged or used for debugging purposes, but MUST 479 otherwise be ignored. 481 3.11 EDNS Tunnel 483 UDP over a port other than 53 is sometimes blocked by firewalls or 484 network access gateways. In this case QRP queries and responses are sent 485 by UDP/53 using an EDNS [RFC2671] option. 487 The DNS Message consists of a single OPT record in the additional 488 section with an OPTION that carries the QRP message. 490 COUNT (the number of pages requested/sent) may need to be set to 1, 491 since firewalls may prevent multiple responses being sent in response to 492 a single query. 494 EDNS Tunnel is used if and only if the Port is 53. 496 3.12 Signalling 498 Clients discover QRP support and parameters by DS records [RFC4034] with 499 Digest Type = QRP (201). The Key Tag is used to specify a Port number. 500 The Algorithm field is set to NACL (204) or zero. The Digest is a list 501 of Name / Key pairs : a lower case name server name relative to the zone 502 followed by the 32-byte public key. If the Algorithm is zero, there is 503 no public key, and encryption / authentication is not available. 505 For example: 507 example.com. 86400 DS ( 508 53 ; Port Number ( normally Key Tag ) 509 204 ; Algorithm = NACL 510 201 ; Digest Type = QRP 511 01 61 02 6E 73 00 ; Name server = a.ns.example.com. 512 94B745D819AA0C50 3B2F06FC566250F4 513 5E004F7D2BD69280 F96EC89E7FB40A6E ; 32 byte public key 514 01 62 02 6E 73 00 ; Name server = b.ns.example.com. 515 261EA433989353E9 1E987D5A3D3FB568 516 BCC46A8CFCF25306 0AC4A9725E4E6F4C ; 32 byte public key 517 ) 519 If the parent zone does not yet have full support for DS records, QRP 520 parameters may instead be stored in the child zone using a CDS resource 521 record, to allow partial "opportunistic" protection. The format of the 522 CDS record is identical to a DS record. Authoritative servers should 523 include the CDS RRset in the Authority section of an authoritative 524 response when DO=1, so that subsequent queries to be performed using 525 QRP. 527 4. Security Considerations 529 Fragmented responses are vulnerable to blind spoofing. If the path 530 MTU is less than the value supplied by the client, denial of service 531 attacks are possible, and data can be altered unless authenticated 532 by other means. 534 Amplification attacks from previous users of the client IP address on 535 the current user are not prevented by the protocol until the long term 536 server secret is changed, as described in section 3.3. In-path 537 (man-in-the-middle) amplification attacks are not prevented, however 538 such attacks are relatively difficult to carry out, requiring 539 the attacker to have network access close to the victim. 541 Transactions not protected as described in section 3.8 are vulnerable 542 to data alteration. Such attacks may be prevented by the use of DNSSEC. 544 Secret values need to be generated so that an attacker cannot easily 545 guess them, by using cryptographic random number generators seeded 546 from data that cannot be guessed by an attacker, such as thermal 547 noise or other random physical fluctuations. 549 5. IANA Considerations 551 The following values may be used for private testing only : 553 QRP Digest type = 201 554 NACL Algorithm = 204 555 QRP Tunnel EDNS OPTION code = 200 556 CDS resource record type = 65351 558 IANA is requested to make official reservations, to allow public 559 operation. 561 6. Acknowledgments 563 Mark Andrews, Alex Bligh, Matthew Dempsky, Robert Elz, Alfred Hoenes, 564 Douglas Otis, Nicholas Weaver and Wouter Wijngaards were each 565 instrumental in creating and refining this specification. 567 7. References 569 7.1 Normative References 571 [RFC1035] Mockapetris, P., "Domain names - implementation and 572 specification", STD 13, RFC 1035, November 1987. 574 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 575 Requirement Levels", BCP 14, RFC 2119, March 1997. 577 [RFC768] J. Postel, "User Datagram Protocol", RFC 768, 578 USC/Information Sciences Institute, August 1980. 580 [NACL] Bernstein, D., "Cryptography in NaCl", April 2009. 582 [RFC3168] Ramakrishnan, K., "The Addition of Explicit Congestion 583 Notification (ECN) to IP", September 2001. 585 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 586 "Resource Records for DNS Security Extensions", RFC 4034, 587 March 2005. 589 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 590 2671, August 1999. 592 7.2 Informative References 594 [GONT] Gont, F., "Security Assessment of the Internet Protocol 595 version 4", August 2009. 597 Appendix A. Implementation of Cookies 599 The suggested implementation of cookies is by version numbers. Each 600 RRset has a version number assigned from a 64-bit clock that is 601 increased whenever the DNS database is updated. The version of a 602 response is the largest version number of the associated RRsets. The 603 cookie is the version number. 605 If the database is updated while a transfer is progress, a COOKIE error 606 occurs, and the client restarts the transfer. 608 Alternatively, if old queries may be replayed, COOKIE errors may be 609 avoided( however such errors should be rare ). 611 Appendix B. Anycast considerations 613 Anycast DNS servers need to operate consistently. 614 There are (at least ) two possibilities: 616 (a) Each server within the Anycast system issues distinct SERVERTOKENS. 617 If the Anycast routing changes, a SERVERTOKEN error occurs, and the 618 client restarts the query. 620 (b) Each server within the Anycast system has the same long term secret, 621 and thus issues the same SERVERTOKEN to a given client. A global clock 622 is used for issuing updates. If the Anycast routing changes and an 623 update is in progress, a COOKIE error may occur, and the client has to 624 restart the query. Such errors can be avoided by not serving updates 625 until all the Anycast servers have received a copy. 627 Author's Address 629 George Barwood 630 33 Sandpiper Close 631 Gloucester 632 GL2 4LZ 633 United Kingdom 635 Phone: +44 452 722670 636 EMail: george.barwood@blueyonder.co.uk