README
¶
This is a goinstall-able mirror of modified code already published at: http://git.nic.cz/redmine/projects/godns/repository/show/rr Online godoc documentation for this package (should be) available at: http://gopkgdoc.appspot.com/pkg/github.com/cznic/dns/rr
Documentation
¶
Overview ¶
Package rr supports DNS resource records (RFC 1035 chapter 3.2).
Index ¶
- Constants
- Variables
- func TypesEncode(types []Type) (bits []byte)
- func TypesString(types []Type) string
- type A
- type AAAA
- type AFSDB
- type AlgorithmType
- type Bytes
- type CERT
- type CNAME
- type CertType
- type Class
- type DHCID
- type DLV
- type DNAME
- type DNSKEY
- type DS
- type EXT_RCODE
- type GPOS
- type GatewayType
- type HINFO
- type HIP
- type HashAlgorithm
- type IPSECKEY
- type IPSECKEYAlgorithm
- type IP_Port
- type IP_Protocol
- type ISDN
- type KEY
- type KX
- type LOC
- func (rd *LOC) DecAlt() (cm int64)
- func (rd *LOC) DecDMTS(x uint32) (deg, min, ts int, positive bool)
- func (*LOC) DecPrec(x byte) (cm int64)
- func (rd *LOC) Decode(b []byte, pos *int, sniffer dns.WireDecodeSniffer) (err error)
- func (*LOC) Degrees(x uint32) (deg int)
- func (rd *LOC) EncAlt(cm int64)
- func (*LOC) EncDMTS(deg, min, ts int, positive bool) uint32
- func (*LOC) EncPrec(cm uint64) byte
- func (rd *LOC) Encode(b *dns.Wirebuf)
- func (*LOC) Minutes(x uint32) (min int)
- func (rd *LOC) String() string
- func (*LOC) ThousandsSecs(x uint32) (ts int)
- type MB
- type MD
- type MF
- type MG
- type MINFO
- type MR
- type MX
- type NAPTR
- type NODATA
- type NS
- type NSAP
- type NSAP_PTR
- type NSEC
- type NSEC3
- type NSEC3PARAM
- type NULL
- type NXDOMAIN
- type OPT
- type OPT_DATA
- type PTR
- type PX
- type Parts
- type RDATA
- type RP
- type RR
- type RRSIG
- type RRs
- type RT
- type SIG
- type SOA
- type SPF
- type SRV
- type SSHFP
- type SSHFPAlgorithm
- type SSHFPType
- type TA
- type TALINK
- type TKEY
- type TKEYMode
- type TLSA
- type TLSAMatchingType
- type TLSASelector
- type TLSAUsage
- type TSIG
- type TSIGRCODE
- type TXT
- type Tree
- type Type
- type URI
- type WKS
- type X25
Constants ¶
const ( CertReserved0 CertType = iota CertPKIX CertSPKI CertPGP CertIPKIX CertIPGP CertACPKIX CertIACPKIX CertURI = iota + 244 CertOID CertReserved255 CertExperimental65280 = 65280 CertExperimental65534 = 65534 CertReserved = 65535 )
Values of CertifiacteType as defined in rfc4398.
2.1. Certificate Type Values
The following values are defined or reserved:
Value Mnemonic Certificate Type
----- -------- ----------------
0 Reserved
1 PKIX X.509 as per PKIX
2 SPKI SPKI certificate
3 PGP OpenPGP packet
4 IPKIX The URL of an X.509 data object
5 ISPKI The URL of an SPKI certificate
6 IPGP The fingerprint and URL of an OpenPGP packet
7 ACPKIX Attribute Certificate
8 IACPKIX The URL of an Attribute Certificate
9-252 Available for IANA assignment
253 URI URI private
254 OID OID private
255 Reserved
256-65279 Available for IANA assignment
65280-65534 Experimental
65535 Reserved
const (
TYPE_TLSA = 65468 // Experimental, DANE WG, see: http://tools.ietf.org/wg/dane/
)
Variables ¶
var IP_Ports = map[IP_Port]string{ DNS_Port: "DNS", SMTP_Port: "SMTP", }
Text values of IP_Port
var IP_Protocols = map[IP_Protocol]string{ TCP_Protocol: "TCP", UDP_Protocol: "UDP", }
Text values of IP_Protocol
var TKEYModes = map[TKEYMode]string{ TKEYModeReserved0: "Reserved0", TKEYModeServerAssignment: "ServerAssignment", TKEYModeDiffieHellmanExchange: "DiffieHellmanExchange", TKEYModeGSSAPINegotation: "GSSAPINegotation", TKEYModeResolverAssignment: "ResolverAssignment", TKEYModeKeyDeletion: "KeyDeletion", TKEYModeReserved65535: "Reserved65535", }
var TSIGRCODEs = map[TSIGRCODE]string{ 0: "RC_NO_ERROR RCODE", 1: "RC_FORMAT_ERROR", 2: "RC_SERVER_FAILURE", 3: "RC_NAME_ERROR", 4: "RC_NOT_IMPLEMENETD", 5: "RC_REFUSED", TSIG_BADSIG: "BADSIG", TSIG_BADKEY: "BADKEY", TSIG_BADTIME: "BADTIME", TKEY_BADMODE: "BADMODE", TKEY_BADNAME: "BADNAME", TKEY_BADLAG: "BADALG", }
Text values of TSIGRCODE
var Types = map[Type]string{ TYPE_A6: "A6", TYPE_A: "A", TYPE_AAAA: "AAAA", TYPE_AFSDB: "AFSDB", TYPE_APL: "APL", TYPE_ATMA: "ATMA", TYPE_AXFR: "AXFR", TYPE_CAA: "CAA", TYPE_CDS: "CDS", TYPE_CERT: "CERT", TYPE_CNAME: "CNAME", TYPE_DHCID: "DHCID", TYPE_DLV: "DLV", TYPE_DNAME: "DNAME", TYPE_DNSKEY: "DNSKEY", TYPE_DS: "DS", TYPE_EID: "EID", TYPE_GID: "GID", TYPE_GPOS: "GPOS", TYPE_HINFO: "HINFO", TYPE_HIP: "HIP", TYPE_IPSECKEY: "IPSECKEY", TYPE_ISDN: "ISDN", TYPE_IXFR: "IXFR", TYPE_KEY: "KEY", TYPE_KX: "KX", TYPE_LOC: "LOC", TYPE_MAILA: "MAILA", TYPE_MAILB: "MAILB", TYPE_MB: "MB", TYPE_MD: "MD", TYPE_MF: "MF", TYPE_MG: "MG", TYPE_MINFO: "MINFO", TYPE_MR: "MR", TYPE_MX: "MX", TYPE_NAPTR: "NAPTR", TYPE_NIMLOC: "NIMLOC", TYPE_NINFO: "NINFO", TYPE_NODATA: "NODATA", TYPE_NS: "NS", TYPE_NSAP: "NSAP", TYPE_NSAP_PTR: "NSAP-PTR", TYPE_NSEC3: "NSEC3", TYPE_NSEC3PARAM: "NSEC3PARAM", TYPE_NSEC: "NSEC", TYPE_NULL: "NULL", TYPE_NXDOMAIN: "NXDOMAIN", TYPE_NXT: "NXT", TYPE_OPT: "OPT", TYPE_PTR: "PTR", TYPE_PX: "PX", TYPE_RKEY: "RKEY", TYPE_RP: "RP", TYPE_RRSIG: "RRSIG", TYPE_RT: "RT", TYPE_SIG: "SIG", TYPE_SINK: "SINK", TYPE_SOA: "SOA", TYPE_SPF: "SPF", TYPE_SRV: "SRV", TYPE_SSHFP: "SSHFP", TYPE_TA: "TA", TYPE_TALINK: "TALINK", TYPE_TKEY: "TKEY", TYPE_TLSA: "TLSA", TYPE_TSIG: "TSIG", TYPE_TXT: "TXT", TYPE_UID: "UID", TYPE_UINFO: "UINFO", TYPE_UNSPEC: "UNSPEC", TYPE_URI: "URI", TYPE_WKS: "WKS", TYPE_X25: "X25", }
Functions ¶
func TypesEncode ¶
TypesEnccode encodes types into bitmap bits (RFC 4034/4.1.2).
func TypesString ¶
Types ¶
type AFSDB ¶
type AFSDB struct {
// The <subtype> field is a 16 bit integer.
SubType uint16
// The <hostname> field is a domain name of a host that has a server
// for the cell named by the owner name of the RR.
Hostname string
}
The AFS (originally the Andrew File System) system uses the DNS to map from a domain name to the name of an AFS cell database server. The DCE Naming service uses the DNS for a similar function: mapping from the domain name of a cell to authenticated name servers for that cell. The method uses a new RR type with mnemonic AFSDB and type code of 18 (decimal).
type AlgorithmType ¶
type AlgorithmType byte
DNSSEC Algorithm Types
The DNSKEY, RRSIG, and DS RRs use an 8-bit number to identify the security algorithm being used. These values are stored in the "Algorithm number" field in the resource record RDATA.
Some algorithms are usable only for zone signing (DNSSEC), some only for transaction security mechanisms (SIG(0) and TSIG), and some for both. Those usable for zone signing may appear in DNSKEY, RRSIG, and DS RRs. Those usable for transaction security would be present in SIG(0) and KEY RRs, as described in [RFC2931].
Zone Value Algorithm [Mnemonic] Signing References Status ----- -------------------- --------- ---------- --------- 0 reserved 1 RSA/MD5 [RSAMD5] n [RFC2537] NOT RECOMMENDED 2 Diffie-Hellman [DH] n [RFC2539] - 3 DSA/SHA-1 [DSA] y [RFC2536] OPTIONAL 4 Elliptic Curve [ECC] TBA - 5 RSA/SHA-1 [RSASHA1] y [RFC3110] MANDATORY 252 Indirect [INDIRECT] n - 253 Private [PRIVATEDNS] y see below OPTIONAL 254 Private [PRIVATEOID] y see below OPTIONAL 255 reserved 6 - 251 Available for assignment by IETF Standards Action.
const ( AlgorithmReserved0 AlgorithmType = iota AlgorithmRSA_MD5 AlgorithmDiffie_Hellman AlgorithmDSA_SHA1 AlgorithmElliptic AlgorithmRSA_SHA1 AlgorithmIndirect AlgorithmType = iota + 246 // 252 AlgorithmPrivateDNS AlgorithmPrivateOID AlgorithmReserved1255 )
AlgorithmType values
type Bytes ¶
type Bytes []byte
Bytes is a packed binary representation of RRs.
func (*Bytes) Append ¶
Append appends RRs to b. Append is a quite costly operation, so whenever possible collect related RRs firstly and then use Pack instead of e.g. Appending them one by one.
type CERT ¶
type CERT struct {
// The type field is the certificate type as defined by CertType.
Type CertType
// The key tag field is the 16-bit value computed for the key embedded
// in the certificate, using the RRSIG Key Tag algorithm described in
// Appendix B of [12]. This field is used as an efficiency measure to
// pick which CERT RRs may be applicable to a particular key. The key
// tag can be calculated for the key in question, and then only CERT RRs
// with the same key tag need to be examined. Note that two different
// keys can have the same key tag. However, the key MUST be transformed
// to the format it would have as the public key portion of a DNSKEY RR
// before the key tag is computed. This is only possible if the key is
// applicable to an algorithm and complies to limits (such as key size)
// defined for DNS security. If it is not, the algorithm field MUST be
// zero and the tag field is meaningless and SHOULD be zero.
KeyTag uint16
// The algorithm field has the same meaning as the algorithm field in
// DNSKEY and RRSIG RRs [12], except that a zero algorithm field
// indicates that the algorithm is unknown to a secure DNS, which may
// simply be the result of the algorithm not having been standardized
// for DNSSEC [11].
//
// Defined by AlgorithmType
Algorithm AlgorithmType
// Certificate or CRL
Cert []byte
}
type CNAME ¶
type CNAME struct {
Name string
}
CNAME holds the zone CNAME RData
type Class ¶
type Class uint16
Class is a RR CLASS
const ( CLASS_NONE Class = iota CLASS_IN // the Internet CLASS_CS // the CSNET class (Obsolete - used only for examples in some obsolete RFCs) CLASS_CH // the CHAOS class CLASS_HS // Hesiod )
Class values
type DHCID ¶
type DHCID struct {
Data []byte
}
DHCID represents the RDATA of an DHCID RR.
Conflicts can arise if multiple DHCP clients wish to use the same DNS name or a DHCP client attempts to use a name added for another purpose. To resolve such conflicts, [1] proposes storing client identifiers in the DNS to unambiguously associate domain names with the DHCP clients using them. In the interest of clarity, it is preferable for this DHCP information to use a distinct RR type. This memo defines a distinct RR for this purpose for use by DHCP clients or servers: the "DHCID" RR. In order to obscure potentially sensitive client identifying information, the data stored is the result of a one-way SHA-256 hash computation. The hash includes information from the DHCP client's message as well as the domain name itself, so that the data stored in the DHCID RR will be dependent on both the client identification used in the DHCP protocol interaction and the domain name. This means that the DHCID RDATA will vary if a single client is associated over time with more than one name. This makes it difficult to 'track' a client as it is associated with various domain names.
type DLV ¶
type DLV struct {
// The key tag is calculated as specified in RFC 2535
KeyTag uint16
// Algorithm MUST be allowed to sign DNS data
Algorithm AlgorithmType
// The digest type is an identifier for the digest algorithm used
DigestType HashAlgorithm
// The digest is calculated over the
// canonical name of the delegated domain name followed by the whole
// RDATA of the KEY record (all four fields)
Digest []byte
}
DLV represents DLV RR RDATA [RFC4431]. The DLV resource record has exactly the same wire and presentation formats as the DS resource record, defined in RFC 4034, Section 5. It uses the same IANA-assigned values in the algorithm and digest type fields as the DS record. (Those IANA registries are known as the "DNS Security Algorithm Numbers" and "DS RR Type Algorithm Numbers" registries.)
The DLV record is a normal DNS record type without any special processing requirements. In particular, the DLV record does not inherit any of the special processing or handling requirements of the DS record type (described in Section 3.1.4.1 of RFC 4035). Unlike the DS record, the DLV record may not appear on the parent's side of a zone cut. A DLV record may, however, appear at the apex of a zone.
type DNAME ¶
type DNAME struct {
Name string
}
DNAME holds the zone DNAME RData
type DNSKEY ¶
type DNSKEY struct {
// Bit 7 of the Flags field is the Zone Key flag. If bit 7 has value 1,
// then the DNSKEY record holds a DNS zone key, and the DNSKEY RR's
// owner name MUST be the name of a zone. If bit 7 has value 0, then
// the DNSKEY record holds some other type of DNS public key and MUST
// NOT be used to verify RRSIGs that cover RRsets.
//
// Bit 15 of the Flags field is the Secure Entry Point flag, described
// in [RFC3757]. If bit 15 has value 1, then the DNSKEY record holds a
// key intended for use as a secure entry point. This flag is only
// intended to be a hint to zone signing or debugging software as to the
// intended use of this DNSKEY record; validators MUST NOT alter their
// behavior during the signature validation process in any way based on
// the setting of this bit. This also means that a DNSKEY RR with the
// SEP bit set would also need the Zone Key flag set in order to be able
// to generate signatures legally. A DNSKEY RR with the SEP set and the
// Zone Key flag not set MUST NOT be used to verify RRSIGs that cover
// RRsets.
//
// Bits 0-6 and 8-14 are reserved: these bits MUST have value 0 upon
// creation of the DNSKEY RR and MUST be ignored upon receipt.
Flags uint16
// The Protocol Field MUST have value 3, and the DNSKEY RR MUST be
// treated as invalid during signature verification if it is found to be
// some value other than 3.
Protocol byte
// The Algorithm field identifies the public key's cryptographic
// algorithm and determines the format of the Public Key field. A list
// of DNSSEC algorithm types can be found in Appendix A.1
Algorithm AlgorithmType
// The Public Key Field holds the public key material. The format
// depends on the algorithm of the key being stored and is described in
// separate documents.
Key []byte
}
DNSKEY holds the DNS key RData // RFC 4034
type DS ¶
type DS struct {
// The key tag is calculated as specified in RFC 2535
KeyTag uint16
// Algorithm MUST be allowed to sign DNS data
Algorithm AlgorithmType
// The digest type is an identifier for the digest algorithm used
DigestType HashAlgorithm
// The digest is calculated over the
// canonical name of the delegated domain name followed by the whole
// RDATA of the KEY record (all four fields)
Digest []byte
}
The delegation signer (DS) resource record (RR) is inserted at a zone cut (i.e., a delegation point) to indicate that the delegated zone is digitally signed and that the delegated zone recognizes the indicated key as a valid zone key for the delegated zone. (RFC 3658)
type EXT_RCODE ¶
EXT_RCODE type holds the EDNS extended RCODE (in the RR.TTL field)
type GPOS ¶
type GPOS struct {
// The real number describing the longitude encoded as a printable
// string. The precision is limited by 256 charcters within the range
// -90..90 degrees. Positive numbers indicate locations north of the
// equator.
Longitude float64
// The real number describing the latitude encoded as a printable
// string. The precision is limited by 256 charcters within the range
// -180..180 degrees. Positive numbers indicate locations east of the
// prime meridian.
Latitude float64
// The real number describing the altitude (in meters) from mean
// sea-level encoded as a printable string. The precision is limited by
// 256 charcters. Positive numbers indicate locations above mean
// sea-level.
Altitude float64
}
The geographical location is defined with the mnemonic GPOS and type code 27.
A floating point format was chosen to specify geographical locations for reasons of simplicity. This also guarantees a concise unambiguous description of a location by enforcing three compulsory numerical values to be specified.
type GatewayType ¶
type GatewayType byte
GatewayType type is the type of the IPSECKEY GatewayType field.
const ( GatewayNone GatewayType = iota GatewayIPV4 GatewayIPV6 GatewayDomain )
Values of GatewayType
type HINFO ¶
type HINFO struct {
Cpu string // A <character-string> which specifies the CPU type.
Os string // A <character-string> which specifies the operating system type.
}
HINFO records are used to acquire general information about a host. The main use is for protocols such as FTP that can use special procedures when talking between machines or operating systems of the same type.
type HIP ¶
type HIP struct {
// The PK algorithm field indicates the public key cryptographic
// algorithm and the implied public key field format. This is an 8-bit
// unsigned integer. This document reuses the values defined for the
// 'algorithm type' of the IPSECKEY RR [RFC4025].
PKAlgorithm IPSECKEYAlgorithm
// Host identity tag
HIT []byte
// Both of the public key types defined in this document (RSA and DSA)
// reuse the public key formats defined for the IPSECKEY RR [RFC4025].
//
// The DSA key format is defined in RFC 2536 [RFC2536].
//
// The RSA key format is defined in RFC 3110 [RFC3110] and the RSA key
// size limit (4096 bits) is relaxed in the IPSECKEY RR [RFC4025]
// specification.
PublicKey []byte
// The Rendezvous Servers field indicates one or more variable length
// wire-encoded domain names of rendezvous server(s), as described in
// Section 3.3 of RFC 1035 [RFC1035]. The wire-encoded format is self-
// describing, so the length is implicit. The domain names 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.
RendezvousServers []string
}
HIP represents the RDATA of a HIP RR. This RR allows a HIP node to store in the DNS its Host Identity (HI, the public component of the node public-private key pair), Host Identity Tag (HIT, a truncated hash of its public key), and the Domain Names of its rendezvous servers (RVSs).
type HashAlgorithm ¶
type HashAlgorithm byte
HashAlgorithm is the type of the hash algorithm in the NSEC3 RR
const ( HashAlgorithmReserved HashAlgorithm = iota HashAlgorithmSHA1 )
IANA registry for "DNSSEC NSEC3 Hash Algorithms". Values of HashAlgorithm.
type IPSECKEY ¶
type IPSECKEY struct {
// This is an 8-bit precedence for this record. It is interpreted in
// the same way as the PREFERENCE field described in section 3.3.9 of
// RFC 1035.
//
// Gateways listed in IPSECKEY records with lower precedence are to be
// attempted first. Where there is a tie in precedence, the order
// should be non-deterministic.
Precedence byte
// The gateway type field indicates the format of the information that
// is stored in the gateway field.
//
// The following values are defined:
// 0 No gateway is present.
// Gateway == nil
// 1 A 4-byte IPv4 address is present.
// Gateway.(type) == net.IP w/ len() == 4
// 2 A 16-byte IPv6 address is present.
// Gateway.(type) == net.IP w/ len() == 16
// 3 A wire-encoded domain name is present. The wire-encoded format is
// self-describing, so the length is implicit. The domain name MUST
// NOT be compressed. (See Section 3.3 of RFC 1035.)
// Gateway.(type) == dns.DomainName
GatewayType GatewayType
// The algorithm type field identifies the public key's cryptographic
// algorithm and determines the format of the public key field.
//
// A value of 0 indicates that no key is present.
//
// The following values are defined:
// 1 A DSA key is present, in the format defined in RFC 2536.
// 2 A RSA key is present, in the format defined in RFC 3110.
Algorithm IPSECKEYAlgorithm
// The gateway field indicates a gateway to which an IPsec tunnel may be
// created in order to reach the entity named by this resource record.
//
// There are three formats:
//
// A 32-bit IPv4 address is present in the gateway field. The data
// portion is an IPv4 address as described in section 3.4.1 of RFC 1035
// [2]. This is a 32-bit number in network byte order.
//
// A 128-bit IPv6 address is present in the gateway field. The data
// portion is an IPv6 address as described in section 2.2 of RFC 3596
// [12]. This is a 128-bit number in network byte order.
//
// The gateway field is a normal wire-encoded domain name, as described
// in section 3.3 of RFC 1035 [2]. Compression MUST NOT be used.
Gateway interface{}
// Both the public key types defined in this document (RSA and DSA)
// inherit their public key formats from the corresponding KEY RR
// formats. Specifically, the public key field contains the
// algorithm-specific portion of the KEY RR RDATA, which is all the KEY
// RR DATA after the first four octets. This is the same portion of the
// KEY RR that must be specified by documents that define a DNSSEC
// algorithm. Those documents also specify a message digest to be used
// for generation of SIG RRs; that specification is not relevant for
// IPSECKEY RRs.
//
// Future algorithms, if they are to be used by both DNSSEC (in the KEY
// RR) and IPSECKEY, are likely to use the same public key encodings in
// both records. Unless otherwise specified, the IPSECKEY public key
// field will contain the algorithm-specific portion of the KEY RR RDATA
// for the corresponding algorithm. The algorithm must still be
// designated for use by IPSECKEY, and an IPSECKEY algorithm type number
// (which might be different from the DNSSEC algorithm number) must be
// assigned to it.
//
// The DSA key format is defined in RFC 2536.
//
// The RSA key format is defined in RFC 3110, with the following
// changes:
//
// The earlier definition of RSA/MD5 in RFC 2065 limited the exponent
// and modulus to 2552 bits in length. RFC 3110 extended that limit to
// 4096 bits for RSA/SHA1 keys. The IPSECKEY RR imposes no length
// limit on RSA public keys, other than the 65535 octet limit imposed
// by the two-octet length encoding. This length extension is
// applicable only to IPSECKEY; it is not applicable to KEY RRs.
PublicKey []byte
}
IPSECKEY type represents the IPSECKEY RR RData. The IPSECKEY resource record (RR) is used to publish a public key that is to be associated with a Domain Name System (DNS) [1] name for use with the IPsec protocol suite. This can be the public key of a host, network, or application (in the case of per-port keying).
NOTE: IPSECKEY.Encode(), .String() will panic and/or fail to perform properly if GatewayType doesn't reflect the appropriate type stored in Gateway. Use the SetGateway helper to avoid such situation.
func (*IPSECKEY) SetGateway ¶
func (rd *IPSECKEY) SetGateway(g interface{}) (t GatewayType, err error)
SetGeteway will safely set d.Gateway and d.GatewayType or return an error otherwise if g type is not (nil or net.IP or a string).
type IPSECKEYAlgorithm ¶
type IPSECKEYAlgorithm byte
IPSECKEYAlgorithm is the type of the IPSECKEY RData Algorithm field
const ( IPSECKEYAlgorithmNone IPSECKEYAlgorithm = iota IPSECKEYAlgorithmDSA IPSECKEYAlgorithmRSA )
Values of IPSECKEYAlgorithm
type IP_Port ¶
type IP_Port int
IP_Port is a IP port number. Used by WKS. See e.g. http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
type IP_Protocol ¶
type IP_Protocol byte
IP_Protocol is a IP protocol number. Used by WKS RR. See e.g. http://en.wikipedia.org/wiki/List_of_IP_protocol_numbers
const ( TCP_Protocol IP_Protocol = 6 // Transmission Control Protocol UDP_Protocol IP_Protocol = 17 // User Datagram Protocol )
Values of IP_Protocol
type ISDN ¶
type ISDN struct {
// <ISDN-address> identifies the ISDN number of <owner> and DDI (Direct
// Dial In) if any, as defined by E.164 [8] and E.163 [7], the ISDN and
// PSTN (Public Switched Telephone Network) numbering plan. E.163
// defines the country codes, and E.164 the form of the addresses. Its
// format in master files is a <character-string> syntactically
// identical to that used in TXT and HINFO.
ISDN string
// <sa> specifies the subaddress (SA). The format of <sa> in master
// files is a <character-string> syntactically identical to that used
// in TXT and HINFO.
Sa string
}
An ISDN (Integrated Service Digital Network) number is simply a telephone number. The intent of the members of the CCITT is to upgrade all telephone and data network service to a common service.
The <ISDN-address> field is required; <sa> is optional.
type KEY ¶
type KEY struct {
// Bit 7 of the Flags field is the Zone Key flag. If bit 7 has value 1,
// then the KEY record holds a DNS zone key, and the KEY RR's
// owner name MUST be the name of a zone. If bit 7 has value 0, then
// the KEY record holds some other type of DNS public key and MUST
// NOT be used to verify RRSIGs that cover RRsets.
//
// Bit 15 of the Flags field is the Secure Entry Point flag, described
// in [RFC3757]. If bit 15 has value 1, then the KEY record holds a
// key intended for use as a secure entry point. This flag is only
// intended to be a hint to zone signing or debugging software as to the
// intended use of this KEY record; validators MUST NOT alter their
// behavior during the signature validation process in any way based on
// the setting of this bit. This also means that a KEY RR with the
// SEP bit set would also need the Zone Key flag set in order to be able
// to generate signatures legally. A KEY RR with the SEP set and the
// Zone Key flag not set MUST NOT be used to verify RRSIGs that cover
// RRsets.
//
// Bits 0-6 and 8-14 are reserved: these bits MUST have value 0 upon
// creation of the KEY RR and MUST be ignored upon receipt.
Flags uint16
// The Protocol Field MUST have value 3, and the KEY RR MUST be
// treated as invalid during signature verification if it is found to be
// some value other than 3.
Protocol byte
// The Algorithm field identifies the public key's cryptographic
// algorithm and determines the format of the Public Key field. A list
// of DNSSEC algorithm types can be found in Appendix A.1
Algorithm AlgorithmType
// The Public Key Field holds the public key material. The format
// depends on the algorithm of the key being stored and is described in
// separate documents.
Key []byte
}
The KEY resource record (RR) is used to store a public key that is associated with a Domain Name System (DNS) name. This can be the public key of a zone, a user, or a host or other end entity. Security aware DNS implementations MUST be designed to handle at least two simultaneously valid keys of the same type associated with the same name.
A KEY RR is, like any other RR, authenticated by a SIG RR. KEY RRs must be signed by a zone level key.
type KX ¶
type KX struct {
// A 16 bit non-negative integer which specifies the preference given
// to this RR among other KX records at the same owner. Lower values
// are preferred.
Preference uint16
// A <domain-name> which specifies a host willing to act as a mail
// exchange for the owner name.
Exchanger string
}
type LOC ¶
type LOC struct {
// 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.
Version byte
// The diameter of a sphere enclosing the described entity, in
// centimeters, 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.
Size byte
// 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.)
HorizPre byte
// 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 SIZE; 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 [WGS 84]
// ellipsoid, the precision value should be adjusted.
VertPre byte
// 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.
Latitude uint32
// 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.
Longitude uint32
// 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 [WGS 84] 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 [WGS 84]
// 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 [WGS 84] spheroid. Adjustments to ALTITUDE
// and/or VERT PRE will be necessary in most cases. The Defense
// Mapping Agency publishes geoid height values relative to the [WGS
// 84] ellipsoid.
Altitude uint32
}
The LOC record is expressed in a master file in the following format:
<owner> <TTL> <class> LOC ( d1 [m1 [s1]] {"N"|"S"} d2 [m2 [s2]]
{"E"|"W"} alt["m"] [siz["m"] [hp["m"]
[vp["m"]]]] )
(The parentheses are used for multi-line data as specified in [RFC 1035] section 5.1.)
where:
d1: [0 .. 90] (degrees latitude) d2: [0 .. 180] (degrees longitude) m1, m2: [0 .. 59] (minutes latitude/longitude) s1, s2: [0 .. 59.999] (seconds latitude/longitude) alt: [-100000.00 .. 42849672.95] BY .01 (altitude in meters) siz, hp, vp: [0 .. 90000000.00] (size/precision in meters)
If omitted, minutes and seconds default to zero, size defaults to 1m, horizontal precision defaults to 10000m, and vertical precision defaults to 10m. These defaults are chosen to represent typical ZIP/postal code area sizes, since it is often easy to find approximate geographical location by ZIP/postal code.
func (*LOC) ThousandsSecs ¶
type MB ¶
type MB struct {
// A <domain-name> which specifies a host which has the specified
// mailbox.
MADNAME string
}
MB records cause additional section processing which looks up an A type RRs corresponding to MADNAME.
type MD ¶
type MD struct {
// A <domain-name> which specifies a host which has a mail agent for
// the domain which should be able to deliver mail for the domain.
MADNAME string
}
MD records cause additional section processing which looks up an A type record corresponding to MADNAME.
MD is obsolete. See the definition of MX and [RFC-974] for details of the new scheme. The recommended policy for dealing with MD RRs found in a master file is to reject them, or to convert them to MX RRs with a preference of 0.
type MF ¶
type MF struct {
// A <domain-name> which specifies a host which has a mail agent for
// the domain which will accept mail for forwarding to the domain.
MADNAME string
}
MF records cause additional section processing which looks up an A type record corresponding to MADNAME.
MF is obsolete. See the definition of MX and [RFC-974] for details ofw the new scheme. The recommended policy for dealing with MD RRs found in a master file is to reject them, or to convert them to MX RRs with a preference of 10.
type MG ¶
type MG struct {
// A <domain-name> which specifies a mailbox which is a member of the
// mail group specified by the domain name.
MGNAME string
}
MG records cause no additional section processing.
type MINFO ¶
type MINFO struct {
// A <domain-name> which specifies a mailbox which is responsible for
// the mailing list or mailbox. If this domain name names the root,
// the owner of the MINFO RR is responsible for itself. Note that many
// existing mailing lists use a mailbox X-request for the RMAILBX field
// of mailing list X, e.g., Msgroup-request for Msgroup. This field
// provides a more general mechanism.
RMAILBX string
// A <domain-name> which specifies a mailbox which is to receive error
// messages related to the mailing list or mailbox specified by the
// owner of the MINFO RR (similar to the ERRORS-TO: field which has
// been proposed). If this domain name names the root, errors should
// be returned to the sender of the message.
EMAILBX string
}
MINFO records cause no additional section processing. Although these records can be associated with a simple mailbox, they are usually used with a mailing list.
type MR ¶
type MR struct {
// A <domain-name> which specifies a mailbox which is the proper rename
// of the specified mailbox.
NEWNAME string
}
MR records cause no additional section processing. The main use for MR is as a forwarding entry for a user who has moved to a different mailbox.
type MX ¶
type MX struct {
// A 16 bit integer which specifies the preference given to
// this RR among others at the same owner. Lower values
// are preferred.
Preference uint16
// A <domain-name> which specifies a host willing to act as
// a mail exchange for the owner name.
Exchange string
}
MX holds the zone MX RData
type NAPTR ¶
type NAPTR struct {
// 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.
Order uint16
// Although it is called "preference" in deference to DNS terminology,
// this field is equivalent to the Priority value in the DDDS
// Algorithm. It is a 16-bit unsigned integer that 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.
Preference uint16
// A <character-string> containing 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.
Flags string
// A <character-string> that 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.
Services string
// A <character-string> containing 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.
Regexp string
// A <domain-name> which is 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.
Replacement string
}
type NODATA ¶
type NODATA struct {
Type // The Type for which we are caching the NODATA
}
NODATA is used for negative caching of authoritative answers for queried non existent Type/Class combinations.
type NS ¶
type NS struct {
// A <domain-name> which specifies a host which should be
// authoritative for the specified class and domain.
NSDName string
}
NS holds the zone NS RData
type NSAP ¶
type NSAP struct {
// A variable length string of octets containing the NSAP. The value
// is the binary encoding of the NSAP as it would appear in the CLNP
// source or destination address field.
NSAP []byte
}
The NSAP RR is used to map from domain names to NSAPs. Name-to-NSAP mapping in the DNS using the NSAP RR operates analogously to IP address lookup. A query is generated by the resolver requesting an NSAP RR for a provided domain name.
NSAP RRs conform to the top level RR format and semantics as defined in Section 3.2.1 of RFC 1035.
type NSAP_PTR ¶
type NSAP_PTR struct {
Name string
}
NSAP_PTR has a function analogous to the PTR record used for IP addresses
type NSEC ¶
type NSEC struct {
// The Next Domain field contains the next owner name (in the canonical
// ordering of the zone) that has authoritative data or contains a
// delegation point NS RRset; see Section 6.1 for an explanation of
// canonical ordering. The value of the Next Domain Name field in the
// last NSEC record in the zone is the name of the zone apex (the owner
// name of the zone's SOA RR). This indicates that the owner name of
// the NSEC RR is the last name in the canonical ordering of the zone.
//
// A sender MUST NOT use DNS name compression on the Next Domain Name
// field when transmitting an NSEC RR.
//
// Owner names of RRsets for which the given zone is not authoritative
// (such as glue records) MUST NOT be listed in the Next Domain Name
// unless at least one authoritative RRset exists at the same owner
// name.
NextDomainName string
// The Type Bit Maps field identifies the RRset types that exist at the
// NSEC RR's owner name.
TypeBitMaps []byte
}
Type NSEC represents NSEC RR RData. The NSEC resource record lists two separate things: the next owner name (in the canonical ordering of the zone) that contains authoritative data or a delegation point NS RRset, and the set of RR types present at the NSEC RR's owner name [RFC3845]. The complete set of NSEC RRs in a zone indicates which authoritative RRsets exist in a zone and also form a chain of authoritative owner names in the zone. This information is used to provide authenticated denial of existence for DNS data, as described in [RFC4035].
Because every authoritative name in a zone must be part of the NSEC chain, NSEC RRs must be present for names containing a CNAME RR. This is a change to the traditional DNS specification [RFC1034], which stated that if a CNAME is present for a name, it is the only type allowed at that name. An RRSIG (see Section 3) and NSEC MUST exist for the same name as does a CNAME resource record in a signed zone.
See [RFC4035] for discussion of how a zone signer determines precisely which NSEC RRs it has to include in a zone.
The NSEC RR is class independent.
The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL field. This is in the spirit of negative caching ([RFC2308]).
type NSEC3 ¶
type NSEC3 struct {
NSEC3PARAM
// The Next Hashed Owner Name field contains the next hashed owner name
// in hash order. This value is in binary format.
NextHashedOwnerName []byte
// The Type Bit Maps field identifies the RRSet types that exist at the
// original owner name of the NSEC3 RR
TypeBitMaps []byte
}
The NSEC3 Resource Record (RR) provides authenticated denial of existence for DNS Resource Record Sets. (RFC 5155)
type NSEC3PARAM ¶
type NSEC3PARAM struct {
// The Hash Algorithm field identifies the cryptographic hash algorithm
// used to construct the hash-value.
HashAlgorithm
// The Flags field contains 8 one-bit flags that can be used to indicate
// different processing. All undefined flags must be zero. The only
// flag defined by this specification is the Opt-Out flag.
Flags byte
// The Iterations field defines the number of additional times the hash
// function has been performed.
Iterations uint16
// The Salt field is appended to the original owner name before hashing
// in order to defend against pre-calculated dictionary attacks
Salt []byte
}
The NSEC3PARAM RR contains the NSEC3 parameters (hash algorithm, flags, iterations, and salt) needed by authoritative servers to calculate hashed owner names. (RFC 5155)
func (*NSEC3PARAM) Decode ¶
func (rd *NSEC3PARAM) Decode(b []byte, pos *int, sniffer dns.WireDecodeSniffer) (err error)
Implementation of dns.Wirer
func (*NSEC3PARAM) Encode ¶
func (rd *NSEC3PARAM) Encode(b *dns.Wirebuf)
Implementation of dns.Wirer
func (*NSEC3PARAM) String ¶
func (rd *NSEC3PARAM) String() string
type NXDOMAIN ¶
type NXDOMAIN struct{}
NXDOMAIN is used for negative caching of authoritave answers for queried non existing domain names.
type OPT ¶
type OPT struct {
Values []OPT_DATA
}
OPT holds the RFC2671 OPT pseudo RR RData
type OPT_DATA ¶
OPT_DATA holds an {attribute, value} pair of the OPT RR
type PTR ¶
type PTR struct {
// A <domain-name> which points to some location in the
// domain name space.
PTRDName string
}
PTR holds the zone PTR RData
type PX ¶
type PX struct {
// A 16 bit integer which specifies the preference given to
// this RR among others at the same owner. Lower values
// are preferred.
Preference uint16
// A <domain-name> element containing <rfc822-domain>, the RFC822 part
// of the MCGAM.
MAP822 string
// A <domain-name> element containing the value of
// <x400-in-domain-syntax> derived from the X.400 part of the MCGAM.
MAPX400 string
}
type RDATA ¶
type RDATA []byte
RDATA hodls DNS RR rdata for a unknown/unsupported RR type (RFC3597).
type RP ¶
type RP struct {
// The first field, <mbox-dname>, is a domain name that specifies the
// mailbox for the responsible person. Its format in master files uses
// the DNS convention for mailbox encoding, identical to that used for
// the RNAME mailbox field in the SOA RR. The root domain name (just
// ".") may be specified for <mbox-dname> to indicate that no mailbox
// is available.
Mbox string
// The second field, <txt-dname>, is a domain name for which TXT RR's
// exist. A subsequent query can be performed to retrieve the
// associated TXT resource records at <txt-dname>. This provides a
// level of indirection so that the entity can be referred to from
// multiple places in the DNS. The root domain name (just ".") may be
// specified for <txt-dname> to indicate that the TXT_DNAME is absent,
// and no associated TXT RR exists.
Txt string
}
The Responsible Person RR can be associated with any node in the Domain Name System hierarchy, not just at the leaves of the tree.
type RR ¶
type RR struct {
// An owner name, i.e., the name of the node to which this resource record pertains.
Name string
// Two octets containing one of the RR TYPE codes.
Type
// Two octets containing one of the RR CLASS codes.
Class
// A 32 bit signed integer that specifies the time interval
// that the resource record may be cached before the source
// of the information should again be consulted. Zero
// values are interpreted to mean that the RR can only be
// used for the transaction in progress, and should not be
// cached. For example, SOA records are always distributed
// with a zero TTL to prohibit caching. Zero values can
// also be used for extremely volatile data.
TTL int32
//The format of this information varies according to the TYPE and CLASS of the resource record.
RData dns.Wirer
}
RR holds a zone resource record data.
type RRSIG ¶
type RRSIG struct {
// The Type Covered field identifies the type of the RRset that is covered
// by this RRSIG record.
Type Type
// The Algorithm Number field identifies the cryptographic algorithm used
// to create the signature.
Algorithm AlgorithmType
// The Labels field specifies the number of labels in the original RRSIG RR owner name.
Labels byte
// The Original TTL field specifies the TTL of the covered RRset as it appears
// in the authoritative zone.
TTL int32
// The Signature Expiration field specifies a validity period for the signature.
// The RRSIG record MUST NOT be used for authentication after the expiration date.
Expiration uint32
// The Signature Inception field specifies a validity period for the signature.
// The RRSIG record MUST NOT be used for authentication prior to the inception date.
Inception uint32
// The Key Tag field contains the key tag value of the DNSKEY RR that validates
// this signature, in network byte order.
KeyTag uint16
// The Signer's Name field value identifies the owner name of the DNSKEY
// RR that a validator is supposed to use to validate this signature.
Name string
// The Signature field contains the cryptographic signature that covers
// the RRSIG RDATA (excluding the Signature field) and the RRset
// specified by the RRSIG owner name, RRSIG class, and RRSIG Type
// Covered field.
Signature []byte
}
RRSIG holds the zone RRSIG RData (RFC4034)
type RRs ¶
type RRs []*RR
RRs is a slice of resource records with attached convenience methods
func (RRs) Partition ¶
Partition groups resource record of the same type. If unique == true then the result parts are processed by Unique.
type RT ¶
type RT struct {
// The first field, <preference>, is a 16 bit integer, representing the
// preference of the route. Smaller numbers indicate more preferred
// routes.
Preference uint16
// <intermediate-host> is the domain name of a host which will serve as
// an intermediate in reaching the host specified by <owner>. The DNS
// RRs associated with <intermediate-host> are expected to include at
// least one A, X25, or ISDN record.
Hostname string
}
The RT resource record provides a route-through binding for hosts that do not have their own direct wide area network addresses. It is used in much the same way as the MX RR.
Both RDATA fields are required in all RT RRs.
type SIG ¶
type SIG struct {
// The Type Covered field identifies the type of the RRset that is covered
// by this SIG record.
Type Type
// The Algorithm Number field identifies the cryptographic algorithm used
// to create the signature.
Algorithm AlgorithmType
// The Labels field specifies the number of labels in the original SIG RR owner name.
Labels byte
// The Original TTL field specifies the TTL of the covered RRset as it appears
// in the authoritative zone.
TTL int32
// The Signature Expiration field specifies a validity period for the signature.
// The SIG record MUST NOT be used for authentication after the expiration date.
Expiration uint32
// The Signature Inception field specifies a validity period for the signature.
// The SIG record MUST NOT be used for authentication prior to the inception date.
Inception uint32
// The Key Tag field contains the key tag value of the DNSKEY RR that validates
// this signature, in network byte order.
KeyTag uint16
// The Signer's Name field value identifies the owner name of the DNSKEY
// RR that a validator is supposed to use to validate this signature.
Name string
// The Signature field contains the cryptographic signature that covers
// the SIG RDATA (excluding the Signature field) and the RRset
// specified by the SIG owner name, SIG class, and SIG Type
// Covered field.
Signature []byte
}
The SIG or "signature" resource record (RR) is the fundamental way that data is authenticated in the secure Domain Name System (DNS). As such it is the heart of the security provided.
type SOA ¶
type SOA struct {
// The <domain-name> of the name server that was the
// original or primary source of data for this zone.
MName string
// A <domain-name> which specifies the mailbox of the
// person responsible for this zone.
RName string
// The unsigned 32 bit version number of the original copy
// of the zone. Zone transfers preserve this value. This
// value wraps and should be compared using sequence space
// arithmetic.
Serial uint32
// A 32 bit time interval before the zone should be
// refreshed.
Refresh uint32
// A 32 bit time interval that should elapse before a
// failed refresh should be retried.
Retry uint32
// A 32 bit time value that specifies the upper limit on
// the time interval that can elapse before the zone is no
// longer authoritative.
Expire uint32
// The unsigned 32 bit minimum TTL field that should be
// exported with any RR from this zone.
Minimum uint32
}
SOA holds the zone SOA RData
type SPF ¶
type SPF struct {
S []string
}
SPF represents SPF RR RDATA. The format of this type is identical to the TXT RR [RFC1035]. For either type, the character content of the record is encoded as [US-ASCII].
It is recognized that the current practice (using a TXT record) is not optimal, but it is necessary because there are a number of DNS server and resolver implementations in common use that cannot handle the new RR type. The two-record-type scheme provides a forward path to the better solution of using an RR type reserved for this purpose.
An SPF-compliant domain name SHOULD have SPF records of both RR types. A compliant domain name MUST have a record of at least one type. If a domain has records of both types, they MUST have identical content. For example, instead of publishing just one record as in Section 3.1 above (RFC4408), it is better to publish:
example.com. IN TXT "v=spf1 +mx a:colo.example.com/28 -all" example.com. IN SPF "v=spf1 +mx a:colo.example.com/28 -all"
Example RRs in this document are shown with the TXT record type; however, they could be published with the SPF type or with both types.
type SRV ¶
type SRV struct {
// The priority of this target host. 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. The range is 0-65535. This is a 16
// bit unsigned integer in network byte order.
Priority uint16
// 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. The
// range of this number is 0-65535. This is a 16 bit unsigned integer
// in network byte order. 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.
Weight uint16
// The port on this target host of this service. The range is 0-
// 65535. This is a 16 bit unsigned integer in network byte order.
// This is often as specified in Assigned Numbers but need not be.
Port uint16
// 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.
Target string
}
type SSHFP ¶
type SSHFP struct {
// This algorithm number octet describes the algorithm of the public
// key. The following values are assigned:
//
// Value Algorithm name
// ----- --------------
// 0 reserved
// 1 RSA
// 2 DSS
Algorithm SSHFPAlgorithm
// The fingerprint type octet describes the message-digest algorithm
// used to calculate the fingerprint of the public key. The following
// values are assigned:
//
// Value Fingerprint type
// ----- ----------------
// 0 reserved
// 1 SHA-1
Type SSHFPType
// The fingerprint is calculated over the public key blob as described
// in: Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
// Transport Layer Protocol", RFC 4253, January 2006.
//
// The message-digest algorithm is presumed to produce an opaque octet
// string output, which is placed as-is in the RDATA fingerprint field.
Fingerprint []byte
}
SSHFP type represents RData of a SSHFP RR. The SSHFP resource record (RR) is used to store a fingerprint of an SSH public host key that is associated with a Domain Name System (DNS) name.
type SSHFPAlgorithm ¶
type SSHFPAlgorithm byte
SSHFPAlgorithm is the type of the SSHFP RData Algorithm field
const ( SSHFPAlgorithmReserved SSHFPAlgorithm = iota SSHFPAlgorithmRSA SSHFPAlgorithmDSA )
Values of SSHFPAlgorithm
type TA ¶
type TA struct {
// The key tag is calculated as specified in RFC 2535
KeyTag uint16
// Algorithm MUST be allowed to sign DNS data
Algorithm AlgorithmType
// The digest type is an identifier for the digest algorithm used
DigestType HashAlgorithm
// The digest is calculated over the
// canonical name of the delegated domain name followed by the whole
// RDATA of the KEY record (all four fields)
Digest []byte
}
TA represent TA RR RDATA.
From: http://tools.ietf.org/html/draft-lewis-dns-undocumented-types-01
2.10 TA (32768) TA stands for "Trust Anchor" and, as far as can be determined, not defined in an IETF document. (The ATMA record is also not mentioned in an IETF document.) The record is described in a document named INI1999-19.pdf on the www.watson.org web site. In that document, the RDATA is described as "The fields in the TA record contain exactly the same data as the DS record and use the same IANA-assigned values in the algorithm and digest type fields as the DS record." The following appears on the IANA webpage for DNS Parameters: Deploying DNSSEC Without a Signed Rott[sic]. TR 1999-19, Information Networking Institute, Carnegie Mellon U, April 2004. http://cameo.library.cmu.edu/ http://www.watson.org/~weiler/INI1999-19.pdf The DS record is defined in RFC4034.
type TALINK ¶
TALINK represent TALINK RR RDATA.
From: http://tools.ietf.org/html/draft-lewis-dns-undocumented-types-01
2.6 TALINK (58) TALINK stands for Trust Anchor Link and is last defined in the draft named draft-wijngaards-dnsop-trust-history-02, available on the tools.ietf.org site. The RDATA section is defined as two fully qualified domain names that are not subject to message compression nor DNSSEC downcasing. The draft expired in February 2010.
type TKEY ¶
type TKEY struct {
// The algorithm name is in the form of a domain name with the same
// meaning as in [RFC 2845]. The algorithm determines how the secret
// keying material agreed to using the TKEY RR is actually used to
// derive the algorithm specific key.
Algorithm string
// The inception time and expiration times are in number of seconds
// since the beginning of 1 January 1970 GMT ignoring leap seconds
// treated as modulo 2**32 using ring arithmetic [RFC 1982]. In
// messages between a DNS resolver and a DNS server where these fields
// are meaningful, they are either the requested validity interval for
// the keying material asked for or specify the validity interval of
// keying material provided.
//
// To avoid different interpretations of the inception and expiration
// times 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.
Inception time.Time
Expiration time.Time
// The mode field 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.
Mode TKEYMode
// The error code field is an extended RCODE.
Error TSIGRCODE
// The meaning of this data depends on the mode.
KeyData []byte
// The Other Data field is not used in this specification but may be
// used in future extensions.
OtherData []byte
}
TKEY represents TKEY RR RDATA [RFC2930]. TKEY RR can be used in a number of different modes to establish and delete such shared secret keys between a DNS resolver and server.
type TKEYMode ¶
type TKEYMode uint16
TKEYMode type is the type of the TKEY Mode field.
type TLSA ¶
type TLSA struct {
// A one-octet value, called "certificate usage" or just "usage",
// specifying the provided association that will be used to match the
// target certificate from the TLS handshake.
Usage TLSAUsage
// A one-octet value, called "selector", specifying which part of the
// TLS certificate presented by the server will be matched against the
// association data.
Selector TLSASelector
// A one-octet value, called "matching type", specifying how the
// certificate association is presented.
MatchingType TLSAMatchingType
// The "certificate association data" to be matched. This field
// contains the data to be matched. These bytes are either raw data
// (that is, the full certificate or its SubjectPublicKeyInfo,
// depending on the selector) for matching type 0, or the hash of the
// raw data for matching types 1 and 2. The data refers to the
// certificate in the association, not to the TLS ASN.1 Certificate
// object.
Certificate []byte
}
TLSA represents TLSA RR RDATA. TLSA (DANE WG) has experimantal status, see: http://tools.ietf.org/wg/dane/
From: http://tools.ietf.org/html/draft-ietf-dane-protocol-16
The TLSA DNS resource record (RR) is used to associate a certificate with the domain name where the record is found. The semantics of how the TLSA RR is interpreted are given later in this document.
type TLSAMatchingType ¶
type TLSAMatchingType byte
TLSAMatchingType is the type of the TLSA MatchingType field.
const ( TLSAMatchingTypeNoHash TLSAMatchingType = iota TLSAMatchingTypeSHA256 TLSAMatchingTypeSHA512 TLSAMatchingTypePrivateUse TLSAMatchingType = 255 )
Values of TLSAMatchingType
Value Short description Reference --------------------------------------------- 0 No hash used 1 SHA-256 NIST FIPS 180-3 2 SHA-512 NIST FIPS 180-3 3-254 Unassigned 255 Private use
type TLSASelector ¶
type TLSASelector byte
TLSASelector is the type of the TLSA Selector field.
const ( TLSASelectorFullCert TLSASelector = iota TLSASelectorSubjectPKInfo TLSASelectorPrivateUse TLSASelector = 255 )
Values of TLSASelector
Value Short description ----------------------------- 0 Full Certificate 1 SubjectPublicKeyInfo 2-254 Unassigned 255 Private use
type TLSAUsage ¶
type TLSAUsage byte
TLSAUsage is the type of the TLSA Usage field.
const ( TLSAUsagePKIX_CA TLSAUsage = iota TLSAUsagePKIX_EE TLSAUsagePKIX_CERT TLSAUsageMatchCert TLSAUsagePrivateUse TLSAUsage = 255 )
Values of TLSAUsage
Value Short description ------------------------------------------------ 0 Pass PKIX and chain through CA 1 Pass PKIX and match EE 2 Pass PKIX and trusted via certificate 3 Match certificate 4-254 Unassigned 255 Private use
type TSIG ¶
type TSIG struct {
AlgorithmName string // Name of the algorithm in domain name syntax.
TimeSigned time.Time
Fudge time.Duration // Permitted error in TimeSigned
MAC []byte // Defined by Algorithm Name.
OriginalID uint16 // Original message ID.
Error TSIGRCODE // Expanded RCODE covering TSIG processing.
OtherData []byte // Empty unless Error == BADTIME.
}
TSIG represents TSIG RR RDATA. TSIG RRs are dynamically computed to cover a particular DNS transaction and are not DNS RRs in the usual sense.
type TSIGRCODE ¶
type TSIGRCODE uint16
TSIGRCODE is the type of the TKEY/TSIG Error field. Values of TSIGRCODE <= 15 have the same meaning as the same numbered values of msg.RCODE.
type TXT ¶
type TXT struct {
S []string
}
TXT holds the TXT RData
type Tree ¶
Tree "subclasses" the dns.Tree methods for the RRs type.
func (*Tree) Add ¶
Add will add data to Tree. If the owner node has no data yet, the data will be simply inserted in that node. If the updater is not nil and the owner node already has some existing data then the value returned by updater(existing_data) is inserted into the owner node.
func (*Tree) Enum ¶
Enum enumerates all data in the tree starting at root and all of its childs. On every datum found the handler is invoked. If the handler returns false the tree traversing stops.
type Type ¶
type Type uint16
TYPE fields are used in resource records. Note that these types are a subset of msg.QTYPEs.
const ( TYPE_A Type // 1 a host address [RFC1035] TYPE_NS // 2 an authoritative name server [RFC1035] TYPE_MD // 3 a mail destination (Obsolete - use MX) [RFC1035] TYPE_MF // 4 a mail forwarder (Obsolete - use MX) [RFC1035] TYPE_CNAME // 5 the canonical name for an alias [RFC1035] TYPE_SOA // 6 marks the start of a zone of authority [RFC1035] TYPE_MB // 7 a mailbox domain name (EXPERIMENTAL) [RFC1035] TYPE_MG // 8 a mail group member (EXPERIMENTAL) [RFC1035] TYPE_MR // 9 a mail rename domain name (EXPERIMENTAL [RFC1035] TYPE_NULL // 10 a null RR (EXPERIMENTAL) [RFC1035] TYPE_WKS // 11 a well known service description [RFC1035] TYPE_PTR // 12 a domain name pointer [RFC1035] TYPE_HINFO // 13 host information [RFC1035] TYPE_MINFO // 14 mailbox or mail list information [RFC1035] TYPE_MX // 15 mail exchange [RFC1035] TYPE_TXT // 16 text strings [RFC1035] TYPE_RP // 17 for Responsible Person [RFC1183] TYPE_AFSDB // 18 for AFS Data Base location [RFC1183][RFC5864] TYPE_X25 // 19 for X.25 PSDN address [RFC1183] TYPE_ISDN // 20 for ISDN address [RFC1183] TYPE_RT // 21 for Route Through [RFC1183] TYPE_NSAP // 22 for NSAP address, NSAP style A record [RFC1706] TYPE_NSAP_PTR // 23 for domain name pointer, NSAP style [RFC1348] TYPE_SIG // 24 for security signature [RFC4034][RFC3755][RFC2535] TYPE_KEY // 25 for security key [RFC4034][RFC3755][RFC2535] TYPE_PX // 26 X.400 mail mapping information [RFC2163] TYPE_GPOS // 27 Geographical Position [RFC1712] TYPE_AAAA // 28 IP6 Address [RFC3596] TYPE_LOC // 29 Location Information [RFC1876] TYPE_NXT // 30 Next Domain - OBSOLETE [RFC3755][RFC2535] TYPE_EID // 31 Endpoint Identifier [Patton]* TYPE_NIMLOC // 32 Nimrod Locator [Patton]* TYPE_SRV // 33 Server Selection [RFC2782] TYPE_ATMA // 34 ATM Address [ATMDOC]* TYPE_NAPTR // 35 Naming Authority Pointer [RFC2915][RFC2168][RFC3403] TYPE_KX // 36 Key Exchanger [RFC2230] TYPE_CERT // 37 CERT [RFC4398] TYPE_A6 // 38 A6 (Experimental) [RFC3226][RFC2874]* TYPE_DNAME // 39 DNAME [RFC2672] TYPE_SINK // 40 SINK [Eastlake]* TYPE_OPT // 41 OPT [RFC2671] TYPE_APL // 42 APL (Experimental) [RFC3123]* TYPE_DS // 43 Delegation Signer [RFC4034][RFC3658] TYPE_SSHFP // 44 SSH Key Fingerprint [RFC4255] TYPE_IPSECKEY // 45 IPSECKEY [RFC4025] TYPE_RRSIG // 46 RRSIG [RFC4034][RFC3755] TYPE_NSEC // 47 NSEC [RFC4034][RFC3755] TYPE_DNSKEY // 48 DNSKEY [RFC4034][RFC3755] TYPE_DHCID // 49 DHCID [RFC4701] TYPE_NSEC3 // 50 NSEC3 [RFC5155] TYPE_NSEC3PARAM // 51 NSEC3PARAM [RFC5155] )
Type codes. Types marked with * next to reference are not supported.
const ( TYPE_HIP Type // 55 Host Identity Protocol [RFC5205] TYPE_NINFO // 56 NINFO [Reid]* TYPE_RKEY // 57 RKEY [Reid]* TYPE_TALINK // 58 Trust Anchor LINK [Wijngaards]* TYPE_CDS // 59 Child DS [Barwood]* )
const ( TYPE_SPF Type // 99 [RFC4408] TYPE_UINFO // 100 [IANA-Reserved]* TYPE_UID // 101 [IANA-Reserved]* TYPE_GID // 102 [IANA-Reserved]* TYPE_UNSPEC // 103 [IANA-Reserved]* )
const ( TYPE_TKEY Type // 249 Transaction Key [RFC2930] TYPE_TSIG // 250 Transaction Signature [RFC2845] TYPE_IXFR // 251 incremental transfer [RFC1995] TYPE_AXFR // 252 transfer of an entire zone [RFC1035][RFC5936] TYPE_MAILB // 253 mailbox-related RRs (MB, MG or MR) [RFC1035] TYPE_MAILA // 254 mail agent RRs (Obsolete - see MX) [RFC1035] )
const ( TYPE_URI Type // 256 URI [Faltstrom]* TYPE_CAA // 257 Certification Authority Authorization [Hallam-Baker]* )
const ( TYPE_TA Type // 32768 DNSSEC Trust Authorities [Weiler]* TYPE_DLV // 32769 DNSSEC Lookaside Validation [RFC4431] )
const ( TYPE_NODATA Type // Pseudo types in the "reserved for private use" area TYPE_NXDOMAIN )
func TypesDecode ¶
TypesDecode decodes RR Type bitmap bits (RFC 4034/4.1.2).
type URI ¶
type URI struct {
// The priority of the target URI in this RR. Its range is 0-65535. A
// client MUST attempt to contact the URI with the lowest-numbered
// priority it can reach; URIs with the same priority SHOULD be tried
// in the order defined by the weight field.
Priority uint16
// 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. The
// range of this number is 0-65535.
Weight uint16
// The URI of the target, enclosed in double-quote characters ('"').
// Resolution of the URI is according to the definitions for the Scheme
// of the URI.
//
// The URI is encoded as one or more <character-string> RFC1035 section
// 3.3 [RFC1035].
Target []string
}
URI represent URI RR RDATA.
From: http://tools.ietf.org/html/draft-lewis-dns-undocumented-types-01
2.8 URI (256) The URI RR type is last defined in draft-faltstrom-uri-06, which expired in April 2011. The draft is available on tools.ietf.org. The RDATA consists of two 16 bit fields called Priority and Weight and a series of text strings called the Target.
The URI resource record enables the querying party to select which ones of the NAPTR records one is interested in. This because data in the service field of the NAPTR record is included in the owner part of the URI resource record type.
Querying for URI resource records is not replacing querying for NAPTR resource records (or use of S-NAPTR [RFC3958]). Instead, the URI resource record type provides a complementary mechanism to use when one already knows what service field is interesting. With it, one can directly query for the specific subset of the otherwise possibly large RRSet given back when querying for NAPTR resource records.
type WKS ¶
type WKS struct {
Address net.IP
Protocol IP_Protocol
Ports map[IP_Port]struct{}
}
The WKS record is used to describe the well known services supported by a particular protocol on a particular internet address. The PROTOCOL field specifies an IP protocol number, and the bit map has one bit per port of the specified protocol. The first bit corresponds to port 0, the second to port 1, etc. If the bit map does not include a bit for a protocol of interest, that bit is assumed zero. The appropriate values and mnemonics for ports and protocols are specified in [RFC-1010].
For example, if PROTOCOL=TCP (6), the 26th bit corresponds to TCP port 25 (SMTP). If this bit is set, a SMTP server should be listening on TCP port 25; if zero, SMTP service is not supported on the specified address.
The purpose of WKS RRs is to provide availability information for servers for TCP and UDP. If a server supports both TCP and UDP, or has multiple Internet addresses, then multiple WKS RRs are used.
WKS RRs cause no additional section processing.
In master files, both ports and protocols are expressed using mnemonics or decimal numbers.
type X25 ¶
type X25 struct {
// <PSDN-address> is required in all X25 RRs.
//
// <PSDN-address> identifies the PSDN (Public Switched Data Network)
// address in the X.121 [10] numbering plan associated with <owner>.
// Its format in master files is a <character-string> syntactically
// identical to that used in TXT and HINFO.
PSDN string
}
X25 RData
Source Files