forked from bortzmeyer/dns-lg
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathdraft-daley-dns-schema.txt
2479 lines (1635 loc) · 78 KB
/
draft-daley-dns-schema.txt
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
DNS Extensions Working Group J. Daley
Internet-Draft S. Morris
Intended status: Informational Nominet UK
Expires: July 28, 2008 January 25, 2008
Schema definition for DNS
draft-daley-dns-schema-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 July 28, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This memo describes a syntax for encoding DNS Resource Records in
XML, and a schema to define that syntax written in XML Schema. It
can be used to represent all DNS RDATA. This can be used by diverse
applications as a common format.
DNS Resource Records are represented as XML elements with the name of
the element taken from the mnemonic used to represent the DNS
Resource Record in presentation format. The RDATA is represented as
Daley & Morris Expires July 28, 2008 [Page 1]
Internet-Draft dns-schema January 2008
XML attributes. The attribute names are taken from the RDATA field
names specified in the normative RFC.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements for the XML syntax for DNS RRs . . . . . . . 4
2.2. Requirements for the XML Schema to describe the XML
syntax for DNS RRs . . . . . . . . . . . . . . . . . . . . 5
2.3. Supported DNS RRs . . . . . . . . . . . . . . . . . . . . 5
2.4. Out of scope issues . . . . . . . . . . . . . . . . . . . 6
3. The XML syntax for DNS RRs . . . . . . . . . . . . . . . . . . 7
3.1. Design considerations . . . . . . . . . . . . . . . . . . 7
3.1.1. Unique element for each RR . . . . . . . . . . . . . . 7
3.1.2. RDATA representation . . . . . . . . . . . . . . . . . 7
3.1.3. RRSet element . . . . . . . . . . . . . . . . . . . . 7
3.1.4. Elements that represent RRs that can be used
inside an RRSet and standalone . . . . . . . . . . . . 8
3.1.5. Element for holding raw RR data . . . . . . . . . . . 8
4. The schema to define the XML syntax . . . . . . . . . . . . . 8
4.1. Design considerations . . . . . . . . . . . . . . . . . . 8
4.1.1. Use of XML Schema . . . . . . . . . . . . . . . . . . 8
4.1.2. Use of XML Namespaces . . . . . . . . . . . . . . . . 8
4.1.3. Base RR element and base attributes . . . . . . . . . 9
4.1.4. RDATA attribute types . . . . . . . . . . . . . . . . 9
4.1.5. RDATA attribute values . . . . . . . . . . . . . . . . 10
4.1.6. Required or optional attributes . . . . . . . . . . . 10
4.1.7. Global attribute declarations . . . . . . . . . . . . 10
4.1.8. Top level container element . . . . . . . . . . . . . 10
4.1.9. Specific attribute considerations . . . . . . . . . . 11
4.2. Limitations of the schema . . . . . . . . . . . . . . . . 14
4.2.1. Spurious attributes . . . . . . . . . . . . . . . . . 14
4.2.2. No restrictions on what RRs can be appended to an
RRset . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.3. Inconsistent or imprecise RFCs . . . . . . . . . . . . 15
4.2.4. Additional presentation formats . . . . . . . . . . . 15
4.2.5. Different wire formats for RDATA with semantic
equivalence . . . . . . . . . . . . . . . . . . . . . 15
4.3. Extending the schema . . . . . . . . . . . . . . . . . . . 15
4.3.1. The extension mechanism . . . . . . . . . . . . . . . 15
4.3.2. Creating an extension . . . . . . . . . . . . . . . . 17
4.3.3. Using an extension . . . . . . . . . . . . . . . . . . 17
4.4. Implementing new versions of the schema . . . . . . . . . 18
4.4.1. Use of version specific namespaces . . . . . . . . . . 18
4.4.2. Possible type changes in a new version . . . . . . . . 18
Daley & Morris Expires July 28, 2008 [Page 2]
Internet-Draft dns-schema January 2008
5. Semantic Web considerations . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8. Full Schema . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
10.1. Normative References . . . . . . . . . . . . . . . . . . . 40
10.2. Informative References . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43
Intellectual Property and Copyright Statements . . . . . . . . . . 44
Daley & Morris Expires July 28, 2008 [Page 3]
Internet-Draft dns-schema January 2008
1. Introduction
Historically, DNS Resource Records (RRs) have a presentation format
and wire format. The presentation format is typically used to
conveniently store DNS RRs in Human Readable Form. The wire format
is typically used in transport and communication between DNS protocol
elements.This memo describes a syntax for encoding DNS RRs in XML
[W3C.REC-XML] and a schema to define that syntax, written in XML
Schema [W3C.REC-XMLSchema-1]. This syntax and corresponding schema
definition are called dns-schema. The use case for dns-schema is to
have a set of rules to which a DNS RR must conform to, in order to
limit common mistakes in DNS Presentation Format, and to have a
common encoding between applications for DNS RRs.
TODO an example of usage.
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 [RFC2119].
1.1. Terminology
'element that represents an RR' An XML element, defined in dns-
schema that represents an RR.
2. Requirements
2.1. Requirements for the XML syntax for DNS RRs
The first requirement is to develop an XML syntax for DNS RRs, with
the following characteristics:
1. A succinct syntax for the XML wrapper around the DNS data such
that a human reading or writing it can do so as quickly and
easily as possible.
2. This syntax should use as closely as possible the presentation
format for RDATA fields given in various RFCs, even if that
reduces overall readability.
3. This syntax should be independent of any name server
implementation.
4. This syntax should use a single element for each RR.
5. This syntax should allow the encoding of an RR of unknown type as
described in [RFC3597].
Daley & Morris Expires July 28, 2008 [Page 4]
Internet-Draft dns-schema January 2008
6. This syntax should allow the encoding of any RDATA that might
appear in a datagram with the correct over structure for a DNS
datagram, even if the data contained in that datagram did not
conform to the DNS specifications. This is necessary to allow
dns-schema to be used with 'broken' DNS data.
2.2. Requirements for the XML Schema to describe the XML syntax for DNS
RRs
The second requirement, leading from the first, is to develop a
schema definition that describes the XML syntax with the following
characteristics:
1. The schema should allow conforming XML to be validated before
this XML was sent to an application, or for a server to validate
it upon receipt before any further processing.
2. This schema must not impose any restrictions on the future
definition of a new RR or a change to an existing RR.
3. This schema must allow for any new RR to be described as an
extension of it and used as easily as any RR described in it.
4. When a new version of this schema is brought out, it must be
possible for it to include new RRs or changes to existing RRs
that have been described in new RFCs, without preventing the
continuing use of any other extensions.
5. This schema should make a semantic link between RDATA fields that
represent semantically equivalent data.
2.3. Supported DNS RRs
The following RFCs and Resource Records are supported in dns-schema:
o From [RFC1035], A, CNAME, HINFO, MB, MG, MINFO, MR, MX, NS, NULL,
PTR, SOA, TXT and WKS.
o From [RFC1183], AFSDB, ISDN, RP, RT and X25.
o From [RFC1706], NSAP.
o From [RFC1712], GPOS.
o From [RFC1876], LOC.
o From [RFC2163], PX.
Daley & Morris Expires July 28, 2008 [Page 5]
Internet-Draft dns-schema January 2008
o From [RFC2230], KX.
o From [RFC2538], CERT.
o From [RFC2672], DNAME.
o From [RFC2782], SRV.
o From [RFC2845], TSIG.
o From [RFC2874], A6.
o From [RFC2930], TKEY.
o From [RFC3403], NAPTR.
o From [RFC3596], AAAA.
o From [RFC4025], IPSECKEY.
o From [RFC4034], DNSKEY, DS, NSEC and RRSIG.
o From [RFC4255], SSHFP.
o From [RFC4408], SPF.
o From [RFC4431], DLV.
o From [RFC4701], DHCID.
Obsolete DNS resource records are not supported. Neither are the NB
and NBSTAT RRs defined in [RFC1002].
2.4. Out of scope issues
There are some issues that are out of scope for this memo:
o No use is made of Master File Format [RFC1035], section 5.1.
o No use is made of the DNS header section of a DNS datagram.
o This memo speculates on possible uses of dns-schema, but does not
require any such use.
Daley & Morris Expires July 28, 2008 [Page 6]
Internet-Draft dns-schema January 2008
3. The XML syntax for DNS RRs
The syntax by which the DNS RRs is represented has been chosen
carefully to meet the given requirements of being succinct and easy
to read and write for a human. This is an example of a resource
record described in this syntax:
<A owner="example" class="IN" ttl="86400" address="192.0.2.1"/>
and this is an example of an RRSet:
<RRSet owner="example" class="IN" type="A" ttl="86400" >
<A address="192.0.2.1" />
<A address="192.0.2.2" />
</RRSet>
3.1. Design considerations
The design considerations behind this syntax are:
3.1.1. Unique element for each RR
Each DNS RR has a corresponding element. That ensures that any
schema can constrain the allowable attributes on a per RR basis. The
alternative would be to create a generic <RR> element, but in that
case a schema could not constrain the allowable attributes and would
place more emphasis on the application to validate this.
3.1.2. RDATA representation
All RDATA can be correctly represented in attributes, rather than
elements. This significantly reduces the verbosity of the XML.
For each element that represents an RR, the attributes specified
correspond to those specified in the normative RFC that defines the
RDATA for that RR. The names of the attributes are those given the
corresponding RR. For example, the MX element has the specific
attributes of 'preference' and 'exchange' as specified in [RFC1035].
3.1.3. RRSet element
An element that represents an RRSet is included, using the definition
from [RFC2136] that it is a set of RRs that share the same owner,
class and type. In addition a ttl attribute is specified because
[RFC2181] requires all the RRs in an RRSet to share the same ttl.
If an RR is ever defined with the mnemonic of 'RRSET' then this would
present future versions of dns-schema with a naming conflict.
Daley & Morris Expires July 28, 2008 [Page 7]
Internet-Draft dns-schema January 2008
3.1.4. Elements that represent RRs that can be used inside an RRSet and
standalone
The elements that represent RRs can be used standalone or inside an
RRSet. When used inside an RRSet the owner and class attributes are
superfluous and the ttl attribute may only be used subject to the
restrictions of [RFC2181].
3.1.5. Element for holding raw RR data
An element called binaryRR is included that can hold an RR of any
type. This has an attribute 'rtype' that holds the DNS type code, an
attribute 'rdlength' that holds the length of the RDATA and another
attribute 'rdata' that holds the raw rdata. An application MUST
encode the rdata in hexadecimal data encoding as specified as part of
the the presentation format of an RR of unknown type in [RFC3597].
This element can also be used to contain 'broken' DNS data,
satisfying this requirement.
4. The schema to define the XML syntax
4.1. Design considerations
The schema appears in full in Section 8. The design considerations
behind this schema are:
4.1.1. Use of XML Schema
This schema is written using XML Schemas [W3C.REC-XMLSchema-1] and
[W3C.REC-XMLSchema-2] because this is a W3C standard and provides the
necessary level of flexibility to correctly specify the preferred
syntax. Other schema languages could have been used just as well.
4.1.2. Use of XML Namespaces
XML Namespaces [W3C.REC-xml-names] need to be used in the schema to
reference the defined types. Any document validated against dns-
schema must contain a namespace reference in order for it to validate
properly. For example
<dnsSchema xmlns="urn:ietf:params:xml:ns:dns"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:dns dns-1.0.xsd">
In that example the default namespace is set to refer to elements and
attributes from dns-schema. A third party extension could be
Daley & Morris Expires July 28, 2008 [Page 8]
Internet-Draft dns-schema January 2008
included in the namespace declarations, with a specified prefix, and
so all use of the extension would be clearly identified by use of
that prefix. This is described more fully in Section 4.3
4.1.3. Base RR element and base attributes
An abstract 'RR' element is declared with a defined base type that
contains the base attributes of 'class', 'ttl' and 'owner'. All
elements that represent RRs are derived from this base element and
have a type derived from the base type. This ensures that all
elements that represent RRs have those attributes. This is achieved
using the XML Schema [W3C.REC-XMLSchema-1] feature of
substitutionGroup
This same mechanism is used by any new RRs that are created in
extensions, which ensures they are treated equally to built-in RRs
rather than needing to appear in a separate extension element. This
is covered further in Section 4.3
It should be noted that, as this is an abstract element, it cannot be
used in a conforming XML document.
4.1.4. RDATA attribute types
The type of an attribute is chosen to represent the presentation
format for the RDATA field specified in the relevant RFC. For
example a field specified as 32 bit unsigned integer is represented
using the XML Schema [W3C.REC-XMLSchema-2] type of 'unsignedInt'.
Most attributes are typed by a simple type built in to XML Schema
[W3C.REC-XMLSchema-2]. Some attributes are typed indirectly by the
use of a new simple type defined in dns-schema. These are in most
cases just the simplest restriction of a base type. This is done for
a number of reasons:
o Where there are multiple presentation formats for a single RDATA
field and so the defined type is a union of two built-in types.
o Where the type chosen allows for a greater range of values than is
allowed in the RDATA field wire format. Using a defined type
allows for later development where the range of values is further
constrained to match those of the wire format. Such restriction
on values is not implemented in this version of dnsSchema as
explained in Section 4.1.5
o Where there are fields that share the same semantic use (for
example an IP address or domain name). This use of types is to
prepare for later semantic inferences as explained in Section 5
Daley & Morris Expires July 28, 2008 [Page 9]
Internet-Draft dns-schema January 2008
4.1.5. RDATA attribute values
The values of attributes that represent RDATA are not constrained to
match the allowable values in the relevant RFC. This is done for a
number of reasons:
o To reduce the complexity and processing requirements of the schema
validation.
o To aid extensibility. It should be noted that the only way to
restrict attributes to a list of known values is to use a feature
of XML Schema [W3C.REC-XMLSchema-1], attribute value enumerations,
that cannot be extended.
It is therefore down to the application to check the values of
attributes that represent RDATA to ensure they are meaningful.
4.1.6. Required or optional attributes
Extensive use is made of the XML Schema [W3C.REC-XMLSchema-1]
attribute 'use="required"' by which the use of an attribute in
conforming documents is mandated. This is used when the normative
RFC for that RR states that an RDATA MUST exist.
4.1.7. Global attribute declarations
Global attribute declarations are not used, instead a similar effect
is attained by the use of defined types. The reason for not using
global attribute declarations is to simplify an instance document,
which would otherwise require namespace declarations for such
attributes, complicating those documents.
4.1.8. Top level container element
There is an element in the schema called 'dnsSchema' that does not
represent any DNS data. It is provided as an optional top-level
container element, which can be used in a document as the opening
element and contain an arbitrary list of 'RRSet' elements and
elements representing RRs.
However it does not have to be used, as both the 'RRSet' element and
the elements representing RRs are declared as top level elements and
so can be used directly in a valid document.
It would be sensible for the 'dnsSchema' element to be used in
document that only references this schema (a standalone document), as
a container for a set of elements and not to be used where dnsSchema
elements would appear embedded in elements defined in another schema.
Daley & Morris Expires July 28, 2008 [Page 10]
Internet-Draft dns-schema January 2008
For example, a standalone document might look like this
<dnsSchema xmlns="urn:ietf:params:xml:ns:dns"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:dns dns-1.0.xsd" >
<A owner="example1" class="IN" ttl="86400" address="192.0.2.2" />
<A owner="example2" class="IN" ttl="86400" address="192.0.2.1" />
</dnsSchema>
Whereas a fragment of a document where dnsSchema is embedded, might
look like this
:
<someApp>
<someCommand>
<dns:A owner="example2" class= IN" ttl="86400"
address="192.0.2.1" />
</someCommand>
</someApp>
:
4.1.9. Specific attribute considerations
There are some special cases that require further discussion, these
are described below:
4.1.9.1. Anonymous RDATA
The SPF, TXT and DHCID RRs have a single anonymous RDATA field just
referred to as the RDATA in the normative RFC. For each of these the
attribute that represents the RDATA is called 'rdata'.
4.1.9.2. IP address in RDATA
An IPv4 address is defined to be of type 'ipaddressType', which in
turn is defined to be a 'string' with the maximum length restricted
and is intended to hold the address in dotted-quad notation. A later
development may be to use a regular expression to ensure that the
contents of the string are indeed a valid IP address, but that is not
tackled in this memo.
IP v6 addresses are similarly defined. The maximum length is set to
allow for embedded dotted quad in the IPv6 address.
Daley & Morris Expires July 28, 2008 [Page 11]
Internet-Draft dns-schema January 2008
4.1.9.3. Domain names in RDATA
Attributes for RDATA fields that are used for domain names are all of
the type 'domainType'. This is defined to be a 'string' with the
maximum length restricted. No use is made of a regular expression to
check that the contents of an attribute are a correctly formatted
domain name.
4.1.9.4. The rdata attribute of the binaryRR element
[RFC3597] specifies a presentation format for an RR of an unknown
type. In dns-schema 'rdata' is of the type hexBinary.
4.1.9.5. XML in RDATA
Any data in attributes that represent an RDATA field that can contain
XML MUST be escaped using the rules given in [W3C.REC-XML]
Because escaping is a standard part of XML, no specific type is
defined to use for those fields where escaping may be required.
4.1.9.6. Unparsed data in RDATA
A number of RDATA fields are defined in RFCs as containing any text
data. Again any data in the attributes that represent these RDATA
fields MUST be escaped following the rules given in [W3C.REC-XML]
4.1.9.7. Variable length binary data in RDATA
There are a number of examples where RDATA contains a binary field
such as set of flags or a bit map field. For example WKS has a
variable length bit map field, with no defined presentation format.
These fields are represented either by the XML Schema
[W3C.REC-XMLSchema-2] types of 'hexBinary' or 'base64Binary'
depending on context. XML Schema [W3C.REC-XMLSchema-2] in turn
references [RFC2045] for the definition of base64.
4.1.9.8. Preferences in RDATA
A number of RRs have a preference RDATA field, namely KX, MX, PX, RT,
NAPTR. The attributes that represent the preference field for these
RRs are all defined to be of the type 'preferenceType' on the
potentially contentious grounds that they are semantically
equivalent.
Additionally the IPSECKEY RR has a precedence RDATA field, which is
defined as being equivalent to the preference RDATA field of the MX
Daley & Morris Expires July 28, 2008 [Page 12]
Internet-Draft dns-schema January 2008
RR. The attribute representing this field is therefore also defined
as being of type 'preferenceType'.
4.1.9.9. Seconds (units of time) in RDATA
Many RDATA fields are defined as unsigned 32 bit integers that record
a number of seconds. This is used in three separate ways:
o Fields such as the 'refresh' field of the SOA RR, contain seconds
as a relative value.
o Fields such as the 'signature expiration' field of the RRSIG RR,
contain the number of seconds since the epoch.
o Fields such as the 'ttl' field of all RRs, contain a relative
number of seconds but with specific semantic usage of Time To
Live.
These three separate ways are represented by attributes of three
different defined types:
o Attributes that represent RDATA fields of relative seconds are
defined to be of type 'secondsType'. This is an unsigned int.
o Attributes that represent RDATA fields of seconds since the epoch
are defined to be of type 'secondsSinceEpochType'. Different RRs
define different presentation formats for these fields, some using
straight integers such as the 'inception' field of the TKEY RR,
but the 'signature inception' field of the RRSIG RR additionally
defines the 14 character 'YYYYMMDDHHmmSS' string format.
Accordingly 'secondsSinceEpochType' is a union of two simple
types, one that allows the integer representation and one that
allows a string representation of 14 characters, sufficient for
the 'YYYYMMDDHHmmSS' representation.
o Attributes that represent TTL are defined to be of type 'ttlType',
which is derived from 'secondsType'. This enables the semantic
equivalence of fields that represent TTL.
Unfortunately there are anomalies with seconds (units of time) in
RDATA. These are explained further in section Section 4.2
4.1.9.10. [RFC4034] algorithms in RDATA
Three RRs defined in [RFC4034], namely DNSKEY, RRSIG and DS all have
an algorithm field in their RDATA. This is specified as having two
presentation formats, an unsigned integer and a string mnemonic. The
attributes that represent these fields have the type 'algorithmType'.
Daley & Morris Expires July 28, 2008 [Page 13]
Internet-Draft dns-schema January 2008
This is defined as a union of two simple types, one that allows
integer representation and one that allows a string representation.
The string type is not restricted to the mnemonic values given in
[RFC4034].
4.1.9.11. DNSKEY flags and protocol in RDATA
The flags and protocol RDATA fields of DNSKEY (defined in [RFC4034])
are represented in integer format and so the attributes that
represent these fields are only defined to be the appropriate integer
type.
4.2. Limitations of the schema
4.2.1. Spurious attributes
Each element that represents an RR has the base attributes of
'class', 'owner' and 'ttl', which also appear as attributes of an
RRSet. Because of the syntax requirement Section 2.1 to have a
single element for each RR, it is possible for the elements within an
RRSet to have 'class', 'owner' and 'ttl' attributes that contradict
those of the RRSet. For example
<RRSet owner="example" class="IN" type="A" ttl="86400" >
<A class="CH" address="192.0.2.1" />
<A owner="different" address="192.0.2.2" />
<A ttl="400" address="192.0.2.3" />
</RRSet>
To correct this anomaly would require such significant alterations to
the schema that a number of important characteristics, including
simplicity and ease of use, would be lost.
As it is the intent of this memo to mirror the presentation format of
DNS RRs in XML, not to change them, then applications that are
presented with such inconsistent data SHOULD ignore any 'class',
'ttl' and 'owner' attributes given in the elements within an RRSet,
whether or not they contradict those of the RRSet.
Note that the use of different ttl values for each RR within an RRSet
was deprecated in section 5.2 of [RFC2181].
4.2.2. No restrictions on what RRs can be appended to an RRset
[RFC2136] lists a number of RRs that cannot be appended to an RRset.
This restriction is not enforced in this schema.
Daley & Morris Expires July 28, 2008 [Page 14]
Internet-Draft dns-schema January 2008
4.2.3. Inconsistent or imprecise RFCs
Some RFCs are not clear on whether a specified RDATA field is a
signed or unsigned integer. This syntax has made a reasoned choice.
For example the 'refresh' field within the SOA RR is not explicitly
defined as signed or unsigned, but it would not make sense if a
signed integer was used here.
4.2.4. Additional presentation formats
In order to preserve semantic equivalence some attributes that
represent RDATA are of the same type and so allow the same
presentation formats when the normative RFCs do not specify those
presentation formats for that RDATA.
Examples of this include the 'inception' field of the TKEY RR. The
attribute that represents this is of the type
'secondsSinceEpochType', which allows the string representation of
'YYYYMMDDHHmmSS' even though this is not a defined presentation
format for this field.
4.2.5. Different wire formats for RDATA with semantic equivalence
There are some RDATA fields in different RRs that have the semantic
equivalence but are represented in different wire formats, making it
impossible to use common attribute types.
The one example of this is the 'timesigned' field of the TSIG RR,
which is defined as representing seconds since the epoch but has the
wire format of a 48 bit unsigned integer, when all other semantically
equivalent fields use a 32 bit unsigned integer. In this instance
this field uses its own unique type.
4.3. Extending the schema
4.3.1. The extension mechanism
All elements that represent RRs are specified using the same
mechanism that is made available for the development of third-party
extensions.
The schema defines an abstract element called 'RR', which is of an
abstract type 'RRType' that defines the three base attributes of
'class', 'ttl' and 'owner'. This is done in this code:
Daley & Morris Expires July 28, 2008 [Page 15]
Internet-Draft dns-schema January 2008
<element name="RR" type="dns:RRType" />
<complexType name="RRType" abstract="true">
<attribute name="class" type="dns:classType" />
<attribute name="ttl" type="dns:ttlType" />
<attribute name="owner" type="dns:hostType" />
</complexType>
Being abstract, the element 'RR' cannot be instantiated; it is just a
placeholder that is designed to be replaced by elements that
represent DNS RRs.
All elements that represent RRs are then defined using the
substitutionGroup syntax of XML Schema [W3C.REC-XMLSchema-1]. In
order to do this, two requirements must be met
o The new element has the substitutionGroup attribute, specifying
the 'RR' element as the target.
o The new element must be of a type that is defined as an extension
of the type 'RRType'.
For example, the A element is defined in exactly this manner, as
shown by this code:
<element name="A" substitutionGroup="dns:RR" type="dns:AType" />
<complexType name="AType">
<complexContent>
<extension base="dns:RRType">
<attribute name="address" type="dns:ipaddressType" />
</extension>
</complexContent>
</complexType>
A new RR defined in a different schema follows exactly the same
requirements. For example, the 'EXAMPLE' RR could be defined as:
<element name="EXAMPLE" substitutionGroup="dns:RR"
type="dns:EXAMPLEType" />
<complexType name="EXAMPLEType">
<complexContent>
<extension base="dns:RRType">
<attribute name="exampleRDATA" type="dns:hostType" />
</extension>
</complexContent>
</complexType>
Daley & Morris Expires July 28, 2008 [Page 16]
Internet-Draft dns-schema January 2008
4.3.2. Creating an extension
The purpose of an extension is to provide syntax for a DNS RR that is
not included in dns-schema. Extensions are specified in a new XML
Schema instance document, which has the following characteristics:
o declares its own XML Namespace [W3C.REC-xml-names];
o references dns-schema both as a namespace and importing that
schema;
o uses the extension mechanism to create a new element to represent
an RR as described in Section 4.3.1.
An extension schema to add an element representing a new RR called
EXAMPLE would look as follows:
<?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="http://www.example.org/example-schema"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:ex="http://www.example.org/example-schema"
xmlns:dns="urn:ietf:params:xml:ns:dns">
<annotation>
<documentation>Example extension to dns-schema</documentation>
</annotation>
<import namespace="urn:ietf:params:xml:ns:dns"
schemaLocation="dns-1.0.xsd"/>
<element name="EXAMPLE" substitutionGroup="dns:RR"
type="ex:EXAMPLEType" />
<complexType name="EXAMPLEType">
<complexContent>
<extension base="dns:RRType">
<attribute name="exampleRDATA" type="dns:hostType" />
</extension>
</complexContent>
</complexType>
</schema>
4.3.3. Using an extension
With an extension declared as per Section 4.3.2 it can then be
referenced in a XML document that also references dns-schema. The
use of namespaces will keep the references separate.
Daley & Morris Expires July 28, 2008 [Page 17]
Internet-Draft dns-schema January 2008
<dnsSchema xmlns="urn:ietf:params:xml:ns:dns"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:dns dns-1.0.xsd"
xmlns:ex="http://www.example.org/example-schema"
xsi:schemaLocation=
"http://www.example.org/example-schema example.xsd">
<ex:EXAMPLE owner="example" class="IN" ttl="86400"
exampleRDATA="whatever" />
<A owner="example" class="IN" ttl="86400" address="192.0.2.1" />
</dnsSchema>
4.4. Implementing new versions of the schema
If a new version of the schema is developed that includes within it
new RRs already described in third party extensions, the use of XML
Namespaces [W3C.REC-xml-names] will ensure that the third party
extension can continue to be used.
If dns-1.1.xsd were now available and the document updated to use
that, then the document would still validate correctly. If the
author then wanted to use the 'example' RR from the new version of
dns-schema as well as the version from the extension then they could
do so as it sits in a different namespace.
4.4.1. Use of version specific namespaces
This memo specifies two URNs that can be used to refer to dns-schema.
The first of these is a version independent reference
'urn:ietf:params:xml:ns:dns', the second is a version specific
reference 'urn:ietf:params:xml:ns:dns-1.0'. A document can use
either reference, depending on need.
4.4.2. Possible type changes in a new version