thrownewArgumentOutOfRangeException("addressFamilyDependentPart",addressFamilyDependentPart,"Cannot be longer than "+AddressFamilyDependentPartMaxLength);
/// Indicates an X.509 certificate conforming to the profile defined by the IETF PKIX working group.
/// The certificate section will start with a one-octet unsigned OID length and then an X.500 OID indicating the nature of the remainder of the certificate section.
/// Note: X.509 certificates do not include their X.500 directory-type-designating OID as a prefix.
/// </summary>
Pkix=1,
/// <summary>
/// RFC 4398.
/// SPKI certificate.
/// </summary>
Spki=2,
/// <summary>
/// RFC 4398.
/// Indicates an OpenPGP packet.
/// This is used to transfer public key material and revocation signatures.
/// The data is binary and must not be encoded into an ASCII armor.
/// An implementation should process transferable public keys, but it may handle additional OpenPGP packets.
/// </summary>
Pgp=3,
/// <summary>
/// RFC 4398.
/// The URL of an X.509 data object.
/// Must be used when the content is too large to fit in the CERT RR and may be used at the implementer's discretion.
/// Should not be used where the DNS message is 512 octets or smaller and could thus be expected to fit a UDP packet.
/// </summary>
IPkix=4,
/// <summary>
/// RFC 4398.
/// The URL of an SPKI certificate.
/// Must be used when the content is too large to fit in the CERT RR and may be used at the implementer's discretion.
/// Should not be used where the DNS message is 512 octets or smaller and could thus be expected to fit a UDP packet.
/// </summary>
ISpki=5,
/// <summary>
/// RFC 4398.
/// Contains both an OpenPGP fingerprint for the key in question, as well as a URL.
/// The certificate portion of the IPgp CERT RR is defined as a one-octet fingerprint length, followed by the OpenPGP fingerprint, followed by the URL.
/// The OpenPGP fingerprint is calculated as defined in RFC 2440.
/// A zero-length fingerprint or a zero-length URL are legal, and indicate URL-only IPGP data or fingerprint-only IPGP data, respectively.
/// A zero-length fingerprint and a zero-length URL are meaningless and invalid.
/// Must be used when the content is too large to fit in the CERT RR and may be used at the implementer's discretion.
/// Should not be used where the DNS message is 512 octets or smaller and could thus be expected to fit a UDP packet.
/// </summary>
Ipgp=6,
/// <summary>
/// RFC 4398.
/// Attribute Certificate.
/// </summary>
AcPkix=7,
/// <summary>
/// RFC 4398.
/// The URL of an Attribute Certificate.
/// Must be used when the content is too large to fit in the CERT RR and may be used at the implementer's discretion.
/// Should not be used where the DNS message is 512 octets or smaller and could thus be expected to fit a UDP packet.
/// </summary>
IAcPkix=8,
/// <summary>
/// RFC 4398.
/// Indicates a certificate format defined by an absolute URI.
/// The certificate portion of the CERT RR must begin with a null-terminated URI, and the data after the null is the private format certificate itself.
/// The URI should be such that a retrieval from it will lead to documentation on the format of the certificate.
/// Recognition of private certificate types need not be based on URI equality but can use various forms of pattern matching so that, for example, subtype or version information can also be encoded into the URI.
/// </summary>
Uri=253,
/// <summary>
/// RFC 4398.
/// Indicates a private format certificate specified by an ISO OID prefix.
/// The certificate section will start with a one-octet unsigned OID length and then a BER-encoded OID indicating the nature of the remainder of the certificate section.
/// This can be an X.509 certificate format or some other format.
/// X.509 certificates that conform to the IETF PKIX profile should be indicated by the PKIX type, not the OID private type.
/// Recognition of private certificate types need not be based on OID equality but can use various forms of pattern matching such as OID prefix.
/// If set, the critical flag is asserted and the property must be understood if the CAA record is to be correctly processed by a certificate issuer.
/// A Certification Authority must not issue certificates for any Domain that contains a CAA critical property for an unknown or unsupported property type that has the issuer flag set.
/// 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.
/// 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.
/// 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.
/// The server cannot grant the LLQ request because it is overloaded,
/// or the request exceeds the server's rate limit (see Section 8 "Security Considerations").
/// Upon returning this error, the server MUST include in the LEASE-LIFE field a time interval, in seconds,
/// after which the client may re-try the LLQ Setup.
/// </summary>
ServerFull=1,
/// <summary>
/// The data for this name and type is not expected to change frequently, and the server therefore does not support the requested LLQ.
/// The client must not poll for this name and type, nor should it re-try the LLQ Setup, and should instead honor the normal resource record TTLs returned.
/// To reduce server load, an administrator MAY return this error for all records with types other than PTR and TXT as a matter of course.
/// </summary>
Static=2,
/// <summary>
/// The LLQ was improperly formatted.
/// Note that if the rest of the DNS message is properly formatted, the DNS header error code must not include a format error code,
/// as this would cause confusion between a server that does not understand the LLQ format, and a client that sends malformed LLQs.
/// </summary>
FormatError=3,
/// <summary>
/// The client attempts to refresh an expired or non-existent LLQ (as determined by the LLQ-ID in the request).
/// </summary>
NoSuchLlq=4,
/// <summary>
/// The protocol version specified in the client's request is not supported by the server.
/// </summary>
BadVersion=5,
/// <summary>
/// The LLQ was not granted for an unknown reason.
/// Encoded as an eight-bit unsigned integer with value between 0 and 128 inclusive.
/// </summary>
publicbytePrefixLength{get;privateset;}
/// <summary>
/// An IPv6 address suffix, encoded in network order (high-order octet first).
/// There must be exactly enough octets in this field to contain a number of bits equal to 128 minus prefix length, with 0 to 7 leading pad bits to make this field an integral number of octets.
/// Pad bits, if present, must be set to zero when loading a zone file and ignored (other than for SIG verification) on reception.
/// Variable length string of octets containing the ATM address of the node to which this RR pertains.
/// When the format is AESA, the address is coded as described in ISO 8348/AD 2 using the preferred binary encoding of the ISO NSAP format.
/// When the format value is E.164, the Address/Number Digits appear in the order in which they would be entered on a numeric keypad.
/// Digits are coded in IA5 characters with the leftmost bit of each digit set to 0.
/// This ATM address appears in ATM End System Address Octets field (AESA format) or the Address/Number Digits field (E.164 format) of the Called party number information element [ATMUNI3.1].
/// Subaddress information is intentionally not included because E.164 subaddress information is used for routing.
/// Contains the algorithm-specific portion of the KEY RR RDATA.
/// </summary>
publicDataSegmentPublicKey{get;privateset;}
/// <summary>
/// Indicates one or more domain names of rendezvous server(s).
/// Must not be compressed.
/// The rendezvous server(s) are listed in order of preference (i.e., first rendezvous server(s) are preferred),
/// defining an implicit order amongst rendezvous servers of a single RR.
/// When multiple HIP RRs are present at the same owner name,
/// this implicit order of rendezvous servers within an RR must not be used to infer a preference order between rendezvous servers stored in different RRs.
/// 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.
/// </summary>
publicboolExperimental{get;privateset;}
/// <summary>
/// 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.
/// </summary>
publicboolUserAssociated{get;privateset;}
/// <summary>
/// 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.
/// </summary>
publicboolIpSec{get;privateset;}
/// <summary>
/// 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.
/// </summary>
publicboolEmail{get;privateset;}
/// <summary>
/// The name type.
/// </summary>
publicDnsKeyNameTypeNameType{get;privateset;}
/// <summary>
/// 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.
thrownewArgumentOutOfRangeException("size",size,"Must be in the form <digit> * 10^<digit>.");
if(!IsValidSize(horizontalPrecision))
thrownewArgumentOutOfRangeException("horizontalPrecision",horizontalPrecision,"Must be in the form <digit> * 10^<digit>.");
if(!IsValidSize(verticalPrecision))
thrownewArgumentOutOfRangeException("verticalPrecision",verticalPrecision,"Must be in the form <digit> * 10^<digit>.");
Version=version;
Size=size;
HorizontalPrecision=horizontalPrecision;
VerticalPrecision=verticalPrecision;
Latitude=latitude;
Longitude=longitude;
Altitude=altitude;
}
/// <summary>
/// Version number of the representation.
/// This must be zero.
/// Implementations are required to check this field and make no assumptions about the format of unrecognized versions.
/// </summary>
publicbyteVersion{get;privateset;}
/// <summary>
/// The diameter of a sphere enclosing the described entity, in centimeters.
/// Only numbers of the form decimal digit times 10 in the power of a decimal digit are allowed since it is expressed as a pair of four-bit unsigned integers,
/// each ranging from zero to nine, with the most significant four bits representing the base and the second number representing the power of ten by which to multiply the base.
/// This allows sizes from 0e0 (<1cm) to 9e9(90,000km) to be expressed.
/// This representation was chosen such that the hexadecimal representation can be read by eye; 0x15 = 1e5.
/// Four-bit values greater than 9 are undefined, as are values with a base of zero and a non-zero exponent.
///
/// Since 20000000m (represented by the value 0x29) is greater than the equatorial diameter of the WGS 84 ellipsoid (12756274m),
/// it is therefore suitable for use as a "worldwide" size.
/// </summary>
publiculongSize{get;privateset;}
/// <summary>
/// The horizontal precision of the data, in centimeters, expressed using the same representation as Size.
/// This is the diameter of the horizontal "circle of error", rather than a "plus or minus" value.
/// (This was chosen to match the interpretation of Size; to get a "plus or minus" value, divide by 2.)
/// </summary>
publiculongHorizontalPrecision{get;privateset;}
/// <summary>
/// The vertical precision of the data, in centimeters, expressed using the sane representation as for Size.
/// This is the total potential vertical error, rather than a "plus or minus" value.
/// (This was chosen to match the interpretation of SIize; to get a "plus or minus" value, divide by 2.)
/// Note that if altitude above or below sea level is used as an approximation for altitude relative to the ellipsoid, the precision value should be adjusted.
/// </summary>
publiculongVerticalPrecision{get;privateset;}
/// <summary>
/// The latitude of the center of the sphere described by the Size field, expressed as a 32-bit integer,
/// most significant octet first (network standard byte order), in thousandths of a second of arc.
/// 2^31 represents the equator; numbers above that are north latitude.
/// </summary>
publicuintLatitude{get;privateset;}
/// <summary>
/// The longitude of the center of the sphere described by the Size field, expressed as a 32-bit integer,
/// most significant octet first (network standard byte order), in thousandths of a second of arc, rounded away from the prime meridian.
/// 2^31 represents the prime meridian; numbers above that are east longitude.
/// </summary>
publicuintLongitude{get;privateset;}
/// <summary>
/// The altitude of the center of the sphere described by the Size field, expressed as a 32-bit integer,
/// most significant octet first (network standard byte order), in centimeters,
/// from a base of 100,000m below the reference spheroid used by GPS (semimajor axis a=6378137.0, reciprocal flattening rf=298.257223563).
/// Altitude above (or below) sea level may be used as an approximation of altitude relative to the the spheroid,
/// though due to the Earth's surface not being a perfect spheroid, there will be differences.
/// (For example, the geoid (which sea level approximates) for the continental US ranges from 10 meters to 50 meters below the spheroid.
/// Adjustments to Altitude and/or VerticalPrecision will be necessary in most cases.
/// The Defense Mapping Agency publishes geoid height values relative to the ellipsoid.
/// A 16-bit unsigned integer specifying the order in which the NAPTR records MUST be processed in order to accurately represent the ordered list of Rules.
/// The ordering is from lowest to highest.
/// If two records have the same order value then they are considered to be the same rule and should be selected based on the combination of the Preference values and Services offered.
/// </summary>
publicushortOrder{get;privateset;}
/// <summary>
/// Although it is called "preference" in deference to DNS terminology, this field is equivalent to the Priority value in the DDDS Algorithm.
/// It specifies the order in which NAPTR records with equal Order values should be processed, low numbers being processed before high numbers.
/// This is similar to the preference field in an MX record, and is used so domain administrators can direct clients towards more capable hosts or lighter weight protocols.
/// A client may look at records with higher preference values if it has a good reason to do so such as not supporting some protocol or service very well.
/// The important difference between Order and Preference is that once a match is found the client must not consider records with a different Order but they may process records with the same Order but different Preferences.
/// The only exception to this is noted in the second important Note in the DDDS algorithm specification concerning allowing clients to use more complex Service determination between steps 3 and 4 in the algorithm.
/// Preference is used to give communicate a higher quality of service to rules that are considered the same from an authority standpoint but not from a simple load balancing standpoint.
///
/// It is important to note that DNS contains several load balancing mechanisms and if load balancing among otherwise equal services should be needed then methods such as SRV records or multiple A records should be utilized to accomplish load balancing.
/// </summary>
publicushortPreference{get;privateset;}
/// <summary>
/// Flags to control aspects of the rewriting and interpretation of the fields in the record.
/// Flags are single characters from the set A-Z and 0-9.
/// The case of the alphabetic characters is not significant.
/// The field can be empty.
///
/// It is up to the Application specifying how it is using this Database to define the Flags in this field.
/// It must define which ones are terminal and which ones are not.
/// </summary>
publicDataSegmentFlags{get;privateset;}
/// <summary>
/// Specifies the Service Parameters applicable to this this delegation path.
/// It is up to the Application Specification to specify the values found in this field.
/// </summary>
publicDataSegmentServices{get;privateset;}
/// <summary>
/// A substitution expression that is applied to the original string held by the client in order to construct the next domain name to lookup.
/// See the DDDS Algorithm specification for the syntax of this field.
///
/// As stated in the DDDS algorithm, The regular expressions must not be used in a cumulative fashion, that is, they should only be applied to the original string held by the client, never to the domain name produced by a previous NAPTR rewrite.
/// The latter is tempting in some applications but experience has shown such use to be extremely fault sensitive, very error prone, and extremely difficult to debug.
/// </summary>
publicDataSegmentRegexp{get;privateset;}
/// <summary>
/// The next domain-name to query for depending on the potential values found in the flags field.
/// This field is used when the regular expression is a simple replacement operation.
/// Any value in this field must be a fully qualified domain-name.
/// Name compression is not to be used for this field.
///
/// This field and the Regexp field together make up the Substitution Expression in the DDDS Algorithm.
/// It is simply a historical optimization specifically for DNS compression that this field exists.
/// The fields are also mutually exclusive.
/// If a record is returned that has values for both fields then it is considered to be in error and SHOULD be either ignored or an error returned.
/// One bit per RR type present for the owner name.
/// A one bit indicates that at least one RR of that type is present for the owner name.
/// A zero indicates that no such RR is present.
/// All bits not specified because they are beyond the end of the bit map are assumed to be zero.
/// Note that bit 30, for NXT, will always be on so the minimum bit map length is actually four octets.
/// Trailing zero octets are prohibited in this format.
/// The first bit represents RR type zero (an illegal type which can not be present) and so will be zero in this format.
/// This format is not used if there exists an RR with a type number greater than 127.
/// If the zero bit of the type bit map is a one, it indicates that a different format is being used which will always be the case if a type number greater than 127 is present.
/// Contains the next hashed owner name in hash order.
/// This value is in binary format.
/// Given the ordered set of all hashed owner names, the Next Hashed Owner Name field contains the hash of an owner name that immediately follows the owner name of the given NSEC3 RR.
/// The value of the Next Hashed Owner Name field in the last NSEC3 RR in the zone is the same as the hashed owner name of the first NSEC3 RR in the zone in hash order.
/// Note that, unlike the owner name of the NSEC3 RR, the value of this field does not contain the appended zone name.
/// Defines the number of additional times the hash function has been performed.
/// More iterations result in greater resiliency of the hash value against dictionary attacks, but at a higher computational cost for both the server and resolver.
/// </summary>
publicushortIterations{get;privateset;}
/// <summary>
/// Appended to the original owner name before hashing in order to defend against pre-calculated dictionary attacks.
/// A client must attempt to contact the target host with the lowest-numbered priority it can reach;
/// target hosts with the same priority should be tried in an order defined by the weight field.
/// </summary>
publicushortPriority{get;privateset;}
/// <summary>
/// A server selection mechanism.
/// The weight field specifies a relative weight for entries with the same priority.
/// Larger weights should be given a proportionately higher probability of being selected.
/// Domain administrators should use Weight 0 when there isn't any server selection to do, to make the RR easier to read for humans (less noisy).
/// In the presence of records containing weights greater than 0, records with weight 0 should have a very small chance of being selected.
///
/// In the absence of a protocol whose specification calls for the use of other weighting information, a client arranges the SRV RRs of the same Priority in the order in which target hosts,
/// specified by the SRV RRs, will be contacted.
/// The following algorithm SHOULD be used to order the SRV RRs of the same priority:
/// To select a target to be contacted next, arrange all SRV RRs (that have not been ordered yet) in any order, except that all those with weight 0 are placed at the beginning of the list.
/// Compute the sum of the weights of those RRs, and with each RR associate the running sum in the selected order.
/// Then choose a uniform random number between 0 and the sum computed (inclusive), and select the RR whose running sum value is the first in the selected order which is greater than or equal to the random number selected.
/// The target host specified in the selected SRV RR is the next one to be contacted by the client.
/// Remove this SRV RR from the set of the unordered SRV RRs and apply the described algorithm to the unordered SRV RRs to select the next target host.
/// Continue the ordering process until there are no unordered SRV RRs.
/// This process is repeated for each Priority.
/// </summary>
publicushortWeight{get;privateset;}
/// <summary>
/// The port on this target host of this service.
/// This is often as specified in Assigned Numbers but need not be.
/// </summary>
publicushortPort{get;privateset;}
/// <summary>
/// The domain name of the target host.
/// There must be one or more address records for this name, the name must not be an alias (in the sense of RFC 1034 or RFC 2181).
/// Implementors are urged, but not required, to return the address record(s) in the Additional Data section.
/// Unless and until permitted by future standards action, name compression is not to be used for this field.
///
/// A Target of "." means that the service is decidedly not available at this domain.
/// The type of the other RRs covered by this SIG.
/// </summary>
publicDnsTypeTypeCovered{get;privateset;}
/// <summary>
/// The key algorithm.
/// </summary>
publicDnsAlgorithmAlgorithm{get;privateset;}
/// <summary>
/// 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.
/// </summary>
publicbyteLabels{get;privateset;}
/// <summary>
/// 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.
/// </summary>
publicuintOriginalTtl{get;privateset;}
/// <summary>
/// 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.
/// 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.
/// </summary>
publicushortKeyTag{get;privateset;}
/// <summary>
/// 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.
/// </summary>
publicDnsDomainNameSignersName{get;privateset;}
/// <summary>
/// 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.
thrownewArgumentOutOfRangeException("key",key.Length,string.Format("Cannot be longer than {0}",ushort.MaxValue));
if(other.Length>ushort.MaxValue)
thrownewArgumentOutOfRangeException("other",other.Length,string.Format("Cannot be longer than {0}",ushort.MaxValue));
Algorithm=algorithm;
Inception=inception;
Expiration=expiration;
Mode=mode;
Error=error;
Key=key;
Other=other;
}
/// <summary>
/// Name of the algorithm in domain name syntax.
/// The algorithm determines how the secret keying material agreed to using the TKEY RR is actually used to derive the algorithm specific key.
/// </summary>
publicDnsDomainNameAlgorithm{get;privateset;}
/// <summary>
/// Number of seconds since the beginning of 1 January 1970 GMT ignoring leap seconds treated as modulo 2**32 using ring arithmetic.
/// In messages between a DNS resolver and a DNS server where this field is meaningful,
/// it is either the requested validity interval start for the keying material asked for or
/// specify the validity interval start of keying material provided.
///
/// To avoid different interpretations of the inception time in TKEY RRs,
/// resolvers and servers exchanging them must have the same idea of what time it is.
/// One way of doing this is with the NTP protocol [RFC 2030] but that or any other time synchronization used for this purpose must be done securely.
/// </summary>
publicSerialNumber32Inception{get;privateset;}
/// <summary>
/// Number of seconds since the beginning of 1 January 1970 GMT ignoring leap seconds treated as modulo 2**32 using ring arithmetic.
/// In messages between a DNS resolver and a DNS server where this field is meaningful,
/// it is either the requested validity interval end for the keying material asked for or
/// specify the validity interval end of keying material provided.
///
/// To avoid different interpretations of the expiration time in TKEY RRs,
/// resolvers and servers exchanging them must have the same idea of what time it is.
/// One way of doing this is with the NTP protocol [RFC 2030] but that or any other time synchronization used for this purpose must be done securely.
/// </summary>
publicSerialNumber32Expiration{get;privateset;}
/// <summary>
/// Specifies the general scheme for key agreement or the purpose of the TKEY DNS message.
/// Servers and resolvers supporting this specification must implement the Diffie-Hellman key agreement mode and the key deletion mode for queries.
/// All other modes are optional.
/// A server supporting TKEY that receives a TKEY request with a mode it does not support returns the BADMODE error.
/// </summary>
publicDnsTransactionKeyModeMode{get;privateset;}
/// <summary>
/// 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.
thrownewArgumentOutOfRangeException("messageAuthenticationCode",messageAuthenticationCode.Length,string.Format("Cannot be longer than {0}",ushort.MaxValue));
if(other.Length>ushort.MaxValue)
thrownewArgumentOutOfRangeException("other",other.Length,string.Format("Cannot be longer than {0}",ushort.MaxValue));
/// This coding value will not be assigned to a standard abstract syntax notation.
/// An OSI Object Identifier (OID) preceded by a one byte unsigned length appears at the beginning of the data area to indicate which private abstract syntax is being used.
/// </summary>
AsnPrivate=0x3F,
/// <summary>
/// DNS RRs.
/// The data portion consists of DNS resource records as they would be transmitted in a DNS response section.
/// The subcoding octet is the number of RRs in the data area as an unsigned integer.
/// Domain names may be compressed via pointers as in DNS replies.
/// The origin for the pointers is the beginning of the RDATA section of the SINK RR.
/// Thus the SINK RR is safe to cache since only code that knows how to parse the data portion need know of and can expand these compressions.
/// </summary>
DnsResourceRecords=0x40,
/// <summary>
/// MIME structured data [RFC 2045, 2046].
/// The data portion is a MIME structured message.
/// The "MIME-Version:" header line may be omitted unless the version is other than "1.0".
/// The top level Content-Transfer-Encoding may be encoded into the subcoding octet.
/// Note that, to some extent, the size limitations of DNS RRs may be overcome in the MIME case by using the "Content-Type: message/external-body" mechanism.
/// </summary>
Mime=0x41,
/// <summary>
/// Text tagged data.
/// The data potion consists of text formated as specified in the TXT RR except that the first and every subsequent odd numbered text item
/// is considered to be a tag labeling the immediately following text item.
/// If there are an odd number of text items overall, then the last is considered to label a null text item.
/// Syntax of the tags is as specified in RFC 1738 for the "Common Internet Scheme Syntax" without the two leading slashes ("//").
/// Thus any organization with a domain name can assign tags without fear of conflict.
/// </summary>
TextTaggedData=0x42,
/// <summary>
/// Private formats indicated by a URL.
/// The format of the data portion is indicated by an initial URL [RFC 1738] which is terminated by a zero valued octet
/// followed by the data with that format.
/// The subcoding octet is available for whatever use the private formating wishes to make of it.
/// The manner in which the URL specifies the format is not defined but presumably the retriever will recognize the URL or the data it points to.
/// An OID preceded by a one byte unsigned length appears at the beginning of the data area to indicate which private encoding.
/// </summary>
Asn1SnmpPrivate=0x01FE,
/// <summary>
/// OSI ASN.1 1990 [ASN.1].
/// Basic Encoding Rules.
/// </summary>
Asn1Osi1990Ber=0x0201,
/// <summary>
/// OSI ASN.1 1990 [ASN.1].
/// Distinguished Encoding Rules.
/// </summary>
Asn1Osi1990Der=0x0202,
/// <summary>
/// OSI ASN.1 1990 [ASN.1].
/// Packed Encoding Rules Aligned.
/// </summary>
Asn1Osi1990Per=0x0203,
/// <summary>
/// OSI ASN.1 1990 [ASN.1].
/// Packed Encoding Rules Unaligned.
/// </summary>
Asn1Osi1990PerUnaligned=0x0204,
/// <summary>
/// OSI ASN.1 1990 [ASN.1].
/// Canonical Encoding Rules.
/// </summary>
Asn1Osi1990Cer=0x0205,
/// <summary>
/// OSI ASN.1 1990 [ASN.1].
/// An OID preceded by a one byte unsigned length appears at the beginning of the data area to indicate which private encoding.
/// </summary>
Asn1Osi1990Private=0x02FE,
/// <summary>
/// OSI ASN.1 1994.
/// Basic Encoding Rules.
/// </summary>
Asn1Osi1994Ber=0x0301,
/// <summary>
/// OSI ASN.1 1994.
/// Distinguished Encoding Rules.
/// </summary>
Asn1Osi1994Der=0x0302,
/// <summary>
/// OSI ASN.1 1994.
/// Packed Encoding Rules Aligned.
/// </summary>
Asn1Osi1994Per=0x0303,
/// <summary>
/// OSI ASN.1 1994.
/// Packed Encoding Rules Unaligned.
/// </summary>
Asn1Osi1994PerUnaligned=0x0304,
/// <summary>
/// OSI ASN.1 1994.
/// Canonical Encoding Rules.
/// </summary>
Asn1Osi1994Cer=0x0305,
/// <summary>
/// OSI ASN.1 1994.
/// An OID preceded by a one byte unsigned length appears at the beginning of the data area to indicate which private encoding.
/// </summary>
Asn1Osi1994Private=0x03FE,
/// <summary>
/// Private abstract syntax notations.
/// This coding value will not be assigned to a standard abstract syntax notation.
/// An OSI Object Identifier (OID) preceded by a one byte unsigned length appears at the beginning of the data area to indicate which private abstract syntax is being used.
/// Basic Encoding Rules.
/// </summary>
AsnPrivateBer=0x3F01,
/// <summary>
/// Private abstract syntax notations.
/// This coding value will not be assigned to a standard abstract syntax notation.
/// An OSI Object Identifier (OID) preceded by a one byte unsigned length appears at the beginning of the data area to indicate which private abstract syntax is being used.
/// Distinguished Encoding Rules.
/// </summary>
AsnPrivateDer=0x3F02,
/// <summary>
/// Private abstract syntax notations.
/// This coding value will not be assigned to a standard abstract syntax notation.
/// An OSI Object Identifier (OID) preceded by a one byte unsigned length appears at the beginning of the data area to indicate which private abstract syntax is being used.
/// Packed Encoding Rules Aligned.
/// </summary>
AsnPrivatePer=0x3F03,
/// <summary>
/// Private abstract syntax notations.
/// This coding value will not be assigned to a standard abstract syntax notation.
/// An OSI Object Identifier (OID) preceded by a one byte unsigned length appears at the beginning of the data area to indicate which private abstract syntax is being used.
/// Packed Encoding Rules Unaligned.
/// </summary>
AsnPrivatePerUnaligned=0x3F04,
/// <summary>
/// Private abstract syntax notations.
/// This coding value will not be assigned to a standard abstract syntax notation.
/// An OSI Object Identifier (OID) preceded by a one byte unsigned length appears at the beginning of the data area to indicate which private abstract syntax is being used.
/// Canonical Encoding Rules.
/// </summary>
AsnPrivateCer=0x3F05,
/// <summary>
/// Private abstract syntax notations.
/// This coding value will not be assigned to a standard abstract syntax notation.
/// An OSI Object Identifier (OID) preceded by a one byte unsigned length appears at the beginning of the data area to indicate which private abstract syntax is being used.
/// An OID preceded by a one byte unsigned length appears in the data area just after the coding OID.
/// </summary>
AsnPrivatePrivate=0x3FFE,
/// <summary>
/// MIME structured data [RFC 2045, 2046].
/// The data portion is a MIME structured message.
/// The "MIME-Version:" header line may be omitted unless the version is other than "1.0".
/// Note that, to some extent, the size limitations of DNS RRs may be overcome in the MIME case by using the "Content-Type: message/external-body" mechanism.
/// 7 bit.
/// </summary>
Mime7Bit=0x4101,
/// <summary>
/// MIME structured data [RFC 2045, 2046].
/// The data portion is a MIME structured message.
/// The "MIME-Version:" header line may be omitted unless the version is other than "1.0".
/// Note that, to some extent, the size limitations of DNS RRs may be overcome in the MIME case by using the "Content-Type: message/external-body" mechanism.
/// 8 bit.
/// </summary>
Mime8Bit=0x4102,
/// <summary>
/// MIME structured data [RFC 2045, 2046].
/// The data portion is a MIME structured message.
/// The "MIME-Version:" header line may be omitted unless the version is other than "1.0".
/// Note that, to some extent, the size limitations of DNS RRs may be overcome in the MIME case by using the "Content-Type: message/external-body" mechanism.
/// Binary.
/// </summary>
MimeBinary=0x4103,
/// <summary>
/// MIME structured data [RFC 2045, 2046].
/// The data portion is a MIME structured message.
/// The "MIME-Version:" header line may be omitted unless the version is other than "1.0".
/// Note that, to some extent, the size limitations of DNS RRs may be overcome in the MIME case by using the "Content-Type: message/external-body" mechanism.
/// Quoted-printable.
/// </summary>
MimeQuotedPrintable=0x4104,
/// <summary>
/// MIME structured data [RFC 2045, 2046].
/// The data portion is a MIME structured message.
/// The "MIME-Version:" header line may be omitted unless the version is other than "1.0".
/// Note that, to some extent, the size limitations of DNS RRs may be overcome in the MIME case by using the "Content-Type: message/external-body" mechanism.
/// Base 64.
/// </summary>
MimeBase64=0x4105,
/// <summary>
/// MIME structured data [RFC 2045, 2046].
/// The data portion is a MIME structured message.
/// The "MIME-Version:" header line may be omitted unless the version is other than "1.0".
/// Note that, to some extent, the size limitations of DNS RRs may be overcome in the MIME case by using the "Content-Type: message/external-body" mechanism.
/// The data portion must start with an "x-" token denoting the private content-transfer-encoding immediately followed by one null (zero) octet
/// followed by the remainder of the MIME object.
/// </summary>
MimePrivate=0x41FE,
/// <summary>
/// Text tagged data.
/// The data potion consists of text formated as specified in the TXT RR except that the first and every subsequent odd numbered text item
/// is considered to be a tag labeling the immediately following text item.
/// If there are an odd number of text items overall, then the last is considered to label a null text item.
/// Syntax of the tags is as specified in RFC 1738 for the "Common Internet Scheme Syntax" without the two leading slashes ("//").
/// Thus any organization with a domain name can assign tags without fear of conflict.
/// ASCII.
/// </summary>
TextTaggedDataAscii=0x4201,
/// <summary>
/// Text tagged data.
/// The data potion consists of text formated as specified in the TXT RR except that the first and every subsequent odd numbered text item
/// is considered to be a tag labeling the immediately following text item.
/// If there are an odd number of text items overall, then the last is considered to label a null text item.
/// Syntax of the tags is as specified in RFC 1738 for the "Common Internet Scheme Syntax" without the two leading slashes ("//").
/// Thus any organization with a domain name can assign tags without fear of conflict.
/// UTF-7 [RFC 1642].
/// </summary>
TextTaggedDataUtf7=0x4202,
/// <summary>
/// Text tagged data.
/// The data potion consists of text formated as specified in the TXT RR except that the first and every subsequent odd numbered text item
/// is considered to be a tag labeling the immediately following text item.
/// If there are an odd number of text items overall, then the last is considered to label a null text item.
/// Syntax of the tags is as specified in RFC 1738 for the "Common Internet Scheme Syntax" without the two leading slashes ("//").
/// Thus any organization with a domain name can assign tags without fear of conflict.
/// UTF-8 [RFC 2044].
/// </summary>
TextTaggedDataUtf8=0x4203,
/// <summary>
/// Text tagged data.
/// The data potion consists of text formated as specified in the TXT RR except that the first and every subsequent odd numbered text item
/// is considered to be a tag labeling the immediately following text item.
/// If there are an odd number of text items overall, then the last is considered to label a null text item.
/// Syntax of the tags is as specified in RFC 1738 for the "Common Internet Scheme Syntax" without the two leading slashes ("//").
/// Thus any organization with a domain name can assign tags without fear of conflict.
/// ASCII with MIME header escapes [RFC 2047].
/// </summary>
TextTaggedDataAsciiMimeHeaderEscapes=0x4204,
/// <summary>
/// Text tagged data.
/// The data potion consists of text formated as specified in the TXT RR except that the first and every subsequent odd numbered text item
/// is considered to be a tag labeling the immediately following text item.
/// If there are an odd number of text items overall, then the last is considered to label a null text item.
/// Syntax of the tags is as specified in RFC 1738 for the "Common Internet Scheme Syntax" without the two leading slashes ("//").
/// Thus any organization with a domain name can assign tags without fear of conflict.
/// Each text item must start with a domain name [RFC 1034] denoting the private text encoding immediately followed by one null (zero) octet