mir/bind
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/bind9 synced 2025-09-02 07:35:26 +00:00
Code Issues Releases Wiki Activity

new draft

Browse Source
This commit is contained in:
Mark Andrews
2003-07-01 23:27:51 +00:00
parent b589c67902
commit 41e0210277
2 changed files with 208 additions and 154 deletions
Download Patch File Download Diff File Expand all files Collapse all files

294
doc/draft/draft-ietf-dnsext-dns-threats-02.txt → doc/draft/draft-ietf-dnsext-dns-threats-03.txt
View File

@@ -5,10 +5,10 @@
Network Working Group D. Atkins Network Working Group D. Atkins
draft-ietf-dnsext-dns-threats-02.txt IHTFP Consulting draft-ietf-dnsext-dns-threats-03.txt IHTFP Consulting
R. Austein R. Austein
Bourgeois Dilettant Grunchweather Associates
November 2002 June 2003
Threat Analysis Of The Domain Name System Threat Analysis Of The Domain Name System
@@ -55,9 +55,9 @@ Abstract
Atkins & Austein Expires 10 May 2003 [Page 1] Atkins & Austein Expires 29 December 2003 [Page 1]
draft-ietf-dnsext-dns-threats-02.txt November 2002 draft-ietf-dnsext-dns-threats-03.txt June 2003
1. Introduction 1. Introduction
@@ -93,7 +93,7 @@ draft-ietf-dnsext-dns-threats-02.txt November 2002
While a number of detail decisions were yet to be made (and in some While a number of detail decisions were yet to be made (and in some
cases remade after implementation experience) over the subsequent cases remade after implementation experience) over the subsequent
eight years, the basic model and design goals have remained fixed. decade, the basic model and design goals have remained fixed.
Nowhere, however, does any of the DNSSEC work attempt to specify in Nowhere, however, does any of the DNSSEC work attempt to specify in
any detail the sorts of attacks against which DNSSEC is intended to any detail the sorts of attacks against which DNSSEC is intended to
@@ -103,17 +103,17 @@ draft-ietf-dnsext-dns-threats-02.txt November 2002
published until 1995, for reasons that Bellovin explained in the published until 1995, for reasons that Bellovin explained in the
paper's epilogue [Bellovin95]. paper's epilogue [Bellovin95].
While it may seem a bit strange to publish the threat analysis eight While it may seem a bit strange to publish the threat analysis a
years after starting work on the protocol designed to defend against decade after starting work on the protocol designed to defend against
it, that is nevertheless what this note attempts to do. Better late it, that is nevertheless what this note attempts to do. Better late
than never. than never.
Atkins & Austein Expires 10 May 2003 [Page 2] Atkins & Austein Expires 29 December 2003 [Page 2]
draft-ietf-dnsext-dns-threats-02.txt November 2002 draft-ietf-dnsext-dns-threats-03.txt June 2003
This note assumes that the reader is familiar with both the DNS and This note assumes that the reader is familiar with both the DNS and
@@ -121,12 +121,12 @@ draft-ietf-dnsext-dns-threats-02.txt November 2002
For purposes of discussion, this note uses the term "DNSSEC" to refer For purposes of discussion, this note uses the term "DNSSEC" to refer
to the core hierarchical public key and signature mechanism specified to the core hierarchical public key and signature mechanism specified
in the DNSSEC documents, and refer to TKEY and TSIG as separate in the DNSSEC documents, and refers to TKEY and TSIG as separate
mechanisms, even though TKEY and TSIG are also part of the larger mechanisms, even though TKEY and TSIG are also part of the larger
problem of "securing DNS" and thus are often considered part of the problem of "securing DNS" and thus are often considered part of the
overall set of "DNS security extensions". This is an arbitrary overall set of "DNS security extensions". This is an arbitrary
distinction that in part reflects the way in which the protocol has distinction that in part reflects the way in which the protocol has
evolved (introduction of a putatively simpler transaction model evolved (introduction of a putatively simpler transaction model for
certain operations), and perhaps should be changed in a future certain operations), and perhaps should be changed in a future
revision of this note. revision of this note.
@@ -153,8 +153,8 @@ draft-ietf-dnsext-dns-threats-02.txt November 2002
may just be a means to an end for the attacker: the attacker might may just be a means to an end for the attacker: the attacker might
even chose to return the correct result in the answer section of a even chose to return the correct result in the answer section of a
reply message while using other parts of the message to set the stage reply message while using other parts of the message to set the stage
for something more complicated, for example, a name-based attack for something more complicated, for example, a name-based attack (see
(q.v., below). below).
While it certainly would be possible to sign DNS messages using TSIG While it certainly would be possible to sign DNS messages using TSIG
or IPsec, or even to encrypt them using IPsec, this would not be a or IPsec, or even to encrypt them using IPsec, this would not be a
@@ -167,9 +167,9 @@ draft-ietf-dnsext-dns-threats-02.txt November 2002
Atkins & Austein Expires 10 May 2003 [Page 3] Atkins & Austein Expires 29 December 2003 [Page 3]
draft-ietf-dnsext-dns-threats-02.txt November 2002 draft-ietf-dnsext-dns-threats-03.txt June 2003
be prohibitively high. Even more important, however, is that the be prohibitively high. Even more important, however, is that the
@@ -192,7 +192,7 @@ draft-ietf-dnsext-dns-threats-02.txt November 2002
Note that DNSSEC does not provide any protection against modification Note that DNSSEC does not provide any protection against modification
of the DNS message header, so any properly paranoid resolver must: of the DNS message header, so any properly paranoid resolver must:
- Perform all all of the DNSSEC signature checking on its own, - Perform all of the DNSSEC signature checking on its own,
- Use TSIG (or some equivalent mechanism) to insure the integrity of - Use TSIG (or some equivalent mechanism) to insure the integrity of
its communication with whatever name servers it chooses to trust, its communication with whatever name servers it chooses to trust,
@@ -223,9 +223,9 @@ draft-ietf-dnsext-dns-threats-02.txt November 2002
Atkins & Austein Expires 10 May 2003 [Page 4] Atkins & Austein Expires 29 December 2003 [Page 4]
draft-ietf-dnsext-dns-threats-02.txt November 2002 draft-ietf-dnsext-dns-threats-03.txt June 2003
most likely to be successful when the victim is in a known state, most likely to be successful when the victim is in a known state,
@@ -268,22 +268,24 @@ draft-ietf-dnsext-dns-threats-02.txt November 2002
The general form of a name-based attack is something like this: The general form of a name-based attack is something like this:
- Victim issues a query, perhaps at the instigation of the attacker - Victim issues a query, perhaps at the instigation of the attacker
or some third party; in some the query itself may be unrelated to or some third party; in some cases the query itself may be
the name under attack (ie, the attacker is just using this query as unrelated to the name under attack (that is, the attacker is just
a means to inject false information about some other name). using this query as a means to inject false information about some
other name).
- Attacker injects response, whether via packet interception, query - Attacker injects response, whether via packet interception, query
guessing, or by being a legitimate name server that's involved at guessing, or by being a legitimate name server that's involved at
some point in the process of answering the query that the victim some point in the process of answering the query that the victim
issued.
Atkins & Austein Expires 10 May 2003 [Page 5] Atkins & Austein Expires 29 December 2003 [Page 5]
draft-ietf-dnsext-dns-threats-02.txt November 2002 draft-ietf-dnsext-dns-threats-03.txt June 2003
issued.
- Attacker's response includes one or more RRs with DNS names in - Attacker's response includes one or more RRs with DNS names in
their RDATA; depending on which particular form this attack takes, their RDATA; depending on which particular form this attack takes,
the object may be to inject false data associated with those names the object may be to inject false data associated with those names
@@ -330,16 +332,16 @@ draft-ietf-dnsext-dns-threats-02.txt November 2002
Another variation on the packet interception attack is the trusted Another variation on the packet interception attack is the trusted
server that turns out not to be so trustworthy, whether by accident server that turns out not to be so trustworthy, whether by accident
or by intent. Many client machines are only configured with stub or by intent. Many client machines are only configured with stub
Atkins & Austein Expires 29 December 2003 [Page 6]
draft-ietf-dnsext-dns-threats-03.txt June 2003
resolvers, and use trusted servers to perform all of their DNS resolvers, and use trusted servers to perform all of their DNS
queries on their behalf. In many cases the trusted server is queries on their behalf. In many cases the trusted server is
Atkins & Austein Expires 10 May 2003 [Page 6]
draft-ietf-dnsext-dns-threats-02.txt November 2002
furnished by the user's ISP and advertised to the client via DHCP or furnished by the user's ISP and advertised to the client via DHCP or
PPP options. Besides accidental betrayal of this trust relationship PPP options. Besides accidental betrayal of this trust relationship
(via server bugs, successful server break-ins, etc), the server (via server bugs, successful server break-ins, etc), the server
@@ -387,15 +389,14 @@ draft-ietf-dnsext-dns-threats-02.txt November 2002
some cases can also increase the number of messages needed to answer some cases can also increase the number of messages needed to answer
a query. TSIG (and similar mechanisms) have equivalent problems. a query. TSIG (and similar mechanisms) have equivalent problems.
DNS servers are also at risk of being used as denial of service
Atkins & Austein Expires 29 December 2003 [Page 7]
Atkins & Austein Expires 10 May 2003 [Page 7]
draft-ietf-dnsext-dns-threats-02.txt November 2002 draft-ietf-dnsext-dns-threats-03.txt June 2003
DNS servers are also at risk of being used as denial of service
amplifiers, since DNS response packets tend to be significantly amplifiers, since DNS response packets tend to be significantly
longer than DNS query packets. Unsurprisingly, DNSSEC doesn't help longer than DNS query packets. Unsurprisingly, DNSSEC doesn't help
here either. here either.
@@ -414,9 +415,10 @@ draft-ietf-dnsext-dns-threats-02.txt November 2002
Arguably, in some cases, even the immediate failure of a missing RR Arguably, in some cases, even the immediate failure of a missing RR
might be considered a problem. The question remains: how serious is might be considered a problem. The question remains: how serious is
this threat? Clearly the threat does exist; general paranoia says this threat? Clearly the threat does exist; general paranoia says
that some day it'll be on the front page of the New York Times, even that some day it'll be on the front page of some major newspaper,
if we cannot conceive of a plausible scenario involving this attack even if we cannot conceive of a plausible scenario involving this
today. This implies that some mitigation of this risk is required. attack today. This implies that some mitigation of this risk is
required.
Note that it's necessary to prove the non-existance of applicable Note that it's necessary to prove the non-existance of applicable
wildcard RRs as part of the authenticated denial mechanism, and that, wildcard RRs as part of the authenticated denial mechanism, and that,
@@ -442,16 +444,17 @@ draft-ietf-dnsext-dns-threats-02.txt November 2002
- We need to prove the non-existance of any RRs which, if they - We need to prove the non-existance of any RRs which, if they
existed, would make the wildcard RR irrelevant according to the existed, would make the wildcard RR irrelevant according to the
Atkins & Austein Expires 29 December 2003 [Page 8]
draft-ietf-dnsext-dns-threats-03.txt June 2003
synthesis rules the way in which wildcards are used (that is, we synthesis rules the way in which wildcards are used (that is, we
need to prove that the synthesis rule is applicable). need to prove that the synthesis rule is applicable).
Atkins & Austein Expires 10 May 2003 [Page 8]
draft-ietf-dnsext-dns-threats-02.txt November 2002
Note that this makes the wildcard proof mechanism dependent upon the Note that this makes the wildcard proof mechanism dependent upon the
authenticated denial mechanism described in the previous section. authenticated denial mechanism described in the previous section.
@@ -497,17 +500,17 @@ draft-ietf-dnsext-dns-threats-02.txt November 2002
come close to adequately specifying how the root key rolls over, or come close to adequately specifying how the root key rolls over, or
even how it's configured in the first place. even how it's configured in the first place.
Atkins & Austein Expires 29 December 2003 [Page 9]
draft-ietf-dnsext-dns-threats-03.txt June 2003
- DNSSEC creates a requirement of loose time synchronization between - DNSSEC creates a requirement of loose time synchronization between
the resolver and the host creating the DNSSEC signatures. Prior to the resolver and the host creating the DNSSEC signatures. Prior to
DNSSEC, all time-related actions in DNS could be performed by a DNSSEC, all time-related actions in DNS could be performed by a
Atkins & Austein Expires 10 May 2003 [Page 9]
draft-ietf-dnsext-dns-threats-02.txt November 2002
machine that only knew about "elapsed" or "relative" time. Because machine that only knew about "elapsed" or "relative" time. Because
the validity period of a DNSSEC signature is based on "absolute" the validity period of a DNSSEC signature is based on "absolute"
time, a resolver must have the same concept of absolute time in time, a resolver must have the same concept of absolute time in
@@ -533,9 +536,10 @@ draft-ietf-dnsext-dns-threats-02.txt November 2002
make DNSSEC's wildcard proof mechanisms more or less fragile. make DNSSEC's wildcard proof mechanisms more or less fragile.
4. Other issues 4. Topics for Future Work
[Odds and ends that don't yet fit anywhere else, to be revised...] This section lists a few subjects not covered above which probably
need additional study, additional mechanisms, or both.
4.1. Interactions With Other Protocols 4.1. Interactions With Other Protocols
@@ -543,7 +547,7 @@ draft-ietf-dnsext-dns-threats-02.txt November 2002
the boundaries of the DNS protocol itself, since those are the the boundaries of the DNS protocol itself, since those are the
problems against (some of) which DNSSEC was intended to protect. problems against (some of) which DNSSEC was intended to protect.
There are, however, other potential problems at the boundaries where There are, however, other potential problems at the boundaries where
DNS interacts with other protocols. This topic needs further study. DNS interacts with other protocols.
4.2. Securing DNS Dynamic Update 4.2. Securing DNS Dynamic Update
@@ -552,18 +556,18 @@ draft-ietf-dnsext-dns-threats-02.txt November 2002
authenticate the updating client to the server. While TSIG does not authenticate the updating client to the server. While TSIG does not
scale very well (it requires manual configuration of shared keys scale very well (it requires manual configuration of shared keys
between the DNS name server and each TSIG client), it works well in a between the DNS name server and each TSIG client), it works well in a
Atkins & Austein Expires 29 December 2003 [Page 10]
draft-ietf-dnsext-dns-threats-03.txt June 2003
limited or closed environment such as a DHCP server updating a local limited or closed environment such as a DHCP server updating a local
DNS name server. DNS name server.
Major issues arise when trying to use dynamic update on a secure Major issues arise when trying to use dynamic update on a secure
Atkins & Austein Expires 10 May 2003 [Page 10]
draft-ietf-dnsext-dns-threats-02.txt November 2002
zone. TSIG can similarly be used in a limited fashion to zone. TSIG can similarly be used in a limited fashion to
authenticate the client to the server, but TSIG only protects DNS authenticate the client to the server, but TSIG only protects DNS
transactions, not the actual data, and the TSIG is not inserted into transactions, not the actual data, and the TSIG is not inserted into
@@ -595,7 +599,7 @@ draft-ietf-dnsext-dns-threats-02.txt November 2002
to be able to remove zones but not add them; Carol may need to be to be able to remove zones but not add them; Carol may need to be
able to add, remove, or modify nodes, but only A records. able to add, remove, or modify nodes, but only A records.
NOTE: Scaling properties of the key management problem here is a Scaling properties of the key management problem here are a
particular concern that needs more study. particular concern that needs more study.
4.3. Securing DNS Zone Replication 4.3. Securing DNS Zone Replication
@@ -608,18 +612,18 @@ draft-ietf-dnsext-dns-threats-02.txt November 2002
DNSSEC does not provide object security, because zones include DNSSEC does not provide object security, because zones include
unsigned NS RRs and glue at delegation points. Use of TSIG to unsigned NS RRs and glue at delegation points. Use of TSIG to
protect zone transfer (AXFR or IXFR) operations provides "channel protect zone transfer (AXFR or IXFR) operations provides "channel
Atkins & Austein Expires 29 December 2003 [Page 11]
draft-ietf-dnsext-dns-threats-03.txt June 2003
security", but still does not provide object security for complete security", but still does not provide object security for complete
zones, so the trust relationships involved in zone transfer are still zones, so the trust relationships involved in zone transfer are still
very much a hop-by-hop matter of name server operators trusting other very much a hop-by-hop matter of name server operators trusting other
name server operators, rather than an end-to-end matter of name name server operators, rather than an end-to-end matter of name
Atkins & Austein Expires 10 May 2003 [Page 11]
draft-ietf-dnsext-dns-threats-02.txt November 2002
server operators trusting zone administrators. server operators trusting zone administrators.
Zone object security was not an explicit design goal of DNSSEC, so Zone object security was not an explicit design goal of DNSSEC, so
@@ -640,51 +644,24 @@ Security Considerations
This entire document is about security considerations of the DNS. This entire document is about security considerations of the DNS.
The authors believe that deploying DNSSEC will help to address some, The authors believe that deploying DNSSEC will help to address some,
but not all, of the known threats to with DNS. but not all, of the known threats to the DNS.
IANA Considerations IANA Considerations
None known. None.
Acknowledgments Acknowledgments
This note is based both previous published works by others and on a This note is based both previous published works by others and on a
number of discussions both public and private over a period of many number of discussions both public and private over a period of many
years, but particular thanks go to Steve Bellovin, Dan Bernstein, years, but particular thanks go to Jaap Akkerhuis, Steve Bellovin,
Randy Bush, Olafur Gudmundsson, Allison Mankin, Paul Vixie, and any Dan Bernstein, Randy Bush, Olafur Gudmundsson, Rip Loomis, Allison
other members of the DNS, DNSSEC, DNSIND, and DNSEXT working groups Mankin, Paul Mockapetris, Mans Nilsson, Paul Vixie, Xunhua Wang, and
whose names and contributions the authors have forgotten, none of any other members of the DNS, DNSSEC, DNSIND, and DNSEXT working
whom are responsible for what the authors did with their ideas. groups whose names and contributions the authors have forgotten, none
of whom are responsible for what the authors did with their ideas.
The authors would also like to thank Paul Mockapetris and Xunhua Normative References
Wang, both of whom sent useful information to the authors, about
which the authors have, as yet, done absolutely nothing. We were
listening, really, we just ran out of time before the draft deadline.
References
[Bellovin95] Bellovin, S., "Using the Domain Name System for System
Break-Ins", Proceedings of the Fifth Usenix Unix Security
Symposium, June 1995.
Atkins & Austein Expires 10 May 2003 [Page 12]
draft-ietf-dnsext-dns-threats-02.txt November 2002
[Galvin93] Design team meeting summary message posted to dns-
security@tis.com mailing list by Jim Galvin on 19 November 1993.
[Schuba93] Schuba, C., "Addressing Weaknesses in the Domain Name
System Protocol", Master's thesis, Purdue University Department
of Computer Sciences, August 1993.
[Vixie95] Vixie, P, "DNS and BIND Security Issues", Proceedings of
the Fifth Usenix Unix Security Symposium, June 1995.
[DNS-CONCEPTS] Mockapetris, P., "Domain names - concepts and [DNS-CONCEPTS] Mockapetris, P., "Domain names - concepts and
facilities", RFC 1034, November 1987. facilities", RFC 1034, November 1987.
@@ -692,10 +669,17 @@ draft-ietf-dnsext-dns-threats-02.txt November 2002
[DNS-IMPLEMENTATION] Mockapetris, P., "Domain names - implementation [DNS-IMPLEMENTATION] Mockapetris, P., "Domain names - implementation
and specification", RFC 1035, November 1987. and specification", RFC 1035, November 1987.
Atkins & Austein Expires 29 December 2003 [Page 12]
draft-ietf-dnsext-dns-threats-03.txt June 2003
[HOST-REQUIREMENTS] Braden, R., Editor, "Requirements for Internet [HOST-REQUIREMENTS] Braden, R., Editor, "Requirements for Internet
Hosts - Application and Support", RFC 1123, October 1989. Hosts - Application and Support", RFC 1123, October 1989.
[DNS-CLARIFY] Elz, R., and Bush, R., "Clarifications to the DNS [DNS-CLARIFY] Elz, R., and R. Bush, "Clarifications to the DNS
Specification" RFC 2181, July 1997. Specification" RFC 2181, July 1997.
[NCACHE] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)" [NCACHE] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)"
@@ -707,7 +691,7 @@ draft-ietf-dnsext-dns-threats-02.txt November 2002
[EDNS0] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, [EDNS0] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
August 1999. August 1999.
[TSIG] Vixie, P., Gudmundsson, O., Eastlake, D., and Wellington, B., [TSIG] Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington,
"Secret Key Transaction Authentication for DNS (TSIG)" RFC 2845, "Secret Key Transaction Authentication for DNS (TSIG)" RFC 2845,
May 2000. May 2000.
@@ -723,24 +707,40 @@ draft-ietf-dnsext-dns-threats-02.txt November 2002
[DNSSEC-ZONE-STATUS] Lewis, E., "DNS Security Extension Clarification [DNSSEC-ZONE-STATUS] Lewis, E., "DNS Security Extension Clarification
on Zone Status" RFC 3090, March 2001. on Zone Status" RFC 3090, March 2001.
Informative References
[Bellovin95] Bellovin, S., "Using the Domain Name System for System
Break-Ins", Proceedings of the Fifth Usenix Unix Security
Symposium, June 1995.
[Galvin93] Design team meeting summary message posted to dns-
security@tis.com mailing list by Jim Galvin on 19 November 1993.
[Schuba93] Schuba, C., "Addressing Weaknesses in the Domain Name
System Protocol", Master's thesis, Purdue University Department
of Computer Sciences, August 1993.
[Vixie95] Vixie, P, "DNS and BIND Security Issues", Proceedings of
the Fifth Usenix Unix Security Symposium, June 1995.
Atkins & Austein Expires 10 May 2003 [Page 13]
Atkins & Austein Expires 29 December 2003 [Page 13]
draft-ietf-dnsext-dns-threats-02.txt November 2002 draft-ietf-dnsext-dns-threats-03.txt June 2003
[SEC-CONS] Rescorla, E., Korver, B., and the Internet Architecture [SEC-CONS] Rescorla, E., Korver, B., and the Internet Architecture
Board, "Guidelines for Writing RFC Text on Security Board, "Guidelines for Writing RFC Text on Security
Considerations", work in progress (draft-iab-sec-cons-01.txt), Considerations", work in progress (draft-iab-sec-cons-03.txt),
October 2002. January 2003.
Author's addresses: Author's addresses:
Derek Atkins Derek Atkins
IHTFP Consulting IHTFP Consulting, Inc.
6 Farragut Ave 6 Farragut Ave
Somerville, MA 02144 Somerville, MA 02144
USA USA
@@ -748,9 +748,50 @@ Author's addresses:
Email: derek@ihtfp.com Email: derek@ihtfp.com
Rob Austein Rob Austein
Grunchweather Associates
Email: sra@hactrn.net Email: sra@hactrn.net
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided 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, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it 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 contained herein is provided on an
"AS IS" basis and 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.
Atkins & Austein Expires 29 December 2003 [Page 14]
draft-ietf-dnsext-dns-threats-03.txt June 2003
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
@@ -783,4 +824,19 @@ Author's addresses:
Atkins & Austein Expires 10 May 2003 [Page 14]
Atkins & Austein Expires 29 December 2003 [Page 15]

