/// 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.example could have a public key associated through a KEY RR with name j_random_user.host.subdomain.example.
/// It could be used in a 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.
/// </summary>
UserOrAccountAtEndEntity=0,
/// <summary>
/// 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 the primary DNS security feature of data origin authentication.
/// Zone KEY RRs occur only at delegation points.
/// </summary>
ZoneKey=1,
/// <summary>
/// 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] or numeric IP address.
/// This is the public key used in connection with DNS request and transaction authentication services.
/// It could also be used in an IP-security protocol where authentication at the host, rather than user, level was desired, such as routing, NTP, etc.
/// </summary>
NonZoneEntity=2,
}
/// <summary>
/// RFC 2137.
/// </summary>
[Flags]
publicenumDnsKeySignatory:byte
{
/// <summary>
/// The general update signatory field bit has no special meaning.
/// If the other three bits are all zero, it must be one so that the field is non-zero to designate that the key is an update key.
/// The meaning of all values of the signatory field with the general bit and one or more other signatory field bits on is reserved.
/// </summary>
General=1,
/// <summary>
/// If non-zero, this key is authorized to add and update RRs for only a single owner name.
/// If there already exist RRs with one or more names signed by this key, they may be updated but no new name created until the number of existing names is reduced to zero.
/// This bit is meaningful only for mode A dynamic zones and is ignored in mode B dynamic zones.
/// This bit is meaningful only if the owner name is a wildcard.
/// (Any dynamic update KEY with a non-wildcard name is, in effect, a unique name update key.)
/// </summary>
Unique=2,
/// <summary>
/// If non-zero, this key is authorized to add and delete RRs even if there are other RRs with the same owner name and class that are authenticated by a SIG signed with a different dynamic update KEY.
/// If zero, the key can only authorize updates where any existing RRs of the same owner and class are authenticated by a SIG using the same key.
/// This bit is meaningful only for type A dynamic zones and is ignored in type B dynamic zones.
///
/// Keeping this bit zero on multiple KEY RRs with the same or nested wild card owner names permits multiple entities to exist that can create and delete names but can not effect RRs with different owner names from any they created.
/// In effect, this creates two levels of dynamic update key, strong and weak, where weak keys are limited in interfering with each other but a strong key can interfere with any weak keys or other strong keys.
/// </summary>
Strong=4,
/// <summary>
/// If nonzero, this key is authorized to attach, detach, and move zones by creating and deleting NS, glue A, and zone KEY RR(s).
/// If zero, the key can not authorize any update that would effect such RRs.
/// This bit is meaningful for both type A and type B dynamic secure zones.
/// NOTE: do not confuse the "zone" signatory field bit with the "zone" key type bit.
/// </summary>
Zone=8,
}
/// <summary>
/// RFC 2535.
/// </summary>
publicenumDnsKeyProtocol:byte
{
/// <summary>
/// Connection with TLS.
/// </summary>
Tls=1,
/// <summary>
/// Connection with email.
/// </summary>
Email=2,
/// <summary>
/// DNS security.
/// The protocol field should be set to this value for zone keys and other keys used in DNS security.
/// Implementations that can determine that a key is a DNS security key by the fact that flags label it a zone key or the signatory flag field is non-zero are not required to check the protocol field.
/// </summary>
DnsSec=3,
/// <summary>
/// Oakley/IPSEC [RFC 2401] protocol.
/// 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 flag bits are set.
/// The presence of a KEY resource with this protocol value is an assertion that the host speaks Oakley/IPSEC.
/// </summary>
IpSec=4,
/// <summary>
/// The key can be used in connection with any protocol for which KEY RR protocol octet values have been defined.
/// The use of this value is discouraged and the use of different keys for different protocols is encouraged.
/// If non-zero, indicates that the key can validly sign things as specified in DNS dynamic update.
/// Note that zone keys always have authority to sign any RRs in the zone regardless of the value of the signatory field.
/// </summary>
publicDnsKeySignatorySignatory{get;privateset;}
/// <summary>
/// It is anticipated that keys stored in DNS will be used in conjunction with a variety of Internet protocols.
/// It is intended that the protocol octet and possibly some of the currently unused (must be zero) bits in the KEY RR flags as specified in the future will be used to indicate a key's validity for different protocols.
/// </summary>
publicDnsKeyProtocolProtocol{get;privateset;}
/// <summary>
/// The key algorithm parallel to the same field for the SIG resource.
/// </summary>
publicDnsAlgorithmAlgorithm{get;privateset;}
/// <summary>
/// Optional second 16 bit flag field after the algorithm octet and before the key data.
/// Must not be non-null unless one or more such additional bits have been defined and are non-zero.