Network Working Group P. Vixie, Editor
`Request for Comments: 2136 ISC
`Updates: 1035 S. Thomson
`Category: Standards Track Bellcore
` Y. Rekhter
` Cisco
` J. Bound
` DEC
` April 1997
`
` Dynamic Updates in the Domain Name System (DNS UPDATE)
`
`Status of this Memo
`
` This document specifies an Internet standards track protocol for the
` Internet community, and requests discussion and suggestions for
` improvements. Please refer to the current edition of the "Internet
` Official Protocol Standards" (STD 1) for the standardization state
` and status of this protocol. Distribution of this memo is unlimited.
`
`Abstract
`
` The Domain Name System was originally designed to support queries of
` a statically configured database. While the data was expected to
` change, the frequency of those changes was expected to be fairly low,
` and all updates were made as external edits to a zone’s Master File.
`
` Using this specification of the UPDATE opcode, it is possible to add
` or delete RRs or RRsets from a specified zone. Prerequisites are
` specified separately from update operations, and can specify a
` dependency upon either the previous existence or nonexistence of an
` RRset, or the existence of a single RR.
`
` UPDATE is atomic, i.e., all prerequisites must be satisfied or else
` no update operations will take place. There are no data dependent
` error conditions defined after the prerequisites have been met.
`
`1 - Definitions
`
` This document intentionally gives more definition to the roles of
` "Master," "Slave," and "Primary Master" servers, and their
` enumeration in NS RRs, and the SOA MNAME field. In that sense, the
` following server type definitions can be considered an addendum to
` [RFC1035], and are intended to be consistent with [RFC1996]:
`
` Slave an authoritative server that uses AXFR or IXFR to
` retrieve the zone and is named in the zone’s NS
` RRset.
`
`Vixie, et. al. Standards Track [Page 1]
`
`Petitioner Apple Inc. - Exhibit 1065, p. 1
`
`

`
`RFC 2136 DNS Update April 1997
`
` Master an authoritative server configured to be the
` source of AXFR or IXFR data for one or more slave
` servers.
`
` Primary Master master server at the root of the AXFR/IXFR
` dependency graph. The primary master is named in
` the zone’s SOA MNAME field and optionally by an NS
` RR. There is by definition only one primary master
` server per zone.
`
` A domain name identifies a node within the domain name space tree
` structure. Each node has a set (possibly empty) of Resource Records
` (RRs). All RRs having the same NAME, CLASS and TYPE are called a
` Resource Record Set (RRset).
`
` The pseudocode used in this document is for example purposes only.
` If it is found to disagree with the text, the text shall be
` considered authoritative. If the text is found to be ambiguous, the
` pseudocode can be used to help resolve the ambiguity.
`
` 1.1 - Comparison Rules
`
` 1.1.1. Two RRs are considered equal if their NAME, CLASS, TYPE,
` RDLENGTH and RDATA fields are equal. Note that the time-to-live
` (TTL) field is explicitly excluded from the comparison.
`
` 1.1.2. The rules for comparison of character strings in names are
` specified in [RFC1035 2.3.3].
`
` 1.1.3. Wildcarding is disabled. That is, a wildcard ("*") in an
` update only matches a wildcard ("*") in the zone, and vice versa.
`
` 1.1.4. Aliasing is disabled: A CNAME in the zone matches a CNAME in
` the update, and will not otherwise be followed. All UPDATE
` operations are done on the basis of canonical names.
`
` 1.1.5. The following RR types cannot be appended to an RRset. If the
` following comparison rules are met, then an attempt to add the new RR
` will result in the replacement of the previous RR:
`
` SOA compare only NAME, CLASS and TYPE -- it is not possible to
` have more than one SOA per zone, even if any of the data
` fields differ.
`
` WKS compare only NAME, CLASS, TYPE, ADDRESS, and PROTOCOL
` -- only one WKS RR is possible for this tuple, even if the
` services masks differ.
`
`Vixie, et. al. Standards Track [Page 2]
`
`Petitioner Apple Inc. - Exhibit 1065, p. 2
`
`

`
`RFC 2136 DNS Update April 1997
`
` CNAME compare only NAME, CLASS, and TYPE -- it is not possible
` to have more than one CNAME RR, even if their data fields
` differ.
`
` 1.2 - Glue RRs
`
` For the purpose of determining whether a domain name used in the
` UPDATE protocol is contained within a specified zone, a domain name
` is "in" a zone if it is owned by that zone’s domain name. See
` section 7.18 for details.
`
` 1.3 - New Assigned Numbers
`
` CLASS = NONE (254)
` RCODE = YXDOMAIN (6)
` RCODE = YXRRSET (7)
` RCODE = NXRRSET (8)
` RCODE = NOTAUTH (9)
` RCODE = NOTZONE (10)
` Opcode = UPDATE (5)
`
`2 - Update Message Format
`
` The DNS Message Format is defined by [RFC1035 4.1]. Some extensions
` are necessary (for example, more error codes are possible under
` UPDATE than under QUERY) and some fields must be overloaded (see
` description of CLASS fields below).
`
` The overall format of an UPDATE message is, following [ibid]:
`
` +---------------------+
` | Header |
` +---------------------+
` | Zone | specifies the zone to be updated
` +---------------------+
` | Prerequisite | RRs or RRsets which must (not) preexist
` +---------------------+
` | Update | RRs or RRsets to be added or deleted
` +---------------------+
` | Additional Data | additional data
` +---------------------+
`
`Vixie, et. al. Standards Track [Page 3]
`
`Petitioner Apple Inc. - Exhibit 1065, p. 3
`
`

`
`RFC 2136 DNS Update April 1997
`
` The Header Section specifies that this message is an UPDATE, and
` describes the size of the other sections. The Zone Section names the
` zone that is to be updated by this message. The Prerequisite Section
` specifies the starting invariants (in terms of zone content) required
` for this update. The Update Section contains the edits to be made,
` and the Additional Data Section contains data which may be necessary
` to complete, but is not part of, this update.
`
` 2.1 - Transport Issues
`
` An update transaction may be carried in a UDP datagram, if the
` request fits, or in a TCP connection (at the discretion of the
` requestor). When TCP is used, the message is in the format described
` in [RFC1035 4.2.2].
`
` 2.2 - Message Header
`
` The header of the DNS Message Format is defined by [RFC 1035 4.1].
` Not all opcodes define the same set of flag bits, though as a
` practical matter most of the bits defined for QUERY (in [ibid]) are
` identically defined by the other opcodes. UPDATE uses only one flag
` bit (QR).
`
` The DNS Message Format specifies record counts for its four sections
` (Question, Answer, Authority, and Additional). UPDATE uses the same
` fields, and the same section formats, but the naming and use of these
` sections differs as shown in the following modified header, after
` [RFC1035 4.1.1]:
`
` 1 1 1 1 1 1
` 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
` +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
` | ID |
` +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
` |QR| Opcode | Z | RCODE |
` +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
` | ZOCOUNT |
` +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
` | PRCOUNT |
` +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
` | UPCOUNT |
` +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
` | ADCOUNT |
` +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
`
`Vixie, et. al. Standards Track [Page 4]
`
`Petitioner Apple Inc. - Exhibit 1065, p. 4
`
`

`
`RFC 2136 DNS Update April 1997
`
` These fields are used as follows:
`
` ID A 16-bit identifier assigned by the entity that generates any
` kind of request. This identifier is copied in the
` corresponding reply and can be used by the requestor to match
` replies to outstanding requests, or by the server to detect
` duplicated requests from some requestor.
`
` QR A one bit field that specifies whether this message is a
` request (0), or a response (1).
`
` Opcode A four bit field that specifies the kind of request in this
` message. This value is set by the originator of a request
` and copied into the response. The Opcode value that
` identifies an UPDATE message is five (5).
`
` Z Reserved for future use. Should be zero (0) in all requests
` and responses. A non-zero Z field should be ignored by
` implementations of this specification.
`
` RCODE Response code - this four bit field is undefined in requests
` and set in responses. The values and meanings of this field
` within responses are as follows:
`
` Mneumonic Value Description
` ------------------------------------------------------------
` NOERROR 0 No error condition.
` FORMERR 1 The name server was unable to interpret
` the request due to a format error.
` SERVFAIL 2 The name server encountered an internal
` failure while processing this request,
` for example an operating system error
` or a forwarding timeout.
` NXDOMAIN 3 Some name that ought to exist,
` does not exist.
` NOTIMP 4 The name server does not support
` the specified Opcode.
` REFUSED 5 The name server refuses to perform the
` specified operation for policy or
` security reasons.
` YXDOMAIN 6 Some name that ought not to exist,
` does exist.
` YXRRSET 7 Some RRset that ought not to exist,
` does exist.
` NXRRSET 8 Some RRset that ought to exist,
` does not exist.
`
`Vixie, et. al. Standards Track [Page 5]
`
`Petitioner Apple Inc. - Exhibit 1065, p. 5
`
`

`
`RFC 2136 DNS Update April 1997
`
` NOTAUTH 9 The server is not authoritative for
` the zone named in the Zone Section.
` NOTZONE 10 A name used in the Prerequisite or
` Update Section is not within the
` zone denoted by the Zone Section.
`
` ZOCOUNT The number of RRs in the Zone Section.
`
` PRCOUNT The number of RRs in the Prerequisite Section.
`
` UPCOUNT The number of RRs in the Update Section.
`
` ADCOUNT The number of RRs in the Additional Data Section.
`
` 2.3 - Zone Section
`
` The Zone Section has the same format as that specified in [RFC1035
` 4.1.2], with the fields redefined as follows:
`
` 1 1 1 1 1 1
` 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
` +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
` | |
` / ZNAME /
` / /
` +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
` | ZTYPE |
` +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
` | ZCLASS |
` +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
`
` UPDATE uses this section to denote the zone of the records being
` updated. All records to be updated must be in the same zone, and
` therefore the Zone Section is allowed to contain exactly one record.
` The ZNAME is the zone name, the ZTYPE must be SOA, and the ZCLASS is
` the zone’s class.
`
` 2.4 - Prerequisite Section
`
` This section contains a set of RRset prerequisites which must be
` satisfied at the time the UPDATE packet is received by the primary
` master server. The format of this section is as specified by
` [RFC1035 4.1.3]. There are five possible sets of semantics that can
` be expressed here, summarized as follows and then explained below.
`
` (1) RRset exists (value independent). At least one RR with a
` specified NAME and TYPE (in the zone and class specified by
` the Zone Section) must exist.
`
`Vixie, et. al. Standards Track [Page 6]
`
`Petitioner Apple Inc. - Exhibit 1065, p. 6
`
`