68
doc/draft/draft-ietf-dnsext-unknown-rrs-05.txt → doc/draft/draft-ietf-dnsext-unknown-rrs-06.txt
View File

@@ -1,7 +1,7 @@
INTERNET-DRAFT Andreas Gustafsson INTERNET-DRAFT Andreas Gustafsson
draft-ietf-dnsext-unknown-rrs-05.txt Nominum Inc. draft-ietf-dnsext-unknown-rrs-06.txt Nominum Inc.
March 2003 June 2003
Updates: RFC 1034, RFC 2163, RFC 2535 Updates: RFC 1034, RFC 2163, RFC 2535
@@ -50,9 +50,9 @@ Abstract
Expires September 2003 [Page 1] Expires December 2003 [Page 1]
draft-ietf-dnsext-unknown-rrs-05.txt March 2003 draft-ietf-dnsext-unknown-rrs-06.txt June 2003
Because the deployment of new server software is slow and expensive, Because the deployment of new server software is slow and expensive,
@@ -106,9 +106,9 @@ draft-ietf-dnsext-unknown-rrs-05.txt March 2003
Expires September 2003 [Page 2] Expires December 2003 [Page 2]
draft-ietf-dnsext-unknown-rrs-05.txt March 2003 draft-ietf-dnsext-unknown-rrs-06.txt June 2003
To avoid such corruption, servers MUST NOT compress domain names To avoid such corruption, servers MUST NOT compress domain names
@@ -162,9 +162,9 @@ draft-ietf-dnsext-unknown-rrs-05.txt March 2003
Expires September 2003 [Page 3] Expires December 2003 [Page 3]
draft-ietf-dnsext-unknown-rrs-05.txt March 2003 draft-ietf-dnsext-unknown-rrs-06.txt June 2003
An unsigned decimal integer specifying the An unsigned decimal integer specifying the
@@ -218,9 +218,9 @@ draft-ietf-dnsext-unknown-rrs-05.txt March 2003
Expires September 2003 [Page 4] Expires December 2003 [Page 4]
draft-ietf-dnsext-unknown-rrs-05.txt March 2003 draft-ietf-dnsext-unknown-rrs-06.txt June 2003
As a result, when a new RR type contains one or more embedded domain As a result, when a new RR type contains one or more embedded domain
@@ -274,9 +274,9 @@ draft-ietf-dnsext-unknown-rrs-05.txt March 2003
Expires September 2003 [Page 5] Expires December 2003 [Page 5]
draft-ietf-dnsext-unknown-rrs-05.txt March 2003 draft-ietf-dnsext-unknown-rrs-06.txt June 2003
8. Additional Section Processing 8. Additional Section Processing
@@ -288,10 +288,7 @@ draft-ietf-dnsext-unknown-rrs-05.txt March 2003
9. IANA Considerations 9. IANA Considerations
The IANA is hereby requested to verify that specifications for new RR This document does not require any IANA actions.
types requesting an RR type number comply with this specification.
In particular, the IANA MUST NOT assign numbers to new RR types whose
specification allows embedded domain names to be compressed.
10. Security Considerations 10. Security Considerations
@@ -327,17 +324,17 @@ Non-normative References
Name System, C. Davis, P. Vixie, T. Goodwin, I. Dickinson, January Name System, C. Davis, P. Vixie, T. Goodwin, I. Dickinson, January
1996. 1996.
Expires September 2003 [Page 6]
draft-ietf-dnsext-unknown-rrs-05.txt March 2003
[RFC2052] - A DNS RR for specifying the location of services (DNS [RFC2052] - A DNS RR for specifying the location of services (DNS
SRV), A. Gulbrandsen, P. Vixie, October 1996. Obsoleted by RFC2782. SRV), A. Gulbrandsen, P. Vixie, October 1996. Obsoleted by RFC2782.
Expires December 2003 [Page 6]
draft-ietf-dnsext-unknown-rrs-06.txt June 2003
[RFC2136] - Dynamic Updates in the Domain Name System (DNS UPDATE), [RFC2136] - Dynamic Updates in the Domain Name System (DNS UPDATE),
P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, April 1997. P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, April 1997.
@@ -359,7 +356,7 @@ Author's Address
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2001 - 2002). All Rights Reserved. Copyright (C) The Internet Society (2001 - 2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
@@ -383,18 +380,17 @@ Full Copyright Statement
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
Expires September 2003 [Page 7]
draft-ietf-dnsext-unknown-rrs-05.txt March 2003
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Intellectual Property Statement Intellectual Property Statement
Expires December 2003 [Page 7]
draft-ietf-dnsext-unknown-rrs-06.txt June 2003
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to pertain intellectual property or other rights that might be claimed to pertain
to the implementation or use of the technology described in this to the implementation or use of the technology described in this
@@ -442,6 +438,8 @@ Intellectual Property Statement
Expires September 2003 [Page 8]
Expires December 2003 [Page 8]