/// Constructs an instance out of the authentication prohibited, confidentiality prohibited, experimental, user associated, IPSec, email, name type,
/// signatory, protocol, algorithm, flags extension and public key fields.
/// </summary>
/// <param name="authenticationProhibited">Use of the key is prohibited for authentication.</param>
/// <param name="confidentialityProhibited">Use of the key is prohibited for confidentiality.</param>
/// <param name="experimental">
/// 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.
/// </param>
/// <param name="userAssociated">
/// 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.
/// </param>
/// <param name="ipSec">
/// 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.
/// </param>
/// <param name="email">
/// Indicates 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.
/// </param>
/// <param name="nameType">The name type.</param>
/// <param name="signatory">
/// 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.
/// </param>
/// <param name="protocol">
/// 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.
/// </param>
/// <param name="algorithm">The key algorithm parallel to the same field for the SIG resource.</param>
/// <param name="flagsExtension">
/// 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.
/// </param>
/// <param name="publicKey">The public key value.</param>
/// It is anticipated that keys stored in DNS will be used in conjunction with a variety of Internet protocols.
/// 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.
/// 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.
/// An unsigned count of how many labels there are in the original SIG RR owner name not counting the null label for root and not counting any initial "*" for a wildcard.
/// If a secured retrieval is the result of wild card substitution, it is necessary for the resolver to use the original form of the name in verifying the digital signature.
/// This field makes it easy to determine the original form.
///
/// If, on retrieval, the RR appears to have a longer name than indicated by "labels", the resolver can tell it is the result of wildcard substitution.
/// If the RR owner name appears to be shorter than the labels count, the SIG RR must be considered corrupt and ignored.
/// The maximum number of labels allowed in the current DNS is 127 but the entire octet is reserved and would be required should DNS names ever be expanded to 255 labels.
/// </param>
/// <param name="originalTtl">
/// The "original TTL" field is included in the RDATA portion to avoid
/// (1) authentication problems that caching servers would otherwise cause by decrementing the real TTL field and
/// (2) security problems that unscrupulous servers could otherwise cause by manipulating the real TTL field.
/// This original TTL is protected by the signature while the current TTL field is not.
///
/// NOTE: The "original TTL" must be restored into the covered RRs when the signature is verified.
/// This generaly implies that all RRs for a particular type, name, and class, that is, all the RRs in any particular RRset, must have the same TTL to start with.
/// </param>
/// <param name="signatureExpiration">
/// The last time the signature is valid.
/// Numbers of seconds since the start of 1 January 1970, GMT, ignoring leap seconds.
/// Ring arithmetic is used.
/// This time can never be more than about 68 years after the inception.
/// </param>
/// <param name="signatureInception">
/// The first time the signature is valid.
/// Numbers of seconds since the start of 1 January 1970, GMT, ignoring leap seconds.
/// Ring arithmetic is used.
/// This time can never be more than about 68 years before the expiration.
/// </param>
/// <param name="keyTag">
/// Used to efficiently select between multiple keys which may be applicable and thus check that a public key about to be used
/// for the computationally expensive effort to check the signature is possibly valid.
/// For algorithm 1 (MD5/RSA) as defined in RFC 2537,
/// it is the next to the bottom two octets of the public key modulus needed to decode the signature field.
/// That is to say, the most significant 16 of the least significant 24 bits of the modulus in network (big endian) order.
/// For all other algorithms, including private algorithms, it is calculated as a simple checksum of the KEY RR.
/// </param>
/// <param name="signersName">
/// The domain name of the signer generating the SIG RR.
/// This is the owner name of the public KEY RR that can be used to verify the signature.
/// It is frequently the zone which contained the RRset being authenticated.
/// Which signers should be authorized to sign what is a significant resolver policy question.
/// The signer's name may be compressed with standard DNS name compression when being transmitted over the network.
/// </param>
/// <param name="signature">
/// The actual signature portion of the SIG RR binds the other RDATA fields to the RRset of the "type covered" RRs with that owner name and class.
/// This covered RRset is thereby authenticated.
/// To accomplish this, a data sequence is constructed as follows:
///
/// data = RDATA | RR(s)...
///
/// where "|" is concatenation,
///
/// RDATA is the wire format of all the RDATA fields in the SIG RR itself (including the canonical form of the signer's name) before but not including the signature,
/// and RR(s) is the RRset of the RR(s) of the type covered with the same owner name and class as the SIG RR in canonical form and order.
///
/// How this data sequence is processed into the signature is algorithm dependent.
/// Used to efficiently select between multiple keys which may be applicable and thus check that a public key about to be used for the computationally expensive effort to check the signature is possibly valid.
/// Used to efficiently select between multiple keys which may be applicable and thus check that a public key about to be used
/// For algorithm 1 (MD5/RSA) as defined in RFC 2537, it is the next to the bottom two octets of the public key modulus needed to decode the signature field.
/// for the computationally expensive effort to check the signature is possibly valid.
/// For algorithm 1 (MD5/RSA) as defined in RFC 2537,
/// it is the next to the bottom two octets of the public key modulus needed to decode the signature field.
/// That is to say, the most significant 16 of the least significant 24 bits of the modulus in network (big endian) order.
/// That is to say, the most significant 16 of the least significant 24 bits of the modulus in network (big endian) order.
/// For all other algorithms, including private algorithms, it is calculated as a simple checksum of the KEY RR.
/// For all other algorithms, including private algorithms, it is calculated as a simple checksum of the KEY RR.
/// Two DnsResourceDataSignature are equal iff their type covered, algorithm, labels, original TTL, signature expiration, signature inception, key tag,
/// Two DnsResourceDataSignature are equal iff their type covered, algorithm, labels, original TTL, signature expiration, signature inception, key tag,
/// When the TKEY Error Field is non-zero in a response to a TKEY query, the DNS header RCODE field indicates no error.
/// When the TKEY Error Field is non-zero in a response to a TKEY query, the DNS header RCODE field indicates no error.
/// However, it is possible if a TKEY is spontaneously included in a response the TKEY RR and DNS header error field could have unrelated non-zero error codes.
/// However, it is possible if a TKEY is spontaneously included in a response the TKEY RR and DNS header error field