1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
|
DNS Extensions R. Arends
Internet-Draft Telematica Instituut
Expires: January 13, 2005 R. Austein
ISC
M. Larson
VeriSign
D. Massey
USC/ISI
S. Rose
NIST
July 15, 2004
DNS Security Introduction and Requirements
draft-ietf-dnsext-dnssec-intro-11
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 13, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
The Domain Name System Security Extensions (DNSSEC) add data origin
authentication and data integrity to the Domain Name System. This
Arends, et al. Expires January 13, 2005 [Page 1]
Internet-Draft DNSSEC Introduction and Requirements July 2004
document introduces these extensions, and describes their
capabilities and limitations. This document also discusses the
services that the DNS security extensions do and do not provide.
Last, this document describes the interrelationships between the
group of documents that collectively describe DNSSEC.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions of Important DNSSEC Terms . . . . . . . . . . . . 4
3. Services Provided by DNS Security . . . . . . . . . . . . . . 8
3.1 Data Origin Authentication and Data Integrity . . . . . . 8
3.2 Authenticating Name and Type Non-Existence . . . . . . . . 9
4. Services Not Provided by DNS Security . . . . . . . . . . . . 11
5. Scope of the DNSSEC Document Set and Last Hop Issues . . . . . 12
6. Resolver Considerations . . . . . . . . . . . . . . . . . . . 14
7. Stub Resolver Considerations . . . . . . . . . . . . . . . . . 15
8. Zone Considerations . . . . . . . . . . . . . . . . . . . . . 16
8.1 TTL values vs. RRSIG validity period . . . . . . . . . . . 16
8.2 New Temporal Dependency Issues for Zones . . . . . . . . . 16
9. Name Server Considerations . . . . . . . . . . . . . . . . . . 17
10. DNS Security Document Family . . . . . . . . . . . . . . . . 18
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19
12. Security Considerations . . . . . . . . . . . . . . . . . . 20
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
14.1 Normative References . . . . . . . . . . . . . . . . . . . . 23
14.2 Informative References . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . 26
Arends, et al. Expires January 13, 2005 [Page 2]
Internet-Draft DNSSEC Introduction and Requirements July 2004
1. Introduction
This document introduces the Domain Name System Security Extensions
(DNSSEC). This document and its two companion documents
([I-D.ietf-dnsext-dnssec-records] and
[I-D.ietf-dnsext-dnssec-protocol]) update, clarify, and refine the
security extensions defined in RFC 2535 [RFC2535] and its
predecessors. These security extensions consist of a set of new
resource record types and modifications to the existing DNS protocol
[RFC1035]. The new records and protocol modifications are not fully
described in this document, but are described in a family of
documents outlined in Section 10. Section 3 and Section 4 describe
the capabilities and limitations of the security extensions in
greater detail. Section 5 discusses the scope of the document set.
Section 6, Section 7, Section 8, and Section 9 discuss the effect
that these security extensions will have on resolvers, stub
resolvers, zones and name servers.
This document and its two companions update and obsolete RFCs 2535
[RFC2535], 3008 [RFC3008], 3090 [RFC3090], 3445 [RFC3445], 3655
[RFC3655], 3658 [RFC3658], 3755 [RFC3755], and the Work in Progress
[I-D.ietf-dnsext-nsec-rdata]. This document set also updates, but
does not obsolete, RFCs 1034 [RFC1034], 1035 [RFC1035], 2136
[RFC2136], 2181 [RFC2181], 2308 [RFC2308], 3597 [RFC3597], and parts
of 3226 [RFC3226] (dealing with DNSSEC).
The DNS security extensions provide origin authentication and
integrity protection for DNS data, as well as a means of public key
distribution. These extensions do not provide confidentiality.
Arends, et al. Expires January 13, 2005 [Page 3]
Internet-Draft DNSSEC Introduction and Requirements July 2004
2. Definitions of Important DNSSEC Terms
This section defines a number of terms used in this document set.
Since this is intended to be useful as a reference while reading the
rest of the document set, first-time readers may wish to skim this
section quickly, read the rest of this document, then come back to
this section.
Authentication Chain: An alternating sequence of DNSKEY RRsets and DS
RRsets forms a chain of signed data, with each link in the chain
vouching for the next. A DNSKEY RR is used to verify the
signature covering a DS RR and allows the DS RR to be
authenticated. The DS RR contains a hash of another DNSKEY RR and
this new DNSKEY RR is authenticated by matching the hash in the DS
RR. This new DNSKEY RR in turn authenticates another DNSKEY RRset
and, in turn, some DNSKEY RR in this set may be used to
authenticate another DS RR and so forth until the chain finally
ends with a DNSKEY RR whose corresponding private key signs the
desired DNS data. For example, the root DNSKEY RRset can be used
to authenticate the DS RRset for "example." The "example." DS
RRset contains a hash that matches some "example." DNSKEY, and
this DNSKEY's corresponding private key signs the "example."
DNSKEY RRset. Private key counterparts of the "example." DNSKEY
RRset sign data records such as "www.example." as well as DS RRs
for delegations such as "subzone.example."
Authentication Key: A public key that a security-aware resolver has
verified and can therefore use to authenticate data. A
security-aware resolver can obtain authentication keys in three
ways. First, the resolver is generally configured to know about
at least one public key; this configured data is usually either
the public key itself or a hash of the public key as found in the
DS RR (see "trust anchor"). Second, the resolver may use an
authenticated public key to verify a DS RR and the DNSKEY RR to
which the DS RR refers. Third, the resolver may be able to
determine that a new public key has been signed by the private key
corresponding to another public key which the resolver has
verified. Note that the resolver must always be guided by local
policy when deciding whether to authenticate a new public key,
even if the local policy is simply to authenticate any new public
key for which the resolver is able verify the signature.
Delegation Point: Term used to describe the name at the parental side
of a zone cut. That is, the delegation point for "foo.example"
would be the foo.example node in the "example" zone (as opposed to
the zone apex of the "foo.example" zone).
Arends, et al. Expires January 13, 2005 [Page 4]
Internet-Draft DNSSEC Introduction and Requirements July 2004
Island of Security: Term used to describe a signed, delegated zone
that does not have an authentication chain from its delegating
parent. That is, there is no DS RR containing a hash of a DNSKEY
RR for the island in its delegating parent zone (see
[I-D.ietf-dnsext-dnssec-records]). An island of security is
served by security-aware name servers and may provide
authentication chains to any delegated child zones. Responses
from an island of security or its descendents can only be
authenticated if its authentication keys can be authenticated by
some trusted means out of band from the DNS protocol.
Key Signing Key (KSK): An authentication key that corresponds to a
private key used to sign one or more other authentication keys for
a given zone. Typically, the private key corresponding to a key
signing key will sign a zone signing key, which in turn has a
corresponding private key which will sign other zone data. Local
policy may require the zone signing key to be changed frequently,
while the key signing key may have a longer validity period in
order to provide a more stable secure entry point into the zone.
Designating an authentication key as a key signing key is purely
an operational issue: DNSSEC validation does not distinguish
between key signing keys and other DNSSEC authentication keys, and
it is possible to use a single key as both a key signing key and a
zone signing key. Key signing keys are discussed in more detail
in [RFC3757]. Also see: zone signing key.
Non-Validating Security-Aware Stub Resolver: A security-aware stub
resolver which trusts one or more security-aware recursive name
servers to perform most of the tasks discussed in this document
set on its behalf. In particular, a non-validating security-aware
stub resolver is an entity which sends DNS queries, receives DNS
responses, and is capable of establishing an appropriately secured
channel to a security-aware recursive name server which will
provide these services on behalf of the security-aware stub
resolver. See also: security-aware stub resolver, validating
security-aware stub resolver.
Non-Validating Stub Resolver: A less tedious term for a
non-validating security-aware stub resolver.
Security-Aware Name Server: An entity acting in the role of a name
server (defined in section 2.4 of [RFC1034]) that understands the
DNS security extensions defined in this document set. In
particular, a security-aware name server is an entity which
receives DNS queries, sends DNS responses, supports the EDNS0
[RFC2671] message size extension and the DO bit [RFC3225], and
supports the RR types and message header bits defined in this
document set.
Arends, et al. Expires January 13, 2005 [Page 5]
Security-Aware Recursive Name Server: An entity which acts in both
the security-aware name server and security-aware resolver roles.
A more cumbersome equivalent phrase would be "a security-aware
name server which offers recursive service".
Security-Aware Resolver: An entity acting in the role of a resolver
(defined in section 2.4 of [RFC1034]) which understands the DNS
security extensions defined in this document set. In particular,
a security-aware resolver is an entity which sends DNS queries,
receives DNS responses, supports the EDNS0 [RFC2671] message size
extension and the DO bit [RFC3225], and is capable of using the RR
types and message header bits defined in this document set to
provide DNSSEC services.
Security-Aware Stub Resolver: An entity acting in the role of a stub
resolver (defined in section 5.3.1 of [RFC1034]) which has enough
of an understanding the DNS security extensions defined in this
document set to provide additional services not available from a
security-oblivious stub resolver. Security-aware stub resolvers
may be either "validating" or "non-validating" depending on
whether the stub resolver attempts to verify DNSSEC signatures on
its own or trusts a friendly security-aware name server to do so.
See also: validating stub resolver, non-validating stub resolver.
Security-Oblivious <anything>: An <anything> that is not
"security-aware".
Signed Zone: A zone whose RRsets are signed and which contains
properly constructed DNSKEY, RRSIG, NSEC and (optionally) DS
records.
Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR. A
validating security-aware resolver uses this public key or hash as
a starting point for building the authentication chain to a signed
DNS response. In general, a validating resolver will need to
obtain the initial values of its trust anchors via some secure or
trusted means outside the DNS protocol. Presence of a trust
anchor also implies that the resolver should expect the zone to
which the trust anchor points to be signed.
Unsigned Zone: A zone that is not signed.
Validating Security-Aware Stub Resolver: A security-aware resolver
that sends queries in recursive mode but which performs signature
validation on its own rather than just blindly trusting an
upstream security-aware recursive name server. See also:
security-aware stub resolver, non-validating security-aware stub
resolver.
Arends, et al. Expires January 13, 2005 [Page 6]
Internet-Draft DNSSEC Introduction and Requirements July 2004
Validating Stub Resolver: A less tedious term for a validating
security-aware stub resolver.
Zone Signing Key (ZSK): An authentication key that corresponds to a
private key used to sign a zone. Typically a zone signing key
will be part of the same DNSKEY RRset as the key signing key whose
corresponding private key signs this DNSKEY RRset, but the zone
signing key is used for a slightly different purpose, and may
differ from the key signing key in other ways, such as validity
lifetime. Designating an authentication key as a zone signing key
is purely an operational issue: DNSSEC validation does not
distinguish between zone signing keys and other DNSSEC
authentication keys, and it is possible to use a single key as
both a key signing key and a zone signing key. See also: key
signing key.
Arends, et al. Expires January 13, 2005 [Page 7]
Internet-Draft DNSSEC Introduction and Requirements July 2004
3. Services Provided by DNS Security
The Domain Name System (DNS) security extensions provide origin
authentication and integrity assurance services for DNS data,
including mechanisms for authenticated denial of existence of DNS
data. These mechanisms are described below.
These mechanisms require changes to the DNS protocol. DNSSEC adds
four new resource record types (RRSIG, DNSKEY, DS and NSEC) and two
new message header bits (CD and AD). In order to support the larger
DNS message sizes that result from adding the DNSSEC RRs, DNSSEC also
requires EDNS0 support [RFC2671]. Finally, DNSSEC requires support
for the DO bit [RFC3225], so that a security-aware resolver can
indicate in its queries that it wishes to receive DNSSEC RRs in
response messages.
These services protect against most of the threats to the Domain Name
System described in [I-D.ietf-dnsext-dns-threats].
3.1 Data Origin Authentication and Data Integrity
DNSSEC provides authentication by associating cryptographically
generated digital signatures with DNS RRsets. These digital
signatures are stored in a new resource record, the RRSIG record.
Typically, there will be a single private key that signs a zone's
data, but multiple keys are possible: for example, there may be keys
for each of several different digital signature algorithms. If a
security-aware resolver reliably learns a zone's public key, it can
authenticate that zone's signed data. An important DNSSEC concept is
that the key that signs a zone's data is associated with the zone
itself and not with the zone's authoritative name servers (public
keys for DNS transaction authentication mechanisms may also appear in
zones, as described in [RFC2931], but DNSSEC itself is concerned with
object security of DNS data, not channel security of DNS
transactions. The keys associated with transaction security may be
stored in different RR types. See [RFC3755] for details.).
A security-aware resolver can learn a zone's public key either by
having a trust anchor configured into the resolver or by normal DNS
resolution. To allow the latter, public keys are stored in a new
type of resource record, the DNSKEY RR. Note that the private keys
used to sign zone data must be kept secure, and should be stored
offline when practical to do so. To discover a public key reliably
via DNS resolution, the target key itself needs to be signed by
either a configured authentication key or another key that has been
authenticated previously. Security-aware resolvers authenticate zone
information by forming an authentication chain from a newly learned
public key back to a previously known authentication public key,
Arends, et al. Expires January 13, 2005 [Page 8]
Internet-Draft DNSSEC Introduction and Requirements July 2004
which in turn either has been configured into the resolver or must
have been learned and verified previously. Therefore, the resolver
must be configured with at least one trust anchor. If the configured
key is a zone signing key, then it will authenticate the associated
zone; if the configured key is a key signing key, it will
authenticate a zone signing key. If the resolver has been configured
with the hash of a key rather than the key itself, the resolver may
need to obtain the key via a DNS query. To help security-aware
resolvers establish this authentication chain, security-aware name
servers attempt to send the signature(s) needed to authenticate a
zone's public key(s) in the DNS reply message along with the public
key itself, provided there is space available in the message.
The Delegation Signer (DS) RR type simplifies some of the
administrative tasks involved in signing delegations across
organizational boundaries. The DS RRset resides at a delegation
point in a parent zone and indicates the public key(s) corresponding
to the private key(s) used to self-sign the DNSKEY RRset at the
delegated child zone's apex. The administrator of the child zone, in
turn, uses the private key(s) corresponding to one or more of the
public keys in this DNSKEY RRset to sign the child zone's data. The
typical authentication chain is therefore
DNSKEY->[DS->DNSKEY]*->RRset, where "*" denotes zero or more
DS->DNSKEY subchains. DNSSEC permits more complex authentication
chains, such as additional layers of DNSKEY RRs signing other DNSKEY
RRs within a zone.
A security-aware resolver normally constructs this authentication
chain from the root of the DNS hierarchy down to the leaf zones based
on configured knowledge of the public key for the root. Local
policy, however, may also allow a security-aware resolver to use one
or more configured public keys (or hashes of public keys) other than
the root public key, or may not provide configured knowledge of the
root public key, or may prevent the resolver from using particular
public keys for arbitrary reasons even if those public keys are
properly signed with verifiable signatures. DNSSEC provides
mechanisms by which a security-aware resolver can determine whether
an RRset's signature is "valid" within the meaning of DNSSEC. In the
final analysis however, authenticating both DNS keys and data is a
matter of local policy, which may extend or even override the
protocol extensions defined in this document set. See Section 5 for
further discussion.
3.2 Authenticating Name and Type Non-Existence
The security mechanism described in Section 3.1 only provides a way
to sign existing RRsets in a zone. The problem of providing negative
responses with the same level of authentication and integrity
Arends, et al. Expires January 13, 2005 [Page 9]
Internet-Draft DNSSEC Introduction and Requirements July 2004
requires the use of another new resource record type, the NSEC
record. The NSEC record allows a security-aware resolver to
authenticate a negative reply for either name or type non-existence
via the same mechanisms used to authenticate other DNS replies. Use
of NSEC records requires a canonical representation and ordering for
domain names in zones. Chains of NSEC records explicitly describe
the gaps, or "empty space", between domain names in a zone, as well
as listing the types of RRsets present at existing names. Each NSEC
record is signed and authenticated using the mechanisms described in
Section 3.1.
Arends, et al. Expires January 13, 2005 [Page 10]
Internet-Draft DNSSEC Introduction and Requirements July 2004
4. Services Not Provided by DNS Security
DNS was originally designed with the assumptions that the DNS will
return the same answer to any given query regardless of who may have
issued the query, and that all data in the DNS is thus visible.
Accordingly, DNSSEC is not designed to provide confidentiality,
access control lists, or other means of differentiating between
inquirers.
DNSSEC provides no protection against denial of service attacks.
Security-aware resolvers and security-aware name servers are
vulnerable to an additional class of denial of service attacks based
on cryptographic operations. Please see Section 12 for details.
The DNS security extensions provide data and origin authentication
for DNS data. The mechanisms outlined above are not designed to
protect operations such as zone transfers and dynamic update
[RFC3007]. Message authentication schemes described in [RFC2845] and
[RFC2931] address security operations that pertain to these
transactions.
Arends, et al. Expires January 13, 2005 [Page 11]
Internet-Draft DNSSEC Introduction and Requirements July 2004
5. Scope of the DNSSEC Document Set and Last Hop Issues
The specification in this document set defines the behavior for zone
signers and security-aware name servers and resolvers in such a way
that the validating entities can unambiguously determine the state of
the data.
A validating resolver can determine these 4 states:
Secure: The validating resolver has a trust anchor, a chain of trust
and is able to verify all the signatures in the response.
Insecure: The validating resolver has a trust anchor, a chain of
trust, and, at some delegation point, signed proof of the
non-existence of a DS record. That indicates that subsequent
branches in the tree are provably insecure. A validating resolver
may have local policy to mark parts of the domain space as
insecure.
Bogus: The validating resolver has a trust anchor and there is a
secure delegation which is indicating that subsidiary data will be
signed, but the response fails to validate due to one or more
reasons: missing signatures, expired signatures, signatures with
unsupported algorithms, data missing which the relevant NSEC RR
says should be present, and so forth.
Indeterminate: There is no trust anchor which would indicate that a
specific portion of the tree is secure. This is the default
operation mode.
This specification only defines how security aware name servers can
signal non-validating stub resolvers that data was found to be bogus
(using RCODE=2, "Server Failure" -- see
[I-D.ietf-dnsext-dnssec-protocol]).
There is a mechanism for security aware name servers to signal
security-aware stub resolvers that data was found to be secure (using
the AD bit, see [I-D.ietf-dnsext-dnssec-protocol]).
This specification does not define a format for communicating why
responses were found to be bogus or marked as insecure. The current
signaling mechanism does not distinguish between indeterminate and
insecure.
A method for signaling advanced error codes and policy between a
security aware stub resolver and security aware recursive nameservers
is a topic for future work, as is the interface between a security
aware resolver and the applications that use it. Note, however, that
Arends, et al. Expires January 13, 2005 [Page 12]
Internet-Draft DNSSEC Introduction and Requirements July 2004
the lack of the specification of such communication does not prohibit
deployment of signed zones or the deployment of security aware
recursive name servers that prohibit propagation of bogus data to the
applications.
Arends, et al. Expires January 13, 2005 [Page 13]
Internet-Draft DNSSEC Introduction and Requirements July 2004
6. Resolver Considerations
A security-aware resolver needs to be able to perform cryptographic
functions necessary to verify digital signatures using at least the
mandatory-to-implement algorithm(s). Security-aware resolvers must
also be capable of forming an authentication chain from a newly
learned zone back to an authentication key, as described above. This
process might require additional queries to intermediate DNS zones to
obtain necessary DNSKEY, DS and RRSIG records. A security-aware
resolver should be configured with at least one trust anchor as the
starting point from which it will attempt to establish authentication
chains.
If a security-aware resolver is separated from the relevant
authoritative name servers by a recursive name server or by any sort
of device which acts as a proxy for DNS, and if the recursive name
server or proxy is not security-aware, the security-aware resolver
may not be capable of operating in a secure mode. For example, if a
security-aware resolver's packets are routed through a network
address translation device that includes a DNS proxy which is not
security-aware, the security-aware resolver may find it difficult or
impossible to obtain or validate signed DNS data.
If a security-aware resolver must rely on an unsigned zone or a name
server that is not security aware, the resolver may not be able to
validate DNS responses, and will need a local policy on whether to
accept unverified responses.
A security-aware resolver should take a signature's validation period
into consideration when determining the TTL of data in its cache, to
avoid caching signed data beyond the validity period of the
signature, but should also allow for the possibility that the
security-aware resolver's own clock is wrong. Thus, a security-aware
resolver which is part of a security-aware recursive name server will
need to pay careful attention to the DNSSEC "checking disabled" (CD)
bit [I-D.ietf-dnsext-dnssec-records]. This is in order to avoid
blocking valid signatures from getting through to other
security-aware resolvers which are clients of this recursive name
server. See [I-D.ietf-dnsext-dnssec-protocol] for how a secure
recursive server handles queries with the CD bit set.
Arends, et al. Expires January 13, 2005 [Page 14]
Internet-Draft DNSSEC Introduction and Requirements July 2004
7. Stub Resolver Considerations
Although not strictly required to do so by the protocol, most DNS
queries originate from stub resolvers. Stub resolvers, by
definition, are minimal DNS resolvers which use recursive query mode
to offload most of the work of DNS resolution to a recursive name
server. Given the widespread use of stub resolvers, the DNSSEC
architecture has to take stub resolvers into account, but the
security features needed in a stub resolver differ in some respects
from those needed in a full security-aware resolver.
Even a security-oblivious stub resolver may get some benefit from
DNSSEC if the recursive name servers it uses are security-aware, but
for the stub resolver to place any real reliance on DNSSEC services,
the stub resolver must trust both the recursive name servers in
question and the communication channels between itself and those name
servers. The first of these issues is a local policy issue: in
essence, a security-oblivious stub resolver has no real choice but to
place itself at the mercy of the recursive name servers that it uses,
since it does not perform DNSSEC validity checks on its own. The
second issue requires some kind of channel security mechanism; proper
use of DNS transaction authentication mechanisms such as SIG(0) or
TSIG would suffice, as would appropriate use of IPsec, and particular
implementations may have other choices available, such as operating
system specific interprocess communication mechanisms.
Confidentiality is not needed for this channel, but data integrity
and message authentication are.
A security-aware stub resolver that does trust both its recursive
name servers and its communication channel to them may choose to
examine the setting of the AD bit in the message header of the
response messages it receives. The stub resolver can use this flag
bit as a hint to find out whether the recursive name server was able
to validate signatures for all of the data in the Answer and
Authority sections of the response.
There is one more step that a security-aware stub resolver can take
if, for whatever reason, it is not able to establish a useful trust
relationship with the recursive name servers which it uses: it can
perform its own signature validation, by setting the Checking
Disabled (CD) bit in its query messages. A validating stub resolver
is thus able to treat the DNSSEC signatures as a trust relationship
between the zone administrator and the stub resolver itself.
Arends, et al. Expires January 13, 2005 [Page 15]
Internet-Draft DNSSEC Introduction and Requirements July 2004
8. Zone Considerations
There are several differences between signed and unsigned zones. A
signed zone will contain additional security-related records (RRSIG,
DNSKEY, DS and NSEC records). RRSIG and NSEC records may be
generated by a signing process prior to serving the zone. The RRSIG
records that accompany zone data have defined inception and
expiration times, which establish a validity period for the
signatures and the zone data the signatures cover.
8.1 TTL values vs. RRSIG validity period
It is important to note the distinction between a RRset's TTL value
and the signature validity period specified by the RRSIG RR covering
that RRset. DNSSEC does not change the definition or function of the
TTL value, which is intended to maintain database coherency in
caches. A caching resolver purges RRsets from its cache no later
than the end of the time period specified by the TTL fields of those
RRsets, regardless of whether or not the resolver is security-aware.
The inception and expiration fields in the RRSIG RR
[I-D.ietf-dnsext-dnssec-records], on the other hand, specify the time
period during which the signature can be used to validate the covered
RRset. The signatures associated with signed zone data are only
valid for the time period specified by these fields in the RRSIG RRs
in question. TTL values cannot extend the validity period of signed
RRsets in a resolver's cache, but the resolver may use the time
remaining before expiration of the signature validity period of a
signed RRset as an upper bound for the TTL of the signed RRset and
its associated RRSIG RR in the resolver's cache.
8.2 New Temporal Dependency Issues for Zones
Information in a signed zone has a temporal dependency which did not
exist in the original DNS protocol. A signed zone requires regular
maintenance to ensure that each RRset in the zone has a current valid
RRSIG RR. The signature validity period of an RRSIG RR is an
interval during which the signature for one particular signed RRset
can be considered valid, and the signatures of different RRsets in a
zone may expire at different times. Re-signing one or more RRsets in
a zone will change one or more RRSIG RRs, which in turn will require
incrementing the zone's SOA serial number to indicate that a zone
change has occurred and re-signing the SOA RRset itself. Thus,
re-signing any RRset in a zone may also trigger DNS NOTIFY messages
and zone transfers operations.
Arends, et al. Expires January 13, 2005 [Page 16]
Internet-Draft DNSSEC Introduction and Requirements July 2004
9. Name Server Considerations
A security-aware name server should include the appropriate DNSSEC
records (RRSIG, DNSKEY, DS and NSEC) in all responses to queries from
resolvers which have signaled their willingness to receive such
records via use of the DO bit in the EDNS header, subject to message
size limitations. Since inclusion of these DNSSEC RRs could easily
cause UDP message truncation and fallback to TCP, a security-aware
name server must also support the EDNS "sender's UDP payload"
mechanism.
If possible, the private half of each DNSSEC key pair should be kept
offline, but this will not be possible for a zone for which DNS
dynamic update has been enabled. In the dynamic update case, the
primary master server for the zone will have to re-sign the zone when
updated, so the private key corresponding to the zone signing key
will have to be kept online. This is an example of a situation where
the ability to separate the zone's DNSKEY RRset into zone signing
key(s) and key signing key(s) may be useful, since the key signing
key(s) in such a case can still be kept offline and may have a longer
useful lifetime than the zone signing key(s).
DNSSEC, by itself, is not enough to protect the integrity of an
entire zone during zone transfer operations, since even a signed zone
contains some unsigned, nonauthoritative data if the zone has any
children. Therefore, zone maintenance operations will require some
additional mechanisms (most likely some form of channel security,
such as TSIG, SIG(0), or IPsec).
Arends, et al. Expires January 13, 2005 [Page 17]
Internet-Draft DNSSEC Introduction and Requirements July 2004
10. DNS Security Document Family
The DNSSEC document set can be partitioned into several main groups,
under the larger umbrella of the DNS base protocol documents.
The "DNSSEC protocol document set" refers to the three documents
which form the core of the DNS security extensions:
1. DNS Security Introduction and Requirements (this document)
2. Resource Records for DNS Security Extensions
[I-D.ietf-dnsext-dnssec-records]
3. Protocol Modifications for the DNS Security Extensions
[I-D.ietf-dnsext-dnssec-protocol]
Additionally, any document that would add to, or change the core DNS
Security extensions would fall into this category. This includes any
future work on the communication between security-aware stub
resolvers and upstream security-aware recursive name servers.
The "Digital Signature Algorithm Specification" document set refers
to the group of documents that describe how specific digital
signature algorithms should be implemented to fit the DNSSEC resource
record format. Each document in this set deals with a specific
digital signature algorithm.
The "Transaction Authentication Protocol" document set refers to the
group of documents that deal with DNS message authentication,
including secret key establishment and verification. While not
strictly part of the DNSSEC specification as defined in this set of
documents, this group is noted because of its relationship to DNSSEC.
The final document set, "New Security Uses", refers to documents that
seek to use proposed DNS Security extensions for other security
related purposes. DNSSEC does not provide any direct security for
these new uses, but may be used to support them. Documents that fall
in this category include the use of DNS in the storage and
distribution of certificates [RFC2538].
Arends, et al. Expires January 13, 2005 [Page 18]
Internet-Draft DNSSEC Introduction and Requirements July 2004
11. IANA Considerations
This overview document introduces no new IANA considerations. Please
see [I-D.ietf-dnsext-dnssec-records] for a complete review of the
IANA considerations introduced by DNSSEC.
Arends, et al. Expires January 13, 2005 [Page 19]
Internet-Draft DNSSEC Introduction and Requirements July 2004
12. Security Considerations
This document introduces the DNS security extensions and describes
the document set that contains the new security records and DNS
protocol modifications. The extensions provide data origin
authentication and data integrity using digital signatures over
resource record sets.This document discusses the capabilities and
limitations of these extensions.
In order for a security-aware resolver to validate a DNS response,
all zones along the path from the trusted starting point to the zone
containing the response zones must be signed, and all name servers
and resolvers involved in the resolution process must be
security-aware, as defined in this document set. A security-aware
resolver cannot verify responses originating from an unsigned zone,
from a zone not served by a security-aware name server, or for any
DNS data which the resolver is only able to obtain through a
recursive name server which is not security-aware. If there is a
break in the authentication chain such that a security-aware resolver
cannot obtain and validate the authentication keys it needs, then the
security-aware resolver cannot validate the affected DNS data.
This document briefly discusses other methods of adding security to a
DNS query, such as using a channel secured by IPsec or using a DNS
transaction authentication mechanism, but transaction security is not
part of DNSSEC per se.
A non-validating security-aware stub resolver, by definition, does
not perform DNSSEC signature validation on its own, and thus is
vulnerable both to attacks on (and by) the security-aware recursive
name servers which perform these checks on its behalf and also to
attacks on its communication with those security-aware recursive name
servers. Non-validating security-aware stub resolvers should use
some form of channel security to defend against the latter threat.
The only known defense against the former threat would be for the
security-aware stub resolver to perform its own signature validation,
at which point, again by definition, it would no longer be a
non-validating security-aware stub resolver.
DNSSEC does not protect against denial of service attacks. DNSSEC
makes DNS vulnerable to a new class of denial of service attacks
based on cryptographic operations against security-aware resolvers
and security-aware name servers, since an attacker can attempt to use
DNSSEC mechanisms to consume a victim's resources. This class of
attacks takes at least two forms. An attacker may be able to consume
resources in a security-aware resolver's signature validation code by
tampering with RRSIG RRs in response messages or by constructing
needlessly complex signature chains. An attacker may also be able to
Arends, et al. Expires January 13, 2005 [Page 20]
Internet-Draft DNSSEC Introduction and Requirements July 2004
consume resources in a security-aware name server which supports DNS
dynamic update, by sending a stream of update messages that force the
security-aware name server to re-sign some RRsets in the zone more
frequently than would otherwise be necessary.
DNSSEC does not provide confidentiality, due to a deliberate design
choice.
DNSSEC introduces the ability for a hostile party to enumerate all
the names in a zone by following the NSEC chain. NSEC RRs assert
which names do not exist in a zone by linking from existing name to
existing name along a canonical ordering of all the names within a
zone. Thus, an attacker can query these NSEC RRs in sequence to
obtain all the names in a zone. While not an attack on the DNS
itself, this could allow an attacker to map network hosts or other
resources by enumerating the contents of a zone.
DNSSEC introduces significant additional complexity to the DNS, and
thus introduces many new opportunities for implementation bugs and
misconfigured zones. In particular, enabling DNSSEC signature
validation in a resolver may cause entire legitimate zones to become
effectively unreachable due to DNSSEC configuration errors or bugs.
DNSSEC does not protect against tampering with unsigned zone data.
Non-authoritative data at zone cuts (glue and NS RRs in the parent
zone) are not signed. This does not pose a problem when validating
the authentication chain, but does mean that the non-authoritative
data itself is vulnerable to tampering during zone transfer
operations. Thus, while DNSSEC can provide data origin
authentication and data integrity for RRsets, it cannot do so for
zones, and other mechanisms must be used to protect zone transfer
operations.
Please see [I-D.ietf-dnsext-dnssec-records] and
[I-D.ietf-dnsext-dnssec-protocol] for additional security
considerations.
Arends, et al. Expires January 13, 2005 [Page 21]
Internet-Draft DNSSEC Introduction and Requirements July 2004
13. Acknowledgements
This document was created from the input and ideas of the members of
the DNS Extensions Working Group. While explicitly listing everyone
who has contributed during the decade during which DNSSEC has been
under development would be an impossible task, the editors would
particularly like to thank the following people for their
contributions to and comments on this document set: Jaap Akkerhuis,
Mark Andrews, Derek Atkins, Roy Badami, Alan Barrett, Dan Bernstein,
David Blacka, Len Budney, Randy Bush, Francis Dupont, Donald
Eastlake, Robert Elz, Miek Gieben, Michael Graff, Olafur Gudmundsson,
Gilles Guette, Andreas Gustafsson, Jun-ichiro itojun Hagino, Phillip
Hallam-Baker, Bob Halley, Ted Hardie, Walter Howard, Greg Hudson,
Christian Huitema, Johan Ihren, Stephen Jacob, Jelte Jansen, Simon
Josefsson, Andris Kalnozols, Peter Koch, Olaf Kolkman, Mark Kosters,
Suresh Krishnaswamy, Ben Laurie, David Lawrence, Ted Lemon, Ed Lewis,
Ted Lindgreen, Josh Littlefield, Rip Loomis, Bill Manning, Russ
Mundy, Mans Nilsson, Masataka Ohta, Mike Patton, Rob Payne, Jim Reid,
Michael Richardson, Erik Rozendaal, Marcos Sanz, Pekka Savola, Jakob
Schlyter, Mike StJohns, Paul Vixie, Sam Weiler, Brian Wellington, and
Suzanne Woolf.
No doubt the above list is incomplete. We apologize to anyone we
left out.
Arends, et al. Expires January 13, 2005 [Page 22]
Internet-Draft DNSSEC Introduction and Requirements July 2004
14. References
14.1 Normative References
[I-D.ietf-dnsext-dnssec-protocol]
Arends, R., Austein, R., Larson, M., Massey, D. and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", draft-ietf-dnsext-dnssec-protocol-06 (work in
progress), May 2004.
[I-D.ietf-dnsext-dnssec-records]
Arends, R., Austein, R., Larson, M., Massey, D. and S.
Rose, "Resource Records for DNS Security Extensions",
draft-ietf-dnsext-dnssec-records-08 (work in progress),
May 2004.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
2671, August 1999.
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
3225, December 2001.
[RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
message size requirements", RFC 3226, December 2001.
[RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY
Resource Record (RR)", RFC 3445, December 2002.
14.2 Informative References
[I-D.ietf-dnsext-dns-threats]
Atkins, D. and R. Austein, "Threat Analysis Of The Domain
Name System", draft-ietf-dnsext-dns-threats-07 (work in
progress), April 2004.
[I-D.ietf-dnsext-nsec-rdata]
Schlyter, J., "DNSSEC NSEC RDATA Format",
draft-ietf-dnsext-nsec-rdata-06 (work in progress), May
2004.
Arends, et al. Expires January 13, 2005 [Page 23]
Internet-Draft DNSSEC Introduction and Requirements July 2004
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
April 1997.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, March 1998.
[RFC2538] Eastlake, D. and O. Gudmundsson, "Storing Certificates in
the Domain Name System (DNS)", RFC 2538, March 1999.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B.
Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)", RFC 2845, May 2000.
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (
SIG(0)s)", RFC 2931, September 2000.
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000.
[RFC3008] Wellington, B., "Domain Name System Security (DNSSEC)
Signing Authority", RFC 3008, November 2000.
[RFC3090] Lewis, E., "DNS Security Extension Clarification on Zone
Status", RFC 3090, March 2001.
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, September 2003.
[RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS
Authenticated Data (AD) bit", RFC 3655, November 2003.
[RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record
(RR)", RFC 3658, December 2003.
[RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation
Signer", RFC 3755, April 2004.
[RFC3757] Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure
Entry Point Flag", RFC 3757, April 2004.
Arends, et al. Expires January 13, 2005 [Page 24]
Internet-Draft DNSSEC Introduction and Requirements July 2004
Authors' Addresses
Roy Arends
Telematica Instituut
Drienerlolaan 5
7522 NB Enschede
NL
EMail: roy.arends@telin.nl
Rob Austein
Internet Systems Consortium
950 Charter Street
Redwood City, CA 94063
USA
EMail: sra@isc.org
Matt Larson
VeriSign, Inc.
21345 Ridgetop Circle
Dulles, VA 20166-6503
USA
EMail: mlarson@verisign.com
Dan Massey
USC Information Sciences Institute
3811 N. Fairfax Drive
Arlington, VA 22203
USA
EMail: masseyd@isi.edu
Scott Rose
National Institute for Standards and Technology
100 Bureau Drive
Gaithersburg, MD 20899-8920
USA
EMail: scott.rose@nist.gov
Arends, et al. Expires January 13, 2005 [Page 25]
Internet-Draft DNSSEC Introduction and Requirements July 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Arends, et al. Expires January 13, 2005 [Page 26]
|