idnits 2.17.1 draft-ietf-dnsind-tsig-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 129 instances of too long lines in the document, the longest one being 19 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 330: '...ror the response MUST be generated as ...' RFC 2119 keyword, line 340: '... TSIG MUST be included on the first ...' RFC 2119 keyword, line 342: '...y header, but it SHOULD be placed on a...' RFC 2119 keyword, line 352: '...ails, the client MUST close the connec...' RFC 2119 keyword, line 353: '...uently enough it SHOULD assume the con...' (12 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 163 has weird spacing: '...hm Name doma...' == Line 168 has weird spacing: '...re Size u_in...' == Line 169 has weird spacing: '... stream defi...' == Line 172 has weird spacing: '... stream unde...' == Line 184 has weird spacing: '... RdLen as ap...' == (4 more instances...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If the response RCODE is 9 (NOTAUTH), and TSIG ERROR is 18 (BADTIME) or the TSIG times in request and answer do not overlap, then this is a TIME error. This is an indication that client and server are not clock synchronized. In this case the client should log the event. DNS resolvers MUST not adjust any clocks in the client based on BADTIME errors. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 1998) is 9538 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) -- Missing reference section? 'RFC1034' on line 483 looks like a reference -- Missing reference section? 'RFC1035' on line 486 looks like a reference -- Missing reference section? 'RFC2065' on line 496 looks like a reference -- Missing reference section? 'RFC2136' on line 503 looks like a reference -- Missing reference section? 'RFC2137' on line 507 looks like a reference -- Missing reference section? 'RFC1321' on line 489 looks like a reference -- Missing reference section? 'RFC2104' on line 499 looks like a reference -- Missing reference section? 'RFC1750' on line 492 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 8 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSIND Working Group Paul Vixie (Ed.) (ISC) 3 INTERNET-DRAFT Olafur Gudmundsson (TIS) 4 Donald Eastlake 3rd (CyberCash) 5 March 1998 7 Amends: RFC 1035 9 Secret Key Transaction Signatures for DNS (TSIG) 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check the 24 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 Abstract 31 This protocol allows for transaction level authentication using 32 shared secrets and one way hashing. It can be used to authenticate 33 dynamic updates as coming from an approved client, or to authenticate 34 responses as coming from an approved recursive name server. 36 No provision has been made here for distributing the shared secrets; 37 it is expected that a network administrator will statically configure 38 name servers and clients using some out of band mechanism such as 39 sneaker-net until a secure automated mechanism for key distribution 40 is available. 42 1 - Introduction 44 1.1. The Domain Name System (DNS) [RFC1034, RFC1035] is a replicated 45 hierarchical distributed database system that provides information 46 fundamental to Internet operations, such as name <=> address translation 47 and mail handling information. DNS has recently been extended [RFC2065] 48 to provide for data origin authentication, and public key distribution, 49 all based on public key cryptography and public key based digital 50 signatures. To be practical, this form of security generally requires 51 extensive local caching of keys and tracing of authentication through 52 multiple keys and signatures to a pre-trusted locally configured key. 54 1.2. One difficulty with the [RFC2065] scheme is that common DNS 55 implementations include simple ``stub'' resolvers which do not have 56 caches. Such resolvers typically rely on a caching DNS server on 57 another host. It is impractical for these stub resolvers to perform 58 general [RFC2065] authentication and they would naturally depend on 59 their caching DNS server to perform such services for them. To do so 60 securely requires secure communication of queries and responses. 61 [RFC2065] provides public key transaction signatures to support this but 62 such signatures are very expensive computationally to generate. In 63 general, these require the same complex public key logic that is 64 impractical for stubs. This document specifies an efficient secret key 65 based transaction signature that avoids these difficulties. 67 1.3. A second area where use of straight [RFC2065] public key based 68 mechanisms may be impractical is authenticating dynamic update [RFC2136] 69 requests. [RFC2065] provides for request signatures but with [RFC2065] 70 they, like transaction signatures, require computationally expensive 71 public key cryptography and complex authentication logic. Secure Domain 72 Name System Dynamic Update ([RFC2137]) describes how different keys are 73 used in dynamically updated zones. This document's secret key based 74 signatures can be used to authenticate DNS update requests as well as 75 transaction responses, providing a lightweight alternative to the 76 protocol described by [RFC2137]. 78 1.4. A further use of this mechanishm is to protect zone transfers. In 79 this case the data covered would be the whole zone transfer including 80 any glue records sent. The protocol described by [RFC2065] does not 81 protect glue records and unsigned records unless SIG(0) (transaction 82 signature) is used. 84 1.5. The signature mechanism proposed in this document uses shared 85 secret keys to establish trust relationship between two entities. Such 86 keys must be protected in a fashion similar to private keys, lest a 87 third party masquerade as one of the intended parties (forge 88 signatures). There is an urgent need to provide simple and efficient 89 authentication between clients and local servers and this proposal 90 addresses that need. This proposal is unsuitable for general server to 91 server authentication for servers which speak with many other servers, 92 since key management would become unwieldy with the number of shared 93 keys going up quadratically. But it is suitable for many resolvers on 94 hosts that only talk to few recursive servers. 96 1.6. A server acting as an indirect caching resolver -- a ``forwarder'' 97 in common usage -- might use transaction signatures when communicating 98 with its small number of preconfigured ``upstream'' servers. Other uses 99 of DNS secret key signatures and possible systems for automatic secret 100 key distribution may be proposed in separate future documents. 102 1.7. New Assigned Numbers 104 RRTYPE = TSIG (250) 105 ERROR = 0..15 (a DNS RCODE) 106 ERROR = 16 (BADSIG) 107 ERROR = 17 (BADKEY) 108 ERROR = 18 (BADTIME) 110 2 - TSIG RR Format 112 2.1 TSIG RR Type 114 To provide secret key signatures, we use a new RR type whose mnemonic is 115 TSIG and whose type code is 250. TSIG is a meta-RR and can not be 116 stored. TSIG RRs can be used for authentication between DNS entities 117 that have established a shared secret key. TSIG RRs are dynamically 118 computed to cover a particular DNS transaction and are not DNS RRs in 119 the usual sense. 121 2.2 TSIG Calculation 123 As the TSIG RRs are related to one DNS request/response, there is no 124 value in storing or retransmitting them, thus the TSIG RR should be 125 discarded once it has been used to authenticate DNS message. The only 126 Message Digest algorithm specified in this document is ``HMAC-MD5'' (see 127 [RFC1321], [RFC2104]). Other algorithms can be specified at later date. 128 Names and definitions of new algorithms should be registered with IANA. 129 All multi-octet integers in TSIG Record are sent in network byte order 130 (see [RFC1035 2.3.2]). 132 2.3. Record Format 134 NAME A domain-like name of the key used. The name should reflect 135 the names of the hosts and uniquely identify the key among a 136 set of keys these two hosts may share at any given time. If 137 hosts A and B in same zone share a key then the key name could 138 be A-B-.. If two hosts in different zones share the 139 key the key name could be .A..B. It should 140 be possible for more than one key to be in simultaneous use 141 among a set of interacting hosts. The name only needs to be 142 meaningful to the communicating hosts but a meaningful 143 mnemonic name as above is strongly recommended. 145 The name may be used as a local index to the key involved and 146 it is recommended that it be globally unique. Where a key is 147 just shared between two hosts, its name actually only need 148 only be meaningful to them but it is recommended that the key 149 name be mnemonic and incorporate the resolver and server host 150 names in that order. 152 TYPE TSIG (250: Transaction SIGnature) 154 CLASS ANY 156 TTL 0 158 RdLen (variable) 159 RDATA 161 Field Name Data Type Notes 162 ------------------------------------------------------------------------------ 163 Algorithm Name domain-name points to an RP RR giving the 164 algorithm definer's address. 165 Time Signed u_int32_t seconds since 1-Jan-70 UTC. 166 Expire u_int32_t Time Signed + estimate of 167 RTT/2+fudge. 168 Signature Size u_int16_t number of octets in Signature. 169 Signature octet stream defined by Algorithm Name. 170 Error u_int16_t expanded RCODE covering signature processing. 171 Other Len u_int16_t length, in octets, of Other Data. 172 Other Data octet stream undefined by this protocol. 174 2.4. Example 176 NAME GW-DENVAX-0042.HOME.VIX.COM. 178 TYPE TSIG 180 CLASS ANY 182 TTL 0 184 RdLen as appropriate 186 RDATA 188 Field Name Contents 189 ------------------------------------------- 190 Algorithm Name HMAC-MD5.SIG-ALG.REG.INT. 191 Time Signed 853804800 192 Expire 853805400 193 Signature Size as appropriate 194 Signature as appropriate 195 Error 0 (NOERROR) 196 Other Len 0 197 Other Data empty 199 3 - Protocol Operation 201 3.1. Effects of adding TSIG to outgoing message 203 Once the outgoing message has been constructed, the keyed message digest 204 operation can be performed. The resulting message digest will then be 205 stored in a TSIG which is appended to the additional data section. 206 Appending a transaction signature to an DNS message is not allowed to 207 result in a truncated response; a TCP connection must be used to prevent 208 the truncation. To force a TCP connection, the server is permitted to 209 return an answer with no data only TSIG attached and TC bit set and 210 RCODE 0 (NOERROR). The client should at this point retry the request 211 using TCP (per [RFC1035 4.2.2]). 213 3.2. TSIG processing on incoming messages 215 Upon receipt of a message with a TSIG RR, the TSIG RR is copied to a 216 safe location, removed from the DNS Message, and decremented out of the 217 DNS Message Headers ARCOUNT. At this point the keyed message digest 218 operation is performed. If the algorithm name or key name is unknown to 219 the recipient, or if the message digests do not match, the whole DNS 220 Message must be discarded. A response with RCODE 9 (NOTAUTH) should be 221 sent back to the originator with TSIG ERROR 17 (BADKEY). A message to 222 the system operations log should to be generated, to warn the operations 223 staff of a possible security incident in progress. Care should be taken 224 to ensure that logging of this type of event does not open the system to 225 a denial of service attack. 227 3.3. Expire value considerations 229 If the value of expire field is in the past this transaction should be 230 assumed to be an replay attack, and RCODE 9 (NOTAUTH) should returned 231 with TSIG ERROR 18 (BADTIME). For expire to work correctly it is 232 recommended that all machines using TSIG signatures use clock 233 synchronization. If clock synchronization is not used the ``Fudge'' has 234 to be larger but ``Fudge'' should always be less than or equal to the 235 smallest TTL of the RR in the message. If the smallest TTL is 0 or 236 other very small value fudge may be set to a larger value but not 237 greater than 300. In any case ``Fudge'' should always be set to a value 238 that is less than half the reuse time of request ID's. 240 3.4. Time values used in TSIG calculations 242 The data digested includes the two timer values in the TSIG header in 243 order to prevent replay attacks. If this were not done an attacker 244 could replay old messages but update the ``Time Signed'' and ``Expire'' 245 fields to make the message look new. This data is named ``TSIG 246 Timers'', and for the purpose of digest calculation they are invoked in 247 their ``on the wire'' format, in the following order: first Time Signed, 248 then Expire. For example: 250 Field Name Decimal Value Wire Format Actual Date 251 ------------------------------------------------------------------------- 252 Time Signed 853804800 32 e4 07 00 Tue Jan 21 00:00:00 1997 253 Expire 853805400 32 e4 09 58 Tue Jan 21 00:10:00 1997 255 3.5. TSIG Variables and Coverage 257 When generating or verifying a transaction signature, the following data 258 are digested, in network byte order or wire format, depending on 259 context: 261 DNS Message 262 A whole and complete DNS message in wire format, before the TSIG RR 263 has been added to the additional data section and before the DNS 264 Message Header's ARCOUNT field has been incremented to contain the 265 TSIG RR. 267 TSIG Variables 269 Source Field Name Notes 270 -------------------------------------------------------------------- 271 TSIG RR NAME Key name, in uncompressed wire format 272 TSIG RDATA Algorythm Name in uncompressed wire format 273 TSIG RDATA Time Signed in network byte order 274 TSIG RDATA Time Expired in network byte order 275 TSIG RDATA Error in network byte order 276 TSIG RDATA Other Len in network byte order 277 TSIG RDATA Other Data exactly as transmitted 279 Request Signature 280 Response signatures will include the request signature in their 281 digest. The request's signature is digested in wire format, 282 including the following fields: 284 Field Type Description 285 --------------------------------------------------------- 286 Signature Length u_int16_t in network byte order 287 Signature Data octet stream exactly as transmitted 289 Digested components are fed into the hashing function as a continuous 290 octet stream with no interfield padding. 292 4 - Protocol Details 294 4.1. TSIG generation on requests 296 Client performs the message digest operation and appends TSIG to 297 additional data section and transmits request to server. The client 298 must store the message digest from the request while awaiting an answer. 299 Digest components for requests are: 301 DNS Message (request) 302 TSIG Variables (response) 304 Note that some older name servers will not accept requests with a 305 nonempty additional data section, but clients should only attempt signed 306 transactions against servers who are known to support TSIG and share 307 some secret key with the client -- so, this is not a problem in 308 practice. 310 4.2. TSIG on Answers 312 When a server has generated a response to a signed request, it signs the 313 response using the same algorythm and key. Digest components are: 315 Request Signature 316 DNS Message (response) 317 TSIG Variables (response) 319 4.3. TSIG on TSIG Error returns 321 When a server detects an error in TSIG checks, and the server shares a 322 secret with the client, the server should send back a signed error 323 message. Digest components are: 325 DNS Message (response) 326 TSIG Variables (response) 328 The reason that the request is not included in this digest is to make it 329 possible for the client to verify the error. If the error is not a TSIG 330 error the response MUST be generated as specified in section in 4.2. If 331 the server shares multiple secrets with the client, the server should 332 use the secret the client used if the problem was not a signature error 333 in the request, or any available shared secret otherwise. 335 4.4. TSIG on TCP connection 337 A DNS TCP session can include multiple DNS headers. This is, for 338 example commonly used by AXFR. TSIG on such a connection can be used to 339 protect the connection from hijacking and provide data integrity. The 340 TSIG MUST be included on the first and last DNS header. It can be 341 optionally placed on any intermediary header. It is expensive to 342 include it on every header, but it SHOULD be placed on at least every 343 100'th header. The first envelope is processed as a standard answer, 344 and subject messages have the following digests components: 346 Prior Digest (running) 347 DNS Message (current message) 348 TSIG Timers (current message) 350 This allows client to rapidly detect when a transfer has been altered 351 and it can close the connection at that point and retry. Once client 352 TSIG check fails, the client MUST close the connection. If the client 353 does not get TSIG frequently enough it SHOULD assume the connection has 354 been hijacked and it SHOULD close the connection. Client should treat 355 this the same way as any other interrupted transfer. 357 4.5. Server TSIG checks 359 Upon receipt of a message, server will check if there is a TSIG RR. If 360 one exists, the server is required to return a TSIG RR in the response. 361 The server MUST perform the following checks in the following order, 362 check KEY, check TIME values, check Signature. 364 4.5.1. KEY check and error handling 366 If a non-forwarding server does not recognize the key used by the client 367 the server MUST generate an error response with RCODE 9 (NOTAUTH) and 368 TSIG ERROR 17 (BADKEY). If the server and client share another key the 369 server should use the one of the other keys to sign the error message as 370 specified in section 4.3. If server does not share any secret with 371 client the server should log the error. 373 4.5.2. TIME check and Error handling 375 If the server time is outside the time interval in the request, the 376 server MUST generate an error response with RCODE 9 (NOTAUTH) and TSIG 377 ERROR 18 (BADTIME). This response MUST be signed by the same key and 378 MUST include the servers current time in the time signed field. The 379 data signed is specified in section 4.3. 381 4.5.3. Signature check and error handling 383 If TSIG fails to verify, the server MUST generate an error response as 384 specified in section 4.3 with RCODE of 9 (NOTAUTH) and TSIG ERROR 16 385 (BADSIG). The server MUST sign this error response with the same key 386 the client used. 388 4.6. Client processing of answer 390 When a client receives a response from a server it expects a TSIG from, 391 it first checks if the TSIG RR is present in the response. Otherwise 392 the response is treated as having a format error and discarded. The 393 client then extracts the TSIG, adjusts the ARCOUNT, and calculates the 394 keyed digest in the same way as the server. If the TSIG does not 395 validate, that response must be discarded, unless the RCODE is 9 396 (NOTAUTH), in which case the client should attempt to verify the 397 response as it was TSIG error as specified in section 4.3. 399 4.6.1. Key error handling 401 If an RCODE on a response is 9 (NOTAUTH), and the response TSIG 402 validates, and the TSIG key is different from the key used on the 403 request, then this is a key error. Client should retry the request 404 using the key specified by server. 406 4.6.2. Time error handling 408 If the response RCODE is 9 (NOTAUTH), and TSIG ERROR is 18 (BADTIME) or 409 the TSIG times in request and answer do not overlap, then this is a TIME 410 error. This is an indication that client and server are not clock 411 synchronized. In this case the client should log the event. DNS 412 resolvers MUST not adjust any clocks in the client based on BADTIME 413 errors. 415 4.6.3. Signature error handling 417 If the response RCODE is 9 (NOTAUTH) and TSIG ERROR is 16 (BADSIG), this 418 is a signature error, and client MAY retry the request with a new 419 request ID but it would be better to try a different shared key if one 420 is available. Client SHOULD keep track of how many times each key has 421 Signature errors. Clients should log this event. 423 4.7. Special considerations for Forwarding Server 425 A server acting as a Forwarding Server of a DNS message, should check 426 for the existence of the TSIG record. If the name on the TSIG is not of 427 a secret that the server shares with the originator the server will 428 forward the message unchanged including the TSIG. If the name of the 429 TSIG is of a key this server shares with the originator it processes the 430 TSIG. If the TSIG passes all checks, the forwarding server has the 431 obligation of including a TSIG of his own, to the destination or the 432 next forwarder. If no transaction security is available to the 433 destination and response has the AD flag (see [RFC2065]), the forwarder 434 MUST unset the AD flag before adding the TSIG to the answer. 436 5 - Shared Secrets 438 5.1. Secret keys are very sensitive information and all available steps 439 should be taken to protect them on every host on which they are stored. 440 Generally such hosts need to be physically protected. If they are 441 multi-user machines, great care should be taken that unprivileged users 442 have no access to keying material. Resolvers usually run unprivileged, 443 which means all users of a host will usually be able to see whatever 444 configuration data is used by the resolver. 446 5.2. A name server usually runs privileged, which means its 447 configuration data need not be visible to all users of the host. For 448 this reason, a host that implements transaction signatures should 449 probably be configured with a ``stub resolver'' and a local caching and 450 forwarding name server. This presents a special problem for [RFC2136] 451 which otherwise depends on clients to communicate only with a zone's 452 authoritative name servers. 454 5.3. Use of strong random shared secrets is essential to the security of 455 TSIG. See [RFC1750] for a discussion of this issue. The secret should 456 be at least as long as the keyed message digest digest, i.e., 16 bytes 457 for HMAC-MD5 or 20 bytes for HMAC-SHA1. 459 6 - Security Considerations 461 6.1. The approach specified here is computationally much less expensive 462 than the signatures specified in [RFC2065]. As long as the shared 463 secret key is not compromised, strong authentication is provided for the 464 last hop from a local name server to the user resolver. 466 6.2. Secret keys should be changed periodically. If the client host has 467 been compromised, the server should suspend the use of all secrets known 468 to that client. If possible, secrets should be stored in encrypted 469 form. Secrets should never be transmitted in the clear over any 470 network. This document does not address the issue on how to distribute 471 secrets. 473 6.3. This mechanism does not authenticate source data, only its 474 transmission between two parties who share some secret. The original 475 source data can come from a compromised zone master or can be corrupted 476 during transit from an authentic zone master to some ``caching 477 forwarder.'' However, if the server is faithfully performing the full 478 [RFC2065] security checks, then only security checked data will be 479 available to the client. 481 7 - References 483 [RFC1034] P. Mockapetris, ``Domain Names - Concepts and Facilities,'' 484 RFC 1034, ISI, November 1987. 486 [RFC1035] P. Mockapetris, ``Domain Names - Implementation and 487 Specification,'' RFC 1034, ISI, November 1987. 489 [RFC1321] R. Rivest, ``The MD5 Message-Digest Algorithm,'' RFC 1321, 490 MIT LCS & RSA Data Security, Inc., April 1992. 492 [RFC1750] D. Eastlake, S. Crocker, J. Schiller, ``Randomness 493 Recommendations for Security,'' RFC 1750, DEC, CyberCash & 494 MIT, December 1995. 496 [RFC2065] D. Eastlake , C Kaufman, ``Domain Name System Security 497 Extensions,'' RFC 2065, CyberCash & Iris, January 1997. 499 [RFC2104] H. Krawczyk, M. Bellare, R. Canetti, ``HMAC-MD5: Keyed-MD5 500 for Message Authentication,'' RFC 2104 , IBM, UCSD & IBM, 501 February 1997. 503 [RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic 504 Updates in the Domain Name System,'' RFC 2136, ISC & Bellcore 505 & Cisco & DEC, April 1997. 507 [RFC2137] D. Eastlake 3rd ``Secure Domain Name System Dynamic Update,'' 508 CyberCash, April 1997. 510 9 - Author's Addresses 512 Paul Vixie Olafur Gudmundsson 513 Internet Software Consortium Trusted Information Systems 514 950 Charter Street 3060 Washington Road, Route 97 515 Redwood City, CA 94063 Glenwood, MD 21738 516 +1 650 779 7001 +1 301 854 6889 517 519 Donald E. Eastlake 3rd. 520 CyberCash, Inc. 521 318 Acton Street 522 Carlisle, MA 01741 523 +1 978 287 4877 524