blank.gif (43 bytes)

Church Of The
Swimming Elephant

5. Duplicate Detection, Ordering and Mutual Exclusion Connected: An Internet Encyclopedia
5. Duplicate Detection, Ordering and Mutual Exclusion

Up: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 2136
Prev: 4. Requestor Behaviour
Next: 6. Forwarding

5. Duplicate Detection, Ordering and Mutual Exclusion

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 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.

Next: 6. Forwarding

Connected: An Internet Encyclopedia
5. Duplicate Detection, Ordering and Mutual Exclusion


Protect yourself from cyberstalkers, identity thieves, and those who would snoop on you.
Stop spam from invading your inbox without losing the mail you want. We give you more control over your e-mail than any other service.
Block popups, ads, and malicious scripts while you surf the net through our anonymous proxies.
Participate in Usenet, host your web files, easily send anonymous messages, and more, much more.
All private, all encrypted, all secure, all in an easy to use service, and all for only $5.95 a month!

Service Details

Have you gone to church today?
All pages ©1999, 2000, 2001, 2002, 2003 Church of the Swimming Elephant unless otherwise stated
Church of the Swimming Elephant©1999, 2000, 2001, 2002, 2003 is a wholly owned subsidiary of Packetderm, LLC.

Packetderm, LLC
210 Park Ave #308
Worcester, MA 01609