`
`RFC 2136 DNS Update April 1997
`
` (2) RRset exists (value dependent). A set of RRs with a
` specified NAME and TYPE exists and has the same members
` with the same RDATAs as the RRset specified here in this
` Section.
`
` (3) RRset does not exist. No RRs with a specified NAME and TYPE
` (in the zone and class denoted by the Zone Section) can exist.
`
` (4) Name is in use. At least one RR with a specified NAME (in
` the zone and class specified by the Zone Section) must exist.
` Note that this prerequisite is NOT satisfied by empty
` nonterminals.
`
` (5) Name is not in use. No RR of any type is owned by a
` specified NAME. Note that this prerequisite IS satisfied by
` empty nonterminals.
`
` The syntax of these is as follows:
`
` 2.4.1 - RRset Exists (Value Independent)
`
` At least one RR with a specified NAME and TYPE (in the zone and class
` specified in the Zone Section) must exist.
`
` For this prerequisite, a requestor adds to the section a single RR
` whose NAME and TYPE are equal to that of the zone RRset whose
` existence is required. RDLENGTH is zero and RDATA is therefore
` empty. CLASS must be specified as ANY to differentiate this
` condition from that of an actual RR whose RDLENGTH is naturally zero
` (0) (e.g., NULL). TTL is specified as zero (0).
`
` 2.4.2 - RRset Exists (Value Dependent)
`
` A set of RRs with a specified NAME and TYPE exists and has the same
` members with the same RDATAs as the RRset specified here in this
` section. While RRset ordering is undefined and therefore not
` significant to this comparison, the sets be identical in their
` extent.
`
` For this prerequisite, a requestor adds to the section an entire
` RRset whose preexistence is required. NAME and TYPE are that of the
` RRset being denoted. CLASS is that of the zone. TTL must be
` specified as zero (0) and is ignored when comparing RRsets for
` identity.
`
`Vixie, et. al. Standards Track [Page 7]
`
`Petitioner Apple Inc. - Exhibit 1065, p. 7
`
`

`
`RFC 2136 DNS Update April 1997
`
` 2.4.3 - RRset Does Not Exist
`
` No RRs with a specified NAME and TYPE (in the zone and class denoted
` by the Zone Section) can exist.
`
` For this prerequisite, a requestor adds to the section a single RR
` whose NAME and TYPE are equal to that of the RRset whose nonexistence
` is required. The RDLENGTH of this record is zero (0), and RDATA
` field is therefore empty. CLASS must be specified as NONE in order
` to distinguish this condition from a valid RR whose RDLENGTH is
` naturally zero (0) (for example, the NULL RR). TTL must be specified
` as zero (0).
`
` 2.4.4 - Name Is In Use
`
` Name is in use. At least one RR with a specified NAME (in the zone
` and class specified by the Zone Section) must exist. Note that this
` prerequisite is NOT satisfied by empty nonterminals.
`
` For this prerequisite, a requestor adds to the section a single RR
` whose NAME is equal to that of the name whose ownership of an RR is
` required. RDLENGTH is zero and RDATA is therefore empty. CLASS must
` be specified as ANY to differentiate this condition from that of an
` actual RR whose RDLENGTH is naturally zero (0) (e.g., NULL). TYPE
` must be specified as ANY to differentiate this case from that of an
` RRset existence test. TTL is specified as zero (0).
`
` 2.4.5 - Name Is Not In Use
`
` Name is not in use. No RR of any type is owned by a specified NAME.
` Note that this prerequisite IS satisfied by empty nonterminals.
`
` For this prerequisite, a requestor adds to the section a single RR
` whose NAME is equal to that of the name whose nonownership of any RRs
` is required. RDLENGTH is zero and RDATA is therefore empty. CLASS
` must be specified as NONE. TYPE must be specified as ANY. TTL must
` be specified as zero (0).
`
` 2.5 - Update Section
`
` This section contains RRs to be added to or deleted from the zone.
` The format of this section is as specified by [RFC1035 4.1.3]. There
` are four possible sets of semantics, summarized below and with
` details to follow.
`
`Vixie, et. al. Standards Track [Page 8]
`
`Petitioner Apple Inc. - Exhibit 1065, p. 8
`
`

`
`RFC 2136 DNS Update April 1997
`
` (1) Add RRs to an RRset.
` (2) Delete an RRset.
` (3) Delete all RRsets from a name.
` (4) Delete an RR from an RRset.
`
` The syntax of these is as follows:
`
` 2.5.1 - Add To An RRset
`
` RRs are added to the Update Section whose NAME, TYPE, TTL, RDLENGTH
` and RDATA are those being added, and CLASS is the same as the zone
` class. Any duplicate RRs will be silently ignored by the primary
` master.
`
` 2.5.2 - Delete An RRset
`
` One RR is added to the Update Section whose NAME and TYPE are those
` of the RRset to be deleted. TTL must be specified as zero (0) and is
` otherwise not used by the primary master. CLASS must be specified as
` ANY. RDLENGTH must be zero (0) and RDATA must therefore be empty.
` If no such RRset exists, then this Update RR will be silently ignored
` by the primary master.
`
` 2.5.3 - Delete All RRsets From A Name
`
` One RR is added to the Update Section whose NAME is that of the name
` to be cleansed of RRsets. TYPE must be specified as ANY. TTL must
` be specified as zero (0) and is otherwise not used by the primary
` master. CLASS must be specified as ANY. RDLENGTH must be zero (0)
` and RDATA must therefore be empty. If no such RRsets exist, then
` this Update RR will be silently ignored by the primary master.
`
` 2.5.4 - Delete An RR From An RRset
`
` RRs to be deleted are added to the Update Section. The NAME, TYPE,
` RDLENGTH and RDATA must match the RR being deleted. TTL must be
` specified as zero (0) and will otherwise be ignored by the primary
` master. CLASS must be specified as NONE to distinguish this from an
` RR addition. If no such RRs exist, then this Update RR will be
` silently ignored by the primary master.
`
`Vixie, et. al. Standards Track [Page 9]
`
`Petitioner Apple Inc. - Exhibit 1065, p. 9
`
`

`
`RFC 2136 DNS Update April 1997
`
` 2.6 - Additional Data Section
`
` This section contains RRs which are related to the update itself, or
` to new RRs being added by the update. For example, out of zone glue
` (A RRs referred to by new NS RRs) should be presented here. The
` server can use or ignore out of zone glue, at the discretion of the
` server implementor. The format of this section is as specified by
` [RFC1035 4.1.3].
`
`3 - Server Behavior
`
` A server, upon receiving an UPDATE request, will signal NOTIMP to the
` requestor if the UPDATE opcode is not recognized or if it is
` recognized but has not been implemented. Otherwise, processing
` continues as follows.
`
` 3.1 - Process Zone Section
`
` 3.1.1. The Zone Section is checked to see that there is exactly one
` RR therein and that the RR’s ZTYPE is SOA, else signal FORMERR to the
` requestor. Next, the ZNAME and ZCLASS are checked to see if the zone
` so named is one of this server’s authority zones, else signal NOTAUTH
` to the requestor. If the server is a zone slave, the request will be
` forwarded toward the primary master.
`
` 3.1.2 - Pseudocode For Zone Section Processing
`
` if (zcount != 1 || ztype != SOA)
` return (FORMERR)
` if (zone_type(zname, zclass) == SLAVE)
` return forward()
` if (zone_type(zname, zclass) == MASTER)
` return update()
` return (NOTAUTH)
`
` Sections 3.2 through 3.8 describe the primary master’s behaviour,
` whereas Section 6 describes a forwarder’s behaviour.
`
` 3.2 - Process Prerequisite Section
`
` Next, the Prerequisite Section is checked to see that all
` prerequisites are satisfied by the current state of the zone. Using
` the definitions expressed in Section 1.2, if any RR’s NAME is not
` within the zone specified in the Zone Section, signal NOTZONE to the
` requestor.
`
`Vixie, et. al. Standards Track [Page 10]
`
`Petitioner Apple Inc. - Exhibit 1065, p. 10
`
`

`
`RFC 2136 DNS Update April 1997
`
` 3.2.1. For RRs in this section whose CLASS is ANY, test to see that
` TTL and RDLENGTH are both zero (0), else signal FORMERR to the
` requestor. If TYPE is ANY, test to see that there is at least one RR
` in the zone whose NAME is the same as that of the Prerequisite RR,
` else signal NXDOMAIN to the requestor. If TYPE is not ANY, test to
` see that there is at least one RR in the zone whose NAME and TYPE are
` the same as that of the Prerequisite RR, else signal NXRRSET to the
` requestor.
`
` 3.2.2. For RRs in this section whose CLASS is NONE, test to see that
` the TTL and RDLENGTH are both zero (0), else signal FORMERR to the
` requestor. If the TYPE is ANY, test to see that there are no RRs in
` the zone whose NAME is the same as that of the Prerequisite RR, else
` signal YXDOMAIN to the requestor. If the TYPE is not ANY, test to
` see that there are no RRs in the zone whose NAME and TYPE are the
` same as that of the Prerequisite RR, else signal YXRRSET to the
` requestor.
`
` 3.2.3. For RRs in this section whose CLASS is the same as the ZCLASS,
` test to see that the TTL is zero (0), else signal FORMERR to the
` requestor. Then, build an RRset for each unique <NAME,TYPE> and
` compare each resulting RRset for set equality (same members, no more,
` no less) with RRsets in the zone. If any Prerequisite RRset is not
` entirely and exactly matched by a zone RRset, signal NXRRSET to the
` requestor. If any RR in this section has a CLASS other than ZCLASS
` or NONE or ANY, signal FORMERR to the requestor.
`
` 3.2.4 - Table Of Metavalues Used In Prerequisite Section
`
` CLASS TYPE RDATA Meaning
` ------------------------------------------------------------
` ANY ANY empty Name is in use
` ANY rrset empty RRset exists (value independent)
` NONE ANY empty Name is not in use
` NONE rrset empty RRset does not exist
` zone rrset rr RRset exists (value dependent)
`
`Vixie, et. al. Standards Track [Page 11]
`
`Petitioner Apple Inc. - Exhibit 1065, p. 11
`
`

`
`RFC 2136 DNS Update April 1997
`
` 3.2.5 - Pseudocode for Prerequisite Section Processing
`
` for rr in prerequisites
` if (rr.ttl != 0)
` return (FORMERR)
` if (zone_of(rr.name) != ZNAME)
` return (NOTZONE);
` if (rr.class == ANY)
` if (rr.rdlength != 0)
` return (FORMERR)
` if (rr.type == ANY)
` if (!zone_name<rr.name>)
` return (NXDOMAIN)
` else
` if (!zone_rrset<rr.name, rr.type>)
` return (NXRRSET)
` if (rr.class == NONE)
` if (rr.rdlength != 0)
` return (FORMERR)
` if (rr.type == ANY)
` if (zone_name<rr.name>)
` return (YXDOMAIN)
` else
` if (zone_rrset<rr.name, rr.type>)
` return (YXRRSET)
` if (rr.class == zclass)
` temp<rr.name, rr.type> += rr
` else
` return (FORMERR)
`
` for rrset in temp
` if (zone_rrset<rrset.name, rrset.type> != rrset)
` return (NXRRSET)
`
` 3.3 - Check Requestor’s Permissions
`
` 3.3.1. Next, the requestor’s permission to update the RRs named in
` the Update Section may be tested in an implementation dependent
` fashion or using mechanisms specified in a subsequent Secure DNS
` Update protocol. If the requestor does not have permission to
` perform these updates, the server may write a warning message in its
` operations log, and may either signal REFUSED to the requestor, or
` ignore the permission problem and proceed with the update.
`
`Vixie, et. al. Standards Track [Page 12]
`
`Petitioner Apple Inc. - Exhibit 1065, p. 12
`
`

`
`RFC 2136 DNS Update April 1997
`
` 3.3.2. While the exact processing is implementation defined, if these
` verification activities are to be performed, this is the point in the
` server’s processing where such performance should take place, since
` if a REFUSED condition is encountered after an update has been
` partially applied, it will be necessary to undo the partial update
` and restore the zone to its original state before answering the
` requestor.
`
` 3.3.3 - Pseudocode for Permission Checking
`
` if (security policy exists)
` if (this update is not permitted)
` if (local option)
` log a message about permission problem
` if (local option)
` return (REFUSED)
`
` 3.4 - Process Update Section
`
` Next, the Update Section is processed as follows.
`
` 3.4.1 - Prescan
`
` The Update Section is parsed into RRs and each RR’s CLASS is checked
` to see if it is ANY, NONE, or the same as the Zone Class, else signal
` a FORMERR to the requestor. Using the definitions in Section 1.2,
` each RR’s NAME must be in the zone specified by the Zone Section,
` else signal NOTZONE to the requestor.
`
` 3.4.1.2. For RRs whose CLASS is not ANY, check the TYPE and if it is
` ANY, AXFR, MAILA, MAILB, or any other QUERY metatype, or any
` unrecognized type, then signal FORMERR to the requestor. For RRs
` whose CLASS is ANY or NONE, check the TTL to see that it is zero (0),
` else signal a FORMERR to the requestor. For any RR whose CLASS is
` ANY, check the RDLENGTH to make sure that it is zero (0) (that is,
` the RDATA field is empty), and that the TYPE is not AXFR, MAILA,
` MAILB, or any other QUERY metatype besides ANY, or any unrecognized
` type, else signal FORMERR to the requestor.
`
`Vixie, et. al. Standards Track [Page 13]
`
`Petitioner Apple Inc. - Exhibit 1065, p. 13
`
`

`
`RFC 2136 DNS Update April 1997
`
` 3.4.1.3 - Pseudocode For Update Section Prescan
`
` [rr] for rr in updates
` if (zone_of(rr.name) != ZNAME)
` return (NOTZONE);
` if (rr.class == zclass)
` if (rr.type & ANY|AXFR|MAILA|MAILB)
` return (FORMERR)
` elsif (rr.class == ANY)
` if (rr.ttl != 0 || rr.rdlength != 0
` || rr.type & AXFR|MAILA|MAILB)
` return (FORMERR)
` elsif (rr.class == NONE)
` if (rr.ttl != 0 || rr.type & ANY|AXFR|MAILA|MAILB)
` return (FORMERR)
` else
` return (FORMERR)
`
` 3.4.2 - Update
`
` The Update Section is parsed into RRs and these RRs are processed in
` order.
`
` 3.4.2.1. If any system failure (such as an out of memory condition,
` or a hardware error in persistent storage) occurs during the
` processing of this section, signal SERVFAIL to the requestor and undo
` all updates applied to the zone during this transaction.
`
` 3.4.2.2. Any Update RR whose CLASS is the same as ZCLASS is added to
` the zone. In case of duplicate RDATAs (which for SOA RRs is always
` the case, and for WKS RRs is the case if the ADDRESS and PROTOCOL
` fields both match), the Zone RR is replaced by Update RR. If the
` TYPE is SOA and there is no Zone SOA RR, or the new SOA.SERIAL is
` lower (according to [RFC1982]) than or equal to the current Zone SOA
` RR’s SOA.SERIAL, the Update RR is ignored. In the case of a CNAME
` Update RR and a non-CNAME Zone RRset or vice versa, ignore the CNAME
` Update RR, otherwise replace the CNAME Zone RR with the CNAME Update
` RR.
`
` 3.4.2.3. For any Update RR whose CLASS is ANY and whose TYPE is ANY,
` all Zone RRs with the same NAME are deleted, unless the NAME is the
` same as ZNAME in which case only those RRs whose TYPE is other than
` SOA or NS are deleted. For any Update RR whose CLASS is ANY and
` whose TYPE is not ANY all Zone RRs with the same NAME and TYPE are
` deleted, unless the NAME is the same as ZNAME in which case neither
` SOA or NS RRs will be deleted.
`
`Vixie, et. al. Standards Track [Page 14]
`
`Petitioner Apple Inc. - Exhibit 1065, p. 14
`
`

`
`RFC 2136 DNS Update April 1997
`
` 3.4.2.4. For any Update RR whose class is NONE, any Zone RR whose
` NAME, TYPE, RDATA and RDLENGTH are equal to the Update RR is deleted,
` unless the NAME is the same as ZNAME and either the TYPE is SOA or
` the TYPE is NS and the matching Zone RR is the only NS remaining in
` the RRset, in which case this Update RR is ignored.
`
` 3.4.2.5. Signal NOERROR to the requestor.
`
` 3.4.2.6 - Table Of Metavalues Used In Update Section
`
` CLASS TYPE RDATA Meaning
` ---------------------------------------------------------
` ANY ANY empty Delete all RRsets from a name
` ANY rrset empty Delete an RRset
` NONE rrset rr Delete an RR from an RRset
` zone rrset rr Add to an RRset
`
` 3.4.2.7 - Pseudocode For Update Section Processing
`
` [rr] for rr in updates
` if (rr.class == zclass)
` if (rr.type == CNAME)
` if (zone_rrset<rr.name, ˜CNAME>)
` next [rr]
` elsif (zone_rrset<rr.name, CNAME>)
` next [rr]
` if (rr.type == SOA)
` if (!zone_rrset<rr.name, SOA> ||
` zone_rr<rr.name, SOA>.serial > rr.soa.serial)
` next [rr]
` for zrr in zone_rrset<rr.name, rr.type>
` if (rr.type == CNAME || rr.type == SOA ||
` (rr.type == WKS && rr.proto == zrr.proto &&
` rr.address == zrr.address) ||
` rr.rdata == zrr.rdata)
` zrr = rr
` next [rr]
` zone_rrset<rr.name, rr.type> += rr
` elsif (rr.class == ANY)
` if (rr.type == ANY)
` if (rr.name == zname)
` zone_rrset<rr.name, ˜(SOA|NS)> = Nil
` else
`