 |
A key part of prerequisite processing is reporting on failures. Towards this
end, multiple responses are defined, any of which may be generated during
prerequisite processing. The prerequisite-processing responses are provided in
the "response-code" field of the message headers, just as in normal queries. In
fact, many of the response codes from the standard query also are used with
dynamic DNS responses, though many new responses are defined explicitly for
reporting on the success of prerequisite processing. The five prerequisite
comparisons and response codes defined in RFC 2136 are:
- Domain Name Must Not Exist. If an update operation needs to verify that a domain name does not already exist in the zone table (regardless of the resource records that may be associated with the domain name), the client provides the domain name to be tested along with a resource record code for "all" (code value 255), and a network class code of "none" (code value 254). Because there is no comparison of the domain name's resource records or their values, the data is set to null and the time-to-live value is set to 0 in these entries. If this prerequisite fails, the name exists error (code value 6) must be returned in the response code of the response message.
- Domain Name Must Exist. If an update operation needs to verify that a domain name does exist in the current zone, it provides the domain name to be tested along with a resource code of "all" and a network class code of "any." The use of "any" instead of "none" identifies this prerequisite separately from the Name Must Not Exist prerequisite. Because there is no comparison of the domain name's resource records or their values, the data is set to null and the time-to-live value is set to 0 in these entries. If this prerequisite fails, the nonexistent domain name error (code value 3) must be returned in the response code of the response message.
- Resource Record Must Not Exist. If an update operation needs to verify that a domain name exists and does not have a particular type of resource record associated with it, the domain name of the leaf node will be provided along with the specific resource code that needs to be tested. However, the network class code must be "none," and no data should be provided with the resource record, while the time-to-live value should be 0. If the prerequisite fails, the resource record exists error (code value 7) must be returned in the response code of the response message.
- Resource Record of Any Value Must Exist. If an update operation needs to verify that a domain name exists and has a specific type of resource record attached to it (regardless of that resource record's data), the domain name of the leaf node will be provided along with the specific resource code that needs to be tested. However, the network class code must be "*" (distinguishing this prerequisite from the Resource Record Must Not Exist prerequisite which uses a network class of "none"), and no data should be provided with the resource record, while the time-to-live value should be 0. If the prerequisite fails, the Resource Record Does Not Exist error (code value 8) must be returned in the Response Code of the response message.
- Resource Record of a Specific Value Must Exist. If an update operation needs to verify that a domain name exists with a specific type of resource record with specific data, the domain name of the leaf node will be provided along with the specific resource code that needs to be tested, a network class code that is equal to the data being tested, and the resource record data which must be present. The time-to-live value must be zero, but all other elements of the comparison must be provided. If the prerequisite fails, the resource record does not exist error (code value 8) must be returned in the response code of the response message.
Although it may seem that a normal lookup query issued by the client prior to
update processing could serve the same purpose of detecting existing entries,
this isn't entirely true since standard queries are not guaranteed to have
access to valid data. For example, the lookup query may be received by a local
caching server that answers the query with invalid data. Conversely, an Update
Message will eventually have to be processed by a server that is authoritative
for the zone in question, so sending prerequisites as part of the Update message practically guarantees that conditions will be tested against accurate and current data.
|
|
RSS
