2.2. Message Header (original) (raw)
Connected: An Internet Encyclopedia
2.2. Message Header
Up: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 2136
Up: 2. Update Message Format
Prev: 2.1. Transport Issues
Next: 2.3. Zone Section
2.2. Message Header
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 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+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.
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.
Next: 2.3. Zone Section
Connected: An Internet Encyclopedia
2.2. Message Header