📄 rfc2136.txt
字号:
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]
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
zone_rrset<rr.name, *> = Nil
elsif (rr.name == zname &&
(rr.type == SOA || rr.type == NS))
next [rr]
else
Vixie, et. al. Standards Track [Page 15]
RFC 2136 DNS Update April 1997
zone_rrset<rr.name, rr.type> = Nil
elsif (rr.class == NONE)
if (rr.type == SOA)
next [rr]
if (rr.type == NS && zone_rrset<rr.name, NS> == rr)
next [rr]
zone_rr<rr.name, rr.type, rr.data> = Nil
return (NOERROR)
3.5 - Stability
When a zone is modified by an UPDATE operation, the server must
commit the change to nonvolatile storage before sending a response to
the requestor or answering any queries or transfers for the modified
zone. It is reasonable for a server to store only the update records
as long as a system reboot or power failure will cause these update
records to be incorporated into the zone the next time the server is
started. It is also reasonable for the server to copy the entire
modified zone to nonvolatile storage after each update operation,
though this would have suboptimal performance for large zones.
3.6 - Zone Identity
If the zone's SOA SERIAL is changed by an update operation, that
change must be in a positive direction (using modulo 2**32 arithmetic
as specified by [RFC1982]). Attempts to replace an SOA with one
whose SERIAL is less than the current one will be silently ignored by
the primary master server.
If the zone's SOA's SERIAL is not changed as a result of an update
operation, then the server shall increment it automatically before
the SOA or any changed name or RR or RRset is included in any
response or transfer. The primary master server's implementor might
choose to autoincrement the SOA SERIAL if any of the following events
occurs:
(1) Each update operation.
(2) A name, RR or RRset in the zone has changed and has subsequently
been visible to a DNS client since the unincremented SOA was
visible to a DNS client, and the SOA is about to become visible
to a DNS client.
(3) A configurable period of time has elapsed since the last update
operation. This period shall be less than or equal to one third
of the zone refresh time, and the default shall be the lesser of
that maximum and 300 seconds.
Vixie, et. al. Standards Track [Page 16]
RFC 2136 DNS Update April 1997
(4) A configurable number of updates has been applied since the last
SOA change. The default value for this configuration parameter
shall be one hundred (100).
It is imperative that the zone's contents and the SOA's SERIAL be
tightly synchronized. If the zone appears to change, the SOA must
appear to change as well.
3.7 - Atomicity
During the processing of an UPDATE transaction, the server must
ensure atomicity with respect to other (concurrent) UPDATE or QUERY
transactions. No two transactions can be processed concurrently if
either depends on the final results of the other; in particular, a
QUERY should not be able to retrieve RRsets which have been partially
modified by a concurrent UPDATE, and an UPDATE should not be able to
start from prerequisites that might not still hold at the completion
of some other concurrent UPDATE. Finally, if two UPDATE transactions
would modify the same names, RRs or RRsets, then such UPDATE
transactions must be serialized.
3.8 - Response
At the end of UPDATE processing, a response code will be known. A
response message is generated by copying the ID and Opcode fields
from the request, and either copying the ZOCOUNT, PRCOUNT, UPCOUNT,
and ADCOUNT fields and associated sections, or placing zeros (0) in
the these "count" fields and not including any part of the original
update. The QR bit is set to one (1), and the response is sent back
to the requestor. If the requestor used UDP, then the response will
be sent to the requestor's source UDP port. If the requestor used
TCP, then the response will be sent back on the requestor's open TCP
connection.
4 - Requestor Behaviour
4.1. From a requestor's point of view, any authoritative server for
the zone can appear to be able to process update requests, even
though only the primary master server is actually able to modify the
zone's master file. Requestors are expected to know the name of the
zone they intend to update and to know or be able to determine the
name servers for that zone.
Vixie, et. al. Standards Track [Page 17]
RFC 2136 DNS Update April 1997
4.2. If update ordering is desired, the requestor will need to know
the value of the existing SOA RR. Requestors who update the SOA RR
must update the SOA SERIAL field in a positive direction (as defined
by [RFC1982]) and also preserve the other SOA fields unless the
requestor's explicit intent is to change them. The SOA SERIAL field
must never be set to zero (0).
4.3. If the requestor has reasonable cause to believe that all of a
zone's servers will be equally reachable, then it should arrange to
try the primary master server (as given by the SOA MNAME field if
matched by some NS NSDNAME) first to avoid unnecessary forwarding
inside the slave servers. (Note that the primary master will in some
cases not be reachable by all requestors, due to firewalls or network
partitioning.)
4.4. Once the zone's name servers been found and possibly sorted so
that the ones more likely to be reachable and/or support the UPDATE
opcode are listed first, the requestor composes an UPDATE message of
the following form and sends it to the first name server on its list:
ID: (new)
Opcode: UPDATE
Zone zcount: 1
Zone zname: (zone name)
Zone zclass: (zone class)
Zone ztype: T_SOA
Prerequisite Section: (see previous text)
Update Section: (see previous text)
Additional Data Section: (empty)
4.5. If the requestor receives a response, and the response has an
RCODE other than SERVFAIL or NOTIMP, then the requestor returns an
appropriate response to its caller.
4.6. If a response is received whose RCODE is SERVFAIL or NOTIMP, or
if no response is received within an implementation dependent timeout
period, or if an ICMP error is received indicating that the server's
port is unreachable, then the requestor will delete the unusable
server from its internal name server list and try the next one,
repeating until the name server list is empty. If the requestor runs
out of servers to try, an appropriate error will be returned to the
requestor's caller.
Vixie, et. al. Standards Track [Page 18]
RFC 2136 DNS Update April 1997
5 - Duplicate Detection, Ordering and Mutual Exclusion
5.1. For correct operation, mechanisms may be needed to ensure
idempotence, order UPDATE requests and provide mutual exclusion. An
UPDATE message or response might be delivered zero times, one time,
or multiple times. Datagram duplication is of particular interest
since it covers the case of the so-called "replay attack" where a
correct request is duplicated maliciously by an intruder.
5.2. Multiple UPDATE requests or responses in transit might be
delivered in any order, due to network topology changes or load
balancing, or to multipath forwarding graphs wherein several slave
servers all forward to the primary master. In some cases, it might
be required that the earlier update not be applied after the later
update, where "earlier" and "later" are defined by an external time
base visible to some set of requestors, rather than by the order of
request receipt at the primary master.
5.3. A requestor can ensure transaction idempotence by explicitly
deleting some "marker RR" (rather than deleting the RRset of which it
is a part) and then adding a new "marker RR" with a different RDATA
field. The Prerequisite Section should specify that the original
"marker RR" must be present in order for this UPDATE message to be
accepted by the server.
5.4. If the request is duplicated by a network error, all duplicate
requests will fail since only the first will find the original
"marker RR" present and having its known previous value. The
decisions of whether to use such a "marker RR" and what RR to use are
left up to the application programmer, though one obvious choice is
the zone's SOA RR as described below.
5.5. Requestors can ensure update ordering by externally
synchronizing their use of successive values of the "marker RR."
Mutual exclusion can be addressed as a degenerate case, in that a
single succession of the "marker RR" is all that is needed.
5.6. A special case where update ordering and datagram duplication
intersect is when an RR validly changes to some new value and then
back to its previous value. Without a "marker RR" as described
above, this sequence of updates can leave the zone in an undefined
state if datagrams are duplicated.
5.7. To achieve an atomic multitransaction "read-modify-write" cycle,
a requestor could first retrieve the SOA RR, and build an UPDATE
message one of whose prerequisites was the old SOA RR. It would then
specify updates that would delete this SOA RR and add a new one with
an incremented SOA SERIAL, along with whatever actual prerequisites
Vixie, et. al. Standards Track [Page 19]
RFC 2136 DNS Update April 1997
and updates were the object of the transaction. If the transaction
succeeds, the requestor knows that the RRs being changed were not
otherwise altered by any other requestor.
6 - Forwarding
When a zone slave forwards an UPDATE message upward toward the zone's
primary master server, it must allocate a new ID and prepare to enter
the role of "forwarding server," which is a requestor with respect to
the forward server.
6.1. The set of forward servers will be same as the set of servers
this zone slave would use as the source of AXFR or IXFR data. So,
while the original requestor might have used the zone's NS RRset to
locate its update server, a forwarder always forwards toward its
designated zone master servers.
6.2. If the original requestor used TCP, then the TCP connection from
the requestor is still open and the forwarder must use TCP to forward
the message. If the original requestor used UDP, the forwarder may
use either UDP or TCP to forward the message, at the whim of the
implementor.
6.3. It is reasonable for forward servers to be forwarders
themselves, if the AXFR dependency graph being followed is a deep one
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -