idnits 2.17.1
draft-daley-dnsxml-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** There is 1 instance of too long lines in the document, the longest one
being 1 character in excess of 72.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (July 31, 2013) is 3922 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Missing Reference: '0-9a-vA-V' is mentioned on line 1059, but not defined
== Missing Reference: '0-5' is mentioned on line 1316, but not defined
== Missing Reference: '0-2' is mentioned on line 1166, but not defined
== Missing Reference: '0-9' is mentioned on line 1302, but not defined
== Missing Reference: '0-4' is mentioned on line 1316, but not defined
-- Looks like a reference, but probably isn't: '01' on line 1302
== Missing Reference: '1-9' is mentioned on line 1328, but not defined
== Missing Reference: '0-9A-Fa-f' is mentioned on line 1321, but not defined
** Obsolete normative reference: RFC 2538 (Obsoleted by RFC 4398)
** Obsolete normative reference: RFC 2672 (Obsoleted by RFC 6672)
** Obsolete normative reference: RFC 2845 (Obsoleted by RFC 8945)
** Obsolete normative reference: RFC 3445 (Obsoleted by RFC 4033, RFC 4034,
RFC 4035)
** Obsolete normative reference: RFC 4408 (Obsoleted by RFC 7208)
** Obsolete normative reference: RFC 6195 (Obsoleted by RFC 6895)
-- Obsolete informational reference (is this intentional?): RFC 2671
(Obsoleted by RFC 6891)
Summary: 7 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Internet Engineering Task Force J. Daley, Ed.
3 Internet-Draft .nz Registry Services
4 Intended status: Informational S. Morris
5 Expires: February 01, 2014 Internet Systems Consortium
6 J. Dickinson
7 Sinodun
8 July 31, 2013
10 dnsxml - A standard XML representation of DNS data
11 draft-daley-dnsxml-00
13 Abstract
15 This memo describes a syntax for encoding DNS Resource Records in
16 XML, and a schema to define that syntax written in XML Schema. It
17 can be used to represent all DNS RDATA. This can be used by diverse
18 applications as a common format.
20 DNS Resource Records are represented as XML elements with the name of
21 the element taken from the mnemonic used to represent the DNS
22 Resource Record in presentation format. The RDATA is represented as
23 XML attributes or content of the element. The attribute names are
24 taken from the RDATA field names specified in the normative RFC.
26 Status of This Memo
28 This Internet-Draft is submitted in full conformance with the
29 provisions of BCP 78 and BCP 79.
31 Internet-Drafts are working documents of the Internet Engineering
32 Task Force (IETF). Note that other groups may also distribute
33 working documents as Internet-Drafts. The list of current Internet-
34 Drafts is at http://datatracker.ietf.org/drafts/current/.
36 Internet-Drafts are draft documents valid for a maximum of six months
37 and may be updated, replaced, or obsoleted by other documents at any
38 time. It is inappropriate to use Internet-Drafts as reference
39 material or to cite them other than as "work in progress."
41 This Internet-Draft will expire on February 01, 2014.
43 Copyright Notice
45 Copyright (c) 2013 IETF Trust and the persons identified as the
46 document authors. All rights reserved.
48 This document is subject to BCP 78 and the IETF Trust's Legal
49 Provisions Relating to IETF Documents
50 (http://trustee.ietf.org/license-info) in effect on the date of
51 publication of this document. Please review these documents
52 carefully, as they describe your rights and restrictions with respect
53 to this document. Code Components extracted from this document must
54 include Simplified BSD License text as described in Section 4.e of
55 the Trust Legal Provisions and are provided without warranty as
56 described in the Simplified BSD License.
58 Table of Contents
60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
61 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
62 2. Design goals . . . . . . . . . . . . . . . . . . . . . . . . 4
63 2.1. Design goals for the XML syntax for DNS RRs . . . . . . . 4
64 2.2. Design goals for the XML schema definition . . . . . . . 4
65 2.3. Semantic inference . . . . . . . . . . . . . . . . . . . 5
66 2.4. Supported DNS RR tyopes . . . . . . . . . . . . . . . . . 5
67 2.5. Exclusions and limitations . . . . . . . . . . . . . . . 6
68 3. The XML syntax and XML schema for DNS RRs . . . . . . . . . . 7
69 3.1. General features . . . . . . . . . . . . . . . . . . . . 7
70 3.1.1. Unique XML element for each RR type . . . . . . . . . 7
71 3.1.2. Representation of RDATA . . . . . . . . . . . . . . . 7
72 3.1.2.1. RDATA represented as XML attributes . . . . . . . 7
73 3.1.2.2. RDATA represented as element content . . . . . . 8
74 3.1.3. Use of XML Schema . . . . . . . . . . . . . . . . . . 9
75 3.1.4. Use of XML Namespaces . . . . . . . . . . . . . . . . 9
76 3.2. Elements and RRs . . . . . . . . . . . . . . . . . . . . 9
77 3.2.1. Base RR element and base attributes . . . . . . . . . 9
78 3.2.2. RRset element . . . . . . . . . . . . . . . . . . . . 10
79 3.2.3. TYPE element for holding unknown RR types and raw RR
80 data . . . . . . . . . . . . . . . . . . . . . . . . 11
81 3.2.4. CLASS . . . . . . . . . . . . . . . . . . . . . . . . 11
82 3.2.5. Top level container element . . . . . . . . . . . . . 12
83 3.3. Attributes and RDATA . . . . . . . . . . . . . . . . . . 12
84 3.3.1. Semantic equivalence of RDATA . . . . . . . . . . . . 12
85 3.3.2. Anonymous RDATA . . . . . . . . . . . . . . . . . . . 12
86 3.3.3. IP addresses in RDATA . . . . . . . . . . . . . . . . 13
87 3.3.4. Domain names in RDATA . . . . . . . . . . . . . . . . 13
88 3.3.5. XML in RDATA . . . . . . . . . . . . . . . . . . . . 13
89 3.3.6. Unparsed data in RDATA . . . . . . . . . . . . . . . 13
90 3.3.7. Variable length binary data in RDATA . . . . . . . . 13
91 3.3.8. Preferences in RDATA . . . . . . . . . . . . . . . . 14
92 3.3.9. Seconds (units of time) in RDATA . . . . . . . . . . 14
93 3.3.10. RCODE in RDATA . . . . . . . . . . . . . . . . . . . 15
94 3.3.11. RDATA field that specifies the length of another
95 RDATA field . . . . . . . . . . . . . . . . . . . . . 15
97 3.3.12. Mnemonics for integer RDATA . . . . . . . . . . . . . 15
98 3.3.13. Cryptographic algorithms and digest types in RDATA . 16
99 3.3.14. RDATA of the KEY and SIG RRs . . . . . . . . . . . . 16
100 3.3.15. Lists of RR types in RDATA . . . . . . . . . . . . . 17
101 3.3.16. RDATA of the APL RR type . . . . . . . . . . . . . . 17
102 3.3.17. Imprecise RFCs on signed/unsigned integers in RDATA . 18
103 3.3.18. Dependency rules in RDATA . . . . . . . . . . . . . . 18
104 3.4. Extending the schema . . . . . . . . . . . . . . . . . . 18
105 3.4.1. The extension mechanism . . . . . . . . . . . . . . . 18
106 3.4.2. Creating an extension . . . . . . . . . . . . . . . . 20
107 3.4.3. Using an extension . . . . . . . . . . . . . . . . . 21
108 3.5. Implementing new versions of the schema . . . . . . . . . 22
109 3.5.1. Use of version specific namespaces . . . . . . . . . 22
110 4. Full schema definition . . . . . . . . . . . . . . . . . . . 22
111 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 49
112 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
113 7. Security Considerations . . . . . . . . . . . . . . . . . . . 50
114 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 50
115 8.1. Normative References . . . . . . . . . . . . . . . . . . 50
116 8.2. Informative References . . . . . . . . . . . . . . . . . 53
117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54
119 1. Introduction
121 Historically, DNS Resource Records (RRs) have a presentation format
122 and wire format. The presentation format is typically used to
123 conveniently store DNS RRs in Human Readable Form. The wire format
124 is typically used in transport and communication between DNS protocol
125 elements.
127 This memo describes an alternative presentation format for DNS using
128 an XML syntax [W3C.REC-xml-20081126] with an XML schema defined in
129 XML Schema [W3C.REC-xmlschema-1-20041028]. These two parts taken
130 together are called dnsxml.
132 The purpose of dnsxml is to enable XML based applications and
133 protocols to contain DNS Resource Records in their native XML rather
134 than the existing DNS presentation format. This simplifies the
135 processing of XML documents that contain DNS Resource Records and
136 enables the use of standard XML tools such as validation and
137 transformation on those records.
139 An example of an XML based protocol that may choose to use dnsxml is
140 Extensible Provisioning Protocol (EPP).
142 1.1. Requirements Language
143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
145 document are to be interpreted as described in RFC 2119 [RFC2119].
147 2. Design goals
149 dnsxml consists of two parts:
151 o an XML syntax for representing DNS RRs in XML;
153 o an XML schema definition of that syntax.
155 Each of these two parts has a set of design goals, as set out below.
157 2.1. Design goals for the XML syntax for DNS RRs
159 The XML syntax should:
161 1. be clear, unambiguous, succinct and easy to read for the human
162 reader;
164 2. use as closely as possible the presentation format for RDATA
165 fields given in various RFCs, even if that reduces overall
166 readability for those unfamiliar with DNS, in the expectation
167 that it will be easier to use for those familiar with DNS;
169 3. split out RDATA into separate components so as to minimise the
170 secondary parsing that an application needs to do in order to
171 obtain the values of individual RDATA fields;
173 4. be independent of any name server implementation;
175 5. allow the representation of an RR of unknown type as described in
176 RFC 3597 [RFC3597].
178 2.2. Design goals for the XML schema definition
180 The schema definition should:
182 1. validate as much RDATA as possible;
184 2. not require excessive processing power for validation;
186 3. not impose any restrictions on the future definition of a new RR
187 element or a change to an existing RR element;
189 4. allow for any new RR to be described as an extension of this
190 schema definition and used as easily as any RR element described
191 in it;
193 5. ensure that a new version of this schema definition may include
194 new RRs or changes to existing RRs that have been described in
195 new RFCs, without preventing the continuing use of any
196 extensions;
198 6. not require an excessive frequency of updates to address changes
199 in normative RFCs or the IANA registry;
201 7. support semantic inference between RDATA fields that represent
202 semantically equivalent data.
204 Clearly, some of these goals need to be balanced against each other.
206 2.3. Semantic inference
208 The design goal [semantic] for semantic inference is intended to
209 allow users of dnsxml to carry out semantically-aware processing,
210 which may be achieved through the use of schema-aware XSLT.
212 2.4. Supported DNS RR tyopes
214 The following RFCs and Resource Records types are supported in
215 dnsxml:
217 o From [RFC1035], A, CNAME, HINFO, MB, MG, MINFO, MR, MX, NS, NULL,
218 PTR, SOA, TXT and WKS.
220 o From [RFC1183], AFSDB, ISDN, RP, RT and X25.
222 o From [RFC1706], NSAP.
224 o From [RFC1712], GPOS.
226 o From [RFC1876], LOC.
228 o From [RFC2163], PX.
230 o From [RFC2230], KX.
232 o From [RFC2538], CERT.
234 o From [RFC2672], DNAME.
236 o From [RFC2782], SRV.
238 o From [RFC2845], TSIG.
240 o From [RFC2874], A6.
242 o From [RFC2930], TKEY.
244 o From [RFC2931], SIG.
246 o From [RFC3123], APL.
248 o From [RFC3445], KEY.
250 o From [RFC3403], NAPTR.
252 o From [RFC3596], AAAA.
254 o From [RFC4025], IPSECKEY.
256 o From [RFC4034], DNSKEY, DS, NSEC and RRSIG.
258 o From [RFC4255], SSHFP.
260 o From [RFC4408], SPF.
262 o From [RFC4431], DLV.
264 o From [RFC4701], DHCID.
266 o From [RFC5155], NSEC3 and NSEC3PARAM.
268 Obsolete DNS resource records are not supported. Neither are the NB
269 and NBSTAT RR types defined in [RFC1002].
271 2.5. Exclusions and limitations
273 The focus of dnsxml is DNS data only and dnsxml is not intended as a
274 replacement for the DNS protocol. For this reason there are a number
275 of parts of DNS that are not represented in dnsxml:
277 o It is not possible to define all the parts of a DNS datagram in
278 dnsxml. There is no XML element in dnsxml that represents the
279 header section of a DNS datagram or the question section.
281 o There is no representation of the OPT pseudo-RR because OPT, as
282 described in [RFC2671], "pertains to a particular transport level
283 message and not to any actual DNS data"
285 For clarity:
287 o No use is made of Master File Format [RFC1035], section 5.1.
289 o dnsxml is not intended to obsolete the presentation format of RR
290 types as specified in their normative RFCs.
292 o dnsxml is not intended to limit the presentation formats of future
293 RR types.
295 3. The XML syntax and XML schema for DNS RRs
297 These are examples of resource records represented in this syntax:
299
300 Any text here
302 and this is an example of an RRSet:
304
305
306
307
309 3.1. General features
311 3.1.1. Unique XML element for each RR type
313 Each DNS RR type has a corresponding element. That ensures that the
314 schema definition can constrain the allowable attributes on a per RR
315 basis. It also meets the design goal of clear, unambiguous and easy
316 to read.
318 3.1.2. Representation of RDATA
320 Most RDATA is represented in attributes as this significantly reduces
321 the verbosity of the XML. Some RDATA is represented as the content
322 of the element.
324 3.1.2.1. RDATA represented as XML attributes
326 For each element that represents an RR type, the attributes specified
327 correspond to those specified in the normative RFC that defines the
328 RDATA for that RR type. For example, the MX element has the specific
329 attributes of 'preference' and 'exchange' as specified in [RFC1035].
331 Extensive use is made of the XML Schema
332 [W3C.REC-xmlschema-1-20041028] attribute 'use="required"' by which
333 the use of an attribute in conforming documents is mandated. This is
334 used when the normative RFC for that RR type states that an RDATA
335 field 'MUST' exist.
337 The type of an attribute is chosen to represent the presentation
338 format for the RDATA field specified in the relevant RFC. For
339 example a field specified as 32 bit unsigned integer is represented
340 using the XML Schema [W3C.REC-xmlschema-2-20041028] type of
341 'unsignedInt'.
343 Where there are multiple presentation formats for a single RDATA
344 field, the defined type is a union of two built-in types.
346 3.1.2.2. RDATA represented as element content
348 Some RDATA is better suited to be represented as the content of an
349 element rather than as an attribute. The following criteria have
350 been used as a general guide to determine when to use this method fo
351 representation:
353 o the RDATA is anonymous. In other words the RDATA field is simply
354 labelled as RDATA and no other label is given;
356 o the RDATA is of variable length or is expected to be long enough
357 that representing it in an attribute will make it hard to read;
359 o the text representation of the RDATA in the normative RFC allows
360 it to be split across multiple lines.
362 To aid the implementer the following table lists the elements that
363 allow or require content:
365 +----------+--------------------+-------------------+----------+
366 | Element | RDATA field | Type | Nillable |
367 +----------+--------------------+-------------------+----------+
368 | APL | -anonymous- | string | yes |
369 | NULL | -anonymous- | string | yes |
370 | SPF | -anonymous- | string | no |
371 | TXT | -anonymous- | string | no |
372 | TYPE | -anonymous- | hexWithWhitespace | no |
373 | DLV | digest | hexWithWhitespace | no |
374 | DS | digest | hexWithWhitespace | no |
375 | SSHFP | fingerprint | hexWithWhitespace | no |
376 | TKEY | other data | hexWithWhitespace | yes |
377 | TSIG | other data | hexWithWhitespace | yes |
378 | WKS | bitmap | hexWithWhitespace | no |
379 | CERT | certificate or CRL | base64Binary | no |
380 | DHCID | -anonymous- | base64Binary | no |
381 | DNSKEY | public key | base64Binary | no |
382 | IPSECKEY | public key | base64Binary | no |
383 | KEY | public key | base64Binary | no |
384 | RRSIG | signature | base64Binary | no |
385 | SIG | signature | base64Binary | no |
386 +----------+--------------------+-------------------+----------+
388 Table 1
390 More information on the types used to represent variable length
391 binary data can be found in Section 3.3.7.
393 3.1.3. Use of XML Schema
395 This schema is written using XML Schema
396 [W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028]
397 because this is a W3C standard and provides the necessary level of
398 flexibility to correctly specify the preferred syntax. Other schema
399 languages could have been used just as well.
401 3.1.4. Use of XML Namespaces
403 XML Namespaces [W3C.REC-xml-names-20091208] need to be used in the
404 schema to reference the defined types. Any document validated
405 against dnsxml must contain a namespace reference in order for it to
406 validate properly. For example
408
412 In that example the default namespace is set to refer to elements and
413 attributes from dnsxml. A third party extension could be included in
414 the namespace declarations, with a specified prefix, and so all use
415 of the extension would be clearly identified by use of that prefix.
416 This is described more fully in Section 3.4.
418 3.2. Elements and RRs
420 3.2.1. Base RR element and base attributes
422 All elements that represent RRs are derived from an abstract element.
423 All elements include the attribute group 'baseAttributes' that
424 provide the 'class', 'owner', 'ttl' and 'rdlength' attributes. The
425 elements that represent RRs are defined using the XML Schema
426 [W3C.REC-xmlschema-1-20041028] feature of substitutionGroup to
427 substitute for the abstract RR element.
429 This same mechanism is used by any new RR types that are defined in
430 extensions, which ensures they are treated equally to built-in
431 elements rather than needing to appear in a separate extension
432 element. This is covered further in Section 3.4.1
434 It should be noted that, as this is an abstract element, it cannot be
435 used in an XML document that is to be validated by dnsxml.
437 3.2.2. RRset element
439 The schema has an element called 'RRset' that represents an RRset,
440 using the definition from [RFC2136] of a set of RRs that share the
441 same 'owner', 'class' and 'type' RDATA fields, each of which is
442 represented as attributes. In addition a 'ttl' attribute is
443 specified because [RFC2181] requires all the RRs in an RRSet to share
444 the same ttl.
446 (If an RR type is ever defined with the mnemonic of 'RRSET', this
447 would present future versions of dnsxml with a naming conflict.)
449 Any element that represents an RR can be used either standalone or
450 within an RRset element.
452 The RRset element may be empty to represent an empty RRset.
454 The RRset element implementation in dnsxml has a number of
455 limitations to the validation that it performs. These could
456 theoretically be fixed but would require such significant alterations
457 to the schema that a number of important characteristics, including
458 extensibility, simplicity and ease of use, would be lost.
460 The validation limitations of the RRset element are:
462 o An RRset element may contain elements that represent different DNS
463 RR types from the type specified for the RRset element. The
464 processing behaviour of such errant elements is left to the
465 application to decide.
467 o It is possible for the elements within an RRset element to have
468 'class', 'owner' and 'ttl' attributes that contradict those of the
469 RRset element. The processing behaviour of such errant elements
470 is left to the application to decide.
472 o [RFC2136] lists a number of RR types (SOA, WKS and CNAME) that can
473 only appear once in an RRset. This restriction is not enforced in
474 this schema.
476 This may mean that the RRset element is used by appplications as a
477 general container for a set of RRs, which is quite different from the
478 normative use of an RRset in DNS.
480 3.2.3. TYPE element for holding unknown RR types and raw RR data
482 To fit with the convention of naming the element after the RR type
483 mnemonic it would be preferable to have 65535 different elements with
484 names of the form TYPEnnnnn, but this would make the schema
485 unnecessarily long and slow to process. Instead an element called
486 TYPE is included, named in the spirit of [RFC3597] that can hold an
487 RR of any type. This has an attribute 'rrtype' that holds the DNS
488 type as an unsignedShort (type mnemonics cannot be used here) and the
489 raw data is represented as content of the element. The optional base
490 attribute 'rdlength' can be set if required. See Section 3.3.11 for
491 more information on the 'rdlength' attribute.
493 No use is made of the special token '\#' specified in [RFC3597] to
494 indicate the start of the RDATA for a TYPE RR as this is superfluous
495 in the XML representation.
497 To comply with the [RFC3597] specification of the presentation format
498 for an RR of an unknown type, the 'rdata' attribute of the TYPE
499 element is of the type hexBinary.
501 This element can also be used to contain 'broken' DNS data.
503 3.2.4. CLASS
505 The 'class' attribute is a union of three types, allowing three
506 different representation formats:
508 1. The defined mnemonics of [RFC6195], section 3.2. The mnemonics
509 of NONE, * and ANY are included for completeness;
511 2. The CLASSnnnnn mnemonic in conformance with [RFC3597], section 5.
513 3. An integer in the range 0-65535
515 dnsxml does not set a default of "IN" for CLASS as this would be
516 incorrect for some RR types including TKEY as defined in [RFC2930].
517 Nor is the 'class' attribute required.
519 3.2.5. Top level container element
521 There is an element in the schema called 'dnsxml' that does not
522 represent any DNS data. It is provided as an optional top-level
523 container element, which can be used in a document as the opening
524 element and contain an arbitrary list of 'RRSet' elements and
525 elements representing RRs. However it does not have to be used, as
526 both the 'RRSet' element and the elements representing RRs are
527 declared as top level elements and so can be used directly in a valid
528 document. It would be sensible for the 'dnsxml' element to be used
529 in document that only references this schema (a standalone document),
530 or as a container for a set of elements.
532 For example, a standalone document might look like this:
534
538
539
540
542 Whereas a fragment of a document where dnsxml is embedded, might look
543 like this:
545 :
546
547
548
550
551
552 :
554 3.3. Attributes and RDATA
556 3.3.1. Semantic equivalence of RDATA
558 Fields that share the same semantic use (for example an IP address or
559 domain name) use the same defined types or the types that are derived
560 from a common type, in order to enable later semantic inferences to
561 be developed.
563 3.3.2. Anonymous RDATA
564 The SPF, TXT and DHCID RR types have a single anonymous RDATA field
565 just referred to as the RDATA in the normative RFC. For each of
566 these the attribute that represents the RDATA is called 'rdata'.
568 3.3.3. IP addresses in RDATA
570 All attributes that contain IPv4 address are defined to be of type
571 'ip4AddressType', which uses a regular expression to validate that
572 the content of the attribute is a valid IPv4 address. Attributes
573 that hold IPv6 addresses are similarly defined to be of type
574 'ip6Addresstype', which also uses a regular expression to validate
575 the content of the attribute.
577 In addition the type 'ipAddressType' exists as a union of
578 'ip4AddressType' and 'ip6AddressType' for use in the APL RR type.
580 3.3.4. Domain names in RDATA
582 Attributes for RDATA fields that are used for domain names are all of
583 the type 'domainType'. This is defined to be a 'string' with the
584 maximum length restricted. A later development for a future version
585 may be to validate the contents of these attributes using a regular
586 expression.
588 3.3.5. XML in RDATA
590 Any data in attributes that represent an RDATA field that can contain
591 XML MUST be escaped using the rules given in [W3C.REC-xml-20081126]
593 Because escaping is a standard part of XML, no specific type is
594 defined to use for those fields where escaping may be required.
596 3.3.6. Unparsed data in RDATA
598 A number of RDATA fields are defined in RFCs as containing any text
599 data. Any data in the attributes that represent these RDATA fields
600 MUST be escaped following the rules given in [W3C.REC-xml-20081126]
602 3.3.7. Variable length binary data in RDATA
604 There are a number of examples where RDATA contains a binary field
605 such as set of flags or a bit map field. For example WKS has a
606 variable length bit map field, with no defined presentation format.
607 These fields are represented either by the defined type of
608 'hexWithWhitespace'or the built-in type of 'base64Binary' depending
609 on context. XML Schema [W3C.REC-xmlschema-2-20041028] in turn
610 references [RFC2045] for the definition of base64. The built-in type
611 of 'hexBinary' is not suitable because it does not allow whitespace,
612 whereas the presentation format of many RR types does for
613 hexadecimally presented RDATA.
615 It should be noted that the NSEC3 RR type has the Next Hashed Owner
616 Name field that may be up to 255 octets long but whitespace in the
617 presentation format is forbidden and so a value that is 255 octets
618 long will have readability problems whether it is an attribute or
619 element content. For simplicity this is encoded as an attribute of
620 defined type 'base32HexRestricted' that uses a regular expression to
621 validate the allowable characters.
623 3.3.8. Preferences in RDATA
625 A number of RR types have a preference RDATA field, namely KX, MX,
626 PX, RT, NAPTR. The attributes that represent the preference field
627 for these RR types are all defined to be of the type 'preferenceType'
628 on the potentially contentious grounds that they are semantically
629 equivalent.
631 Additionally the IPSECKEY RR type has a precedence RDATA field, which
632 is defined as being semantically equivalent to the preference RDATA
633 field of the MX RR type. The attribute representing this field is
634 therefore also defined as being of type 'preferenceType'.
636 3.3.9. Seconds (units of time) in RDATA
638 Many RDATA fields are defined as unsigned integers that record a
639 number of seconds. There are a number of different types of time
640 field:
642 o Fields such as the 'refresh' field of the SOA RR type, are defined
643 as an interval. The attributes that represent these fields are
644 defined as being of type 'secondsInterval32Type'.
646 o Fields such as the 'signature expiration' field of the RRSIG RR
647 type, contain the number of seconds since the unix Epoch. This is
648 in turn comes in a number of variants:
650 * The 'timesigned' field of the TSIG RR type, which has the wire
651 format of a 48 bit unsigned integer and the corresponding
652 attribute is defined as being of type
653 'secondsSinceEpoch48Type';.
655 * Those that use a 32 bit unsigned integer and so are defined as
656 being of type 'secondsSinceEpoch32Type', which is a restriction
657 of 'secondSinceEpoch48Type'
659 * Those that use a 32 bit unsigned integer but whose presentation
660 format also allows a text representation of the form
661 'YYYYMMDDHHmmSS' such as the 'signatureexpiration' field of
662 RRSIG. These are defined as being of type
663 'secondsSinceEpochTextType', which is a union of
664 'secondsSinceEpoch32Type' and a 14 character string.
666 o Fields such as the 'ttl' field of all RR types, contain an
667 interval but with specific semantic usage of Time To Live.
669 Semantic equivalence is maintained by all the time types being
670 derived from a common type 'secondsBaseType'.
672 3.3.10. RCODE in RDATA
674 Attributes that represent an RCODE are either of type 'rcode16Type'
675 or 'rcode12Type' depending on the number of bits in the corresponding
676 RDATA field. These are all derived from the 'baseRcode16Type' to
677 provide semantic equivalence.
679 3.3.11. RDATA field that specifies the length of another RDATA field
681 The Resource Record format as defined in [RFC1035] includes an
682 'rdlength' field. There is a corresponding base attribute called
683 'rdlength' that is optional. This attribute is of type
684 'rdataLengthType', which is limited to an unsigned 16 bit integer.
686 Numerous RR types including NSEC3, TKEY and TSIG have an RDATA field
687 that specifies the length of another RDATA field in octets. The
688 attributes that represent these fields all share the same type of
689 'rdataLengthType', or 'rdataLength8Type', the latter being limited to
690 an unsigned 8 bit integer.
692 It could be argued that RDATA fields that hold the length of other
693 RDATA fields do not need to be included in dnsxml as these values can
694 be calculated directly from the data with certainty. However these
695 fields have been included for completeness and for unknown future
696 uses, but they are generally defined as 'use="optional"' to allow for
697 applications that will calculate the length directly.
699 3.3.12. Mnemonics for integer RDATA
700 A number of RR types, for example DNSKEY, RRSIG, DS and DLV, have
701 fields in their RDATA that are integer types but also have string
702 mnemonics. The attributes that represent these fields are defined as
703 a union of two simple types, one that allows integer representation
704 and one that allows a string representation. The string
705 representation is restricted to the known mnemonics but the integer
706 values are not restricted to those for which a mnemonic is defined.
708 A number of sets of mnemonics are defined in the IANA registry
709 [dns-sec-alg-numbers]. If a new mnemonic is defined by IANA after
710 the definition of this protocol, a new version of dnsxml will need to
711 be issued for that to be incorporated into the schema. Until that
712 time the mnemonic will fail validation and instead the integer the
713 mnemonic refers must be used or the TYPE syntax of [RFC3597].
715 Mnemonics are only defined in the schema where they appear in a
716 normative RFC and not where they appear in an online database, such
717 as the allowable values of 'host' and 'cpu' in the HINFO RR type.
719 Various RFCs previously referenced have been used as the normative
720 references for the lists of mnemonics and in addition to those
721 [RFC4509], [RFC5702], [RFC5933] and [RFC6605], have been used for
722 DNSSEC algorithm mnemonics. [RFC6195] has been used as the normative
723 reference for the mnemonics for 'class' and 'rcode'.
725 3.3.13. Cryptographic algorithms and digest types in RDATA
727 There are two sets of cryptographic algorithms and digest types
728 specified in RDATA:
730 o Those specified for DNSSEC RFCs. The CERT RR type algorithm type
731 references the DNSSEC types for its RDATA. The attributes that
732 represent this RDATA are defined to be of defined type
733 'dnssecAlgorithmType'.
735 o Those specified in [RFC4255]for SSHFP. The terminology is also
736 different with the 'fptype' RDATA of SSSHFP being semantically
737 equivalent to the 'digest type' RDATA of DNSSEC RR types. The
738 attributes that represent this RDATA are defined to be of types
739 'sshAlgorithmType' and 'sshDigestType'.
741 These attributes that represent these different RDATA are derived
742 from the common base type of 'baseAlgorithmType', preserving semantic
743 equivalence.
745 3.3.14. RDATA of the KEY and SIG RRs
746 The KEY and SIG RRs are unusual in that their wire formats are
747 identical to other RR types (DNSKEY and RRSIG respectively) but their
748 allowable values are different. This leads to some notable design
749 decisions for dnsxml:
751 o The 'flags' RDATA fields of KEY and DNSKEY are both functionally
752 equivalent as they flag the use of the key material, but the
753 allowable values are different as [RFC4034] allows bit 15 to be
754 set in DNSKEY, whereas [RFC3445] forbids that for KEY. Given this
755 divergence, the two 'flags' attributes are both defined as being
756 of type 'unsignedShort' rather than sharing a common defined type
757 to allow for semantic inference.
759 o While the 'protocol' RDATA field for both the KEY and DNSKEY RR
760 types are currently semantically and functionally identical the
761 corresponding attributes do not use a common defined type for
762 either semantic or functional equivalence. This decision is taken
763 because the two fields are defined independently and so may
764 diverge as the 'flags' fields have done.
766 o The 'type covered' RDATA field of SIG was originally used to hold
767 an RR type. The combination of [RFC2931] and [RFC4034] changes
768 this field to only have the allowable value of 0. It is the
769 understanding of the authors that this changes means that this
770 field no longer represents an RR type. Consequently the attribute
771 'typecovered' in the SIG element is defined as being of type
772 'unsignedShort' and no semantic link is made with any other
773 attribute that holds an RR type, nor can an RR type mnemonic be
774 used as a value for this attribute.
776 3.3.15. Lists of RR types in RDATA
778 A number of RR types including RRSIG and NSEC have RDATA that
779 contains a list of RR types. This is implemented as a list of RR
780 type mnemonics using the XML Schema 'list' feature. The TYPE
781 representation as specified in [RFC3597], section 5 is fully
782 supported.
784 3.3.16. RDATA of the APL RR type
786 The APL RR type [RFC3123] is unusual as the representation format
787 specified is a complex encoding of the RDATA whereby the RDATA fields
788 appear in a different order from the wire format and additional
789 separator characters are used. To address this complexity, the APL
790 element provides for two different mechanisms to specify RDATA:
792 1. using individual attributes that correspond to the individual
793 RDATA fields; or
795 2. using a single 'rdata' attribute that contains the textual
796 representation specified in [RFC3123]
798 To enable these two different mechanisms, the various attributes are
799 optional and so it may be possible for attributes to be ommitted or
800 for the two different mechanisms to be used simultaneously. It is
801 left to the application to decide what action to take in either of
802 these cases.
804 It should be noted that the 'afdpart' attribute does not fully
805 correspond to the wire format of the RDATA field that it represents.
806 The wire format specification is for only the octets covered by the
807 'prefixlength' to be present, whereas the attibute requires a full
808 and valid IPv4 or IPv6 address.
810 It should be noted that the 'n' attribute, if it appears, can only
811 contain the '!' character.
813 3.3.17. Imprecise RFCs on signed/unsigned integers in RDATA
815 Some RFCs are not clear on whether a specified RDATA field is a
816 signed or unsigned integer. This syntax has made a reasoned choice.
817 For example the 'refresh' field within the SOA RR type definition in
818 [RFC1035]is not explicitly defined as signed or unsigned, but it
819 would not make sense if a signed integer was used here.
821 3.3.18. Dependency rules in RDATA
823 There is no validation of the dependency rules that specify that the
824 value set in one RDATA field limits or specifies the allowable values
825 that may appear in another field of the same RR. For example, as
826 defined for the IPSECKEY RR type.
828 3.4. Extending the schema
830 3.4.1. The extension mechanism
832 All elements that represent RRs are specified using the same
833 mechanism and this is available for the development of third-party
834 extensions.
836 The schema defines an abstract element called 'RR'. Being abstract,
837 the element 'RR' cannot be instantiated; it is just a placeholder
838 that is designed to be replaced by elements that represent DNS RR.
839 The definition of RR is as follows
841
842 To create an element that represents a new RR type the type for that
843 element is first be created. This is done in one of two ways
844 depending on whether or not the RDATA is to be represented solely in
845 attributes.
847 If the RDATA is to be represented solely in attributes then the type
848 for the element is defined as a 'complexType' that contains the
849 relevant attributes. The following example is the type for the A
850 element:
852
853
854
856
858 If one field of the RDATA is to be represented as content of the
859 element then the type for the attribute is defined as a 'complexType'
860 that contain 'simpleContent' that determines the type of the content
861 and the list of attributes. The following example is the type for
862 the TXT element:
864
865
866
867
868
869
870
872 All the 'simpleContent' in dnsxml is an extenstion of 'string',
873 'base64Binary' or 'hexWithWhitespace' as listed in Table 1.
875 The examples above show that the base attributes of 'class', 'ttl',
876 'owner' and 'rdlength' are included in the element type definition by
877 the inclusion of the attribute group named 'baseAttributes'.
879 All elements that represent RRs are then defined using the
880 substitutionGroup syntax of XML Schema [W3C.REC-xmlschema-1-20041028]
881 and referencing the newly defined type.
883 For example, the A element is defined in exactly this manner:
885
886 This memo defines a number of rules for creating extension:
888 1. The element representing the new RR type MUST include the
889 attribute group 'baseAttributes'. This is true even if 'class'
890 and 'ttl' attributes are meaningless as they for SIG(0).
892 2. All RDATA fields MUST be represented.
894 3. The attributes that represent the RDATA of the new RR MUST reuse
895 existing types wherever possible and where new types are created,
896 every effort SHOULD be made to maintain semantic equivalence.
898 3.4.2. Creating an extension
900 The purpose of an extension is to provide syntax for a DNS RR type
901 that is not included in dnsxml. Extensions are specified in a new
902 XML Schema instance document, which has the following
903 characteristics:
905 o declares its own XML Namespace [W3C.REC-xml-names-20091208];
907 o references dnsxml both as a namespace and importing that schema;
909 o uses the extension mechanism to create a new element to represent
910 an RR as described in Section 3.4.1.
912 An extension schema to add an element representing a new RR called
913 EXAMPLE where all the RDATA is represented in attributes, would look
914 as follows:
916
917
922
923 Example extension to dnsxml
924
926
929
932
933
934
935
937
939 If the RR type is
941 3.4.3. Using an extension
943 With an extension declared as described in Section 3.4.2 it can then
944 be referenced in a XML document that also references dnsxml. The use
945 of namespaces will keep the references separate.
947
954
957
959
961 3.5. Implementing new versions of the schema
963 If a new version of the schema is developed that includes within it
964 new RR types already described in third party extensions, the use of
965 XML Namespaces [W3C.REC-xml-names-20091208] will ensure that the
966 third party extension can continue to be used.
968 If a new version of dnsxml were now available and an XML document
969 updated to use that, then the document would still validate
970 correctly. If the author then wanted to use the 'example' RR from
971 the new version of dnsxml as well as the version from the extension
972 then they could do so as it sits in a different namespace.
974 3.5.1. Use of version specific namespaces
976 This memo specifies two URNs that can be used to refer to dnsxml.
977 The first of these is a version independent reference
978 'urn:ietf:params:xml:ns:dns', the second is a version specific
979 reference 'urn:ietf:params:xml:ns:dns-1.0'. A document can use
980 either reference, depending on need.
982 4. Full schema definition
984 In the following schema definition a number of regular expressions
985 have been split across multiple lines to enable them to be included
986 in this memo. To use this schema correctly these regular expressions
987 must be combined back into a single line without whitespace or they
988 will not work correctly.
990
991
995
996 dnsxml v1.0
997
999
1000
1001
1003
1004
1005
1006
1007
1008
1010
1011
1013
1014
1015
1017
1018
1019
1020
1021
1022
1024
1025
1026
1028
1030
1031
1032
1033
1034
1035
1036
1037
1038
1040
1041
1042
1044
1046
1047
1048
1050
1051
1052
1053
1055
1057
1058
1059
1060
1061
1063
1064
1065
1067
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
1126
1130
1131
1132
1133
1135
1136
1137
1139
1140
1141
1142
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1165
1169
1170
1171
1172
1173
1174
1175
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1201
1202
1203
1205
1206
1207
1208
1209
1211
1212
1213
1215
1216
1217
1219
1220
1221
1222
1224
1225
1226
1227
1229
1230
1231
1233
1234
1235
1237
1238
1239
1240
1241
1243
1244
1245
1247
1249
1250
1251
1253
1254
1255
1256
1257
1258
1260
1261
1262
1263
1264
1265
1267
1268
1269
1270
1271
1272
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1288
1289
1290
1292
1293
1294
1296
1297
1298
1300
1304
1305
1307
1308
1309
1311
1330
1331
1333
1334
1335
1337
1338
1339
1340
1342
1344
1345
1346
1347
1349
1350
1351
1352
1354
1355
1356
1358
1360
1361
1362
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
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1434
1435
1436
1437
1438
1439
1441
1442
1443
1445
1446
1447
1449
1450
1451
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1467
1468
1469
1471
1473
1474
1475
1476
1477
1478
1479
1480
1482
1483
1484
1486
1488
1489
1490
1491
1493
1494
1495
1497
1499
1500
1501
1503
1505
1506
1508
1509
1510
1512
1514
1515
1516
1518
1520
1521
1522
1524
1527
1528
1529
1530
1531
1533
1534
1535
1537
1540
1541
1542
1543
1544
1546
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1564
1565
1566
1568
1569
1570
1572
1574
1575
1576
1577
1578
1580
1581
1583
1584
1585
1587
1588
1589
1591
1594
1595
1596
1597
1599
1600
1601
1603
1606
1607
1608
1609
1610
1611
1612
1614
1615
1616
1618
1620
1621
1622
1623
1624
1625
1627
1629
1630
1631
1633
1634
1635
1637
1640
1641
1642
1643
1645
1646
1647
1649
1652
1653
1654
1655
1656
1657
1658
1660
1661
1662
1664
1665
1666
1667
1669
1670
1671
1672
1673
1674
1676
1678
1679
1680
1682
1683
1684
1686
1688
1689
1690
1692
1693
1694
1696
1697
1698
1700
1703
1704
1705
1706
1707
1709
1710
1711
1712
1715
1716
1717
1718
1719
1721
1723
1725
1726
1727
1729
1730
1731
1733
1735
1736
1737
1738
1739
1740
1742
1743
1744
1746
1748
1749
1750
1751
1752
1753
1754
1756
1757
1759
1761
1762
1763
1765
1767
1768
1769
1771
1772
1774
1775
1776
1778
1780
1781
1782
1783
1784
1785
1786
1787
1789
1790
1792
1793
1794
1796
1798
1799
1800
1801
1802
1803
1804
1806
1808
1809
1810
1811
1813
1814
1815
1817
1820
1821
1822
1823
1824
1826
1827
1828
1830
1832
1833
1834
1835
1837
1838
1839
1841
1843
1844
1845
1848
1849
1851
1852
1853
1855
1858
1859
1860
1861
1863
1864
1865
1866
1868
1870
1871
1872
1874
1876
1877
1878
1879
1881
1882
1883
1885
1887
1888
1889
1890
1891
1892
1893
1894
1896
1898
1899
1900
1902
1904
1906
1907
1908
1910
1913
1914
1915
1917
1918
1919
1921
1922
1924
1926
1928
1930
1931
1932
1934
1937
1938
1939
1941
1942
1943
1945
1946
1948
1949
1950
1952
1955
1956
1957
1958
1959
1960
1961
1963
1964
1965
1967
1969
1970
1971
1972
1974
1975
1976
1978
1980
1981
1982
1984
1985
1986
1988
1989
1990
1992
1994
1995
1996
1997
1998
2000
2001
2002
2004
2007
2008
2009
2010
2011
2013
2015
2016
2018
2020
2022
2023
2025
2026
2027
2028
2029
2030
2032
2034
2035
2036
2038
2040
2042
2043
2044
2046
2048
2049
2050
2051
2052
2054
2056
2057
2059
2061
2063
2064
2066
2067
2068
2070
2071
2072
2073
2076
2077
2078
2079
2080
2082
2084
2085
2086
2088
2089
2090
2092
2094
2095
2096
2097
2098
2099
2101
2103
2105
2106
2108
2109
2110
2112
2114
2115
2116
2117
2118
2120
2121
2123
2124
2125
2127
2129
2130
2131
2132
2133
2134
2135
2137
2138
2139
2141
2144
2145
2146
2147
2148
2150
2152
2154
2155
2156
2157
2158
2160
2161
2162
2164
2165
2166
2168
2171
2172
2173
2174
2175
2177
2179
2180
2181
2182
2183
2184
2186
2187
2188
2190
2191
2192
2194
2196
2197
2198
2199
2200
2201
2202
2204
2205
2206
2208
2210
2211
2212
2213
2214
2216
2218
2219
2220
2222
2223
2224
2226
2228
2229
2230
2231
2233
2235 5. Acknowledgements
2237 We would like to thank Alex Dalitz and Roy Arends for their review of
2238 early versions of this draft.
2240 The regular expression for IPv6 addresses was published by Dartware
2241 and altered by the authors to fit with the limited regular expression
2242 syntax of XML Schema.
2244 6. IANA Considerations
2246 This memo uses URNs to describe XML namespaces
2247 [W3C.REC-xml-names-20091208] and XML schemas conforming to a registry
2248 mechanism described in [RFC3688]. Three URI assignments need to be
2249 registered by the IANA.
2251 Registration request for the dnsxml namespace:
2253 URI: urn:ietf:params:xml:ns:dns
2255 Registrant Contact: See the "Author's Address" section of this
2256 memo.
2258 XML: None. Namespace URIs do not represent an XML specification.
2260 Registration request for the dnsxml version specific namespace:
2262 URI: urn:ietf:params:xml:ns:dns-1.0
2264 Registrant Contact: See the "Author's Address" section of this
2265 memo.
2267 XML: None. Namespace URIs do not represent an XML specification.
2269 Registration request for the dnsxml XML schema:
2271 URI: urn:ietf:params:xml:schema:dns-1.0
2273 Registrant Contact: See the "Author's Address" section of this
2274 memo.
2276 XML: See Section 4 of this memo.
2278 7. Security Considerations
2280 This memo includes no security considerations.
2282 8. References
2284 8.1. Normative References
2286 [RFC1035] Mockapetris, P., "Domain names - implementation and
2287 specification", STD 13, RFC 1035, November 1987.
2289 [RFC1183] Everhart, C., Mamakos, L., Ullmann, R., and P.
2290 Mockapetris, "New DNS RR Definitions", RFC 1183, October
2291 1990.
2293 [RFC1706] Manning, B. and R. Colella, "DNS NSAP Resource Records",
2294 RFC 1706, October 1994.
2296 [RFC1712] Farrell, C., Schulze, M., Pleitner, S., and D. Baldoni,
2297 "DNS Encoding of Geographical Location", RFC 1712,
2298 November 1994.
2300 [RFC1876] Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, "A
2301 Means for Expressing Location Information in the Domain
2302 Name System", RFC 1876, January 1996.
2304 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
2305 Requirement Levels", BCP 14, RFC 2119, March 1997.
2307 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
2308 "Dynamic Updates in the Domain Name System (DNS UPDATE)",
2309 RFC 2136, April 1997.
2311 [RFC2163] Allocchio, C., "Using the Internet DNS to Distribute MIXER
2312 Conformant Global Address Mapping (MCGAM)", RFC 2163,
2313 January 1998.
2315 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
2316 Specification", RFC 2181, July 1997.
2318 [RFC2230] Atkinson, R., "Key Exchange Delegation Record for the
2319 DNS", RFC 2230, November 1997.
2321 [RFC2538] Eastlake, D. and O. Gudmundsson, "Storing Certificates in
2322 the Domain Name System (DNS)", RFC 2538, March 1999.
2324 [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC
2325 2672, August 1999.
2327 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
2328 specifying the location of services (DNS SRV)", RFC 2782,
2329 February 2000.
2331 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B.
2332 Wellington, "Secret Key Transaction Authentication for DNS
2333 (TSIG)", RFC 2845, May 2000.
2335 [RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support
2336 IPv6 Address Aggregation and Renumbering", RFC 2874, July
2337 2000.
2339 [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
2340 RR)", RFC 2930, September 2000.
2342 [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (
2343 SIG(0)s)", RFC 2931, September 2000.
2345 [RFC3123] Koch, P., "A DNS RR Type for Lists of Address Prefixes
2346 (APL RR)", RFC 3123, June 2001.
2348 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
2349 Part Three: The Domain Name System (DNS) Database", RFC
2350 3403, October 2002.
2352 [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY
2353 Resource Record (RR)", RFC 3445, December 2002.
2355 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
2356 "DNS Extensions to Support IP Version 6", RFC 3596,
2357 October 2003.
2359 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
2360 (RR) Types", RFC 3597, September 2003.
2362 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
2363 January 2004.
2365 [RFC4025] Richardson, M., "A Method for Storing IPsec Keying
2366 Material in DNS", RFC 4025, March 2005.
2368 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
2369 Rose, "Resource Records for the DNS Security Extensions",
2370 RFC 4034, March 2005.
2372 [RFC4255] Schlyter, J. and W. Griffin, "Using DNS to Securely
2373 Publish Secure Shell (SSH) Key Fingerprints", RFC 4255,
2374 January 2006.
2376 [RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF)
2377 for Authorizing Use of Domains in E-Mail, Version 1", RFC
2378 4408, April 2006.
2380 [RFC4431] Andrews, M. and S. Weiler, "The DNSSEC Lookaside
2381 Validation (DLV) DNS Resource Record", RFC 4431, February
2382 2006.
2384 [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
2385 (DS) Resource Records (RRs)", RFC 4509, May 2006.
2387 [RFC4701] Stapp, M., Lemon, T., and A. Gustafsson, "A DNS Resource
2388 Record (RR) for Encoding Dynamic Host Configuration
2389 Protocol (DHCP) Information (DHCID RR)", RFC 4701, October
2390 2006.
2392 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
2393 Security (DNSSEC) Hashed Authenticated Denial of
2394 Existence", RFC 5155, March 2008.
2396 [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY
2397 and RRSIG Resource Records for DNSSEC", RFC 5702, October
2398 2009.
2400 [RFC5933] Dolmatov, V., Chuprina, A., and I. Ustinov, "Use of GOST
2401 Signature Algorithms in DNSKEY and RRSIG Resource Records
2402 for DNSSEC", RFC 5933, July 2010.
2404 [RFC6195] Eastlake, D., "Domain Name System (DNS) IANA
2405 Considerations", RFC 6195, March 2011.
2407 [RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital
2408 Signature Algorithm (DSA) for DNSSEC", RFC 6605, April
2409 2012.
2411 [W3C.REC-xml-20081126]
2412 Yergeau, F., Maler, E., Paoli, J., Sperberg-McQueen, C.,
2413 and T. Bray, "Extensible Markup Language (XML) 1.0 (Fifth
2414 Edition)", World Wide Web Consortium Recommendation REC-
2415 xml-20081126, November 2008,
2416 .
2418 [W3C.REC-xml-names-20091208]
2419 Hollander, D., Layman, A., Bray, T., Tobin, R., and H.
2420 Thompson, "Namespaces in XML 1.0 (Third Edition)", World
2421 Wide Web Consortium Recommendation REC-xml-names-20091208,
2422 December 2009,
2423 .
2425 [W3C.REC-xmlschema-1-20041028]
2426 Beech, D., Thompson, H., Maloney, M., and N. Mendelsohn,
2427 "XML Schema Part 1: Structures Second Edition", World Wide
2428 Web Consortium Recommendation REC-xmlschema-1-20041028,
2429 October 2004,
2430 .
2432 [W3C.REC-xmlschema-2-20041028]
2433 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
2434 Second Edition", World Wide Web Consortium Recommendation
2435 REC-xmlschema-2-20041028, October 2004,
2436 .
2438 [dns-sec-alg-numbers]
2439 IANA, "Domain Name System Security (DNSSEC) Algorithm
2440 Numbers", 2012, .
2443 8.2. Informative References
2445 [RFC1002] NetBIOS Working Group, "Protocol standard for a NetBIOS
2446 service on a TCP/UDP transport: Detailed specifications",
2447 STD 19, RFC 1002, March 1987.
2449 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
2450 Extensions (MIME) Part One: Format of Internet Message
2451 Bodies", RFC 2045, November 1996.
2453 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
2454 2671, August 1999.
2456 Authors' Addresses
2458 Jay Daley (editor)
2459 .nz Registry Services
2460 PO Box 24361, Manners Street
2461 Wellington 6142
2462 New Zealand
2464 Phone: +64 4 931 6970
2465 Email: jay@nzrs.net.nz
2467 Stephen Morris
2468 Internet Systems Consortium
2469 Grove
2470 UK
2472 John Dickinson
2473 Sinodun
2474 Wallingford
2475 UK