DNSEXT Working Group Olafur Gudmundsson (NAI Labs)
-INTERNET-DRAFT June 2000
+INTERNET-DRAFT October 2000
-<draft-ietf-dnsext-message-size-00.txt>
+<draft-ietf-dnsext-message-size-01.txt>
-Updates: RFC 2535
+Updates: RFC 2535, RFC 2874
Comments should be sent to the authors or the DNSEXT WG mailing list
namedroppers@ops.ietf.org
- This draft expires on December 29, 2000.
+ This draft expires on March 29, 2001.
Copyright Notice
-Expires December 2000 [Page 1]
+Expires March 2001 [Page 1]
\f
-INTERNET-DRAFT DNSSEC and IPng message size requirement June 2000
+INTERNET-DRAFT DNSSEC and IPng message size requirement October 2000
Abstract
This document mandates support for EDNS0 in DNS entities claiming to
support DNS Security Extensions and A6 records. This requirement is
necessary because these new features increase the size of DNS
- messages. If EDNS0 is not supported fallback to TCP will happen,
+ messages. If EDNS0 is not supported fall back to TCP will happen,
having a detrimental impact on query latency and DNS server load.
1 - Introduction
- Familiarity with the DNS [RFC1034, RFC1035], DNS Security Extensions
- [RFC2535], EDNS0[RFC2671] and A6 [RFCA6] is helpful.
+ Familiarity with the DNS[RFC1034, RFC1035], DNS Security
+ Extensions[RFC2535], EDNS0[RFC2671] and A6[RFC2874] is helpful.
RFC 1035[RFC1035] Section 2.3.4 requires that DNS messages over UDP
have a data payload of 512 octets or less. Most DNS software today
Compared to UDP, TCP is an expensive protocol to use for a simple
transaction like DNS: a TCP connection requires 5 packets for setup
- and teardown, excluding data packets, thus requiring at least 3
+ and tear down, excluding data packets, thus requiring at least 3
round trips on top of the one for the original UDP query. The DNS
server also needs to keep a state of the connection during this
transaction. As many DNS servers answer thousands of queries per
second, requiring them to use TCP will cause significant overhead and
delays.
+
+1.1 - DNSSEC motivations
+
DNSSEC[RFC2535] secures DNS by adding a Public Key signature on each
RR set. These signatures range in size from about 80 octets to 800
octets most are going to be in the range of 80..200 octets. The
will significantly increase the size of DNS answers from secure
zones.
+ It is important that security aware servers and resolvers get all the
+ data in Answer and Authority section in one query without truncation.
+ In some cases it is important that some Additional Data be sent
+
+
+
+Expires March 2001 [Page 2]
+\f
+INTERNET-DRAFT DNSSEC and IPng message size requirement October 2000
+
+
+ along, mainly in delegation cases.
TSIG[RFC2845] allows for the light weight authentication of DNS
messages, but increases the size of the messages by at least 70
octets. DNSSEC allows for computationally expensive message
authentication with a standard public key signature. As only one TSIG
or SIG(0) can be attached to each DNS answer the size increase of
+ message authentication is not significant, but may still lead to a
+ truncation.
+1.2 - IPv6 Motivations
-Expires December 2000 [Page 2]
-\f
-INTERNET-DRAFT DNSSEC and IPng message size requirement June 2000
-
-
- message authentication is not significant.
-
-
- IPv6 addresses[A6] are 128 bits and are represented in the DNS by
- multiple A6 records, each consisting of a domain name and a bit
+ IPv6 addresses[RFC2874] are 128 bits and are represented in the DNS
+ by multiple A6 records, each consisting of a domain name and a bit
field. The domain name refers to an address prefix that may require
additional A6 RRs to be included in the answer. Answers where
queried name has multiple A6 addresses may overflow a 512-octet UDP
packet size.
+
+1.3 Root server and TLD server motivations
+
The current number of root servers is limited to 13 as that is the
maximum number of name servers and their address records that fit in
one 512-octet DNS message. If root servers start advertising A6 or
an single 512-octet DNS message. Resulting in a large number of TCP
connections to the root servers.
+ It is important that a high level domains have a high number of
+ domain name servers for redundancy, latency and load balancing
+ reasons.
+
+
+1.4 UDP vs TCP for DNS messages
+
Given all these factors, it is essential that any implementations
that supports DNSSEC and or A6 be able to use larger DNS messages
than 512 octets.
+ The original 512 restriction was put in place to avoid fragmentation
+ of DNS responses. A fragmented UDP message that suffers a loss off
+ one of the fragments renders the answer useless and DNS must
+ retransmit the query. TCP connection requires number of round trips
+ for establishment, data transfer and tear down, but only the lost
+ data segments are retransmitted.
+
+
+
+
+Expires March 2001 [Page 3]
+\f
+INTERNET-DRAFT DNSSEC and IPng message size requirement October 2000
+
+
+ In the early days number of IP implementations did not handle
+ fragmentation well, but all modern operating systems have overcome
+ that issue thus sending fragmented messages is fine from that
+ standpoint. The open issue is the effect of losses on fragmented
+ messages. If connection has high loss ratio only TCP will allow
+ reliable transfer of DNS data, most links have low loss ratios thus
+ sending fragmented UDP packet in one round trip is better than
+ establishing a TCP connection to transfer few thousand octets.
+
+
+1.5 EDNS0 and large UDP messages
+
EDNS0[RFC2671] allows clients to declare the maximum size of UDP
message they are willing to handle. Thus, if the expected answer is
between 512 octets and the maximum size that the client can accept,
the additional overhead of a TCP connection can be avoided.
-
-1.2 - Requirements
+1.7 - Requirements
The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
in this document are to be interpreted as described in RFC 2119.
2 - Protocol changes:
- This document updates [RFC2535] and [A6].
+ This document updates [RFC2535] and [RFC2874], by adding new
+ requirements.
All RFC2535-compliant servers and resolvers MUST support EDNS0 and
- advertise message size of at least 1280 octets.
+ advertise message size of at least 1220 octets, but SHOULD advertise
+ message size of 4000. This value might be too low to get full
+ answers for high level servers and successor of this document may
+ require a larger value.
+
+ All RFC2874-compliant servers and resolver MUST support EDNS0 and
+ advertise message size of at least 1024 octets, but SHOULD advertise
+ message size of 2048.
- All [A6] compliant servers and resolver MUST support EDNS0 and
- advertise message size of at least 1280 octets.
+ All RFC2535 and RFC2874 compliant entities MUST be able to handle
+ fragmented IP and IPv6 UDP packets.
+ All hosts supporting both RFC2535 and RFC2874 MUST use the larger
+ required value in EDNS0 advertisements.
-Expires December 2000 [Page 3]
+Expires March 2001 [Page 4]
\f
-INTERNET-DRAFT DNSSEC and IPng message size requirement June 2000
+INTERNET-DRAFT DNSSEC and IPng message size requirement October 2000
3 Acknowledgments
Harald Alvestrand, Rob Austein, Randy Bush, David Conrad, Andreas
- Gustafsson, Bob Halley and Edward Lewis where instrumental in
- motivating and shaping this document.
+ Gustafsson, Bob Halley, Edward Lewis and Kazu Yamamoto where
+ instrumental in motivating and shaping this document.
4 - Security Considerations:
None
-
References:
+[RFC1034] P. Mockapetris, ``Domain Names - Concepts and Facilities''
+ STD 13, RFC 1034, November 1987.
+
[RFC1035] P. Mockapetris, ``Domain Names - Implementation and
Specification'', STD 13, RFC 1035, November 1987.
2845, May 2000.
-[A6] M. Crawford, C. Huitema, S. Thompson, ``DNS Extensions to
- Support IPv6 Address Aggregation and Renumbering'', RFCxxx,
+[RFC2874] M. Crawford, C. Huitema, S. Thompson, ``DNS Extensions to
+ Support IPv6 Address Aggregation and Renumbering'', RFC2874,
Sometime 2000.
-
-
-Expires December 2000 [Page 4]
+Expires March 2001 [Page 5]
\f
-INTERNET-DRAFT DNSSEC and IPng message size requirement June 2000
+INTERNET-DRAFT DNSSEC and IPng message size requirement October 2000
Author Address
-Expires December 2000 [Page 5]
+Expires March 2001 [Page 6]
+DNSEXT Working Group Brian Wellington (Nominum)
+INTERNET-DRAFT October 2000
-DNSIND Working Group Brian Wellington (Nominum)
-INTERNET-DRAFT May 2000
-
-<draft-ietf-dnsext-signing-auth-01.txt>
+<draft-ietf-dnsext-signing-auth-02.txt>
Updates: RFC 2535
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
- Comments should be sent to the authors or the DNSIND WG mailing list
- namedroppers@internic.net.
+ Comments should be sent to the authors or the DNSEXT WG mailing list
+ namedroppers@ops.ietf.org.
- This draft expires on November 12, 2000.
+ This draft expires on April 2, 2000.
Copyright Notice
-Expires November 2000 [Page 1]
+Expires April 2001 [Page 1]
\f
-INTERNET-DRAFT DNSSEC Signing Authority May 2000
+INTERNET-DRAFT DNSSEC Signing Authority October 2000
secure resolution process. Specifically, this affects the
authorization of keys to sign sets of records.
+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 [RFC2119].
+
1 - Introduction
SIGs may also be used for transaction security. In this case, a SIG
record with a type covered field of 0 is attached to a message, and is
used to protect message integrity. This is referred to as a SIG(0)
-[RFC2535].
+[RFC2535, RFC2931].
The following sections define requirements for all of the fields of a
SIG record. These requirements MUST be met in order for a DNSSEC
-
-
-
-
-Expires November 2000 [Page 2]
+Expires April 2001 [Page 2]
\f
-INTERNET-DRAFT DNSSEC Signing Authority May 2000
+INTERNET-DRAFT DNSSEC Signing Authority October 2000
2.1 - Type Covered
The signer's name field of a data SIG MUST contain the name of the zone
to which the data and signature belong. The combination of signer's
name, key tag, and algorithm MUST identify a zone key if the SIG is to
-be considered material. This document defines a standard policy for
-DNSSEC validation; local policy may override the standard policy.
+be considered material. The only exception that the signer's name field
+in a SIG KEY at a zone apex SHOULD contain the parent zone's name,
+unless the KEY set is self-signed. This document defines a standard
+policy for DNSSEC validation; local policy may override the standard
+policy.
-There are no restrictions on the signer field of a SIG(0) record. The
-combination of signer's name, key tag, and algorithm MUST identify a key
-if this SIG(0) is to be processed.
-Expires November 2000 [Page 3]
+Expires April 2001 [Page 3]
\f
-INTERNET-DRAFT DNSSEC Signing Authority May 2000
+INTERNET-DRAFT DNSSEC Signing Authority October 2000
+
+
+There are no restrictions on the signer field of a SIG(0) record. The
+combination of signer's name, key tag, and algorithm MUST identify a key
+if this SIG(0) is to be processed.
2.8 - Signature
The primary reason that RFC 2535 allows host and user keys to generate
material DNSSEC signatures is to allow dynamic update without online
-zone keys; that is, avoid storing private keys in an online server. The
-desire to avoid online signing keys cannot be achieved, though, because
-they are necessary to sign NXT and SOA sets [SSU]. These online zone
-keys can sign any incoming data. Removing the goal of having no online
-keys removes the reason to allow host and user keys to generate material
-Expires November 2000 [Page 4]
+Expires April 2001 [Page 4]
\f
-INTERNET-DRAFT DNSSEC Signing Authority May 2000
+INTERNET-DRAFT DNSSEC Signing Authority October 2000
-signatures. in the DNS.
+zone keys; that is, avoid storing private keys in an online server. The
+desire to avoid online signing keys cannot be achieved, though, because
+they are necessary to sign NXT and SOA sets [SSU]. These online zone
+keys can sign any incoming data. Removing the goal of having no online
+keys removes the reason to allow host and user keys to generate material
+signatures.
Limiting material signatures to zone keys simplifies the validation
process. The length of the verification chain is bounded by the name's
MUST NOT trust any signature that it generates.
-3.5 - Algorithm Number
-
-The algorithm field MUST be identical to that of the generated SIG
-record, and MUST meet all requirements for an algorithm value in a SIG
-record.
-Expires November 2000 [Page 5]
+Expires April 2001 [Page 5]
\f
-INTERNET-DRAFT DNSSEC Signing Authority May 2000
+INTERNET-DRAFT DNSSEC Signing Authority October 2000
+3.5 - Algorithm Number
+
+The algorithm field MUST be identical to that of the generated SIG
+record, and MUST meet all requirements for an algorithm value in a SIG
+record.
+
4 - Security considerations
This document defines a standard baseline for a DNSSEC capable resolver.
[RFC1035] P. Mockapetris, ``Domain Names - Implementation and
Specification,'' RFC 1035, ISI, November 1987.
+[RFC2119] S. Bradner, ``Key words for use in RFCs to Indicate
+ Requirement Levels,'' BCP 14, RFC 2119, Harvard, March 1997.
+
[RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic
Updates in the Domain Name System,'' RFC 2136, ISC & Bellcore
& Cisco & DEC, April 1997.
[RFC2535] D. Eastlake, ``Domain Name System Security Extensions,'' RFC
- 2065, IBM, March 1999.
-
-[SSU] B. Wellington, ``Simple Secure Domain Name System (DNS)
- Dynamic Update,'' draft-ietf-dnsext-simple-secure-
- update-01.txt, Nominum, May 2000.
-
+ 2535, IBM, March 1999.
+[RFC2931] D. Eastlake, ``DNS Request and Transaction Signatures (
+ SIG(0)s ),'' RFC 2931, Motorola, September 2000.
-
-
-
-
-
-
-Expires November 2000 [Page 6]
+Expires April 2001 [Page 6]
\f
-INTERNET-DRAFT DNSSEC Signing Authority May 2000
+INTERNET-DRAFT DNSSEC Signing Authority October 2000
+[SSU] B. Wellington, ``Simple Secure Domain Name System (DNS)
+ Dynamic Update,'' draft-ietf-dnsext-simple-secure-
+ update-02.txt, Nominum, October 2000.
+
7 - Author's Address
-
-
-
-
-Expires November 2000 [Page 7]
+Expires April 2001 [Page 7]
-DNSIND Working Group Brian Wellington (NAILabs)
-INTERNET-DRAFT May 2000
+DNSEXT Working Group Brian Wellington (Nominum)
+INTERNET-DRAFT October 2000
-<draft-ietf-dnsext-simple-secure-update-01.txt>
+<draft-ietf-dnsext-simple-secure-update-02.txt>
-Updates: RFC 2535, RFC 2136,
-Replaces: RFC 2137, [update2]
+Updates: RFC 2535, RFC 2136
+Replaces: RFC 2137
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
- Comments should be sent to the authors or the DNSIND WG mailing list
- namedroppers@internic.net.
+ Comments should be sent to the authors or the DNSEXT WG mailing list
+ namedroppers@ops.ietf.org.
- This draft expires on November 12, 2000.
+ This draft expires on April 2, 2000.
Copyright Notice
-Expires November 2000 [Page 1]
+Expires April 2001 [Page 1]
\f
-INTERNET-DRAFT Secure Dynamic Update May 2000
+INTERNET-DRAFT Secure Dynamic Update October 2000
to be flexible and useful while requiring as few changes to the
communication based on authenticated requests and transactions is
used to provide authorization.
+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 [RFC2119].
+
1 - Introduction
Familiarity with the DNS system [RFC1034, RFC1035] and dynamic update
[RFC2136] is helpful and is assumed by this document. In addition,
knowledge of DNS security extensions [RFC2535], SIG(0) transaction
-security [RFC2535], and TSIG transaction security [TSIG] is recommended.
-
-This document updates portions of RFC 2535, in particular section 3.1.2.
-This document obsoletes RFC 2137, an alternate proposal for secure
-dynamic update, due to implementation experience.
+security [RFC2535, RFC2931], and TSIG transaction security [RFC2845] is
+recommended.
+This document updates portions of RFC 2535, in particular section 3.1.2,
+and RFC 2136. This document obsoletes RFC 2137, an alternate proposal
+for secure dynamic update, due to implementation experience.
1.1 - Overview of DNS Dynamic Update
zone SOA serial number when an update occurs or before the next
retrieval of the SOA.
-
1.2 - Overview of DNS Transaction Security
-Exchanges of DNS messages which include TSIG [TSIG] or SIG(0) [RFC2535]
-records allow two DNS entities to authenticate DNS requests and
-responses sent between them. A TSIG MAC (message authentication code)
-is derived from a shared secret, and a SIG(0) is generated from a
-private key whose public counterpart is stored in DNS. In both cases, a
-record containing the message signature/MAC is included as the final
-resource record in a DNS message. Keyed hashes, used in TSIG, are
-inexpensive to calculate and verify. Public key encryption, as used in
-SIG(0), is more scalable as the public keys are stored in DNS.
-
+Exchanges of DNS messages which include TSIG [RFC2845] or SIG(0)
+[RFC2535, RFC2931] records allow two DNS entities to authenticate DNS
+requests and responses sent between them. A TSIG MAC (message
+authentication code) is derived from a shared secret, and a SIG(0) is
+generated from a private key whose public counterpart is stored in DNS.
+In both cases, a record containing the message signature/MAC is included
+as the final resource record in a DNS message. Keyed hashes, used in
-Expires November 2000 [Page 2]
+Expires April 2001 [Page 2]
\f
-INTERNET-DRAFT Secure Dynamic Update May 2000
+INTERNET-DRAFT Secure Dynamic Update October 2000
+TSIG, are inexpensive to calculate and verify. Public key encryption,
+as used in SIG(0), is more scalable as the public keys are stored in
+DNS.
+
1.3 - Comparison of data authentication and message authentication
Message based authentication, using TSIG or SIG(0), provides protection
to protect the data, as specified in [RFC2535]. However, if an RRset is
deleted, there is no data for a SIG to cover.
-
1.4 - Data and message signatures
As specified in [signing-auth], the DNSSEC validation process performed
The primary usefulness of host and user keys, with respect to DNSSEC, is
to authenticate messages, including dynamic updates. Thus, host and
user keys MAY be used to generate SIG(0) records to authenticate updates
-and MAY be used in the TKEY [TKEY] process to generate TSIG shared
+and MAY be used in the TKEY [RFC2930] process to generate TSIG shared
secrets. In both cases, no SIG records generated by non-zone keys will
be used in a DNSSEC validation process unless local policy dictates.
-Authentication of data, once it is present in DNS, only involves DNSSEC
-zone keys and signatures generated by them.
-
-Expires November 2000 [Page 3]
+Expires April 2001 [Page 3]
\f
-INTERNET-DRAFT Secure Dynamic Update May 2000
+INTERNET-DRAFT Secure Dynamic Update October 2000
+
+Authentication of data, once it is present in DNS, only involves DNSSEC
+zone keys and signatures generated by them.
1.5 - Signatory strength
Other TSIG, SIG(0), or dynamic update errors are returned as specified
in the appropriate protocol description.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires April 2001 [Page 4]
+\f
+INTERNET-DRAFT Secure Dynamic Update October 2000
+
+
3 - Policy
All policy is configured by the zone administrator and enforced by the
default, a principal MUST NOT be permitted to make any changes to zone
data; any permissions MUST be enabled though configuration.
-
-
-
-
-Expires November 2000 [Page 4]
-\f
-INTERNET-DRAFT Secure Dynamic Update May 2000
-
-
The policy is fully implemented in the primary zone server's
configuration for several reasons. This removes limitations imposed by
encoding policy into a fixed number of bits (such as the KEY RR's
type of policy should not affect the DNS protocol or data format, and
should not cause interoperability failures.
-
3.1 - Standard policies
Implementations SHOULD allow access control policies to use the
names. Implementations SHOULD allow per-type access control, and SHOULD
provide concise representations of all types and all ``user'' types,
where a user type is defined as one that does not affect the operation
-of DNS itself.
+
+
+
+
+
+
+
+
+
+Expires April 2001 [Page 5]
+\f
+INTERNET-DRAFT Secure Dynamic Update October 2000
+
+
+of DNS itself.
+
3.1.1 - User types
User types include all data types except SOA, NS, SIG, and NXT. SOA and
Issues concerning updates of KEY records are discussed in the Security
Considerations section.
-
-
-
-
-Expires November 2000 [Page 5]
-\f
-INTERNET-DRAFT Secure Dynamic Update May 2000
-
-
3.2 - Additional policies
Users are free to implement any policies. Policies may be as specific
4 - Interaction with DNSSEC
+Although this protocol does not change the way updates to secure zones
+are processed, there are a number of issues that should be clarified.
+
+4.1 - Adding SIGs
An authorized update request MAY include SIG records with each RRset.
Since SIG records (except SIG(0) records) MUST NOT be used for
-authentication of the update message, they are not required. If the
-updated zone is secured, the data affected by an update operation MUST
-be secured by one or more SIG records. For each RRset, if the update
-includes a valid signature by a zone key, this signature SHOULD be
-reused. Otherwise, the server MUST generate SIG records with one or
-more zone keys (of which the private components MUST be online). If
-multiple zone keys are online and an RRset requires a signature, a SIG
-MUST be generated by at least one of the zone keys.
+authentication of the update message, they are not required.
-If a principal is authorized to add SIG records and there are SIG
-records in the request, the following rules are applied. If the SIG was
-generated by a zone key for the relevant zone, verification is attempted
-(the public key must be available if the determination that it is a zone
-key was made). If successful, the SIG is retained; otherwise, the SIG
-is dropped. Otherwise, the SIG is retained without verification, since
-it is considered immaterial to the DNSSEC validation process. The
-server MAY examine SIG records and drop SIGs with a temporal validity
-period in the past. At the completion of the update process, each
-updated RRset must be signed in accordance with the zone's signing
-policy; the SIGs must either be included in the update or generated by
-the server.
-
-The server MUST also, if necessary, generate a new SOA record and new
-NXT records, and sign these with the appropriate zone keys. NXT records
-are explicitly forbidden. SOA updates are allowed, since the
-maintenance of SOA parameters is outside of the scope of the DNS
-protocol.
+If a principal is authorized to update SIG records and there are SIG
+records in the update, the SIG records are added without verification.
+The server MAY examine SIG records and drop SIGs with a temporal
+validity period in the past.
+4.2 - Deleting SIGs
+If a principal is authorized to update SIG records and the update
+specifies the deletion of SIG records, the server MAY choose to override
+the authority and refuse the update. For example, the server may allow
+Expires April 2001 [Page 6]
+\f
+INTERNET-DRAFT Secure Dynamic Update October 2000
+all SIG records not generated by a zone key to be deleted.
+4.3 - Non-explicit updates to SIGs
+If the updated zone is secured, the RRset affected by an update
+operation MUST, at the completion of the update, be signed in accordance
+with the zone's signing policy. This will usually require one or more
+SIG records to be generated by one or more zone keys whose private
+components MUST be online [signing-auth].
+When the contents of an RRset are updated, the server MAY delete all
+associated SIG records, since they will no longer be valid.
-Expires November 2000 [Page 6]
-\f
-INTERNET-DRAFT Secure Dynamic Update May 2000
+4.4 - Effects on the zone
+If any changes are made, the server MUST, if necessary, generate a new
+SOA record and new NXT records, and sign these with the appropriate zone
+keys. Changes to NXT records by secure dynamic update are explicitly
+forbidden. SOA updates are allowed, since the maintenance of SOA
+parameters is outside of the scope of the DNS protocol.
5 - Security considerations
The author would like to thank the following people for review and
informative comments (in alphabetical order):
+ Harald Alvestrand
Donald Eastlake
Olafur Gudmundsson
Andreas Gustafsson
Ed Lewis
+
+
+
+Expires April 2001 [Page 7]
+\f
+INTERNET-DRAFT Secure Dynamic Update October 2000
+
+
7 - References
[RFC1034] P. Mockapetris, ``Domain Names - Concepts and Facilities,''
2137, CyberCash, April 1997.
[RFC2535] D. Eastlake, ``Domain Name System Security Extensions,'' RFC
- 2065, IBM, March 1999.
+ 2535, IBM, March 1999.
-[TSIG] P. Vixie (Ed.), O. Gudmundsson, D. Eastlake, B. Wellington
- ``Secret Key Transaction Signatures for DNS (TSIG),'' draft-
- ietf-dnsext-tsig-00.txt, ISC & NAILabs & IBM & NAILabs, March
- 2000.
+[RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington ``Secret
+ Key Transaction Signatures for DNS (TSIG),'' RFC 2845, ISC &
+ NAILabs & Motorola & Nominum, May 2000.
+[RFC2930] D. Eastlake ``Secret Key Establishment for DNS (TKEY RR),''
+ RFC 2930, Motorola, September 2000.
+[RFC2931] D. Eastlake ``DNS Request and Transaction Signatures (
+ SIG(0)s ),'' RFC 2931, Motorola, September 2000.
+
+[signing-auth]
+ B. Wellington ``Domain Name System Security (DNSSEC) Signing
+ Authority,'' draft-ietf-dnsext-signing-auth-02.txt, Nominum,
+ October 2000.
-Expires November 2000 [Page 7]
-\f
-INTERNET-DRAFT Secure Dynamic Update May 2000
-[TKEY] D. Eastlake ``Secret Key Establishment for DNS (TKEY RR),''
- draft-ietf-dnsext-tkey-02.txt, IBM, April 2000.
-[signing-auth]
- B. Wellington ``Domain Name System Security (DNSSEC) Signing
- Authority,'' draft-ietf-dnsext-signing-auth-01.txt, Nominum,
- May 2000.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires April 2001 [Page 8]
+\f
+INTERNET-DRAFT Secure Dynamic Update October 2000
+
8 - Author's Address
-Expires November 2000 [Page 8]
+
+
+
+
+
+
+
+
+Expires April 2001 [Page 9]
projects / thirdparty / bind9.git / commitdiff
