In the "flags" field:
Bit 2 is the "experimental" bit. It is ignored if the type field indicates "no key" and the following description assumes that type field to be non-zero. Keys may be associated with zones, entities, or users for experimental, trial, or optional use, in which case this bit will be one. If this bit is a zero, it means that the use or availability of security based on the key is "mandatory". Thus, if this bit is off for a zone key, the zone should be assumed secured by SIG RRs and any responses indicating the zone is not secured should be considered bogus. If this bit is a one for a host or end entity, it might sometimes operate in a secure mode and at other times operate without security. The experimental bit, like all other aspects of the KEY RR, is only effective if the KEY RR is appropriately signed by a SIG RR. The experimental bit must be zero for safe secure operation and should only be a one for a minimal transition period.
Bits 3-4 are reserved and must be zero.
Bit 5 on indicates that this is a key associated with a "user" or "account" at an end entity, usually a host. The coding of the owner name is that used for the responsible individual mailbox in the SOA and RP RRs: The owner name is the user name as the name of a node under the entity name. For example, "j.random_user" on host.subdomain.domain could have a public key associated through a KEY RR with name j\.random_user.host.subdomain.domain and the user bit a one. It could be used in an security protocol where authentication of a user was desired. This key might be useful in IP or other security for a user level service such a telnet, ftp, rlogin, etc.
Bit 6 on indicates that this is a key associated with the non- zone "entity" whose name is the RR owner name. This will commonly be a host but could, in some parts of the DNS tree, be some other type of entity such as a telephone number [RFC 1530]. This is the public key used in connection with the optional DNS transaction authentication service if the owner name is a DNS server host. It could also be used in an IP-security protocol where authentication of at the host, rather than user, level was desired, such as routing, NTP, etc.
Bit 7 is the "zone" bit and indicates that this is a zone key for the zone whose name is the KEY RR owner name. This is the public key used for DNS data origin authentication.
Bit 8 is reserved to be the IPSEC [RFC 1825] bit and indicates that this key is valid for use in conjunction with that security standard. This key could be used in connection with secured communication on behalf of an end entity or user whose name is the owner name of the KEY RR if the entity or user bits are on. The presence of a KEY resource with the IPSEC and entity bits on and experimental and no-key bits off is an assertion that the host speaks IPSEC.
Bit 9 is reserved to be the "email" bit and indicate that this key is valid for use in conjunction with MIME security multiparts. This key could be used in connection with secured communication on behalf of an end entity or user whose name is the owner name of the KEY RR if the entity or user bits are on.
Bits 10-11 are reserved and must be zero.
Bits 12-15 are the "signatory" field. If non-zero, they indicate that the key can validly sign RRs or updates of the same name. If the owner name is a wildcard, then RRs or updates with any name which is in the wildcard's scope can be signed. Fifteen different non-zero values are possible for this field and any differences in their meaning are reserved for definition in connection with DNS dynamic update or other new DNS commands. Zone keys always have authority to sign any RRs in the zone regardless of the value of this field. The signatory field, like all other aspects of the KEY RR, is only effective if the KEY RR is appropriately signed by a SIG RR.