blank.gif (43 bytes)

Church Of The
Swimming Elephant

Search:
4. Requestor Behaviour Connected: An Internet Encyclopedia
4. Requestor Behaviour

Up: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 2136
Prev: 3.8. Response
Next: 5. Duplicate Detection, Ordering and Mutual Exclusion

4. Requestor Behaviour

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.

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.


Next: 5. Duplicate Detection, Ordering and Mutual Exclusion

Connected: An Internet Encyclopedia
4. Requestor Behaviour

Cotse.Net

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

 
.
www.cotse.com
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 Cotse.com.
Cotse.com is a wholly owned subsidiary of Packetderm, LLC.

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