The data origin authentication service described above protects retrieved resource records but provides no protection for DNS requests or for message headers.
If header bits are falsely set by a server, there is little that can be done. However, it is possible to add transaction authentication. Such authentication means that a resolver can be sure it is at least getting messages from the server it thinks it queried, that the response is from the query it sent, and that these messages have not been diddled in transit. This is accomplished by optionally adding a special SIG resource record at the end of the reply which digitally signs the concatenation of the server's response and the resolver's query.
Requests can also be authenticated by including a special SIG RR at the end of the request. Authenticating requests serves no function in the current DNS and requests with a non-empty additional information section are ignored by almost all current DNS servers. However, this syntax for signing requests is defined in connection with authenticating future secure dynamic update requests or the like.
The private keys used in transaction and request security belongs to the host composing the request or reply message, not to the zone involved. The corresponding public key is normally stored in and retrieved from the DNS.
Because requests and replies are highly variable, message authentication SIGs can not be pre-calculated. Thus it will be necessary to keep the private key on-line, for example in software or in a directly connected piece of hardware.