RFC 2930
Secret Key Establishment for DNS (TKEY RR)
RFC 2930: Secret Key Establishment for DNS (TKEY RR) 🎀
Okay bestie, this is RFC 2930 ✨ and the title is "Secret Key Establishment for DNS (TKEY RR)". It's a Standards Track doc from the Network Working Group, written by D. Eastlake, 3rd of Motorola 💅, and it's dated September 2000 📅. The header doesn't list anything it obsoletes or updates, so no drama there 🙈
Status of This Memo 📜
This is an Internet standards track protocol for the whole Internet community 🌐, and they're literally asking for discussion and suggestions for improvements 💖. For where this protocol stands in the standardization process, check the current edition of "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited 🦋.
Copyright Notice 🌸
Copyright (C) The Internet Society (2000). All Rights Reserved. ©️
Abstract 📝
Okay so [RFC 2845] lets you authenticate Domain Name System (DNS) queries and responses with shared secret keys, using the Transaction Signature (TSIG) resource record (RR) 🔐. BUT it has no way to set up those keys except manual exchange 😤. This doc describes a Transaction Key (TKEY) RR that can be used in a bunch of different modes to establish shared secret keys between a DNS resolver and server 🗝️✨.
Acknowledgments 🫶
Huge thanks to these amazing people, listed in alphabetical order, whose comments and ideas got folded into this doc:
- Olafur Gudmundsson (TIS)
- Stuart Kwan (Microsoft)
- Ed Lewis (TIS)
- Erik Nordmark (SUN)
- Brian Wellington (Nominum)
Table of Contents 🗂️
1. Introduction............................................... 2
1.1 Overview of Contents...................................... 3
2. The TKEY Resource Record................................... 4
2.1 The Name Field............................................ 4
2.2 The TTL Field............................................. 5
2.3 The Algorithm Field....................................... 5
2.4 The Inception and Expiration Fields....................... 5
2.5 The Mode Field............................................ 5
2.6 The Error Field........................................... 6
2.7 The Key Size and Data Fields.............................. 6
2.8 The Other Size and Data Fields............................ 6
3. General TKEY Considerations................................ 7
4. Exchange via Resolver Query................................ 8
4.1 Query for Diffie-Hellman Exchanged Keying................. 8
4.2 Query for TKEY Deletion................................... 9
4.3 Query for GSS-API Establishment........................... 10
4.4 Query for Server Assigned Keying.......................... 10
4.5 Query for Resolver Assigned Keying........................ 11
5. Spontaneous Server Inclusion............................... 12
5.1 Spontaneous Server Key Deletion........................... 12
6. Methods of Encryption...................................... 12
7. IANA Considerations........................................ 13
8. Security Considerations.................................... 13
References.................................................... 14
Author's Address.............................................. 15
Full Copyright Statement...................................... 161. Introduction 🌷
The Domain Name System (DNS) is a hierarchical, distributed, highly available database 🗄️. It's used for bi-directional mapping between domain names and addresses, for email routing, and for other information [RFC 1034, 1035]. It's been extended to provide public key security and dynamic update [RFC 2535, RFC 2136]. Familiarity with these RFCs is assumed, so go read them if you haven't 📖.
[RFC 2845] efficiently authenticates DNS messages using shared secret keys via the TSIG resource record (RR), but there's no mechanism for setting up those keys other than manual exchange 🙃. This document specifies a TKEY RR that can be used in a number of different modes to establish and delete those shared secret keys between a DNS resolver and server 🔑.
Note that TKEY established keying material and the TSIGs that use it are associated with DNS servers or resolvers 🖥️. They are not associated with zones 🙅. They can authenticate queries and responses, but they do not provide zone based DNS data origin or denial authentication [RFC 2535].
Certain modes of TKEY do encryption, which may affect their export or import status for some countries 🌍. The affected modes in this document are the server assigned mode and the resolver assigned mode.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119] 🧾.
In all cases herein, the term "resolver" includes that part of a server which may make full and incremental [RFC 1995] zone transfer queries, forwards recursive queries, etc. 🔁
1.1 Overview of Contents 🗺️
Section 2 below specifies the TKEY RR and gives a description of, and considerations for, its constituent fields 🧱.
Section 3 describes general principles of operations with TKEY 🧠.
Section 4 discusses key agreement and deletion via DNS requests with the Query opcode for RR type TKEY. This method applies to all currently defined TKEY modes, although in some cases it's not what you'd intuitively call a "query" 🤷.
Section 5 discusses spontaneous inclusion of TKEY RRs in responses by servers, which is currently used only for key deletion 🗑️.
Section 6 describes encryption methods for transmitting secret key information. In this document these are used only for the server assigned mode and the resolver assigned mode 🔐.
Section 7 covers IANA considerations in assignment of TKEY modes 📋.
Finally, Section 8 provides the required security considerations section 🛡️.
2. The TKEY Resource Record 💖
The TKEY resource record (RR) has the structure given below. Its RR type code is 249 🎀.
Field Type Comment
----- ---- -------
NAME domain see description below
TTYPE u_int16_t TKEY = 249
CLASS u_int16_t ignored, SHOULD be 255 (ANY)
TTL u_int32_t ignored, SHOULD be zero
RDLEN u_int16_t size of RDATA
RDATA:
Algorithm: domain
Inception: u_int32_t
Expiration: u_int32_t
Mode: u_int16_t
Error: u_int16_t
Key Size: u_int16_t
Key Data: octet-stream
Other Size: u_int16_t
Other Data: octet-stream undefined by this specification2.1 The Name Field 🏷️
The Name field is all about naming keys 🔖. Its meaning differs somewhat depending on mode and context, as explained in the later sections.
At any DNS server or resolver, only one octet string of keying material may be in place for any particular key name. If you try to establish another set of keying material at a server for an existing name, you get a BADNAME error 💀.
For a TKEY with a non-root name appearing in a query, the TKEY RR name SHOULD be a domain that's locally unique at the resolver, less than 128 octets long in wire encoding, and meaningful to the resolver so it can tell keys and/or key agreement sessions apart 🧩. For TKEY(s) appearing in a response to a query, the TKEY RR name SHOULD be a globally unique server assigned domain 🌍.
Here's a reasonable key naming strategy:
- If the key is generated as the result of a query with root as its owner name, then the server SHOULD create a globally unique domain name, to be the key name, by suffixing a pseudo-random [RFC 1750] label with a domain name of the server. For example:
89n3mDgX072pp.server1.example.com.If generating a new pseudo-random name in each case is an excessive computation load or entropy drain, a serial number prefix can be added to a fixed pseudo-random name generated an DNS server start time, such as1001.89n3mDgX072pp.server1.example.com.🎲 - If the key is generated as the result of a query with a non-root name, say
789.resolver.example.net, then use the concatenation of that with a name of the server. For example:789.resolver.example.net.server1.example.com.🧵
2.2 The TTL Field ⏰
The TTL field is meaningless in TKEY RRs 🙄. It SHOULD always be zero, to be sure that older DNS implementations do not cache TKEY RRs.
2.3 The Algorithm Field 🧮
The algorithm name is in the form of a domain name, with the same meaning as in [RFC 2845]. The algorithm determines how the secret keying material agreed to using the TKEY RR is actually used to derive the algorithm specific key 🔢.
2.4 The Inception and Expiration Fields 📆
The inception and expiration times are in number of seconds since the beginning of 1 January 1970 GMT, ignoring leap seconds, treated as modulo 2**32 using ring arithmetic [RFC 1982] 🕰️. In messages between a DNS resolver and a DNS server where these fields are meaningful, they are either the requested validity interval for the keying material asked for, or they specify the validity interval of keying material provided ✨.
To avoid different interpretations of the inception and expiration times in TKEY RRs, resolvers and servers exchanging them must have the same idea of what time it is ⏱️. One way of doing this is with the NTP protocol [RFC 2030], but that or any other time synchronization used for this purpose MUST be done securely 🔒.
2.5 The Mode Field 🎭
The mode field specifies the general scheme for key agreement or the purpose of the TKEY DNS message. Servers and resolvers supporting this specification MUST implement the Diffie-Hellman key agreement mode and the key deletion mode for queries. All other modes are OPTIONAL. A server supporting TKEY that receives a TKEY request with a mode it does not support returns the BADMODE error 🙅. The following values of the Mode octet are defined, available, or reserved:
Value Description
----- -----------
0 - reserved, see section 7
1 server assignment
2 Diffie-Hellman exchange
3 GSS-API negotiation
4 resolver assignment
5 key deletion
6-65534 - available, see section 7
65535 - reserved, see section 72.6 The Error Field 🚨
The error code field is an extended RCODE. The following values are defined:
Value Description
----- -----------
0 - no error
1-15 a non-extended RCODE
16 BADSIG (TSIG)
17 BADKEY (TSIG)
18 BADTIME (TSIG)
19 BADMODE
20 BADNAME
21 BADALGWhen the TKEY Error Field is non-zero in a response to a TKEY query, the DNS header RCODE field indicates no error 🤯. However, it is possible that if a TKEY is spontaneously included in a response, the TKEY RR and DNS header error field could have unrelated non-zero error codes 🌀.
2.7 The Key Size and Data Fields 📏
The key data size field is an unsigned 16 bit integer in network order, which specifies the size of the key exchange data field in octets. The meaning of this data depends on the mode 🧠.
2.8 The Other Size and Data Fields 🧩
The Other Size and Other Data fields are not used in this specification, but they may be used in future extensions 🔮. The RDLEN field MUST equal the length of the RDATA section through the end of Other Data, or the RR is to be considered malformed and rejected 🚫.
3. General TKEY Considerations ✨
okay bestie, TKEY is a meta-RR, which means it is never stored or cached in the DNS and never shows up in zone files 🫶 It's basically a behind-the-scenes helper for setting up and tearing down shared secret keys between DNS resolvers and servers. It has a bunch of modes for doing that. Setting up a shared key means both ends have to keep state, and reserving resources for that state might need mutual agreement 🧚 So if a server isn't willing to hold that state, it MUST return errors such as NOTIMP or REFUSED when someone tries to use TKEY, and resolvers are free to ignore any TKEY RRs they get 💅
The shared secret keying material you make with TKEY is just a plain octet sequence 🌸 How that material actually gets used in a given TSIG algorithm depends on the algorithm, and it's defined alongside that algorithm. For example, [RFC 2104] explains how TKEY-agreed keying material gets used with HMAC-MD5 or other HMAC algorithms 🎀
There MUST NOT be more than one TKEY RR in a DNS query or response. Not one more. 🙅♀️
Except for GSS-API mode, TKEY responses MUST always have DNS transaction authentication, because the integrity of keying data, error codes and everything else needs protecting 🔐 That authentication MUST use a previously established secret (TSIG) or public (SIG(0) [RFC 2931]) key, and it MUST NOT use any key that the response being verified is itself providing. no self-verifying, we don't do that here 💀
TKEY queries MUST be authenticated for all modes except GSS-API and, under some circumstances, server assignment mode 👑 Specifically, if the query is asking for a server-assigned key so it can assert some privilege, like update authority, then the query must be authenticated to avoid spoofing. But if the key is only for transaction security, then spoofing will lead at worst to denial of service, which is still bad but less of a disaster 😭 Query authentication SHOULD use an established secret (TSIG) key authenticator if one is available. Otherwise, it must use a public (SIG(0)) key signature. And it MUST NOT use any key that the query is itself providing 🙈
If required TKEY authentication is missing, a NOTAUTH error MUST be returned ✨
Now replay attacks, which are very not it 🥀 A TKEY response or query should not be valid if it gets replayed on the order of 232 seconds (about 136 years), or a multiple of that, later. To make that work, the keying material used in any TSIG or SIG(0) RR that authenticates a TKEY message MUST NOT have a lifetime of more than 231 - 1 seconds (about 68 years). That way, when someone tries to replay it, the authenticating TSIG or SIG(0) RR won't be verifiable because the key has expired, and the replay fails 🦋
4. Exchange via Resolver Query
okay so one way a resolver and a server can agree on shared secret keying material for TSIG is through DNS requests from the resolver that are basically DNS queries for type TKEY 💖 Those queries MUST be accompanied by a TKEY RR in the additional information section, which tells the server which mode is in use, plus any other info that mode needs 📦
Type TKEY queries SHOULD NOT be flagged as recursive, and servers MAY ignore the recursive header bit in any TKEY queries they receive 🌈
4.1 Query for Diffie-Hellman Exchanged Keying
this one is so cool 😭 Diffie-Hellman (DH) key exchange lets two parties derive some shared secret information without needing any secrecy for the messages they swap [Schneier]. Storage for DH public keys in the DNS is covered in [RFC 2539] 🧚
A resolver sends a type TKEY query with a TKEY RR in the additional information section that specifies the Diffie-Hellman mode. It also includes a KEY RR, also in the additional information section, that specifies a resolver Diffie-Hellman key 🎀 The TKEY RR algorithm field is set to the authentication algorithm the resolver plans to use. The "key data" in the TKEY is used as a random [RFC 1750] nonce, so the same pair of DH KEYs doesn't always produce the same keying material 🫶
The server response has a TKEY in its answer section with the Diffie-Hellman mode. The "key data" in this TKEY is an additional nonce, so again, the same pair of DH KEYs won't always derive the same keying material ✨ If the TKEY error field is non-zero, the query failed for the reason given. FORMERR means the query had no DH KEY, and BADKEY means the query had an incompatible DH KEY 🙈
If the TKEY error field is zero, the resolver's Diffie-Hellman KEY RR SHOULD be echoed in the additional information section, and a server Diffie-Hellman KEY RR will also show up in the answer section of the response 💅 Both parties can then compute the same shared secret quantity from the pair of Diffie-Hellman (DH) keys used [Schneier] (as long as those DH keys use the same generator and modulus), plus the data in the TKEY RRs. The TKEY RR data gets mixed with the DH result like this:
keying material =
XOR ( DH value, MD5 ( query data | DH value ) |
MD5 ( server data | DH value ) )Where XOR is an exclusive-OR operation and "|" is byte-stream concatenation 🌸 The shorter of the two XOR operands is byte-wise left justified and padded with zero-valued bytes to match the length of the other one. "DH value" is the Diffie-Hellman value derived from the KEY RRs. "query data" and "server data" are the values sent in the TKEY RR data fields. Those nonces each get suffixed with the DH value, digested by MD5, the results get concatenated, and then the whole thing is XORed with the DH value 🔥
The inception and expiry times in the query TKEY RR are the ones requested for the keying material. The inception and expiry times in the response TKEY RR are the maximum period the server will consider the keying material valid. Servers may pre-expire keys, so this is not a guarantee 🦋
4.2 Query for TKEY Deletion
keys set up via TKEY can be treated as soft state 🧚 Since DNS transactions are started by the resolver, the resolver can just toss keys, though it might have to do another key exchange if it needs one later. The server can also discard keys, but then it'll throw an error when it gets a query with a TSIG using a discarded key 💀
To avoid relying on keys that are no longer in effect, servers MUST implement key deletion. That means the server "discards" a key when it gets an authenticated delete request from a resolver for a TKEY RR with that key's name 🙅♀️ If the server has no record of a key with that name, it returns BADNAME 🍓
Key deletion TKEY queries MUST be authenticated. This authentication MAY be a TSIG RR that uses the key being deleted 🔐
For querier assigned and Diffie-Hellman keys, the server MUST truly "discard" all active state associated with the key 🫶 For server assigned keys, the server MAY simply mark the key as no longer retained by the client, and it may re-send that key in response to a future query for server assigned keying material 🌈
4.3 Query for GSS-API Establishment
this mode is described in a separate document that's still being prepared, so go read that for the full picture 📚 Basically, the resolver and server can swap queries and responses for type TKEY, with a TKEY RR that specifies the GSS-API mode in the additional information section and a GSS-API token in the key data part of the TKEY RR 💖
Any encryption of parts of the GSS-API token data being transmitted is handled by the GSS-API level. The GSS-API level also provides its own authentication, so this mode of TKEY query and response MAY be, but does not need to be, authenticated with a TSIG RR or SIG(0) RR [RFC 2931] ✨
The inception and expiry times in a GSS-API mode TKEY RR are ignored 🎀
4.4 Query for Server Assigned Keying
the server can optionally assign keying for the resolver 👑 That keying gets sent to the resolver encrypted under a resolver public key. See section 6 for the encryption methods 🔐
A resolver sends a type TKEY query with a TKEY RR specifying the "server assignment" mode, plus a resolver KEY RR to be used in encrypting the response. Both go in the additional information section. The TKEY algorithm field is set to the authentication algorithm the resolver plans to use. It is RECOMMENDED that any "key data" the resolver puts in the query TKEY RR be strongly mixed by the server with server generated randomness [RFC 1750] to derive the keying material 🌸 The KEY RR in the query doesn't need to come with a SIG(KEY) RR. If the resolver authenticates the query with a TSIG RR [RFC 2845] or SIG(0) RR and that authentication checks out, then any SIG(KEY) in the query SHOULD be ignored 🫶 The KEY RR in such a query SHOULD have a name that matches the resolver, but the only essential thing is that it's a public key the resolver has the matching private key for, so it can decrypt the response data 🦋
The server response has a TKEY RR in its answer section with the server assigned mode, and it echoes the KEY RR from the query in its additional information section 💅
If the response TKEY error field is zero, the key data part of the response TKEY RR will be the server assigned keying data, encrypted under the public key in the resolver's KEY RR. In this case, the owner name of the answer TKEY RR will be the server assigned name of the key ✨
If the error field of the response TKEY is non-zero, the query failed for the reason given. FORMERR is returned if the query specified no encryption key 🙈
The inception and expiry times in the query TKEY RR are the ones requested for the keying material. The inception and expiry times in the response TKEY are the maximum period the server will consider the keying material valid. Servers may pre-expire keys, so this is not a guarantee 🌈
The resolver KEY RR MUST be authenticated, either through authenticating this query with a TSIG or SIG(0), or by signing the resolver KEY with a SIG(KEY). Otherwise, an attacker could forge a resolver KEY for which they know the private key, and then the attacker could get a valid shared secret key from the server. this is a serious one, bestie 😭🚨
4.5 Query for Resolver Assigned Keying ✨
Okay so, a server can optionally accept keys that the resolver picked itself 🔑. Bestie, the keying material MUST be encrypted under a server key so it stays protected while it's in transit, which is covered in Section 6 🔒.
The resolver sends a TKEY query with a TKEY RR holding the encrypted keying material, plus a KEY RR that names the server public key used to encrypt the data. Both go in the additional information section 💌. The resolver fully controls the key name and the keying data, so a globally unique key name SHOULD be used 🌍. The KEY RR used MUST be one where the server has the matching private key, or it can't decrypt the keying material and will return a FORMERR 💀. It's also super important that no untrusted party (ideally nobody except the server) has that private key. If they do, they can capture the messages to the server, learn the shared secret, and spoof valid TSIGs 😱🚨.
The inception and expiry on the query's TKEY RR show the time window the querier wants to treat the keying material as valid ⏰. The server can send back a shorter interval if it won't keep state that long, and it can pre-expire keys whenever it wants 🙈.
This mode of query MUST be authenticated with a TSIG or SIG(0) 🫶. If it isn't, an attacker could forge a resolver assigned TKEY query and pick a shared secret that the server would accept, use, and honor 😭. That's a huge no-no.
5. Spontaneous Server Inclusion 🧚
A DNS server is allowed to include a TKEY RR spontaneously as additional information in its responses 💫. This SHOULD only happen if the server knows the querier understands TKEY and has this option implemented 🤝. The technique can be used to delete a key, and it may be specified for modes defined in the future 🔮. The downside is that the server has no way to get any error or success indication back. Over UDP, it can't even tell whether the DNS response reached the resolver 📭💔.
5.1 Spontaneous Server Key Deletion 🗑️
A server can optionally tell a client that it has deleted a secret key. It does this by spontaneously including a TKEY RR in the additional information section of a response, with the key's name and the key deletion mode 🫧. Such a response SHOULD be authenticated. If it is authenticated, it "deletes" the key with the given name 💅. The inception and expiry times on the delete TKEY RR get ignored ⏭️. If the client fails to receive or properly process that additional info, it might keep using a key the server already threw away, and then it'll get an error indication 😬.
For server assigned and Diffie-Hellman keys, the client MUST "discard" the active state tied to the key 🧹. For querier assigned keys, the querier MAY simply mark the key as no longer retained by the server, and it may re-send it in a future query that specifies querier assigned keying material 🔁✨.
6. Methods of Encryption 🔐
For the server assigned and resolver assigned key agreement modes, the keying material gets sent inside the key data field of a TKEY RR. It's encrypted under the public key in an accompanying KEY RR [RFC 2535] 🎀. This KEY RR MUST be for a public key algorithm where the public and private keys can be used for encryption, and the matching decryption recovers the originally encrypted data 🗝️. The KEY RR SHOULD correspond to a name for the decrypting resolver or server, so the decrypting process has access to the corresponding private key to decrypt the data 🫶. The secret keying material is usually pretty short, generally under 256 bits, because that's plenty for very strong protection with modern keyed hash or symmetric algorithms 💪.
If the KEY RR specifies the RSA algorithm, the keying material gets encrypted as described in RSAES-PKCS1-v1_5 encryption in PKCS#1 [RFC 2437] 🧁. (Heads up: the secret keying material is directly RSA encrypted in PKCS#1 format. It is not "enveloped" under some other symmetric algorithm 🙅♀️.) In the unlikely event that the keying material won't fit within one RSA modulus of the chosen public key, extra RSA encryption blocks get included 🧩. The length of each block is clear from the public RSA key specified, and the RSAES-PKCS1-v1_5 padding makes it clear which part of the encrypted data is actually keying material and which part is formatting or the required at least eight bytes of random [RFC 1750] padding 🌸.
7. IANA Considerations 📋
This section is to be interpreted as provided in [RFC 2434] 💁♀️.
Mode field values 0x0000 and 0xFFFF are reserved 🚫.
Mode field values 0x0001 through 0x00FF, and 0XFF00 through 0XFFFE can only be assigned by an IETF Standards Action 🏛️.
Mode field values 0x0100 through 0x0FFF and 0xF0000 through 0xFEFF are allocated by IESG approval or IETF consensus 🤍.
Mode field values 0x1000 through 0xEFFF are allocated based on Specification Required as defined in [RFC 2434] 📝.
Mode values should not be changed when the status of their use changes 🌷. For example, a mode value assigned based just on providing a specification should not be changed later just because that use's status is changed to standards track 🛤️.
The following assignments are documented herein 📌:
RR Type 249for TKEY 🩷.- TKEY Modes 1 through 5 as listed in section 2.5 🎀.
- Extended RCODE Error values of 19, 20, and 21 as listed in section 2.6 🌈.
8. Security Considerations 🔥
Bestie, the whole spec is about securely establishing a shared secret between DNS clients and servers, all to support TSIG [RFC 2845] 🔑👑. This part is serious!
Protection against denial of service via the use of TKEY is NOT provided. Heads up, you'll need to handle that somewhere else 🚨😭.
Wait, I need to keep that exactly as written, so here it is in its original form:
Protection against denial of service via the use of TKEY is not provided.
References 📚
- [Schneier] Bruce Schneier, "Applied Cryptography: Protocols, Algorithms, and Source Code in C", 1996, John Wiley and Sons 🧠.
- [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987 🌐.
- [RFC 1035] Mockapetris, P., "Domain Names - Implementation and Specifications", STD 13, RFC 1035, November 1987 🛠️.
- [RFC 1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994 🎲.
- [RFC 1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, September 1996 🔢.
- [RFC 1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August 1996 📦.
- [RFC 2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 2030, October 1996 ⏱️.
- [RFC 2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997 🔏.
- [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 💬.
- [RFC 2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997 🔄.
- [RFC 2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998 ✍️.
- [RFC 2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography Specifications Version 2.0", RFC 2437, October 1998 🧮.
- [RFC 2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999 🛡️.
- [RFC 2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the Domain Name System (DNS)", RFC 2539, March 1999 🤝.
- [RFC 2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000 🔐.
- [RFC 2931] Eastlake, D., "DNS Request and Transaction Signatures (SIG(0)s )", RFC 2931, September 2000 ✨.
Author's Address 💌
Donald E. Eastlake 3rd
Motorola
140 Forest Avenue
Hudson, MA 01749 USA
Phone: +1 978-562-2827 (h)
+1 508-261-5434 (w)
Fax: +1 508-261-4447 (w)
EMail: Donald.Eastlake@motorola.comFull Copyright Statement ⚖️
Copyright (C) The Internet Society (2000). All Rights Reserved. 🌸
This document and translations of it may be copied and shared with others. Derivative works that comment on or explain it, or help with implementing it, may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind 🎉. The one condition is that the above copyright notice and this paragraph are included on all such copies and derivative works 📎. However, this document itself may NOT be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations 🙅♀️. The exception is when it's needed for developing Internet standards, in which case the copyright procedures defined in the Internet Standards process must be followed. The other exception is when it's being translated into languages other than English 🌍.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns ♾️💖.
This document and the information in it are provided on an "AS IS" basis. THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 💀.
Acknowledgement 🫶
Funding for the RFC Editor function is currently provided by the Internet Society 💜.
📦 where this page comes from
- ietf: rfc2930 2000-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms