DNS Requirements
RFC 2119 requirements by RFC for DNS:
rfc1034
rfc1035
rfc1982
rfc1995
rfc1996
rfc2136
rfc2163
- Clients using PX records SHOULD ensure that routing and address translations are based only on authoritative answers
- Once DNS Security mechanisms [RFC 2065] become more widely deployed, clients SHOULD employ those mechanisms to verify the authenticity and integrity of PX records
rfc2181
- This memo does not use the oft used expressions MUST, SHOULD, MAY, or their negative forms
rfc2308
- Name servers authoritative for a zone MUST include the SOA record of the zone in the authority section of the response when reporting an NXDOMAIN or indicating that no data of the requested type exists
- If the containing zone is signed [RFC2065] the SOA and appropriate NXT and SIG records MUST be added
- This TTL decrements in a similar manner to a normal cached answer and upon reaching zero (0) indicates the cached negative answer MUST NOT be used again
- The NXT record, if it exists in the authority section of a negative answer received, MUST be stored such that it can be be located and returned with SOA record in the authority section, as should any SIG records in the authority section
- The NXT record MUST have the same owner name as the query name for NODATA responses
- Negative responses without SOA records SHOULD NOT be cached as there is no way to prevent the negative responses looping forever between a pair of servers even with a short TTL
- When a server, in answering a query, encounters a cached negative response it MUST add the cached SOA record to the authority section of the response with the TTL decremented by the amount of time it was stored in the cache
- If a NXT record was cached along with SOA record it MUST be added to the authority section
- If a SIG record was cached along with a NXT record it SHOULD be added to the authority section
- As with all answers coming from the cache, negative answers SHOULD have an implicit referral built into the answer
- In either case a resolver MAY cache a server failure response
- If it does so it MUST NOT cache it for longer than five (5) minutes, and it MUST be cached against the specific query tuple
- A server MAY cache a dead server indication
- If it does so it MUST NOT be deemed dead for longer than five (5) minutes
- The indication MUST be stored against query tuple unless there was a transport layer indication that the server does not exist, in which case it applies to all queries to that specific IP address
- Non-authoritative negative answers MAY be cached
- The SOA record from the authority section MUST be cached
rfc2536
rfc2539
- If "prime length" field is 1 or 2, then the "prime" field is actually an unsigned index into a table of 65,536 prime/generator pairs and the generator length SHOULD be zero
rfc2782
- The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY" used in this document are to be interpreted as specified in [BCP 14]
- Such specification MUST define the symbolic name to be used in the Service field of the SRV record as described below
- It also MUST include security considerations
- Service SRV records SHOULD NOT be used in the absence of such specification
- 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
- 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)
- The following algorithm SHOULD be used to order the SRV RRs of the same priority:
- 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)
- A SRV-cognizant client SHOULD use this procedure to locate a list of servers and connect to the preferred one:
- Port numbers SHOULD NOT be used in place of the symbolic service or protocol names (for the same reason why variant names cannot be allowed: Applications would have to do two or more lookups)
- A client MUST parse all of the RR's in the reply
- If the Additional Data section doesn't contain address records for all the SRV RR's and the client may want to connect to the target host(s) involved, the client MUST look up the address record(s)
rfc2845
- TSIG is a meta-RR and MUST not be cached
- Names and definitions of new algorithms MUST be registered with IANA
- If the TSIG record cannot be added without causing the message to be truncated, the server MUST alter the response so that a TSIG can be included
- The client SHOULD at this point retry the request using TCP (per [RFC1035 4.2.2])
- If an incoming message contains a TSIG record, it MUST be the last record in the additional section
- If a TSIG record is present in any other position, the packet is dropped and a response with RCODE 1 (FORMERR) MUST be returned
- If the algorithm name or key name is unknown to the recipient, or if the message digests do not match, the whole DNS message MUST be discarded
- If the message is a query, a response with RCODE 9 (NOTAUTH) MUST be sent back to the originator with TSIG ERROR 17 (BADKEY) or TSIG ERROR 16 (BADSIG)
- If no key is available to sign this message it MUST be sent unsigned (MAC size == 0 and empty MAC)
- A message to the system operations log SHOULD be generated, to warn the operations staff of a possible security incident in progress
- The client MUST store the message digest from the request while awaiting an answer
- Clients SHOULD only attempt signed transactions with servers who are known to support TSIG and share some secret key with the client -- so, this is not a problem in practice
- The server MUST not generate a signed response to an unsigned request
- When a server detects an error relating to the key or MAC, the server SHOULD send back an unsigned error message (MAC size == 0 and empty MAC)
- If an error is detected relating to the TSIG validity period, the server SHOULD send back a signed error message
- If the error is not a TSIG error the response MUST be generated as specified in [4.2]
- The TSIG MUST be included on the first and last DNS envelopes
- It is expensive to include it on every envelopes, but it MUST be placed on at least every 100'th envelope
- If a client TSIG verification fails, the client MUST close the connection
- If the client does not receive TSIG records frequently enough (as specified above) it SHOULD assume the connection has been hijacked and it SHOULD close the connection
- The client SHOULD treat this the same way as they would any other interrupted transfer (although the exact behavior is not specified)
- If one exists, the server is REQUIRED to return a TSIG RR in the response
- The server MUST perform the following checks in the following order, check KEY, check TIME values, check MAC
- If a non-forwarding server does not recognize the key used by the client, the server MUST generate an error response with RCODE 9 (NOTAUTH) and TSIG ERROR 17 (BADKEY)
- This response MUST be unsigned as specified in [4.3]
- The server SHOULD log the error
- If the server time is outside the time interval specified by the request (which is: Time Signed, plus/minus Fudge), the server MUST generate an error response with RCODE 9 (NOTAUTH) and TSIG ERROR 18 (BADTIME)
- The server SHOULD also cache the most recent time signed value in a message generated by a key, and SHOULD return BADTIME if a message received later has an earlier time signed value
- A response indicating a BADTIME error MUST be signed by the same key as the
- It MUST include the client's current time in the time signed field, the server's current time (a uint48t) in the other data field, and 6 in the other data length field
- The server SHOULD log the error
- If a TSIG fails to verify, the server MUST generate an error response as specified in [4.3] with RCODE 9 (NOTAUTH) and TSIG ERROR 16 (BADSIG)
- This response MUST be unsigned as specified in [4.3]
- The server SHOULD log the error
- If the TSIG does not validate, that response MUST be discarded, unless the RCODE is 9 (NOTAUTH), in which case the client SHOULD attempt to verify the response as if it were a TSIG Error response, as specified in [4.3]
- A message containing an unsigned TSIG record or a TSIG record which fails verification SHOULD not be considered an acceptable response; the client SHOULD log an error and continue to wait for a signed response until the request times out
- The client MAY retry the request using the key specified by the server
- This should never occur, as a server MUST NOT sign a response with a different key than signed the request
- In this case the client SHOULD log the event
- DNS resolvers MUST NOT adjust any clocks in the client based on BADTIME errors, but the server's time in the other data field SHOULD be logged
- If the response RCODE is 9 (NOTAUTH) and TSIG ERROR is 16 (BADSIG), this is a MAC error, and client MAY retry the request with a new request ID but it would be better to try a different shared key if one is available
- Client SHOULD keep track of how many MAC errors are associated with each key
- Clients SHOULD log this event
- A server acting as a forwarding server of a DNS message SHOULD check for the existence of a TSIG record
- If the name on the TSIG is not of a secret that the server shares with the originator the server MUST forward the message unchanged including the TSIG
- If the name of the TSIG is of a key this server shares with the originator, it MUST process the TSIG
- If the TSIG passes all checks, the forwarding server MUST, if possible, include a TSIG of his own, to the destination or the next forwarder
- If no transaction security is available to the destination and the response has the AD flag (see [RFC2535]), the forwarder MUST unset the AD flag before adding the TSIG to the answer
rfc2930
- NAME domain see description below TTYPE uint16t TKEY = 249 CLASS uint16t ignored, SHOULD be 255 (ANY) TTL uint32t ignored, SHOULD be zero RDLEN uint16t size of RDATA RDATA: Algorithm: domain Inception: uint32t Expiration: uint32t Mode: uint16t Error: uint16t Key Size: uint16t Key Data: octet-stream Other Size: uint16t Other Data: octet-stream undefined by this specification
- For a TKEY with a non-root name appearing in a query, the TKEY RR name SHOULD be a domain locally unique at the resolver, less than 128 octets long in wire encoding, and meaningful to the resolver to assist in distinguishing keys and/or key agreement sessions
- For TKEY(s) appearing in a response to a query, the TKEY RR name SHOULD be a globally unique server assigned domain
- If the key is generated as the result of a query with root as its owner name, then the server SHOULD create a globally unique domain name, to be the key name, by suffixing a pseudo-random [RFC 1750] label with a domain name of the server
- It SHOULD always be zero to be sure that older DNS implementations do not cache TKEY RRs
- 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
- 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
- The RDLEN field MUST equal the length of the RDATA section through the end of Other Data or the RR is to be considered malformed and rejected
- In the absence of willingness to provide such state, servers MUST return errors such as NOTIMP or REFUSED for an attempt to use TKEY and resolvers are free to ignore any TKEY RRs they receive
- There MUST NOT be more than one TKEY RR in a DNS query or response
- Except for GSS-API mode, TKEY responses MUST always have DNS transaction authentication to protect the integrity of any keying data, error codes, etc
- This authentication MUST use a previously established secret (TSIG) or public (SIG(0) [RFC 2931]) key and MUST NOT use any key that the response to be verified is itself providing
- TKEY queries MUST be authenticated for all modes except GSS-API and, under some circumstances, server assignment mode
- Query authentication SHOULD use an established secret (TSIG) key authenticator if available
- It MUST NOT use any key that the query is itself providing
- In the absence of required TKEY authentication, a NOTAUTH error MUST be returned
- To accomplish this, the keying material used in any TSIG or SIG(0) RR that authenticates a TKEY message MUST NOT have a lifetime of more then 2**31 - 1 seconds
- Such queries MUST be accompanied by a TKEY RR in the additional information section to indicate the mode in use and accompanied by other information where required
- Type TKEY queries SHOULD NOT be flagged as recursive and servers MAY ignore the recursive header bit in TKEY queries they receive
- If the TKEY error field is zero, the resolver supplied Diffie-Hellman KEY RR SHOULD be echoed in the additional information section and a server Diffie-Hellman KEY RR will also be present in the answer section of the response
- To avoid attempted reliance in requests on keys no longer in effect, servers MUST implement key deletion whereby the server "discards" a key on receipt from a resolver of an authenticated delete request for a TKEY RR with the key's name
- Key deletion TKEY queries MUST be authenticated
- This authentication MAY be a TSIG RR using the key to be deleted
- For querier assigned and Diffie-Hellman keys, the server MUST truly "discard" all active state associated with the key
- For server assigned keys, the server MAY simply mark the key as no longer retained by the client and may re-send it in response to a future query for server assigned keying material
- In addition, the GSS-API level provides its own authentication so that this mode of TKEY query and response MAY be, but do not need to be, authenticated with TSIG RR or SIG(0) RR [RFC 2931]
- It is RECOMMENDED that any "key data" provided in the query TKEY RR by the resolver be strongly mixed by the server with server generated randomness [RFC 1750] to derive the keying material to be used
- If the query is authenticated by the resolver with a TSIG RR [RFC 2845] or SIG(0) RR and that authentication is verified, then any SIG(KEY) provided in the query SHOULD be ignored
- The KEY RR in such a query SHOULD have a name that corresponds to the resolver but it is only essential that it be a public key for which the resolver has the corresponding private key so it can decrypt the response data
- The resolver KEY RR MUST be authenticated, through the authentication of this query with a TSIG or SIG(0) or the signing of the resolver KEY with a SIG(KEY)
- The keying material MUST be encrypted under a server key for protection in transmission as described in Section 6
- The name of the key and the keying data are completely controlled by the sending resolver so a globally unique key name SHOULD be used
- The KEY RR used MUST be one for which the server has the corresponding private key, or it will not be able to decrypt the keying material and will return a FORMERR
- This mode of query MUST be authenticated with a TSIG or SIG(0)
- This SHOULD only be done if the server knows the querier understands TKEY and has this option implemented
- Such a response SHOULD be authenticated
- For server assigned and Diffie-Hellman keys, the client MUST "discard" active state associated with the key
- For querier assigned keys, the querier MAY simply mark the key as no longer retained by the server and may re-send it in a future query specifying querier assigned keying material
- This KEY RR MUST be for a public key algorithm where the public and private keys can be used for encryption and the corresponding decryption which recovers the originally encrypted data
- The KEY RR SHOULD correspond to a name for the decrypting resolver/server such that the decrypting process has access to the corresponding private key to decrypt the data
rfc2931
- For these reasons, SIG(0)s SHOULD only be used on requests when necessary to authenticate that the requester has some required privilege or identity
- For other replies, whether they are authenticated by the server or required to be authenticated by the requester SHOULD be a local configuration option
- For all transaction SIG(0)s, the signer field MUST be a name of the originating host and there MUST be a KEY RR at that name with the public key corresponding to the private key used to calculate the
- The TTL fields SHOULD be zero and the CLASS field SHOULD be ANY
- To conserve space, the owner name SHOULD be root (a single zero octet)
- When SIG(0) authentication on a response is desired, that SIG RR MUST be considered the highest priority of any additional information for inclusion in the response
- If the SIG(0) RR cannot be added without causing the message to be truncated, the server MUST alter the response so that a SIG(0) can be included
- Support of SIG(0) for TCP is OPTIONAL
- For TKEY responses, it MUST be checked and the message rejected if the checks fail unless otherwise specified for the TKEY mode in use
- For all other responses, it MAY be checked and the message rejected if the checks fail
- data-RRs, depending on resolver policy.) If a resolver or server does not implement transaction and/or request SIGs, it MUST ignore them without error where they are optional and treat them as failing where they are required
rfc3007
- As specified in [RFC3008], the DNSSEC validation process performed by a resolver MUST NOT process any non-zone keys unless local policy dictates otherwise
- When performing secure dynamic update, all zone data modified in a signed zone MUST be signed by a relevant zone key
- Thus, host and user keys MAY be used to generate SIG(0) records to authenticate updates and MAY be used in the TKEY [RFC2930] process to generate TSIG shared secrets
- Updating [RFC2535], this field SHOULD be set to 0 in KEY records, and MUST be ignored
- TSIG or SIG(0) records MUST be included in all secure dynamic update messages
- If the message contains a TSIG generated by a dynamically configured shared secret, the principal is the same as the one that authenticated the TKEY process; if the TKEY process was unauthenticated, no information is known about the principal, and the associated TSIG shared secret MUST NOT be used for secure dynamic update
- SIG(0) signatures SHOULD NOT be generated by zone keys, since transactions are initiated by a host or user, not a zone
- DNSSEC SIG records (other than SIG(0)) MAY be included in an update message, but MUST NOT be used to authenticate the update request
- If an update fails because it is signed with an unauthorized key, the server MUST indicate failure by returning a message with RCODE REFUSED
- By default, a principal MUST NOT be permitted to make any changes to zone data; any permissions MUST be enabled though configuration
- Implementations SHOULD allow access control policies to use the principal as an authorization token, and MAY also allow policies to grant permission to a signed message regardless of principal
- Implementations SHOULD allow per-name access control, and SHOULD provide a concise representation of the principal's own name, its subdomains, and all names in the zone
- Additionally, a server SHOULD allow restricting updates by RR type, so that a principal could add, delete, or modify specific record types at certain names
- Implementations SHOULD allow per-type access control, and SHOULD provide concise representations of all types and all "user" types, where a user type is defined as one that does not affect the operation of DNS itself
- SOA and NS records SHOULD NOT be modified by normal users, since these types create or modify delegation points
- NXT records MUST NOT be created, modified, or deleted by dynamic update, as their update may cause instability in the protocol
- An authorized update request MAY include SIG records with each RRset
- Since SIG records (except SIG(0) records) MUST NOT be used for authentication of the update message, they are not required
- The server MAY examine SIG records and drop SIGs with a temporal validity period in the past
- If a principal is authorized to update SIG records and the update specifies the deletion of SIG records, the server MAY choose to override the authority and refuse the update
- If the updated zone is secured, the RRset affected by an update operation MUST, at the completion of the update, be signed in accordance with the zone's signing policy
- This will usually require one or more SIG records to be generated by one or more zone keys whose private components MUST be online [RFC3008]
- When the contents of an RRset are updated, the server MAY delete all associated SIG records, since they will no longer be valid
- If any changes are made, the server MUST, if necessary, generate a new SOA record and new NXT records, and sign these with the appropriate zone keys
rfc3110
- The generation of RSA/MD5 SIG RRs as described in RFC 2537 is NOT RECOMMENDED
- Note: KEY RRs for use with RSA/SHA1 DNS signatures MUST use this algorithm number (rather than the algorithm number specified in the obsoleted RFC 2537)
- The FF octet MUST be repeated the maximum number of times such that the value of the quantity being exponentiated is one octet shorter than the value of n
- The size of "n", including most and least significant bits (which will be 1) MUST be not less than 512 bits and not more than 4096 bits
- "n" and "e" SHOULD be chosen such that the public exponent is small
rfc3225
- The DO bit cleared (set to zero) indicates the resolver is unprepared to handle DNSSEC security RRs and those RRs MUST NOT be returned in the response (unless DNSSEC security RRs are explicitly queried for)
- The DO bit of the query MUST be copied in the response
- More explicitly, DNSSEC-aware nameservers MUST NOT insert SIG, KEY, or NXT RRs to authenticate a response as specified in [RFC2535] unless the DO bit was set on the request
- A recursive DNSSEC-aware server MUST set the DO bit on recursive requests, regardless of the status of the DO bit on the initiating resolver request
- If the initiating resolver request does not have the DO bit set, the recursive DNSSEC-aware server MUST remove DNSSEC security RRs before returning the data to the client, however cached data MUST NOT be modified
- In the event a server returns a NOTIMP, FORMERR or SERVFAIL response to a query that has the DO bit set, the resolver SHOULD NOT expect DNSSEC security RRs and SHOULD retry the query without EDNS0 in accordance with section 5.3 of [RFC2671]
- The absence of DNSSEC data in response to a query with the DO bit set MUST NOT be taken to mean no security information is available for that zone as the response may be forged or a non-forged response of an altered (DO bit cleared) query
rfc3226
- All RFC 2535 compliant servers and resolvers MUST support EDNS0 and advertise message size of at least 1220 octets, but SHOULD advertise message size of 4000
- All RFC 2874 compliant servers and resolver MUST support EDNS0 and advertise message size of at least 1024 octets, but SHOULD advertise message size of 2048
- All RFC 2535 and RFC 2874 compliant entities MUST be able to handle fragmented IPv4 and IPv6 UDP packets
- All hosts supporting both RFC 2535 and RFC 2874 MUST use the larger required value in EDNS0 advertisements
rfc3402
- An Application MUST NOT apply a Rule to the output of a previous Rule
- True sed-style substitution expressions are not appropriate for use in this application for a variety of reasons, therefore the contents of the regexp field MUST follow this grammar:
- The result of applying the substitution expression to the String MUST result in a key which obeys the rules of the Database (unless of course it is a Terminal Rule in which case the output follows the rules of the application)
- Since it is possible for the regular expression to be improperly specified, such that a non-conforming key can be constructed, client software SHOULD verify that the result is a legal database key before using it
- The "i" flag indicates that the ERE matching SHALL be performed in a case-insensitive fashion
- Furthermore, any backref replacements MAY be normalized to lower case when the "i" flag is given
- Since escaped occurrences of the delimiter character will be interpreted as occurrences of that character, digits MUST NOT be used as delimiters
- Specifically, since the expiration of a databases record could cause a new Rule to be retrieved that is inconsistent with previous Rules, while in the algorithm any attempts to optimize the process by falling back to previous keys and Rules MUST ensure that no previously retrieved Rule has expired
- If a Rule has expired then the application MUST start over at Step 1
- This specification MUST be clear as to what allowed character sets exist in order to know in which character set the Keys and Rules are encoded
rfc3403
- Substitution expressions MUST NOT be written where they depend on a specific POSIX locale since this would cause substitution expressions to loose their ability to be universally applicable
- In the case where an application attempts to fall back to previously retrieved sets of Rules (either in the case of a bad delegation path or some network or server failure) the application MUST ensure that none of the records it is relying on have expired
- ORDER 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
- 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
- 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
- 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
- Any value in this field MUST be a fully qualified domain-name
- 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
- DNS servers MAY add RRsets to the additional information section that are relevant to the answer and have the same authenticity as the data in the answer section
- Applications MAY inspect the Additional Information section for relevant records but Applications MUST NOT require that records of any type be in the Additional Information section of any DNS response in order for clients to function
- A client MUST process multiple NAPTR records in the order specified by the "order" field, it MUST NOT simply use the first record that provides a known Service Parameter combination
rfc3404
- This URI or URN MUST be canonicalized and hex encoded according to the "absolute-uri" production found in the Collected ABNF from RFC 2396 [15]
- The S, A, U and P flags are all mutually exclusive, and resolution libraries MAY signal an error if more than one is given
- (Experimental code and code for assisting in the creation of Rewrite Rules would be more likely to signal such an error than a client such as a browser.) It is anticipated that multiple flags will be allowed in the future, so implementers MUST NOT assume that the flags field can only contain 0 or 1 characters
- Finally, if a client encounters a record with an unknown flag, it MUST ignore it and move to the next Rule
- The protocol identifiers that are valid for the 'protocol' production MUST be defined by documents that are specific to URI resolution
- Keep in mind that in order for this to remain safe, the input to step 3 and the output of step 4 MUST be identical to the basic algorithm
- The client software MUST NOT attempt to do this optimization outside a specific set of Rewrite Rules (i.e., across delegation paths)
- DNS servers MAY interpret Flag values and use that information to include appropriate SRV and A records in the Additional Information portion of the DNS packet
- o If a record at a particular order matches the URI, but the client doesn't know the specified protocol and service, the client SHOULD continue to examine records that have the same order
- The client MUST NOT consider records with a higher value of order
rfc3425
- Therefore IQUERY is now obsolete, and name servers SHOULD return a "Not Implemented" error when an IQUERY request is received
rfc3492
- A decoder MUST recognize the letters in both uppercase and lowercase forms (including mixtures of both forms)
- An encoder SHOULD output only uppercase forms or only lowercase forms, unless it uses mixed- case annotation (see appendix A)
rfc3596
rfc3597
- To enable new RR types to be deployed without server changes, name servers and resolvers MUST handle RRs of unknown type transparently
- To ensure the correct operation of equality comparison (section 6) and of the DNSSEC canonical form (section 7) when an RR type is known to some but not all of the servers involved, servers MUST also exactly preserve the RDATA of RRs of known type, except for changes due to compression or decompression where allowed by section 4 of this memo
- In particular, the character case of domain names that are not subject to compression MUST be preserved
- To avoid such corruption, servers MUST NOT compress domain names embedded in the RDATA of types that are class-specific or not well- known
- Receiving servers MUST decompress domain names in RRs of well-known type, and SHOULD also decompress RRs of type RP, AFSDB, RT, SIG, PX, NXT, NAPTR, and SRV (although the current specification of the SRV RR in [RFC2782] prohibits compression, [RFC2052] mandated it, and some servers following that earlier specification are still in use)
- Future specifications for new RR types that contain domain names within their RDATA MUST NOT allow the use of name compression for those names, and SHOULD explicitly state that the embedded domain names MUST NOT be compressed
- An implementation MAY also choose to represent some RRs of known type using the above generic representations for the type, class and/or RDATA, which carries the benefit of making the resulting master file portable to servers where these types are unknown
- Even though an RR of known type represented in the # format is effectively treated as an unknown type for the purpose of parsing the RDATA text representation, all further processing by the server MUST treat it as a known type and take into account any applicable type- specific rules regarding compression, canonicalization, etc
- To ensure that the outcome of the comparison is identical whether the RR is known to the server or not, specifications for new RR types MUST NOT specify type-specific comparison rules
- Future RR type specifications MAY specify type-specific additional section processing rules, but any such processing MUST be optional as it can only be performed by servers for which the RR type in case is known
rfc3645
- For example, a client and server MAY use Kerberos [RFC1964] for one transaction, whereas that same server MAY use SPKM [RFC2025] with a different client
- Client and server MUST be locally authenticated and have acquired default credentials before using this protocol as specified in Section 1.1.1 "Credentials" in RFC 2743 [RFC2743]
- Specifically, Section 4.2 of RFC 2845 MUST be modified as follows:
- Replace: "The server MUST not generate a signed response to an unsigned request."
- With: "The server MUST not generate a signed response to an unsigned request, except in case of response to client's unsigned TKEY query if secret key is established on server side after server processed client's query
- Signing responses to unsigned TKEY queries MUST be explicitly specified in the description of an individual secret key establishment algorithm."
- The key_name is the owner name of the TKEY and TSIG records sent between a client and a server to indicate to each other which context MUST be used to process the current request
- DNS client and server MAY use various underlying security mechanisms to establish security context as described in sections 3 and 4
- At the same time, in order to guarantee interoperability between DNS clients and servers that support GSS-TSIG it is REQUIRED that security mechanism used by client enables use of Kerberos v5 (see Section 9 for more information)
- To obtain the first token to be sent to a server, a client MUST call GSSInitsec_context API
- The following input parameters MUST be used
- Client MAY instead specify some other valid handle to its credentials
- To guarantee interoperability of the implementations of the GSS-TSIG mechanism client MUST specify a valid underlying security mechanism that enables use of Kerberos v5 (see Section 9 for more information)
- Client MAY instead specify another upper bound for the lifetime of the context to be established in seconds
- then the client MUST abandon the algorithm and MUST NOT use the GSS- TSIG algorithm to establish this security context
- Next time when this client needs to establish security context, the client MAY use GSS-TSIG algorithm
- If returned majorstatus is GSSS_COMPLETE AND one or both of these values are FALSE, the client MUST abandon this algorithm
- Client's behavior MAY depend on other OUTPUT parameters according to the policy local to the client
- The owner name of the TKEY resource record set queried for and the owner name of the supplied TKEY resource record in the additional records section MUST be the same
- This name uniquely identifies the security context to both the client and server, and thus the client SHOULD use a value which is globally unique as described in [RFC2930]
- To achieve global uniqueness, the name MAY contain a UUID/GUID [ISO11578]
- The remaining fields in the TKEY RDATA, i.e., Inception, Expiration, Error, Other Size and Data Fields, MUST be set according to [RFC2930]
- Note: if the original client call to GSSInitseccontext returned any majorstatus other than GSSSCONTINUENEEDED or GSSS_COMPLETE, then the client MUST NOT send TKEY query
- Upon the reception of the TKEY query the DNS server MUST respond according to the description in Section 4
- The response MUST be signed with a TSIG record
- The signature in the TSIG record MUST be verified using the procedure detailed in section 5, Sending and Verifying Signed Messages
- In this case, the client MAY continue waiting for a response to its last TKEY query until the time period since the client sent last TKEY query expires
- If the DNS message error is not NO_ERROR or error field in the TKEY record is not 0 (i.e., no error), then the client MUST abandon this negotiation sequence
- The client MUST delete an active context by calling GSSDeleteseccontext providing the associated contexthandle
- The client MAY repeat the negotiation sequence starting with the uninitialized state as described in section 3.1
- To prevent infinite looping the number of attempts to establish a security context MUST be limited to ten or less
- If the DNS message error is NO_ERROR and the error field in the TKEY record is 0 (i.e., no error), then the client MUST pass a token specified in the Key Data field in the TKEY resource record to
- the client MUST take one of the following actions:
- the client MUST abandon this negotiation sequence
- This means that the client MUST delete an active context by calling GSSDeleteseccontext providing the associated contexthandle
- The client MAY repeat the negotiation sequence starting with the uninitialized state as described in section 3.1
- To prevent infinite looping the number of attempts to establish a security context MUST be limited to ten or less
- If OUTPUT majorstatus is GSSSCONTINUENEEDED OR GSSSCOMPLETE then client MUST act as described below
- If the response from the server was signed, and the OUTPUT majorstatus is GSSS_COMPLETE,then the signature in the TSIG record MUST be verified using the procedure detailed in section 5, Sending and Verifying Signed Messages
- If the signature is invalid, then the client MUST abandon this negotiation sequence
- This means that the client MUST delete an active context by calling GSSDeleteseccontext providing the associated contexthandle
- The client MAY repeat the negotiation sequence starting with the uninitialized state as described in section 3.1
- To prevent infinite looping the number of attempts to establish a security context MUST be limited to ten or less
- The token output_token MUST be passed to the server in a TKEY record by repeating the negotiation sequence beginning with section 3.1.2
- The client MUST place a limit on the number of continuations in a context negotiation to prevent endless looping
- Such limit SHOULD NOT exceed value of 10
- If majorstatus is GSSSCOMPLETE and outputtoken is non-NULL, the client-side component of the negotiation is complete but the token output_token MUST be passed to the server by repeating the negotiation sequence beginning with section 3.1.2
- When context negotiation is complete, the handle context_handle MUST be used for the generation and verification of transaction signatures
- When the client is not intended to continue using the established security context, the client SHOULD delete an active context by calling GSSDeleteseccontext providing the associated contexthandle, AND client SHOULD delete the established context on the DNS server by using TKEY RR with the Mode field set to 5, i.e., "key deletion" [RFC2930]
- A server MAY be managing several contexts with several clients
- A server MUST recognize TKEY queries as security context negotiation messages
- Upon receiving a query with QTYPE = TKEY, the server MUST examine whether the Mode and Algorithm Name fields of the TKEY record in the additional records section of the message contain values of 3 and gss-tsig, respectively
- If the name is found in the table and the security context for this name is established and not expired, then the server MUST respond to the query with BADNAME error in the TKEY error field
- The following input parameters MUST be used
- Server MAY instead specify some other valid handle to its credentials
- The server MUST respond to the client with a TKEY query response with RCODE = NOERROR, that contains a TKEY record in the answer section
- If OUTPUT majorstatus is set to GSSSCOMPLETE or GSSSCONTINUENEEDED then server MUST act as described below
- If output_token is non-NULL, then it MUST be returned to the client in a Key Data field of the RDATA in TKEY
- The message MUST be signed with a TSIG record as described in section 5, Sending and Verifying Signed Messages
- If majorstatus is GSSSCOMPLETE and outputtoken is NULL, then the TKEY record received from the client MUST be returned in the Answer section of the response
- The message MUST be signed with a TSIG record as described in section 5, Sending and Verifying Signed Messages
- The server MUST limit the number of times that a given context is allowed to repeat, to prevent endless looping
- Such limit SHOULD NOT exceed value of 10
- In all cases, except if majorstatus is GSSSCOMPLETE and outputtoken is NULL, other TKEY record fields MUST contain the following values:
- The remaining fields in the TKEY RDATA, i.e., Inception, Expiration, Error, Other Size and Data Fields, MUST be set according to [RFC2930]
- A server MAY unilaterally terminate a context at any time (see section 4.2.1)
- Server SHOULD limit the amount of memory used to cache established contexts
- The server MAY hint to the client that the context is being deleted by including a TKEY RR in a response with the Mode field set to 5, i.e., "key deletion" [RFC2930]
- The following input parameters MUST be used
- Caller MAY instead specify other valid value (for details see Section 1.2.4 in [RFC2743])
- If majorstatus is GSSSCONTEXTEXPIRED, GSSSCREDENTIALSEXPIRED or GSSS_FAILURE the caller MUST delete the security context, return to the uninitialized state and SHOULD negotiate a new security context, as described above in Section 3.1
- If majorstatus is GSSSNOCONTEXT, the caller MUST remove the entry for keyname from the (target name, keyname, contexthandle) mapping table, return to the uninitialized state and SHOULD negotiate a new security context, as described above in Section 3.1
- If majorstatus is GSSSBADQOP, the caller SHOULD repeat the GSS_GetMIC call with allowed QOP value
- The number of such repetitions MUST be limited to prevent infinite loops
- The NAME of the TSIG record determines which context_handle maps to the context that MUST be used to verify the signature
- If the NAME does not map to an established context, the server MUST send a standard TSIG error response to the client indicating BADKEY in the TSIG error field (as described in [RFC2845])
- Per [RFC2845], the timer values of the TSIG record MUST also be valid before considering the message to be authentic
- The caller MUST not act on the request or response in the message until these checks are verified
- When a server is processing a client request, the server MUST send a standard TSIG error response to the client indicating BADKEY in the TSIG error field as described in [RFC2845], if major_status is set to one of the following values
- If the timer values of the TSIG record are invalid, the message MUST NOT be considered authentic
- If this error checking fails when a server is processing a client request, the appropriate error response MUST be sent to the client according to [RFC2845]
- Since the majorstatus is set to GSSSCOMPLETE the client side security context is established, but since the outputtoken is not NULL client MUST send a TKEY query to the server as described below
- To support such flexibility, DNS clients and servers SHOULD specify SPNEGO mech_type in their GSS API calls
- In addition to these, GSS APIs used by DNS client and server MAY also support other underlying security mechanisms
rfc3646
- The DNS Recursive Name Server option provides a list of one or more IPv6 addresses of DNS recursive name servers to which a client's DNS resolver MAY send DNS queries [1]
- The list of domain names in the 'searchlist' MUST be encoded as specified in section "Representation and use of domain names" of RFC 3315
- The DNS Recursive Name Server option MUST NOT appear in any other than the following messages: Solicit, Advertise, Request, Renew, Rebind, Information-Request, and Reply
- The Domain Search List option MUST NOT appear in any other than the following messages: Solicit, Advertise, Request, Renew, Rebind, Information-Request, and Reply
- To avoid attacks through the DNS Recursive Name Server option, the DHCP client SHOULD require DHCP authentication (see section "Authentication of DHCP messages" in RFC 3315) before installing a list of DNS recursive name servers obtained through authenticated DHCP
- Hosts implementing the domain search option SHOULD also implement the searchlist recommendations of RFC1536, section 6
- Where DNS parameters such as the domain searchlist or DNS servers have been manually configured, these parameters SHOULD NOT be overridden by DHCP
- A host SHOULD require the use of DHCP authentication (see section "Authentication of DHCP messages" in RFC 3315) prior to accepting a domain search option
rfc4025
- Any CNAMEs or DNAMEs found MUST be followed
- An IPSECKEY resource record SHOULD be used in combination with DNSSEC [8] unless some other means of authenticating the IPSECKEY resource record is available
- The domain name MUST NOT be compressed
- Compression MUST NOT be used
- The precedence, gateway type, algorithm, and gateway fields are REQUIRED
- The base64 encoded public key block is OPTIONAL; if it is not present, the public key field of the resource record MUST be construed to be zero octets in length
- If no gateway is to be indicated, then the gateway type field MUST be zero, and the gateway field MUST be "."
- The IPSECKEY resource record contains information that SHOULD be communicated to the end client in an integral fashion; i.e., free from modification
- Any derivative specification that makes use of this resource record MUST carefully document its trust model and why the trust model of DNSSEC is appropriate, if that is the secure channel used
- If the end-to-end integrity of the IPSECKEY RR is suspect, the end client MUST restrict its use of the IPSECKEY RR to cases where the RR owner name matches the content of the gateway field
- Thus, any records obtained under unverified conditions (e.g., no DNSSEC or trusted path to source) that have a non-null gateway field MUST be ignored
- The IPSECKEY RR MUST be ignored whenever the resulting gateway does not match the QNAME of the original IPSECKEY RR query
rfc4033
rfc4034
- The DNSKEY RR is not intended as a record for storing arbitrary public keys and MUST NOT be used to store certificates or public keys that do not directly relate to the DNS infrastructure
- 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
- 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
- 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
- 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
- The Flag field MUST be represented as an unsigned decimal integer
- The Protocol Field MUST be represented as an unsigned decimal integer with a value of 3
- The Algorithm field MUST be represented either as an unsigned decimal integer or as an algorithm mnemonic as specified in Appendix A.1
- The Public Key field MUST be represented as a Base64 encoding of the Public Key
- The RRSIG RR MUST only be used to carry verification material (digital signatures) used to secure DNS operations
- A RRSIG and NSEC (see Section 4) MUST exist for the same name as a CNAME resource record in a signed zone
- An RRSIG RR MUST have the same class as the RRset it covers
- The TTL value of an RRSIG RR MUST match the TTL value of the RRset it covers
- The value of the Labels field MUST NOT count either the null (root) label that terminates the owner name or the wildcard label (if present)
- The value of the Labels field MUST be less than or equal to the number of labels in the RRSIG owner name
- The RRSIG record MUST NOT be used for authentication prior to the inception date and MUST NOT be used for authentication after the expiration date
- Because of this, all comparisons involving these fields MUST use "Serial number arithmetic", as defined in [RFC1982]
- The Signer's Name field MUST contain the name of the zone of the covered RRset
- A sender MUST NOT use DNS name compression on the Signer's Name field when transmitting a RRSIG RR
- Each RR MUST have the same owner name as the RRSIG RR;
- Each RR MUST have the same class as the RRSIG RR;
- Each RR in the RRset MUST have the RR type listed in the RRSIG RR's Type Covered field;
- Each RR in the RRset MUST have the TTL listed in the RRSIG Original TTL Field;
- Any DNS names in the RDATA field of each RR MUST be in canonical form; and
- The RRset MUST be sorted in canonical order
- When the mnemonic is not known, the TYPE representation as described in [RFC3597], Section 5, MUST be used
- The Algorithm field value MUST be represented either as an unsigned decimal integer or as an algorithm mnemonic, as specified in Appendix A.1
- The Labels field value MUST be represented as an unsigned decimal integer
- The Original TTL field value MUST be represented as an unsigned decimal integer
- The Signature Expiration Time and Inception Time field values MUST be represented either as an unsigned decimal integer indicating seconds since 1 January 1970 00:00:00 UTC, or in the form YYYYMMDDHHmmSS in UTC, where:
- The Key Tag field MUST be represented as an unsigned decimal integer
- The Signer's Name field value MUST be represented as a domain name
- An RRSIG (see Section 3) and NSEC MUST exist for the same name as does a CNAME resource record in a signed zone
- The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL field
- 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
- Bits representing pseudo-types MUST be clear, as they do not appear in zone data
- If encountered, they MUST be ignored upon being read
- Blocks with no types present MUST NOT be included
- Trailing zero octets in the bitmap MUST be omitted
- Trailing zero octets not specified MUST be interpreted as zero octets
- Bits corresponding to the delegation NS RRset and the RR types for which the parent zone has authoritative data MUST be set; bits corresponding to any non-NS RRset for which the parent is not authoritative MUST be clear
- A zone MUST NOT include an NSEC RR for any domain name that only holds glue records
- When the mnemonic is not known, the TYPE representation described in [RFC3597], Section 5, MUST be used
- The DNSKEY RR referred to in the DS RR MUST be a DNSSEC zone key
- The DNSKEY RR Flags MUST have Flags bit 7 set
- If the DNSKEY flags do not indicate a DNSSEC zone key, the DS RR (and the DNSKEY RR it references) MUST NOT be used in the validation process
- The Key Tag field MUST be represented as an unsigned decimal integer
- The Algorithm field MUST be represented either as an unsigned decimal integer or as an algorithm mnemonic specified in Appendix A.1
- The Digest Type field MUST be represented as an unsigned decimal integer
- The Digest MUST be represented as a sequence of case-insensitive hexadecimal digits
- Therefore, if an implementation detects duplicate RRs when putting the RRset in canonical form, it MUST treat this as a protocol error
- If the implementation chooses to handle this protocol error in the spirit of the robustness principle (being liberal in what it accepts), it MUST remove all but one of the duplicate RR(s) for the purposes of calculating the canonical form of the RRset
- The table of algorithms in Appendix A and the key tag calculation algorithms in Appendix B include the RSA/MD5 algorithm for completeness, but the RSA/MD5 algorithm is NOT RECOMMENDED, as explained in [RFC3110]
- A DNSSEC aware resolver or name server MUST implement all MANDATORY algorithms
- 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
- The public key area in the DNSKEY RR and the signature area in the RRSIG RR begin with a wire encoded domain name, which MUST NOT be compressed
- Implementations MUST NOT assume that the key tag uniquely identifies a DNSKEY RR
- It is not necessary to use the following reference code verbatim, but the numerical value of the Key Tag MUST be identical to what the reference implementation would generate for the same input
- Key Tags MUST be calculated using the algorithm described here rather than the ones complement checksum
- Please note that Algorithm 1 is NOT RECOMMENDED
rfc4035
- For each private key used to create RRSIG RRs in a zone, the zone SHOULD include a zone DNSKEY RR containing the corresponding public key
- A zone key DNSKEY RR MUST have the Zone Key bit of the flags RDATA field set (see Section 2.1.1 of [RFC4034])
- Public keys associated with other DNS operations MAY be stored in DNSKEY RRs that are not marked as zone keys but MUST NOT be used to verify RRSIGs
- If the zone administrator intends a signed zone to be usable other than as an island of security, the zone apex MUST contain at least one DNSKEY RR to act as a secure entry point into the zone
- For each authoritative RRset in a signed zone, there MUST be at least one RRSIG record that meets the following requirements:
- An RRset MAY have multiple RRSIG RRs associated with it
- An RRSIG RR itself MUST NOT be signed, as signing an RRSIG RR would add no value and would create an infinite loop in the signing process
- The NS RRset that appears at the zone apex name MUST be signed, but the NS RRsets that appear at delegation points (that is, the NS RRsets in the parent zone that delegate the name to the child zone's name servers) MUST NOT be signed
- Glue address RRsets associated with delegations MUST NOT be signed
- There MUST be an RRSIG for each RRset using at least one DNSKEY of each algorithm in the zone apex DNSKEY RRset
- The apex DNSKEY RRset itself MUST be signed by each algorithm appearing in the DS RRset located at the delegating parent (if any)
- Each owner name in the zone that has authoritative data or a delegation point NS RRset MUST have an NSEC resource record
- The TTL value for any NSEC RR SHOULD be the same as the minimum TTL value field in the zone SOA RR
- An NSEC record (and its associated RRSIG RRset) MUST NOT be the only RRset at any particular owner name
- That is, the signing process MUST NOT create NSEC or RRSIG RRs for owner name nodes that were not the owner name of any RRset before the zone was signed
- The type bitmap of every NSEC resource record in a signed zone MUST indicate the presence of both the NSEC record itself and its corresponding RRSIG record
- Bits corresponding to the delegation NS RRset and any RRsets for which the parent zone has authoritative data MUST be set; bits corresponding to any non-NS RRset for which the parent is not authoritative MUST be clear
- A DS RRset SHOULD be present at a delegation point when the child zone is signed
- The DS RRset MAY contain multiple records, each referencing a public key in the child zone used to verify the RRSIGs in that zone
- All DS RRsets in a zone MUST be signed, and DS RRsets MUST NOT appear at a zone's apex
- A DS RR SHOULD point to a DNSKEY RR that is present in the child's apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed by the corresponding private key
- The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset (that is, the NS RRset from the same zone containing the DS RRset)
- If a CNAME RRset is present at a name in a signed zone, appropriate RRSIG and NSEC RRsets are REQUIRED at that name
- Other types MUST NOT be present at that name
- At the parental side of a zone cut (that is, at a delegation point), NSEC RRs are REQUIRED at the owner name
- A security-aware name server MUST support the EDNS0 ([RFC2671]) message size extension, MUST support a message size of at least 1220 octets, and SHOULD support a message size of 4000 octets
- As IPv6 packets can only be fragmented by the source host, a security aware name server SHOULD take steps to ensure that UDP datagrams it transmits over IPv6 are fragmented, if necessary, at the minimum IPv6 MTU, unless the path MTU is known
- A security-aware name server that receives a DNS query that does not include the EDNS OPT pseudo-RR or that has the DO bit clear MUST treat the RRSIG, DNSKEY, and NSEC RRs as it would any other RRset and MUST NOT perform any of the additional processing described below
- As long as the response is always consistent for each query to the name server, the name server MAY return one of the following:
- The CD bit is controlled by resolvers; a security-aware name server MUST copy the CD bit from a query into the corresponding response
- The AD bit is controlled by name servers; a security-aware name server MUST ignore the setting of the AD bit in queries
- A security aware name server that synthesizes CNAME RRs from DNAME RRs as described in [RFC2672] SHOULD NOT generate signatures for the synthesized CNAME RRs
- Upon receiving a relevant query that has the EDNS ([RFC2671]) OPT pseudo-RR DO bit ([RFC3225]) set, a security-aware authoritative name server for a signed zone MUST include additional RRSIG, NSEC, and DS RRs, according to the following rules:
- o RRSIG RRs that can be used to authenticate a response MUST be included in the response according to the rules in Section 3.1.1
- o NSEC RRs that can be used to provide authenticated denial of existence MUST be included in the response automatically according to the rules in Section 3.1.3
- o Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST be included in referrals automatically according to the rules in Section 3.1.4
- When responding to a query that has the DO bit set, a security-aware authoritative name server SHOULD attempt to send RRSIG RRs that a security-aware resolver can use to authenticate the RRsets in the response
- A name server SHOULD make every attempt to keep the RRset and its associated RRSIG(s) together in a response
- o When placing a signed RRset in the Answer section, the name server MUST also place its RRSIG RRs in the Answer section
- If space does not permit inclusion of these RRSIG RRs, the name server MUST set the TC bit
- o When placing a signed RRset in the Authority section, the name server MUST also place its RRSIG RRs in the Authority section
- If space does not permit inclusion of these RRSIG RRs, the name server MUST set the TC bit
- o When placing a signed RRset in the Additional section, the name server MUST also place its RRSIG RRs in the Additional section
- If space does not permit inclusion of both the RRset and its associated RRSIG RRs, the name server MAY retain the RRset while dropping the RRSIG RRs
- If this happens, the name server MUST NOT set the TC bit solely because these RRSIG RRs didn't fit
- When responding to a query that has the DO bit set and that requests the SOA or NS RRs at the apex of a signed zone, a security-aware authoritative name server for that zone MAY return the zone apex DNSKEY RRset in the Additional section
- The name server SHOULD NOT include the DNSKEY RRset unless there is enough space in the response message for both the DNSKEY RRset and its associated RRSIG RR(s)
- If there is not enough space to include these DNSKEY and RRSIG RRs, the name server MUST omit them and MUST NOT set the TC bit solely because these RRs didn't fit (see Section 3.1.1)
- When responding to a query that has the DO bit set, a security-aware authoritative name server for a signed zone MUST include NSEC RRs in each of the following cases:
- If the zone contains RRsets matching but contains no RRset matching , then the name server MUST include the NSEC RR for along with its associated RRSIG RR(s) in the Authority section of the response (see Section 3.1.1)
- If space does not permit inclusion of the NSEC RR or its associated RRSIG RR(s), the name server MUST set the TC bit (see Section 3.1.1)
- If the zone does not contain any RRsets matching either exactly or via wildcard name expansion, then the name server MUST include the following NSEC RRs in the Authority section, along with their associated RRSIG RRs:
- If it does, the name server SHOULD only include the NSEC RR and its RRSIG RR(s) once in the Authority section
- If space does not permit inclusion of these NSEC and RRSIG RRs, the name server MUST set the TC bit (see Section 3.1.1)
- If the zone does not contain any RRsets that exactly match but does contain an RRset that matches via wildcard name expansion, the name server MUST include the
- wildcard-expanded answer and the corresponding wildcard-expanded RRSIG RRs in the Answer section and MUST include in the Authority section an NSEC RR and associated RRSIG RR(s) proving that the zone does not contain a closer match for
- If space does not permit inclusion of the answer, NSEC and RRSIG RRs, the name server MUST set the TC bit (see Section 3.1.1)
- The name server MUST include the following NSEC RRs in the Authority section, along with their associated RRSIG RRs:
- If it does, the name server SHOULD only include the NSEC RR and its RRSIG RR(s) once in the Authority section
- If space does not permit inclusion of these NSEC and RRSIG RRs, the name server MUST set the TC bit (see Section 3.1.1)
- If a DS RRset is present at the delegation point, the name server MUST return both the DS RRset and its associated RRSIG RR(s) in the Authority section along with the NS RRset
- If no DS RRset is present at the delegation point, the name server MUST return both the NSEC RR that proves that the DS RRset is not present and the NSEC RR's associated RRSIG RR(s) along with the NS RRset
- The name server MUST place the NS RRset before the NSEC RRset and its associated RRSIG RR(s)
- If space does not permit inclusion of the DS or NSEC RRset and associated RRSIG RRs, the name server MUST set the TC bit (see Section 3.1.1)
- In this case, the name server MUST return an authoritative "no data" response showing that the DS RRset does not exist in the child zone's apex
- However, an authoritative name server MAY choose to reject the entire zone transfer if the zone fails to meet any of the signing requirements described in Section 2
- chooses to perform its own zone validation MUST NOT selectively reject some RRs and accept others
- As with any other authoritative RRset, the DS RRset MUST be included in zone transfers of the zone in which the RRset is authoritative data
- As with any other authoritative RRs, NSEC RRs MUST be included in zone transfers of the zone in which they are authoritative data
- The parental NSEC RR at a zone cut MUST be included in zone transfers of the parent zone, and the NSEC at the zone apex of the child zone MUST be included in zone transfers of the child zone
- As with any other authoritative RRs, RRSIG RRs MUST be included in zone transfers of the zone in which they are authoritative data
- A security-aware name server SHOULD clear the CD bit when composing an authoritative response
- A security-aware name server MUST NOT set the AD bit in a response unless the name server considers all RRsets in the Answer and Authority sections of the response to be authentic
- A security-aware name server's local policy MAY consider data from an authoritative zone to be authentic without further validation
- However, the name server MUST NOT do so unless the name server obtained the authoritative zone via secure means (such as a secure zone transfer mechanism) and MUST NOT do so unless this behavior has been configured explicitly
- A security-aware name server that supports recursion MUST follow the rules for the CD and AD bits given in Section 3.2 when generating a response that involves data obtained via recursion
- The resolver side of a security-aware recursive name server MUST set the DO bit when sending requests, regardless of the state of the DO bit in the initiating request received by the name server side
- If the DO bit in an initiating query is not set, the name server side MUST strip any authenticating DNSSEC RRs from the response but MUST NOT strip any DNSSEC RR types that the initiating query explicitly requested
- The name server side MUST copy the setting of the CD bit from a query to the corresponding response
- The name server side of a security-aware recursive name server MUST pass the state of the CD bit to the resolver side along with the rest
- When the CD bit is set, the recursive name server SHOULD, if possible, return the requested data to the originating resolver, even if the recursive name server's local authentication policy would reject the records in question
- If the CD bit is set, the name server side SHOULD return the data from the BAD cache; if the CD bit is not set, the name server side MUST return RCODE 2 (server failure)
- The name server side of a security-aware recursive name server MUST NOT set the AD bit in a response unless the name server considers all RRsets in the Answer and Authority sections of the response to be authentic
- The name server side SHOULD set the AD bit if and only if the resolver side considers all RRsets in the Answer section and any relevant negative response RRs in the Authority section to be authentic
- The resolver side MUST follow the procedure described in Section 5 to determine whether the RRs in question are authentic
- However, for backward compatibility, a recursive name server MAY set the AD bit when a response includes unsigned CNAME RRs if those CNAME
- A security-aware resolver MUST include an EDNS ([RFC2671]) OPT pseudo-RR with the DO ([RFC3225]) bit set when sending queries
- A security-aware resolver MUST support a message size of at least 1220 octets, SHOULD support a message size of 4000 octets, and MUST use the "sender's UDP payload size" field in the EDNS OPT pseudo-RR to advertise the message size that it is willing to accept
- A security-aware resolver's IP layer MUST handle fragmented UDP packets correctly regardless of whether any such fragmented packets were received via IPv4 or IPv6
- A security-aware resolver MUST support the signature verification mechanisms described in Section 5 and SHOULD apply them to every received response, except when:
- A security-aware resolver's support for signature verification MUST include support for verification of wildcard owner names
- Security-aware resolvers MAY query for missing security RRs in an attempt to perform validation; implementations that choose to do so must be aware that the answers received may not be sufficient to validate the original response
- When attempting to retrieve missing NSEC RRs that reside on the parental side at a zone cut, a security-aware iterative-mode resolver MUST query the name servers for the parent zone, not the child zone
- When attempting to retrieve a missing DS, a security-aware iterative-mode resolver MUST query the name servers for the parent zone, not the child zone
- A security-aware resolver MUST be able to determine whether it should expect a particular RRset to be signed
- A security-aware resolver MUST be capable of being configured with at least one trusted public key or DS RR and SHOULD be capable of being configured with multiple trusted public keys or DS RRs
- Since a security-aware resolver will not be able to validate signatures without such a configured trust anchor, the resolver SHOULD have some reasonably robust mechanism for obtaining such keys when it boots; examples of such a mechanism would be some form of non-volatile storage (such as a disk drive) or some form of trusted local network configuration mechanism
- A security-aware resolver SHOULD cache each response as a single atomic entry containing the entire answer, including the named RRset and any associated DNSSEC RRs
- The resolver SHOULD discard the entire atomic entry when any of the RRs contained in it expire
- A security-aware resolver MAY set a query's CD bit in order to indicate that the resolver takes responsibility for performing whatever authentication its local policy requires on the RRsets in the response
- A security-aware resolver MUST clear the AD bit when composing query messages to protect against buggy name servers that blindly copy header bits that they do not understand from the query message to the response message
- A resolver MUST disregard the meaning of the CD and AD bits in a response unless the response was obtained by using a secure channel or the resolver was specifically configured to regard the message header bits without using a secure channel
- To prevent such unnecessary DNS traffic, security-aware resolvers MAY cache data with invalid signatures, with some restrictions
- Resolvers that implement a BAD cache MUST take steps to prevent the cache from being useful as a denial-of-service attack amplifier, particularly the following:
- o Since RRsets that fail to validate do not have trustworthy TTLs, the implementation MUST assign a TTL
- This TTL SHOULD be small, in order to mitigate the effect of caching the results of an attack
- o In order to prevent caching of a transient validation failure (which might be the result of an attack), resolvers SHOULD track queries that result in validation failures and SHOULD only answer from the BAD cache after the number of times that responses to queries for that particular have failed to validate exceeds a threshold value
- Resolvers MUST NOT return RRsets from the BAD cache unless the resolver is not required to validate the signatures of the RRsets in question under the rules given in Section 4.2 of this document
- A validating security-aware resolver MUST treat the signature of a valid signed DNAME RR as also covering unsigned CNAME RRs that could have been synthesized from the DNAME RR, as described in [RFC2672], at least to the extent of not rejecting a response message solely because it contains such CNAME RRs
- The resolver MAY retain such CNAME RRs in its cache or in the answers it hands back, but is not required to do so
- A security-aware stub resolver MUST support the DNSSEC RR types, at least to the extent of not mishandling responses just because they contain DNSSEC RRs
- A non-validating security-aware stub resolver MAY include the DNSSEC RRs returned by a security-aware recursive name server as part of the data that the stub resolver hands back to the application that invoked it, but is not required to do so
- A validating security-aware stub resolver MUST set the DO bit, because otherwise it will not receive the DNSSEC RRs it needs to perform signature validation
- A non-validating security-aware stub resolver SHOULD NOT set the CD bit when sending queries unless it is requested by the application layer, as by definition, a non-validating stub resolver depends on the security-aware recursive name server to perform validation on its behalf
- A validating security-aware stub resolver SHOULD set the CD bit, because otherwise the security-aware recursive name server will answer the query using the name server's local policy, which may prevent the stub resolver from receiving data that would be acceptable to the stub resolver's local policy
- A non-validating security-aware stub resolver MAY chose to examine the setting of the AD bit in response messages that it receives in order to determine whether the security-aware recursive name server that sent the response claims to have cryptographically verified the data in the Answer and Authority sections of the response message
- In any case, a security-aware stub resolver MUST NOT place any reliance on signature validation allegedly performed on its behalf, except when the security-aware stub resolver obtained the data in question from a trusted security-aware recursive name server via a secure channel
- A validating security-aware stub resolver SHOULD NOT examine the setting of the AD bit in response messages, as, by definition, the stub resolver performs its own signature validation regardless of the setting of the AD bit
- To authenticate an apex DNSKEY RRset by using an initial key, the resolver MUST:
- The absence of DNSSEC data in a response MUST NOT by itself be taken as an indication that no authentication information exists
- A resolver SHOULD expect authentication information from signed zones
- A resolver SHOULD believe that a zone is signed if the resolver has been configured with public key information for the zone, or if the zone's parent is signed and the delegation from the parent contains a DS RRset
- If a validator cannot obtain such a key, it SHOULD switch to operating as if the zones in the island of security are unsigned
- A security-aware resolver MUST query the name servers for the parent zone for the DS RRset if the referral includes neither a DS RRset nor a NSEC RRset proving that the DS RRset does not exist (see Section 4)
- If the resolver has an initial DNSKEY or DS RR that belongs to the child zone or to any delegation below the child zone, this initial DNSKEY or DS RR MAY be used to re-establish an authentication path
- A security-aware resolver MUST use the parent NSEC RR when attempting to prove that a DS RRset does not exist
- In this case, the resolver SHOULD treat the child zone as if it were unsigned
- o The RRSIG RR and the RRset MUST have the same owner name and the same class
- o The RRSIG RR's Signer's Name field MUST be the name of the zone that contains the RRset
- o The RRSIG RR's Type Covered field MUST equal the RRset's type
- o The number of labels in the RRset owner name MUST be greater than or equal to the value in the RRSIG RR's Labels field
- o The validator's notion of the current time MUST be less than or equal to the time listed in the RRSIG RR's Expiration field
- o The validator's notion of the current time MUST be greater than or equal to the time listed in the RRSIG RR's Inception field
- o The RRSIG RR's Signer's Name, Algorithm, and Key Tag fields MUST match the owner name, algorithm, and key tag for some DNSKEY RR in the zone's apex DNSKEY RRset
- o The matching DNSKEY RR MUST be present in the zone's apex DNSKEY RRset, and MUST have the Zone Flag bit (DNSKEY RDATA Flag bit 7) set
- In this case, the validator cannot predetermine which DNSKEY RR to use to authenticate the signature, and it MUST try each matching DNSKEY RR until either the signature is validated or the validator has run out of matching public keys to try
- if rrsiglabels > fqdnlabels the RRSIG RR did not pass the necessary validation checks and MUST NOT be used to authenticate this RRset
- When reconstructing the original NSEC RRset for the delegation from the parent zone, the NSEC RRs MUST NOT be combined with NSEC RRs from the child zone
- When reconstructing the original NSEC RRset for the apex of the child zone, the NSEC RRs MUST NOT be combined with NSEC RRs from the parent zone
- The resolver MUST verify that wildcard expansion was applied properly before considering the RRset to be authentic
- If the resolver accepts the RRset as authentic, the validator MUST set the TTL of the RRSIG RR and each RR in the authenticated RRset to a value no greater than the minimum of:
- In addition, security-aware resolvers MUST authenticate the NSEC RRsets that comprise the non-existence proof as described in Section 5.3
- If the complete set of necessary NSEC RRsets is not present in a response (perhaps due to message truncation), then a security-aware resolver MUST resend the query in order to attempt to obtain the full collection of NSEC RRs necessary to verify the non-existence of the requested RRset
- As with all DNS operations, however, the resolver MUST bound the work it puts into answering any particular query
- Since a validated NSEC RR proves the existence of both itself and its corresponding RRSIG RR, a validator MUST ignore the settings of the NSEC and RRSIG bits in an NSEC RR
- If for whatever reason none of the RRSIGs can be validated, the response SHOULD be considered BAD
- If the validation was being done to service a recursive query, the name server MUST return RCODE 2 to the originating client
- However, it MUST return the full response if and only if the original query had the CD bit set
rfc4255
- Upon connection to an SSH server, the SSH client MAY look up the SSHFP resource record(s) for the host it is connecting to
- If the algorithm and fingerprint of the key received from the SSH server match the algorithm and fingerprint of one of the SSHFP resource record(s) returned from DNS, the client MAY accept the identity of the server
- Client implementors SHOULD provide a configurable policy used to select the order of methods used to verify a host key
- In this scenario, the implementation SHOULD verify the host key against a local database before verifying the key via the fingerprint returned from DNS
- The public key algorithm and the SSHFP algorithm number MUST match
- A message digest of the public key, using the message digest algorithm specified in the SSHFP fingerprint type, MUST match the SSHFP fingerprint
- A public key verified using this method MUST NOT be trusted if the SSHFP resource record (RR) used for verification was not authenticated by a trusted SIG RR
- Clients that do validate the DNSSEC signatures themselves SHOULD use standard DNSSEC validation procedures
- Clients that do not validate the DNSSEC signatures themselves MUST use a secure transport (e.g., TSIG [9], SIG(0) [10], or IPsec [8]) between themselves and the entity performing the signature validation
rfc4343
- That is to say, a lookup string octet with a value in the inclusive range from 0x41 to 0x5A, the uppercase ASCII letters, MUST match the identical value and also match the corresponding value in the inclusive range from 0x61 to 0x7A, the lowercase ASCII letters
- A lookup string octet with a lowercase ASCII letter value MUST similarly match the identical value and also match the corresponding value in the uppercase ASCII letter range
- While ASCII label comparisons are case insensitive, [STD13] says case MUST be preserved on output and preserved when convenient on input
- For example, if an "A" record is the first resource record stored under owner name "xyz.BAR.example" and then a second "A" record is stored under "XYZ.BAR.example", the second MAY be stored with the first (lower case initial label) name, the second MAY override the first so that only an uppercase initial label is retained, or both capitalizations MAY be kept in the DNS stored data
rfc4398
- 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
- If it is not, the algorithm field MUST be zero and the tag field is meaningless and SHOULD be zero
- The data is binary and MUST NOT be encoded into an ASCII armor
- An implementation SHOULD process transferable public keys as described in Section 10.1 of [5], but it MAY handle additional OpenPGP packets
- These types MUST be used when the content is too large to fit in the CERT RR and MAY be used at the implementer's discretion
- They SHOULD NOT be used where the DNS message is 512 octets or smaller and could thus be expected to fit a UDP packet
- The certificate portion of the CERT RR MUST begin with a null-terminated URI [10], 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
- X.509 certificates that conform to the IETF PKIX profile SHOULD be indicated by the PKIX type, not the OID private type
- Implementations SHOULD use the purpose-based owner name guidelines described in this document and MAY use CNAME RRs at content-based owner names (or other names), pointing to the purpose-based owner name
- This means that each CERT RR MUST NOT contain more than 64kb of payload, even if the corresponding certificate or certificate revocation list is larger
rfc4470
- The generated NSEC record's type bitmap MUST have the RRSIG and NSEC bits set and SHOULD NOT have any other bits set
- If an existing name is used as the NSEC owner name, that name's real NSEC record MUST be returned
- Like every authoritative record in the zone, each generated NSEC record MUST have corresponding RRSIGs generated using each algorithm (but not necessarily each DNSKEY) in the zone's DNSKEY RRset, as described in RFC 4035 [3] Section 2.2
rfc4501
- dnsqueryelement = ( "CLASS=" dnsclassval ) / ( "TYPE=" dnstypeval ) ; Each clause MUST NOT be used more ; than once
- A dnsquery element MUST NOT contain more than one occurrence of the "CLASS" and "TYPE" fields
- The digit representation of types and classes MAY be used when a mnemonic for the corresponding value is not well known (e.g., for newly introduced types or classes), but it SHOULD NOT be used for the types or classes defined in the DNS specification [2]
- All implementations MUST recognize the mnemonics defined in [2]
- A client MAY want to check that it understands the dnsclassval and dnstypeval before sending a query, so that it will be able to understand the response
rfc4509
- In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC2119]
- The results of the digest algorithm MUST NOT be truncated, and the entire 32 byte digest result is to be published in the DS record
- Implementations MUST support the use of the SHA-256 algorithm in DS RRs
- Validator implementations SHOULD ignore DS RRs containing SHA-1 digests if DS RRs with SHA-256 digests are present in the DS RRset
rfc4592
rfc4635
- Implementations that support TSIG MUST also implement HMAC SHA1 and HMAC SHA256 and MAY implement gss-tsig and the other algorithms listed below
- SHA-1 truncated to 96 bits (12 octets) SHOULD be implemented
- This case MUST NOT be generated and, if received, MUST cause the packet to be dropped and RCODE 1 (FORMERR) to be returned
- With the exception of certain TSIG error messages described in RFC 2845, Section 3.2, where it is permitted that the MAC size be zero, this case MUST NOT be generated and, if received, MUST cause the packet to be dropped and RCODE 1 (FORMERR) to be returned
- Local policies MAY require the rejection of TSIGs, even though they use an algorithm for which implementation is mandatory
- When a local policy permits acceptance of a TSIG with a particular algorithm and a particular non-zero amount of truncation, it SHOULD also permit the use of that algorithm with lesser truncation (a longer MAC) up to the full HMAC output
- Regardless of a lower acceptable truncated MAC length specified by local policy, a reply SHOULD be sent with a MAC at least as long as that in the corresponding request, unless the request specified a MAC length longer than the HMAC output
- Implementations permitting multiple acceptable algorithms and/or truncations SHOULD permit this list to be ordered by presumed strength and SHOULD allow different truncations for the same algorithm to be treated as separate entities in this list
- When so implemented, policies SHOULD accept a presumed stronger algorithm and truncation than the minimum strength required by the policy
- If a TSIG is received with truncation that is permitted under Section 3 above but the MAC is too short for the local policy in force, an RCODE of 22 (BADTRUNC) MUST be returned
rfc4701
- When the updater is using the Client's DUID (either from a DHCPv6 Client Identifier option or from a portion of the DHCPv4 Client Identifier option encoded as specified in [6]), the first two octets of the DHCID RR MUST be 0x0002, in network byte order
- The rest of the DHCID RR MUST contain the results of computing the SHA-256 hash across the octets of the DUID followed by the FQDN
- When the updater is using the DHCPv4 Client Identifier option sent by the client in its DHCPREQUEST message, the first two octets of the DHCID RR MUST be 0x0001, in network byte order
- The rest of the DHCID RR MUST contain the results of computing the SHA-256 hash across the data octets (i.e., the Type and Client-Identifier fields) of the option, followed by the FQDN
- When the updater is using the client's link-layer address as the identifier, the first two octets of the DHCID RDATA MUST be zero
- This RR MUST NOT be used for any purpose other than that detailed in [1]
- If an updater discovers DHCID RRs whose RDATA does not match the client identity that they have computed, the updater SHOULD conclude that a different client is currently associated with the name in question
- The updater SHOULD then proceed according to the site's administrative policy
- Both DHCP clients and servers SHOULD use some form of update authentication (e.g., [12]) when performing DNS updates
rfc4955
- In this case, the resolver SHOULD treat the child zone as if it were unsigned
- Although this behavior isn't strictly mandatory (as marked by MUST), it is unlikely for a validator to implement a substantially different behavior
- Because we are talking about experiments, it is RECOMMENDED that private algorithm numbers be used (see RFC 4034 [3], Appendix A.1.1
- It is RECOMMENDED that for a particular DNSSEC experiment, a particular domain name base is chosen for all new algorithms, then the algorithm number (or name) is prepended to it
- The DNSSEC experiment MUST define the particular set of (previously unknown) algorithm identifiers that identify the experiment and define what each unknown algorithm identifier means
- This DNS name SHOULD be under the control of the authors of the experiment
- Alternately, the experiment MAY use the Object Identifier (OID) private algorithm space instead (using algorithm number 254), or MAY choose non-private algorithm numbers, although this would require an IANA allocation
- Resolvers MUST only recognize the experiment's semantics when present in a zone signed by one or more of these algorithm identifiers
- This general methodology MAY be used for non-backwards compatible DNSSEC protocol changes that start out as or become standards
- o The protocol change SHOULD use public IANA allocated algorithm identifiers instead of private algorithm identifiers
- o Resolvers MAY recognize the protocol change in zones not signed (or not solely signed) using the new algorithm identifiers
rfc5001
- The resolver MUST NOT include any NSID payload data in the query message
- The name server MUST ignore any NSID payload data that might be present in the query message
- A name server MUST NOT send an NSID option back to a resolver which did not request it
- User interfaces MUST read and write the contents of the NSID option as a sequence of hexadecimal digits, two digits per payload octet
- Any comparison between NSID payloads MUST be a comparison of the raw binary data
- Copy operations MUST NOT assume that the raw NSID payload is null- terminated
rfc5011
- Once the resolver sees the REVOKE bit, it MUST NOT use this key as a trust anchor or for any other purpose except to validate the RRSIG it signed over the DNSKEY RRSet specifically for the purpose of validating the revocation
- The resolver MUST NOT treat the new key as a trust anchor until the hold-down time expires AND it has retrieved and validated a DNSKEY RRSet after the hold-down time that contains the new key
- N.B.: Once the resolver has accepted a key as a trust anchor, the key MUST be considered a valid trust anchor by that resolver until explicitly revoked as described above
- A resolver that has been configured for an automatic update of keys from a particular trust point MUST query that trust point (e.g., do a lookup for the DNSKEY RRSet and related RRSIG records) no less often than the lesser of 15 days, half the original TTL for the DNSKEY RRSet, or half the RRSIG expiration interval and no more often than once per hour
- If the query fails, the resolver MUST repeat the query until satisfied no more often than once an hour and no less often than the lesser of 1 day, 10% of the original TTL, or 10% of the original expiration interval
- This ensures that at least two validated DNSKEY RRSets that contain the new key MUST be seen by the resolver prior to the key's acceptance
- A compliant resolver MUST be able to manage at least five SEP keys per trust point
- If this bit is set to '1', AND the resolver sees an RRSIG(DNSKEY) signed by the associated key, then the resolver MUST consider this key permanently invalid for all purposes except for validating the revocation
- If the RRSet is seen and is validated (i.e., verifies against an existing trust anchor), this key MUST be in the RRSet, otherwise a 'KeyRem' event is triggered
- Once in this state, this key MUST permanently be considered invalid as a trust anchor
- A key in the removed state MUST NOT be considered a valid trust anchor
- Alternately, a trust point that is subordinate to another configured trust point MAY be deleted by a resolver after 180 days, where such a
- The resolver owner (and resolver implementers) MAY choose to permit or prevent key status updates based on this mechanism for specific trust points
rfc5155
- Zones signed according to this specification MUST only use these algorithm identifiers for their DNSKEY RRs
- Security aware resolvers that are aware of this specification MUST recognize the new algorithm identifiers and treat them as equivalent to the algorithms that they alias
- The class MUST be the same as the class of the original owner name
- The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL field
- Since bit 0 in window block 0 refers to the non-existing RR type 0, it MUST be set to 0
- After verification, the validator MUST ignore the value of bit 0 in window block 0
- Bits representing Meta-TYPEs or QTYPEs as specified in Section 3.1 of [RFC2929] or within the range reserved for assignment only to QTYPEs and Meta-TYPEs MUST be set to 0, since they do not appear in zone data
- Blocks with no types present MUST NOT be included
- Trailing zero octets in the bitmap MUST be omitted
- Trailing octets not specified MUST be interpreted as zero octets
- When the mnemonic is not known, the TYPE representation as described in Section 5 of [RFC3597] MUST be used
- If an NSEC3PARAM RR is present at the apex of a zone with a Flags field value of zero, then there MUST be an NSEC3 RR using the same hash algorithm, iterations, and salt parameters present at every hashed owner name in the zone
- That is, the zone MUST contain a complete set of NSEC3 RRs with the same hash algorithm, iterations, and salt parameters
- The class MUST be the same as the NSEC3 RRs to which this RR refers
- NSEC3PARAM RRs with a Flags field value other than zero MUST be ignored
- An Opt-Out NSEC3 RR MAY have the same original owner name as an insecure delegation
- Zones using Opt-Out MAY contain a mixture of Opt-Out NSEC3 RRs and non-Opt-Out NSEC3 RRs
- If an NSEC3 RR is not Opt-Out, there MUST NOT be any hashed owner names of insecure delegations (nor any other RRs) between it and the name indicated by the next hashed owner name in the NSEC3 RDATA
- If it is Opt-Out, it MUST only cover hashed owner names or hashed "next closer" names of insecure delegations
- o Each owner name within the zone that owns authoritative RRSets MUST have a corresponding NSEC3 RR
- Owner names that correspond to unsigned delegations MAY have a corresponding NSEC3 RR
- However, if there is not a corresponding NSEC3 RR, there MUST be an Opt-Out NSEC3 RR that covers the "next closer" name to the delegation
- o Each empty non-terminal MUST have a corresponding NSEC3 RR, unless the empty non-terminal is only derived from an insecure delegation covered by an Opt-Out NSEC3 RR
- o The TTL value for any NSEC3 RR SHOULD be the same as the minimum TTL value field in the zone SOA RR
- o The Type Bit Maps field of every NSEC3 RR in a signed zone MUST indicate the presence of all types present at the original owner name, except for the types solely contributed by an NSEC3 RR itself
- If Opt-Out is being used, owner names of unsigned delegations MAY be excluded
- When returning responses containing multiple NSEC3 RRs, all of the NSEC3 RRs MUST use the same hash algorithm, iteration, and salt values
- The Flags field value MUST be either zero or one
- To prove the nonexistence of QNAME, a closest encloser proof and an NSEC3 RR covering the (nonexistent) wildcard RR at the closest encloser MUST be included in the response
- The server MUST include the NSEC3 RR that matches QNAME
- This NSEC3 RR MUST NOT have the bits corresponding to either the QTYPE or CNAME set in its Type Bit Maps field
- If there is an NSEC3 RR that matches QNAME, the server MUST return it in the response
- The bits corresponding with DS and CNAME MUST NOT be set in the Type Bit Maps field of this NSEC3 RR
- If no NSEC3 RR matches QNAME, the server MUST return a closest provable encloser proof for QNAME
- The NSEC3 RR that covers the "next closer" name MUST have the Opt-Out bit set (note that this is true by definition -- if the Opt-Out bit is not set, something has gone wrong)
- If a server is authoritative for both sides of a zone cut at QNAME, the server MUST return the proof from the parent side of the zone cut
- If there is a wildcard match for QNAME, but QTYPE is not present at that name, the response MUST include a closest encloser proof for QNAME and MUST include the NSEC3 RR that matches the wildcard
- Note that the closest encloser to QNAME MUST be the immediate ancestor of the wildcard RR (if this is not the case, then something has gone wrong)
- To this end, the NSEC3 RR that covers the "next closer" name of the immediate ancestor of the wildcard MUST be returned
- If there is an NSEC3 RR that matches the delegation name, then that NSEC3 RR MUST be included in the response
- The DS bit in the type bit maps of the NSEC3 RR MUST NOT be set
- In this case, the closest provable encloser proof MUST be included in the response
- The included NSEC3 RR that covers the "next closer" name for the delegation MUST have the Opt-Out flag set to one
- then the response MUST be constructed as a Name Error response (Section 7.2.2)
- In this case, the server MUST return a response with an RCODE of 2 (server failure)
- Such zones SHOULD be rejected when loading
- Servers SHOULD respond with RCODE=2 (server failure) responses when handling queries that would fall under such zones
- Adding and removing names in a zone MUST account for the creation or removal of empty non-terminals
- o When removing a name with a corresponding NSEC3 RR, any NSEC3 RRs corresponding to empty non-terminals created by that name MUST be removed
- o When adding a name that requires adding an NSEC3 RR, NSEC3 RRs MUST also be added for any empty non-terminals that are created
- o When adding a delegation RRSet, if the "next closer" name of the delegation is covered by an existing Opt-Out NSEC3 RR, then the delegation MAY be added without modifying the NSEC3 RRs in the zone
- Servers SHOULD follow this set of basic rules to resolve the ambiguity
- A validator MUST ignore NSEC3 RRs with unknown hash types
- A validator MUST ignore NSEC3 RRs with a Flag fields value other than zero or one
- A validator MAY treat a response as bogus if the response contains NSEC3 RRs that contain different values for hash algorithm, iterations, or salt from each other for that zone
- In order to verify a closest encloser proof, the validator MUST find the longest name, X, such that
- Once the closest encloser has been discovered, the validator MUST check that the NSEC3 RR that has the closest encloser as the original owner name is from the proper zone
- A validator MUST verify that there is a closest encloser proof for QNAME present in the response and that there is an NSEC3 RR that covers the wildcard at the closest encloser (i.e., the name formed by prepending the asterisk label to the closest encloser)
- The validator MUST verify that an NSEC3 RR that matches QNAME is present and that both the QTYPE and the CNAME type are not set in its Type Bit Maps field
- If there is an NSEC3 RR that matches QNAME present in the response, then that NSEC3 RR MUST NOT have the bits corresponding to DS and CNAME set in its Type Bit Maps field
- If there is no such NSEC3 RR, then the validator MUST verify that a closest provable encloser proof for QNAME is present in the response, and that the NSEC3 RR that covers the "next closer" name has the Opt- Out bit set
- The validator MUST verify a closest encloser proof for QNAME and MUST find an NSEC3 RR present in the response that matches the wildcard name generated by prepending the asterisk label to the closest encloser
- Furthermore, the bits corresponding to both QTYPE and CNAME MUST NOT be set in the wildcard matching NSEC3 RR
- Validators MUST verify that there is an NSEC3 RR that covers the "next closer" name to QNAME present in the response
- If there is an NSEC3 RR present in the response that matches the delegation name, then the validator MUST ensure that the NS bit is set and that the DS bit is not set in the Type Bit Maps field of the NSEC3 RR
- The validator MUST also ensure that the NSEC3 RR is from the correct (i.e., parent) zone
- If there is no NSEC3 RR present that matches the delegation name, then the validator MUST verify a closest provable encloser proof for the delegation name
- The validator MUST verify that the Opt-Out bit is set in the NSEC3 RR that covers the "next closer" name to the delegation name
- Caching resolvers MUST be able to retrieve the appropriate NSEC3 RRs when returning responses that contain them
- The AD bit, as defined by [RFC4035], MUST NOT be set when returning a response containing a closest (provable) encloser proof in which the NSEC3 RR that covers the "next closer" name has the Opt-Out bit set
- If a DNAME RR is present at node N, there MUST be no data at any descendant of N
- A zone owner MUST NOT use a value higher than shown in the table below for iterations for the given key size
- A resolver MAY treat a response with a higher value as insecure, after the validator has verified that the signature over the NSEC3 RR is correct
- Therefore the values in the table MUST be used independent of the key algorithm
- However, the end result MUST be that all DS RRs in the parent use the specified algorithm aliases
- If adding incrementally, then the last RRSet added MUST be the NSEC3PARAM RRSet
- When specifying a new hash algorithm for use with NSEC3, a transition mechanism MUST also be defined
- The salt SHOULD be at least 64 bits long and unpredictable, so that an attacker cannot anticipate the value of the salt and compute the next set of dictionaries before the zone is published
- When specifying a new hash algorithm for use with NSEC3, a transition mechanism MUST also be defined
- Therefore, it is strongly RECOMMENDED that Opt-Out be used sparingly
- In particular, zone signing tools SHOULD NOT default to using Opt- Out, and MAY choose to not support Opt-Out at all
- There MUST be at least one complete set of NSEC3 RRs for the zone using the same salt value
- The salt SHOULD be changed periodically to prevent pre-computation using a single salt
- It is RECOMMENDED that the salt be changed for every re-signing
- However, in order for authoritative servers to be able to consistently find covering NSEC3 RRs, the authoritative server MUST choose a single set of parameters (algorithm, salt, and iterations) to use when selecting NSEC3 RRs
- In the (academic) case of a collision occurring, an alternative salt MUST be chosen and all hash values MUST be regenerated
rfc5321
- In many situations and configurations, the less- capable clients discussed above SHOULD be using the message submission protocol (RFC 4409 [18]) rather than SMTP
- In either case, once the server has issued a success response at the end of the mail data, a formal handoff of responsibility for the message occurs: the protocol requires that a server MUST accept responsibility for either delivering the message or properly reporting the failure to do so (see Sections 6.1, 6.2, and 7.8, below)
- Contemporary SMTP implementations MUST support the basic extension mechanisms
- For instance, servers MUST support the EHLO command even if they do not implement any specific extensions and clients SHOULD preferentially utilize EHLO rather than HELO
- (However, for compatibility with older conforming implementations, SMTP clients and servers MUST support the original HELO mechanisms as a fallback.) Unless the different characteristics of HELO must be identified for interoperability purposes, this document discusses only EHLO
- Keywords beginning with "X" MUST NOT be used in a registered service extension
- Conversely, keyword values presented in the EHLO response that do not begin with "X" MUST correspond to a Standard, Standards-Track, or IESG-approved Experimental SMTP service extension registered with IANA
- A conforming server MUST NOT offer non-"X"-prefixed keyword values that are not described in a registered extension
- In particular, if an extension implies that the delivery path normally supports special features of that extension, and an intermediate SMTP system finds a next hop that does not support the required extension, it MAY choose, based on the specific extension and circumstances, to requeue the message and try later and/or try an alternate MX host
- If this strategy is employed, the timeout to fall back to an unextended format (if one is available) SHOULD be less than the normal timeout for bouncing as undeliverable (e.g., if normal timeout is three days, the requeue timeout before attempting to transmit the mail without the extension might be one day)
- Hosts are known by names (see the next section); they SHOULD NOT be identified by numerical addresses, i.e., by address literals as described in Section 4.1.2
- Local aliases MUST NOT appear in any SMTP transaction
- Local nicknames or unqualified names MUST NOT be used
- o The domain name given in the EHLO command MUST be either a primary host name (a domain name that resolves to an address RR) or, if the host has no name, an address literal, as described in Section 4.1.3 and discussed further in the EHLO discussion of Section 4.1.4
- o The reserved mailbox name "postmaster" may be used in a RCPT command without domain qualification (see Section 4.1.1.3) and MUST be accepted if so used
- Conforming implementations MUST NOT recognize or generate any other character or character sequence as a line terminator
- Limits MAY be imposed on line lengths by servers (see Section 4)
- SMTP client implementations MUST NOT transmit these characters except when they are intended as line terminators and then MUST, as indicated above, transmit them only as a sequence
- optimize transport by modifying them, the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address
- That is, a command verb, an argument value other than a mailbox local-part, and free form text MAY be encoded in upper case, lower case, or any mixture of upper and lower case with no impact on its meaning
- The local-part of a mailbox MUST BE treated as case sensitive
- Therefore, SMTP implementations MUST take care to preserve the case of mailbox local-parts
- Implementations MAY wish to employ this encoding to accommodate those servers
- An originating SMTP client that has not successfully negotiated an appropriate extension with a particular server (see the next paragraph) MUST NOT transmit messages with information in the high-order bit of octets
- If such messages are transmitted in violation of this rule, receiving SMTP servers MAY clear the high- order bit or reject the message as invalid
- In general, a relay SMTP SHOULD assume that the message content it has received is valid and, assuming that the envelope permits doing so, relay it without inspecting that content
- Delivery SMTP systems MAY reject such messages, or return them as undeliverable, rather than deliver them
- Receiving systems SHOULD reject such commands, normally using "500 syntax error - invalid character" replies
- 8-bit message content transmission MAY be requested of the server by a client using extended SMTP facilities, notably the "8BITMIME" extension, RFC 1652 [22]
- 8BITMIME SHOULD be supported by SMTP servers
- However, it MUST NOT be construed as authorization to transmit unrestricted 8-bit material, nor does 8BITMIME authorize transmission of any envelope material in other than ASCII
- 8BITMIME MUST NOT be requested by senders for material with the high bit on that is not in MIME format with an appropriate content-transfer encoding; servers MAY reject such messages
- SMTP server implementations MAY include identification of their software and version information in the connection greeting reply after the 220 code, a practice that permits more efficient isolation and repair of any problems
- Implementations MAY make provision for SMTP servers to disable the software and version announcement where it causes security concerns
- The SMTP protocol allows a server to formally reject a mail session while still allowing the initial connection as follows: a 554 response MAY be given in the initial connection opening message instead of the 220
- A server taking this approach MUST still wait for the client to send a QUIT (see Section 4.1.1.10) before closing the connection and SHOULD respond to any intervening commands with "503 bad sequence of commands"
- Since an attempt to make an SMTP connection to such a system is probably in error, a server returning a 554 response on connection opening SHOULD provide enough information in the reply text to facilitate debugging of the sending system
- Older SMTP systems that are unable to support service extensions, and contemporary clients that do not require service extensions in the mail session being initiated, MAY use HELO instead of EHLO
- Servers MUST NOT return the extended EHLO- style response to a HELO command
- For a particular connection attempt, if the server returns a "command not recognized" response to EHLO, the client SHOULD be able to fall back and send HELO
- If the mailbox specification is not acceptable for some reason, the server MUST return a reply indicating whether the failure is permanent (i.e., will occur again if the client tries to send the same address again) or temporary (i.e., the address might be accepted if the client tries again later)
- In those cases, the server MAY reasonably accept the reverse-path (with a 250 reply) and then report problems after the forward-paths are received and examined
- Historically, the was permitted to contain more than just a mailbox; however, contemporary systems SHOULD NOT use source routing (see Appendix C)
- Historically, the was permitted to contain a source routing list of hosts and the destination mailbox; however, contemporary SMTP clients SHOULD NOT utilize source routes (see Appendix C)
- Servers MUST be prepared to encounter a list of source routes in the forward-path, but they SHOULD ignore the routes or MAY decline to support the relaying they imply
- Similarly, servers MAY decline to accept mail that is destined for other hosts or systems
- Consequently, restricted- capability clients MUST NOT assume that any SMTP server on the Internet can be used as their mail processing (relaying) site
- If a RCPT command appears without a previous MAIL command, the server MUST return a 503 "Bad sequence of commands" response
- If there was no MAIL, or no RCPT, command, or all such commands were rejected, the server MAY return a "command out of sequence" (503) or "no valid recipients" (554) reply in response to the DATA command
- If one of those replies (or any other 5yz reply) is received, the client MUST NOT send the message data; more generally, message data MUST NOT be sent unless a 354 reply is received
- These servers SHOULD treat a failure for one or more recipients as a "subsequent failure" and return a mail message as discussed in Section 6 and, in particular, in Section 6.1
- Server SMTP systems SHOULD NOT reject messages based on perceived defects in the RFC 822 or MIME (RFC 2045 [21]) message header section or message body
- In particular, they MUST NOT reject messages in which the numbers of Resent-header fields do not match or Resent-to appears without Resent-from and/or Resent-date
- Mail transaction commands MUST be used in the order discussed above
- o Servers MAY forward messages when they are aware of an address change
- When they do so, they MAY either provide address-updating information with a 251 code, or may forward "silently" and return a 250 code
- However, if a 251 code is used, they MUST NOT assume that the client will actually update address information or even return that information to the user
- o Servers MAY reject messages or return them as non-deliverable when they cannot be delivered precisely as addressed
- When they do so, they MAY either provide address-updating information with a 551 code, or may reject the message as undeliverable with a 550 code and no address-specific information
- However, if a 551 code is used, they MUST NOT assume that the client will actually update address information or even return that information to the user
- SMTP server implementations that support the 251 and/or 551 reply codes SHOULD provide configuration mechanisms so that sites that conclude that they would undesirably disclose information can disable or restrict their use
- Implementations SHOULD support VRFY and EXPN (however, see Section 3.5.2 and Section 7.3)
- If a normal (i.e., 250) response is returned, the response MAY include the full name of the user and MUST include the mailbox of the user
- It MUST be in either of the following forms:
- When a name that is the argument to VRFY could identify more than one mailbox, the server MAY either note the ambiguity or identify the alternatives
- For the EXPN command, the string identifies a mailing list, and the successful (i.e., 250) multiline response MAY include the full name of the users and MUST give the mailboxes on the mailing list
- If a request is made to apply VRFY to a mailing list, a positive response MAY be given if a message so addressed would be delivered to everyone on the list, otherwise an error SHOULD be reported (e.g., "550 That is a mailing list, not a user" or "252 Unable to verify members of mailing list")
- If a request is made to expand a user name, the server MAY return a
- positive response consisting of a list containing one name, or an error MAY be reported (e.g., "550 That is a user name, not a mailing list")
- An implementation of the VRFY or EXPN commands MUST include at least recognition of local mailboxes as "user names"
- However, since current Internet practice often results in a single host handling mail for multiple domains, hosts, especially hosts that provide this functionality, SHOULD accept the "local-part@domain" form as a "user name"; hosts MAY also choose to recognize other strings as "user names"
- Similarly, historical variations in what is returned by these commands are such that the response SHOULD be interpreted very carefully, if at all, and SHOULD generally only be used for diagnostic purposes
- When normal (2yz or 551) responses are returned from a VRFY or EXPN request, the reply MUST include the name using a "" construction, where "domain" is a fully- qualified domain name
- In circumstances exceptional enough to justify violating the intent of this specification, free-form text MAY be returned
- and people, addresses SHOULD appear in pointed brackets
- When addresses, rather than free-form debugging information, are returned, EXPN and VRFY MUST return only valid domain addresses that are usable in SMTP RCPT commands
- Consequently, if an address implies delivery to a program or other system, the mailbox name used to reach that target MUST be given
- Paths (explicit source routes) MUST NOT be returned by VRFY or EXPN
- Server implementations SHOULD support both VRFY and EXPN
- For security reasons, implementations MAY provide local installations a way to disable either or both of these commands through configuration options or the equivalent (see Section 7.3)
- Since they were both optional in RFC 821, but VRFY was made mandatory in RFC 1123 [3], if EXPN is supported, it MUST be listed as a service extension in an EHLO response
- VRFY MAY be listed as a convenience but, since support for it is required, SMTP clients are not required to check for its presence on the extension list before using it
- A server MUST NOT return a 250 code in response to a VRFY or EXPN command unless it has actually verified the address
- In particular, a server MUST NOT return 250 if all it has done is to verify that the syntax given is valid
- In that case, 502 (Command not implemented) or 500 (Syntax error, command unrecognized) SHOULD be returned
- In these situations, reply code 252 SHOULD be returned
- Implementations generally SHOULD be more aggressive about address verification in the case of VRFY than in the case of RCPT, even if it takes a little longer to do so
- The propagation of aliasing systems with mail on the Internet for hosts (typically with MX and CNAME DNS records), for mailboxes (various types of local host aliases), and in various proxying arrangements has made it nearly impossible for these strategies to work consistently, and mail systems SHOULD NOT attempt them
- SMTP clients SHOULD NOT generate explicit source routes except under unusual circumstances
- SMTP servers MAY decline to act as mail relays or to accept addresses that specify source routes
- When route information is encountered, SMTP servers MAY ignore the route information and simply send to the final destination specified as the last element in the route and SHOULD do so
- This is one of several reasons why SMTP clients MUST NOT generate invalid source routes or depend on serial resolution of names
- relay mail to a particular address for policy reasons, a 550 response SHOULD be returned
- A server MAY attempt to verify the return path before using its address for delivery notifications, but methods of doing so are not defined here nor is any particular method recommended at this time
- If an SMTP server has accepted the task of relaying the mail and later finds that the destination is incorrect or that the mail cannot be delivered for some other reason, then it MUST construct an "undeliverable mail" notification message and send it to the originator of the undeliverable mail (as indicated by the reverse- path)
- Formats specified for non-delivery reports by other standards (see, for example, RFC 3461 [32] and RFC 3464 [33]) SHOULD be used if possible
- Of course, SMTP servers MUST NOT send notification messages about problems transporting notification messages
- When such a message is transmitted, the reverse-path MUST be set to null (see
- As discussed in Section 6.4, a relay SMTP has no need to inspect or act upon the header section or body of the message data and MUST NOT do so except to add its own "Received:" header field (Section 4.4) and, optionally, to attempt to detect looping in the mail system (see Section 6.3)
- Header fields MAY be rewritten when necessary as messages are gatewayed across mail environment boundaries
- When forwarding a message into or out of the Internet environment, a gateway MUST prepend a Received: line, but it MUST NOT alter in any way a Received: line that is already in the header section
- As another consequence of trace header fields arising in non-SMTP environments, receiving systems MUST NOT reject mail based on the format of a trace header field and SHOULD be extremely robust in the light of unexpected information or formats in those header fields
- The gateway SHOULD indicate the environment and protocol in the "via" clauses of Received header field(s) that it supplies
- From the Internet side, the gateway SHOULD accept all valid address formats in SMTP commands and in the RFC 822 header section, and all valid RFC 822 messages
- Addresses and header fields generated by gateways MUST conform to applicable standards (including this one and RFC 5322 [4])
- The gateway MUST ensure that all header fields of a message that it forwards into the Internet mail environment meet the requirements for Internet mail
- In particular, all addresses in "From:", "To:", "Cc:", etc., header fields MUST be transformed (if necessary) to satisfy the standard header syntax of RFC 5322 [4], MUST reference only fully-qualified domain names, and MUST be effective and useful for sending replies
- The translation algorithm used to convert mail from the Internet protocols to another environment's protocol SHOULD ensure that error messages from the foreign mail environment are delivered to the reverse-path from the SMTP envelope, not to an address in the "From:", "Sender:", or similar header fields of the message
- Similarly, when forwarding a message from another environment into the Internet, the gateway SHOULD set the envelope return path in accordance with an error message return address, if supplied by the foreign environment
- An SMTP server MUST NOT intentionally close the connection under normal operational circumstances (see Section 7.8) except:
- An SMTP server that is forcibly shut down via external means SHOULD attempt to send a line containing a 421 response code to the SMTP client before exiting
- SMTP clients that experience a connection close, reset, or other communications failure due to circumstances not under their control (in violation of the intent of this specification but sometimes unavoidable) SHOULD, to maintain the robustness of the mail system, treat the mail transaction as if a 451 response had been received and act accordingly
- An SMTP-capable host SHOULD support both the alias and the list models of address expansion for multiple delivery
- When a message is delivered or forwarded to each address of an expanded list form, the return address in the envelope ("MAIL FROM:") MUST be changed to be the address of a person or other entity who administers the list
- However, in this case, the message header section (RFC 5322 [4]) MUST be left unchanged; in particular, the "From" field of the header section is unaffected
- Servers SHOULD simply utilize the addresses on the list; application of heuristics or other matching rules to eliminate some addresses, such as that of the originator, is strongly discouraged
- (In the interest of improved interoperability, SMTP receivers SHOULD tolerate trailing white space before the terminating .) The syntax of the local part of a mailbox MUST conform to receiver site conventions and the syntax specified in Section 4.1.2
- In the absence of specific extensions offered by the server and accepted by the client, clients MUST NOT send such parameters and servers SHOULD reject commands containing them as having invalid syntax
- available), the client SHOULD send an address literal (see Section 4.1.3)
- In the interest of interoperability, it is probably wise for servers to be prepared for this string to occur, but SMTP clients SHOULD NOT send it
- A client SMTP SHOULD start an SMTP session by issuing the EHLO command
- Older client SMTP systems MAY, as discussed above, use HELO (as specified in RFC 821) instead of EHLO, and servers MUST support the HELO command and reply properly to it
- In any event, a client MUST issue HELO or EHLO before starting a mail transaction
- Although EHLO keywords may be specified in upper, lower, or mixed case, they MUST always be recognized and processed in a case- insensitive manner
- The EHLO response MUST contain keywords (and associated parameters if required) for all commands not listed as "required" in Section 4.5.1 excepting only private-use commands as described in Section 4.1.5
- Private-use commands MAY be listed
- Sending systems SHOULD NOT generate the optional list of hosts known as a source route
- Receiving systems MUST recognize source route syntax but SHOULD strip off the source route specification and utilize the domain name associated with the mailbox as if the source route had not been provided
- Similarly, relay hosts SHOULD strip or ignore source routes, and names MUST NOT be copied into the reverse-path
- As provided in Appendix C, xyz.com MAY also choose to relay the message to hosta.int, using the envelope commands
- Since hosts are not required to relay mail at all, xyz.com MAY also reject the message entirely when the RCPT command is received, using a 550 code (since this is a "policy reason")
- The client MUST NOT transmit parameters other than those associated with a service extension offered by the server in its EHLO response
- The mail data may contain any of the 128 ASCII character codes, although experience has indicated that use of control characters other than SP, HT, CR, and LF may cause problems and SHOULD be avoided when possible
- An extra MUST NOT be added, as that would cause an empty line to be added to the message
- body were passed to the originating SMTP-sender with a final "line" that did not end in ; in that case, the originating SMTP system MUST either reject the message as invalid or add in order to have the receiving SMTP server recognize the "end of data" condition
- The custom of accepting lines ending only in , as a concession to non-conforming behavior on the part of some UNIX systems, has proven to cause more interoperability problems than it solves, and SMTP server systems MUST NOT do this, even in the name of improved robustness
- In particular, the sequence "." (bare line feeds, without carriage returns) MUST NOT be treated as equivalent to . as the end of mail data indication
- If the processing is successful, the receiver MUST send an OK reply
- If the processing fails, the receiver MUST send a failure reply
- Errors that are diagnosed subsequently MUST be reported in a mail message, as discussed in Section 4.4
- Any stored sender, recipients, and mail data MUST be discarded, and all buffers and state tables cleared
- The receiver MUST send a "250 OK" reply to a RSET command with no arguments
- An SMTP server MUST NOT close the connection as the result of receiving a RSET; that action is reserved for QUIT (see Section 4.1.1.10)
- To preserve the robustness of the mail system, SMTP servers SHOULD be prepared for this condition and SHOULD treat it as if a QUIT had been received before the connection disappeared
- The command MAY take an argument (e.g., any command name) and return more specific information as a response
- SMTP servers SHOULD support HELP without arguments and MAY support it with arguments
- If a parameter string is specified, servers SHOULD ignore it
- This command specifies that the receiver MUST send a "221 OK" reply, and then close the transmission channel
- The receiver MUST NOT intentionally close the transmission channel until it receives and replies to a QUIT command (even if there was an error)
- The sender MUST NOT intentionally close the transmission channel until it sends a QUIT command, and it SHOULD wait until it receives the reply (even if there was an error response to a previous command)
- If the connection is closed prematurely due to violations of the above or system or network failure, the server MUST cancel any pending transaction, but not undo any previously completed transaction, and generally MUST act as if the command or transaction in progress had received a temporary error (i.e., a 4yz response)
- A-d-l = At-domain *( "," At-domain ) ; Note that this form, the so-called "source ; route", MUST BE accepted, SHOULD NOT be ; generated, and SHOULD be ignored
- If this string is an email address, ; i.e., a Mailbox, then the "xtext" syntax [32] ; SHOULD be used
- Local-part = Dot-string / Quoted-string ; MAY be case-sensitive
- While the above definition for Local-part is relatively permissive, for maximum interoperability, a host that expects to receive mail SHOULD avoid defining mailboxes where the Local-part requires (or uses) the Quoted-string form or where the Local-part is case- sensitive
- For any purposes that require generating or comparing Local-parts (e.g., to specific mailbox names), all quoted forms MUST be treated as equivalent, and the sending system SHOULD transmit the form that uses the minimum quoting possible
- Systems MUST NOT define mailboxes in such a way as to require the use in SMTP of non-ASCII characters (octets with the high order bit set
- These characters MUST NOT be used in MAIL or RCPT commands or other commands that require mailbox names
- To promote interoperability and consistent with long-standing guidance about conservative use of the DNS in naming and applications (e.g., see Section 2.3.1 of the base DNS document, RFC 1035 [2]), characters outside the set of alphabetic characters, digits, and hyphen MUST NOT appear in domain name labels for SMTP clients or servers
- SMTP servers that receive a command in which invalid character codes have been employed, and for which there are no other reasons for rejection, MUST reject that command with a 501 response (this rule, like others, could be overridden by appropriate SMTP extensions)
- Standardized-tag = Ldh-str ; Standardized-tag MUST be specified in a ; Standards-Track RFC and registered with IANA
- A session that will contain mail transactions MUST first be initialized by the use of the EHLO command
- An SMTP server SHOULD accept commands for non-mail transactions (e.g., VRFY or EXPN) without this initialization
- An EHLO command MAY be issued by a client later in the session
- If it is issued after the session begins and the EHLO command is acceptable to the SMTP server, the SMTP server MUST clear all buffers and reset the state exactly as if a RSET command had been issued
- If the EHLO command is not acceptable to the SMTP server, 501, 500, 502, or 550 failure replies MUST be returned as appropriate
- SMTP server MUST stay in the same state after transmitting these replies that it was in before the EHLO was received
- The SMTP client MUST, if possible, ensure that the domain parameter to the EHLO command is a primary host name as specified for this command in Section 2.3.5
- If this is not possible (e.g., when the client's address is dynamically assigned and the client does not have an obvious name), an address literal SHOULD be substituted for the domain name
- An SMTP server MAY verify that the domain name argument in the EHLO command actually corresponds to the IP address of the client
- However, if the verification fails, the server MUST NOT refuse to accept a message on that basis
- SMTP servers SHOULD process these normally (that is, not return a 503 code) even if no EHLO command has yet been received; clients SHOULD open a session with EHLO before sending these commands
- MAIL (or SEND, SOML, or SAML) MUST NOT be sent if a mail transaction is already open, i.e., it should be sent only if no mail transaction had been started in the session, or if the previous one successfully concluded with a successful DATA command, or if the previous one was aborted, e.g., with a RSET or new EHLO
- If the transaction beginning command argument is not acceptable, a 501 failure reply MUST be returned and the SMTP server MUST stay in the same state
- reply MUST be returned and the SMTP server MUST stay in the same state
- The last command in a session MUST be the QUIT command
- The QUIT command SHOULD be used by the client SMTP to request connection closure, even when no session opening command was sent and accepted
- An extended SMTP server MAY list the feature names associated with these private commands in the response to the EHLO command
- Commands sent or accepted by SMTP systems that do not start with "X" MUST conform to the requirements of Section 2.2.2
- Every command MUST generate exactly one reply
- Since, in violation of this specification, the text is sometimes not sent, clients that do not receive it SHOULD be prepared to process the code alone (with or without a trailing space character)
- An SMTP server SHOULD send only the reply codes listed in this document
- An SMTP server SHOULD use the text shown in the examples whenever appropriate
- An SMTP client MUST determine its actions only by the reply code, not by the text (except for the "change of address" 251 and 551 and, if necessary, 220, 221, and 421 replies); in the general case, any text, including no text at all (although senders SHOULD NOT send bare codes), MUST be acceptable
- Whenever possible, a receiver- SMTP SHOULD test the first digit (severity indication) of the reply code
- The list of codes that appears below MUST NOT be construed as permanent
- Consequently, a sender-SMTP MUST be prepared to handle codes not specified in this document and MUST do so by interpreting the first digit only
- In the absence of extensions negotiated with the client, SMTP servers MUST NOT send reply codes whose first digits are other than 2, 3, 4,
- Clients that receive such out-of-range codes SHOULD normally treat them as fatal errors and terminate the mail transaction
- Each reply in this category might have a different time value, but the SMTP client SHOULD try again
- The SMTP client SHOULD NOT repeat the exact request (in the same sequence)
- As noted above, servers SHOULD send the if subsequent text is not sent, but clients MUST be prepared for it to be omitted
- In a multiline reply, the reply code on each of the lines MUST be the same
- Questions have been raised as to when reply code 502 (Command not implemented) SHOULD be returned in preference to other codes
- 502 SHOULD be used when the command is actually recognized by the SMTP server, but not implemented
- If the command is not recognized, code 500 SHOULD be returned
- Extended SMTP systems MUST NOT list capabilities in response to EHLO for which they will return 502 (or 500) replies
- When an SMTP server returns a temporary error status (4yz) code after the DATA command is completed with ., it MUST NOT make a subsequent attempt to deliver that message
- The user who originated the message SHOULD be able to interpret the return of a transient failure status (by mail message or otherwise) as a non-delivery indication, just as a permanent failure would be interpreted
- When an SMTP server returns a permanent error status (5yz) code after the DATA command is completed with ., it MUST NOT make any subsequent attempt to deliver the message
- As with temporary error status codes, the SMTP client retains responsibility for the message, but SHOULD not again attempt delivery to the same server without user review of the message and response and appropriate intervention
- Unless other arrangements are negotiated through service extensions, the sender MUST wait for this response before sending further commands
- The sender SHOULD wait for this greeting message before sending any commands
- These SHOULD be strictly adhered to
- A receiver MAY
- substitute text in the replies, but the meanings and actions implied by the code numbers and by the specific command reply sequence MUST be preserved
- Since some servers may generate other replies under special circumstances, and to allow for future extension, SMTP clients SHOULD, when possible, interpret only the first digit of the reply and MUST be prepared to deal with unrecognized reply codes by interpreting the first digit only
- Unless extended using the mechanisms described in Section 2.2, SMTP servers MUST NOT transmit reply codes to an SMTP client that are other than three digits or that do not start in a digit between 2 and 5 inclusive
- However, if the target is more precise granularity in the codes, rather than codes for completely new purposes, the system described in RFC 3463 [25] SHOULD be used in preference to the invention of new codes
- In order to provide for future extensions, commands that are specified in this document as not accepting arguments (DATA, RSET, QUIT) SHOULD return a 501 message if arguments are supplied in the absence of EHLO- advertised extensions
- When an SMTP server receives a message for delivery or further processing, it MUST insert trace ("time stamp" or "Received") information at the beginning of the message content, as discussed in Section 4.1.1.4
- This line MUST be structured as follows:
- o The FROM clause, which MUST be supplied in an SMTP environment, SHOULD contain both (1) the name of the source host as presented in the EHLO command and (2) an address literal containing the IP address of the source, determined from the TCP connection
- o The ID clause MAY contain an "@" as suggested in RFC 822, but this is not required
- o If the FOR clause appears, it MUST contain exactly one entry, even when multiple RCPT commands have been given
- An Internet mail program MUST NOT change or delete a Received: line that was previously added to the message header section
- SMTP servers MUST prepend Received lines to messages; they MUST NOT change the order of existing lines or insert Received lines in any other location
- SMTP servers that create Received header fields SHOULD use explicit offsets in the dates (e.g., -0800), rather than time zone names of any type
- Local time (with an offset) SHOULD be used rather than UT when feasible
- If it is desired to supply a time zone name, it SHOULD be included in a comment
- This use of return-path is required; mail systems MUST support it
- Consequently, any further (forwarding, gateway, or relay) systems MAY remove the return path and rebuild the MAIL command as needed to ensure that exactly one such line appears in a delivered message
- A message-originating SMTP system SHOULD NOT send a message that already contains a Return-path header field
- SMTP servers performing a relay function MUST NOT inspect the message data, and especially not to the extent needed to determine if Return-path header fields are present
- SMTP servers making final delivery MAY remove Return- path header fields before adding their own
- For this to be unambiguous, exactly one return path SHOULD be present when the message is delivered
- Systems using RFC 822 syntax with non-SMTP transports SHOULD designate an unambiguous address, associated with the transport envelope, to which error reports (e.g., non-delivery messages) should be sent
- The reverse-path address (as copied into the Return-path) MUST be used as the target of any mail containing delivery error messages
- In particular: o a gateway from SMTP -> elsewhere SHOULD insert a return-path header field, unless it is known that the "elsewhere" transport also uses Internet domain addresses and maintains the envelope sender address separately
- o a gateway from elsewhere -> SMTP SHOULD delete any return-path header field present in the message, and either copy that information to the SMTP envelope or combine it with information present in the envelope of the other transport system to construct the reverse-path argument to the MAIL command in the SMTP envelope
- In such cases, the response to the DATA command MUST be an OK reply
- However, the SMTP server MUST compose and send an "undeliverable mail" notification message to the originator of the message
- A single notification listing all of the failed recipients or separate notification messages MUST be sent for each failed recipient
- For economy of processing by the sender, the former SHOULD be used when possible
- All notification messages about undeliverable mail MUST be sent using the MAIL command (even if they result from processing the obsolete SEND, SOML, or SAML commands) and MUST use a null return path as discussed in Section 3.6
- Stamp = From-domain By-domain Opt-info [CFWS] ";" FWS date-time ; where "date-time" is as defined in RFC 5322 [4] ; but the "obs-" forms, especially two-digit ; years, are prohibited in SMTP and MUST NOT be used
- SMTP servers SHOULD NOT use unregistered ; names
- SMTP servers ; SHOULD NOT use unregistered names
- SMTP servers SHOULD NOT ; use unregistered names
- In order to make SMTP workable, the following minimum implementation MUST be provided by all receivers
- The following commands MUST be supported to conform to this specification:
- Any system that includes an SMTP server supporting mail relaying or delivery MUST support the reserved mailbox "postmaster" as a case- insensitive local name
- The requirement to accept mail for postmaster implies that RCPT commands that specify a mailbox for postmaster at any of the domains for which the SMTP server provides mail service, as well as the special case of "RCPT TO:" (with no domain specification), MUST be supported
- However, such arrangements SHOULD be narrowly tailored so as to avoid blocking messages that are not part of such attacks
- If such transformations are necessary, they MUST be reversible, especially if they are applied to mail being relayed
- Every implementation MUST be able to receive objects of at least these sizes
- Objects larger than these sizes SHOULD be avoided when possible
- Clients MAY attempt to transmit these, but MUST be prepared for a server to reject them if they cannot be handled by it
- The maximum total length of a message content (including any message header section as well as the message body) MUST BE at least 64K octets
- SMTP server systems that must impose restrictions SHOULD implement the "SIZE" service extension of RFC 1870 [10], and SMTP client systems that will send large messages SHOULD utilize it when possible
- The minimum total number of recipients that MUST be buffered is 100 recipients
- The general principle that relaying SMTP server MUST NOT, and delivery SMTP servers SHOULD NOT, perform validation tests on message header fields suggests that messages SHOULD NOT be rejected based on the total number of recipients shown in header fields
- A server that imposes a limit on the number of recipients MUST behave in an orderly fashion, such as rejecting additional addresses over its limit rather than silently discarding addresses previously accepted
- A client that needs to deliver a message containing over 100 RCPT commands SHOULD be prepared to transmit in 100-recipient "chunks" if the server declines to accept more than 100 recipients in a single message
- Clients SHOULD treat a 552 code in this case as a temporary, rather than permanent, failure so the logic below works
- If an SMTP server has an implementation limit on the number of RCPT commands and this limit is exhausted, it MUST use a response code of 452 (but the client SHOULD also be prepared for a 552, as noted above)
- If the server has a configured site-policy limitation on the number of RCPT commands, it MAY instead use a 5yz response code
- An SMTP client MUST provide a timeout mechanism
- It MUST use per- command timeouts rather than somehow trying to time the entire mail transaction
- Timeouts SHOULD be easily reconfigurable, preferably without recompiling the SMTP code
- Based on extensive experience with busy mail-relay hosts, the minimum per-command timeout values SHOULD be as follows:
- An SMTP server SHOULD have a timeout of at least 5 minutes while it is awaiting the next command from the sender
- Any queuing strategy MUST include timeouts on all activities on a per-command basis
- A queuing strategy MUST NOT send error messages in response to error messages under any circumstances
- In a typical system, the program that composes a message has some method for requesting immediate attention for a new piece of outgoing mail, while mail that cannot be transmitted immediately MUST be queued and periodically retried by the sender
- The sender MUST delay retrying a particular destination after one attempt has failed
- In general, the retry interval SHOULD be at least 30 minutes; however, more sophisticated and variable strategies will be beneficial when the SMTP client can determine the reason for non-delivery
- It MAY be appropriate to set a shorter maximum number of retries for non- delivery notifications and equivalent error messages than for standard messages
- The parameters to the retry algorithm MUST be configurable
- A client SHOULD keep a list of hosts it cannot reach and corresponding connection timeouts, rather than just retrying queued mail items
- At the same time, SMTP clients SHOULD use great care in caching negative responses from servers
- More significantly, 5yz responses to the MAIL command MUST NOT be cached
- When a mail message is to be delivered to multiple recipients, and the SMTP server to which a copy of the message is to be sent is the same for multiple recipients, then only one copy of the message SHOULD be transmitted
- That is, the SMTP client SHOULD use the command sequence: MAIL, RCPT, RCPT, ..., RCPT, DATA instead of the sequence: MAIL, RCPT, DATA, ..., MAIL, RCPT, DATA
- However, if there are very many addresses, a limit on the number of RCPT commands per MAIL command MAY be imposed
- This efficiency feature SHOULD be implemented
- Similarly, to achieve timely delivery, the SMTP client MAY support multiple concurrent outgoing mail transactions
- The SMTP server SHOULD attempt to keep a pending listen on the SMTP port (specified by IANA as port 25) at all times
- Some limit MAY be imposed, but servers that cannot handle more than one SMTP transaction at a time are not in conformance with the intent of this specification
- All other types of messages (i.e., any message which is not required by a Standards-Track RFC to have a null reverse-path) SHOULD be sent with a valid, non-null reverse-path
- In particular, such systems SHOULD NOT reply to messages with a null reverse-path, and they SHOULD NOT add a non-null reverse-path, or change a null reverse-path to a non-null one, to such messages when forwarding
- Once an SMTP client lexically identifies a domain to which mail will be delivered for processing (as described in Sections 2.3.5 and 3.6), a DNS lookup MUST be performed to resolve the domain name (RFC 1035 [2])
- Due to a history of problems, SMTP servers used for initial submission of messages SHOULD NOT make such inferences (Message Submission Servers [18] have somewhat more flexibility) and intermediate (relay) SMTP servers MUST NOT make them
- If a non-existent domain error is returned, this situation MUST be reported as an error
- If a temporary error is returned, the message MUST be queued and retried later (see Section 4.5.4.1)
- If MX records are present, but none of them are usable, or the implicit MX is unusable, this situation MUST be reported as an error
- If one or more MX RRs are found for a given name, SMTP systems MUST NOT utilize any address RRs associated with that name unless they are located using the MX RRs; the "implicit MX" rule above applies only if there are no MX records present
- If MX records are present, but none of them are usable, this situation MUST be reported as an error
- When a domain name associated with an MX RR is looked up and the associated data field obtained, the data field of that response MUST contain a domain name
- That domain name, when queried, MUST return at least one address record (e.g., A or AAAA RR) that gives the IP address of the SMTP server to which the message should be directed
- To provide reliable mail transmission, the SMTP client MUST be able to try (and retry) each of the relevant addresses in this list in order, until a delivery attempt succeeds
- However, there MAY also be a configurable limit on the number of alternate addresses that can be tried
- In any case, the SMTP client SHOULD try at least two addresses
- MX records contain a preference indication that MUST be used in sorting if more than one such record appears (see below)
- If there are multiple destinations with the same preference and there is no clear reason to favor one (e.g., by recognition of an easily reached address), then the sender-SMTP MUST randomize them to spread the load across multiple mail exchangers for a specific organization
- It is the responsibility of the domain name resolver interface to have ordered this list by decreasing preference if necessary, and the SMTP sender MUST try them in the order presented
- If an SMTP server receives a message with a destination for which it is a designated Mail eXchanger, it MAY relay the message (potentially after having rewritten the MAIL FROM and/or RCPT TO addresses), make final delivery of the message, or hand it off using some mechanism outside the SMTP-provided transport environment
- If it determines that it should relay the message without rewriting the address, it MUST sort the MX records to determine candidates for
- The relay host MUST then inspect the list for any of the names or addresses by which it might be known in mail transactions
- If a matching record is found, all records at that preference level and higher-numbered ones MUST be discarded from consideration
- If there are no records left at that point, it is an error condition, and the message MUST be returned as undeliverable
- If records do remain, they SHOULD be tried, best preference first, as described above
- It MUST NOT lose the message for frivolous reasons, such as because the host later crashes or because of a predictable resource shortage
- If there is a delivery failure after acceptance of a message, the receiver-SMTP MUST formulate and mail a notification message
- This notification MUST be sent using a null ("<>") reverse-path in the envelope
- The recipient of this notification MUST be the address from the envelope return path (or the Return-Path: line)
- if this address is null ("<>"), the receiver-SMTP MUST NOT send a notification
- If the address is an explicit source route, it MUST be stripped down to its final hop
- The notification message MUST be sent using:
- To avoid receiving duplicate messages as the result of timeouts, a receiver-SMTP MUST seek to minimize the time required to respond to the final . end of data indicator
- Reliably determining that a return address is invalid can be a difficult and time-consuming process, especially if the putative sending system is not directly accessible or does not fully and accurately support VRFY and, even if a "drop messages with invalid return addresses" policy is adopted, it SHOULD be applied only when there is near-certainty that the return addresses are, in fact, invalid
- Conversely, if a message is rejected because it is found to contain hostile content (a decision that is outside the scope of an SMTP server as defined in this document), rejection ("bounce") messages SHOULD NOT be sent unless the receiving site is confident that those messages will be usefully delivered
- SMTP servers using this technique SHOULD use a large rejection threshold, normally at least 100 Received entries
- Whatever mechanisms are used, servers MUST contain provisions for detecting and stopping trivial loops
- The following changes to a message being processed MAY be applied when necessary by an originating SMTP server, or one used as the target of SMTP as an initial posting (message submission) protocol:
- These changes MUST NOT be applied by an SMTP server that provides an intermediate relay function
- In all cases, documentation SHOULD be provided in trace header fields and/or header field comments for actions performed by the servers
- Especially when more than one RCPT command is present, and in order to avoid defeating some of the purpose of these mechanisms, SMTP clients and servers SHOULD NOT copy the full set of RCPT command arguments into the header section, either as part of trace header fields or as informational or private- extension header fields
- Since this rule is often violated in practice, and cannot be enforced, sending SMTP systems that are aware of "bcc" use MAY find it helpful to send each blind copy as a separate message transaction containing only a single RCPT command
- Receiving systems SHOULD NOT attempt to deduce such relationships and use them to alter the header section of the message for delivery
- The popular "Apparently-to" header field is a violation of this principle as well as a common source of unintended information disclosure and SHOULD NOT be used
- As a corollary to the above, implementations that permit this MUST NOT appear to have verified addresses that are not, in fact, verified
- If a site disables these commands for security reasons, the SMTP server MUST return a 252 response, rather than a code that could be confused with successful or unsuccessful verification
- Implementations SHOULD still provide support for EXPN, but sites SHOULD carefully evaluate the tradeoffs
- Sites are encouraged to evaluate the tradeoff with that issue in mind; implementations SHOULD minimally provide for making type and version information available in some way to other network hosts
- Some sites have decided to limit the use of the relay function to known or identifiable sources, and implementations SHOULD provide the capability to perform this type of filtering
- When mail is rejected for these or other policy reasons, a 550 code SHOULD be used in response to EHLO (or HELO), MAIL, or RCPT as appropriate
- In addition, if additional trace header fields (i.e., in addition to Return-path and Received) are ever created, those trace fields MUST be added to the IANA registry established by BCP 90 (RFC 3864) [11] for use with RFC 5322 [4]
- However, if the envelope is not supplied, SMTP commands SHOULD be generated as follows:
- Each recipient address from a TO, CC, or BCC header field SHOULD be copied to a RCPT command (generating multiple message copies if that is required for queuing or delivery)
- Any BCC header fields SHOULD then be removed from the header section
- Once this process is completed, the remaining header fields SHOULD be checked to verify that at least one TO, CC, or BCC header field remains
- If none do, then a BCC header field with no additional information SHOULD be inserted as specified in [4]
- The return address in the MAIL command SHOULD, if possible, be derived from the system's identity for the submitting (local) user, and the "From:" header field otherwise
- If there is a system identity available, it SHOULD also be copied to the Sender header field if it is different from the address in the From header field
- (Any Sender header field that was already there SHOULD be removed.) Systems may provide a way for submitters to override the envelope return address, but may want to restrict its use to privileged users
- A submission protocol based on Standard RFC 822 information alone MUST NOT be used to gateway a message from a foreign (non-SMTP) mail system into an SMTP environment
- The first host in the was historically the host sending the MAIL command; today, source routes SHOULD NOT appear in the reverse-path
- However, in general, the SHOULD contain only a mailbox and domain name, relying on the domain name system to supply routing information if required
- The use of source routes is deprecated (see Appendix F.2); while servers MUST be prepared to receive and handle them as discussed in Section 3.3 and Appendix F.2, clients SHOULD NOT transmit them and this section is included in the current specification only to provide context
- For relay purposes, the forward-path may be a source route of the form "@ONE,@TWO:JOE@THREE", where ONE, TWO, and THREE MUST be fully- qualified domain names
- A server that is reached by means of a source route (e.g., its domain name appears first in the list in the forward-path) MUST remove its domain name from any forward-paths in which that domain name appears before forwarding the message and MAY remove all other source routing information
- The reverse-path SHOULD NOT be updated by servers conforming to this specification
- Conversely, SMTP servers MUST NOT derive final message routing information from message header fields
- If, contrary to the recommendations here, a relay host adds itself to the beginning of the list, it MUST use its name as known in the transport environment to which it is relaying the mail rather than that of the transport environment from which the mail came (if they are different)
- This is another reason why servers needing to return a message SHOULD ignore the source route entirely and simply use the domain as specified in the Mailbox
- In general, gateways between the Internet and other mail systems SHOULD attempt to preserve any layering semantics across the boundaries between the two mail systems involved
- A few features of RFC 821 have proven to be problematic and SHOULD NOT be used in Internet mail
- Its use is deprecated; SMTP systems SHOULD NOT use it unless the server can authenticate the client
- SMTP servers MUST continue to accept source route syntax as specified in the main body of this document and in RFC 1123
- They MAY, if necessary, ignore the routes and utilize only the target domain in the address
- If they do utilize the source route, the message MUST be sent to the first domain shown in the address
- In particular, a server MUST NOT guess at shortcuts within the source route
- Clients SHOULD NOT utilize explicit source routing except under unusual circumstances, such as debugging or potentially relaying around firewall or mail system configuration errors
- As discussed in Sections 3.1 and 4.1.1, EHLO SHOULD be used rather than HELO when the server will accept the former
- Servers MUST continue to accept and process HELO in order to support older clients
- It is deprecated and MUST NOT be used
- When dates are inserted into messages by SMTP clients or servers (e.g., in trace header fields), four-digit years MUST BE used
- Clients SHOULD NOT provide SEND, SAML, or SOML as services
- Servers MAY implement them
- If they are implemented by servers, the implementation model specified in RFC 821 MUST be used and the command names MUST be published in the response to the EHLO command
rfc5452
- A resolver implementation MUST match responses to all of the following attributes of the query:
- A mismatch and the response MUST be considered invalid
- Resolver implementations MUST:
- Resolvers that have multiple IP addresses SHOULD use them in an unpredictable manner for outgoing queries
- Resolver implementations SHOULD provide means to avoid usage of certain ports
- Resolvers SHOULD favor authoritative nameservers with which a trust relation has been established; stub-resolvers SHOULD be able to use Transaction Signature (TSIG) ([RFC2845]) or IPsec ([RFC4301]) when communicating with their recursive resolver
- In case a cryptographic verification of response validity is available (TSIG, SIG(0)), resolver implementations MAY waive above rules, and rely on this guarantee instead
- If a resolver detects that an attempt is being made to spoof it, perhaps by discovering that many packets fail the criteria as outlined above, it MAY abandon the UDP query and re-issue it over TCP
- Nothing in this document specifies specific algorithms for operators to use; it does specify algorithms implementations SHOULD or MUST support
rfc5494
rfc5509
- Section 5 of [RFC3428] states that if a user agent (UA) is presented with an IM URI (e.g., "im:fred@example.com") as the address for an instant message, it SHOULD resolve it to a SIP URI, and place the resulting URI in the Request-URI of the MESSAGE request before
rfc5676
- In case parameters are missing, a forwarding application MUST retrieve the missing parameters from the SYSLOG-MSG-MIB
- If an application reduces the limit while there are SYSLOG messages in the syslogMsgTable, the SYSLOG messages that are in the syslogMsgTable for the longest time MUST be discarded to bring the table down to the new limit
- It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy)
- Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED
- Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security
- It is therefore RECOMMENDED that deployments use SYSLOG security mechanisms in order to prevent attackers from adding malicious SYSLOG data to the MIB tables
rfc5702
- For interoperability, as in [RFC3110], the key size of RSA/SHA-256 keys MUST NOT be less than 512 bits and MUST NOT be more than 4096 bits
- The key size of RSA/SHA-512 keys MUST NOT be less than 1024 bits and MUST NOT be more than 4096 bits
- The FF octet MUST be repeated the exact number of times so that the total length of the concatenated term in parentheses equals the length of the modulus of the signer's public key ("n")
- DNSSEC-aware implementations SHOULD be able to support RRSIG and DNSKEY resource records created with the RSA/SHA-2 algorithms as defined in this document
- A DNSSEC validator that implements RSA/SHA-2 MUST be able to validate negative answers in the form of both NSEC and NSEC3 with hash algorithm 1, as defined in [RFC5155]
- An authoritative server that does not implement NSEC3 MAY still serve zones that use RSA/SHA-2 with NSEC denial of existence
- Since each RRSet MUST be signed with each algorithm present in the DNSKEY RRSet at the zone apex (see Section 2.2 of [RFC4035]), a malicious party cannot filter out the RSA/SHA-2 RRSIG and force the validator to use the RSA/SHA-1 signature if both are present in the zone
rfc5864
- MUST be "udp" for the current AFS protocol, which uses Rx over UDP
- MUST be the AFS cell name for which the identified server provides AFS services
- Clients MUST query DNS SRV RRs only for a value exactly matching the AFS cell of interest
- They MUST NOT remove leading components to search for more general DNS SRV RRs
- This is not a requirement of the AFS protocol, but sites creating new AFS cells SHOULD use names that follow the structure of the DNS and that result in DNS SRV RRs under their administrative control
- As defined in the DNS SRV RR specification [RFC2782], clients MUST attempt to contact the target host with the lowest-numbered priority they can reach
- AFS clients that use a ranked algorithm to determine which server to contact MUST therefore assign a sufficiently distinct rank to targets with different priorities such that targets with a higher-numbered priority are only contacted if all targets with a lower-numbered priority are inaccessible
- If there are multiple targets with an equal priority, the weight value of the DNS SRV RR SHOULD be used as input to a weighted algorithm for selecting servers
- As specified by [RFC2782], larger weights SHOULD be given a proportionately higher probability of being selected
- A weight of 0 SHOULD be used if all targets with that priority are weighted equally
- AFS clients MAY take into account network performance and other protocol metrics along with SRV RR weights when selecting servers, thereby possibly selecting different servers than a system based purely on the SRV RRs would indicate
- However, such information MUST NOT override the priority information in the SRV RR
- DNS RRs SHOULD be discarded after their TTL, and after the DNS query repeated
- Any information derived from the DNS SRV RRs, such as preference ranks, MUST be discarded when the DNS SRV RR is expired
- Instead, they MAY reuse the results of the algorithm until the DNS SRV RRs expire
- AFS clients MAY remember which targets are inaccessible by that client and ignore those targets when determining which server to contact first
- Clients that do this SHOULD have a mechanism to retry targets that were previously inaccessible and reconsider them according to their current priority and weight if they become accessible again
- Clients using this algorithm SHOULD assign their ranks as follows:
- Each base rank value MUST be sufficiently different from the base rank assigned to any higher- numbered priority so that higher-numbered targets will only be
- It MUST, in other words, be farther from the base rank of any distinct priority than any possible automatic adjustment in the rank
- After assignment of ranks, the AFS client MAY then adjust the ranks dynamically based on network performance and other protocol metrics, provided that such adjustments are sufficiently small compared to the difference between base ranks that they cannot cause servers with a higher-numbered priority to be contacted instead of a server with a lower-numbered priority
- The TTL of the DNS SRV RRs MUST be honored by invalidating and regenerating the server preference ranks with new DNS information once that TTL has expired
- AFS client implementations encountering a DNS SRV RR containing targets with more distinct priority values than can be correctly represented as base ranks SHOULD fall back to generating ranks based solely on priorities, ignoring other rank inputs, and disabling dynamic adjustment of ranks
- Implementations MUST be able to assign distinct base ranks as described above for at least ten distinct priority values
- Since many AFS client implementations currently support AFSDB RRs but do not support DNS SRV RRs, AFS cells providing DNS SRV RRs SHOULD also provide AFSDB RRs
- An AFS cell using DNS SRV RRs SHOULD therefore also provide an AFSDB RR listing all AFS servers for which the following statements are all true:
- AFS cell administrators MAY use different lists of servers in the AFSDB RRs and DNS SRV RRs if desired for specific effects based on local knowledge of which clients use AFSDB RRs and which clients use DNS SRV RRs
- However, AFS servers SHOULD NOT be advertised with AFSDB RRs unless they provide VLDB and PTS services via UDP on the standard ports
- (This falls shy of MUST NOT because it may be useful in some unusual circumstances to advertise, via an AFSDB RR, a server that provides only one of the two services, but be aware that such a configuration may confuse legacy clients.)
- An AFS cell SHOULD have at least one VLDB and at least one PTS server providing service on the standard ports of 7003 and 7002, respectively, since clients without DNS SRV RR support cannot locate servers on non-standard ports
- Clients SHOULD query DNS SRV RRs by default but SHOULD then fall back on AFSDB RRs if no DNS SRV RRs are found
- In the absence of DNS SRV RRs, an AFSDB RR of 1 SHOULD be treated as equivalent to the following pair of DNS SRV RRs:
rfc5890
- To allow for future use of mechanisms similar to IDNA, those labels MUST NOT be processed as
- ordinary LDH labels by IDNA-conforming programs and SHOULD NOT be mixed with IDNA labels in the same zone
- These strings MUST contain only characters specified elsewhere in this document series, and only in the contexts indicated as appropriate
rfc5891
- Whenever a domain name is put into a domain name slot that is not IDNA-aware (see Section 2.3.2.6 of the Definitions document [RFC5890]), it MUST contain only ASCII characters (i.e., its labels must be either A-labels or NR-LDH labels), unless the DNS application is not subject to historical recommendations for "hostname"-style names (see RFC 1034 [RFC1034] and Section 3.2.1)
- Labels MUST be compared using equivalent forms: either both A-label forms or both U-label forms
- A pair of A-labels MUST be compared as case-insensitive ASCII (as with all comparisons of ASCII DNS labels)
- U-labels MUST be compared as-is, without case folding or other intermediate steps
- In many cases, not limited to comparison, validation may be important for other reasons and SHOULD be performed
- Labels being registered MUST conform to the requirements of Section 4
- Labels being looked up and the lookup process MUST conform to the requirements of Section 5
- IDNs occupying domain name slots in those older protocols MUST be in A-label form until and unless those protocols and their implementations are explicitly upgraded to be aware of IDNs and to accept the U-label form
- IDNs actually appearing in DNS queries or responses MUST be A-labels
- IDNA-aware protocols and implementations MAY accept U-labels, A-labels, or both as those particular protocols specify
- By the time a string enters the IDNA registration process as described in this specification, it MUST be in Unicode and in Normalization Form C (NFC [Unicode-UAX15])
- Entities responsible for zone files ("registries") MUST accept only the exact string for which registration is requested, free of any mappings or local adjustments
- They MAY accept that input in any of three forms:
- The first two of these forms are RECOMMENDED because the use of A-labels avoids any possibility of ambiguity
- If both the U-label and A-label forms are available, the registry MUST ensure that the A-label form is in lowercase, perform a conversion to a U-label, perform the steps and tests described below on that U-label, and then verify that the A-label produced by the step in Section 4.4 matches the one provided as input
- In addition, the U-label that was provided as input and the one obtained by conversion of the A-label MUST match exactly
- If, for some reason, these tests fail, the registration MUST be rejected
- If only an A-label was provided and the conversion to a U-label is not performed, the registry MUST still verify that the A-label is superficially valid, i.e., that it does not violate any of the rules of Punycode encoding [RFC3492] such as the prohibition on trailing hyphen-minus, the requirement that all characters be ASCII, and so on
- Strings that appear to be A-labels (e.g., they start with "xn--") and strings that are supplied to the registry in a context reserved for A-labels (such as a field in a form to be filled out), but that are not valid A-labels as described in this paragraph, MUST NOT be placed in DNS zones that support IDNA
- If only an A-label is provided, the conversion to a U-label is not performed, but the superficial tests described in the previous paragraph are performed, registration procedures MAY, and usually will, bypass the tests and actions in the balance of Section 4.2 and in Sections 4.3 and 4.4
- The candidate Unicode string MUST NOT contain characters that appear in the "DISALLOWED" and "UNASSIGNED" lists specified in the Tables document [RFC5892]
- The Unicode string MUST NOT contain "--" (two consecutive hyphens) in the third and fourth character positions and MUST NOT start or end with a "-" (hyphen)
- The Unicode string MUST NOT begin with a combining mark or combining character (see The Unicode Standard, Section 2.11 [Unicode] for an exact definition)
- The Unicode string MUST NOT contain any characters whose validity is context-dependent, unless the validity is positively confirmed by a contextual rule
- To check this, each code point identified as CONTEXTJ or CONTEXTO in the Tables document [RFC5892] MUST have a non-null rule
- If the proposed label contains any characters from scripts that are written from right to left, it MUST meet the Bidi criteria [RFC5893]
- The result MUST be a Unicode string in NFC form
- If the input to this procedure appears to be an A-label (i.e., it starts in "xn--", interpreted case-insensitively), the lookup application MAY attempt to convert it to a U-label, first ensuring that the A-label is entirely in lowercase (converting it to lowercase
- If the label is converted to Unicode (i.e., to U-label form) using the Punycode decoding algorithm, then the processing specified in those two sections MUST be performed, and the label MUST be rejected if the resulting label is not identical to the original
- Conversion from the A-label and testing that the result is a U-label SHOULD be performed if the domain name will later be presented to the user in native character form (this requires that the lookup application be IDNA-aware)
- If those steps are not performed, the lookup process SHOULD at least test to determine that the string is actually an A-label, examining it for the invalid formats specified in the Punycode decoding specification
- Applications that are not IDNA-aware will obviously omit that testing; others MAY treat the string as opaque to avoid the additional processing at the expense of providing less protection and information to users
- Putative U-labels with any of the following characteristics MUST be rejected prior to DNS lookup:
- Applications resolving DNS names or carrying out equivalent operations are not required to test contextual rules for "CONTEXTO" characters, only to verify that a rule is defined (although they MAY make such tests to provide better protection or give better information to the user)
- In addition, the application SHOULD apply the following test
- For all other strings, the lookup application MUST rely on the presence or absence of labels in the DNS to determine the validity of those labels and the validity of the characters they contain
rfc5910
- Unless stated otherwise, XML specifications and examples provided in this document MUST be interpreted in the character case presented in order to develop a conforming implementation
- As this document deprecates RFC 4310 [RFC4310], if a server announces support for both secDNS-1.0 [RFC4310] and secDNS-1.1 in the EPP greeting, clients supporting both versions SHOULD prefer secDNS-1.1
- A server SHOULD do the following to help clients migrate from secDNS-1.0 [RFC4310] to secDNS-1.1 as defined in this document
- A server migrating from secDNS-1.0 [RFC4310] to secDNS-1.1 SHOULD support both versions (i.e., secDNS-1.0 and secDNS-1.1) for a reasonable migration period
- The version of the element to be returned by the server in the response to a response SHOULD depend on the elements (indicating the secDNS extension) the client included in the EPP command using the following mapping:
- Boolean values MUST be represented in the XML Schema format described in Part 2 of the W3C XML Schema recommendation [W3C.REC-xmlschema-2-20010502]
- Maximum signature lifetime (maxSigLife) is an OPTIONAL child preference for the number of seconds after signature generation when the parent's signature on the DS information provided by the child will expire
- The maxSigLife value MUST be represented in seconds, using an extended XML Schema "int" format
- The server MUST support one form of interface within a single command or response, where and MUST NOT be mixed, except for when is a child element of for server validation
- The server MUST support the use of only one form of interface across all , , and elements, except during a transition period, during which the server MAY support both
- For instance, during a transition period, the server MAY support either the DS Data Interface or the Key Data Interface on a per-domain basis and allow the client to migrate to the target interface
- The server MUST return an EPP error result code of 2306 if the server receives a command using an unsupported interface
- The key data associated with the DS information MAY be provided by the client, but the server is not obligated to use the key data
- The server operator MAY also issue out-of-band DNS queries to retrieve the key data from the registered domain's apex in order to evaluate the received DS information
- It is RECOMMENDED that the child zone operator have this key data online in the DNS tree to allow the parent zone administrator to validate the data as necessary
- The key data SHOULD have the Secure Entry Point (SEP) bit set as described in RFC 3757 [RFC3757] and RFC 4034 [RFC4034]
- An OPTIONAL element that describes the key data used as input in the DS hash calculation for use in server validation
- When an command has been processed successfully, the EPP element MUST contain child elements as described in the EPP domain mapping [RFC5731]
- In addition, the EPP element SHOULD contain a child element that identifies the extension namespace if the domain object has data associated with this extension and based on server policy
- An OPTIONAL element that indicates a child's preference for the number of seconds after signature generation when the parent's signature on the DS information provided by the child will expire
- Example Response for a Secure Delegation Using the DS Data Interface with OPTIONAL Key Data:
- An EPP error response MUST be returned if an command cannot be processed for any reason
- In addition to the EPP command elements described in the EPP domain mapping [RFC5731], the command MUST contain an element, and the element MUST contain a child element that identifies the extension namespace if the client wants to associate data defined in this extension to the domain object
- An OPTIONAL element that indicates a child's preference for the number of seconds after signature generation when the parent's signature on the DS information provided by the child will expire
- If the server does not support the element, a 2102 error MUST be returned
- Example Command for a Secure Delegation Using the DS Data Interface with OPTIONAL Key Data:
- In addition to the EPP command elements described in the EPP domain mapping, the command MUST contain an element, and the element MUST contain a child element that identifies the extension namespace if the client wants to update the domain object with data defined in this extension
- At least one , , or element MUST be provided
- The order of the and elements is significant, where the server MUST first remove the existing elements prior to adding the new elements
- The element also contains an OPTIONAL "urgent" attribute that a client can use to ask the server operator to complete and implement the update request with high priority
- A server MUST return an EPP error result code of 2102 if the "urgent" attribute is specified with a value of boolean true and the server does not support it
- A server MUST return an EPP error result code of 2306 if the server supports the "urgent" attribute and an urgent update (noted with an "urgent" attribute value of boolean true) cannot be completed with high priority
- An OPTIONAL element that contains a element, or one or more or elements that are used to remove security data from a delegation
- An OPTIONAL element that is used to add security information to an existing set
- The element MUST contain one or more or elements
- An OPTIONAL element that contains security information to be changed
- An OPTIONAL element that indicates a child's preference for the number of seconds after signature generation when the parent's signature on the DS information provided by the child will expire
- If the server does not support the element, a 2102 error MUST be returned
- IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE
- Though XML includes provisions to identify and use other character encodings through use of an "encoding" attribute in an declaration, use of UTF-8 is RECOMMENDED in environments where parser encoding support incompatibility exists
- As with other domain object transforms, the EPP transform operations described in this document MUST be restricted to the sponsoring client as authenticated using the mechanisms described in Sections 2.9.1.1 and 7 of RFC 5730 [RFC5730]
- Any attempt to perform a transform operation on a domain object by any client other than the sponsoring client MUST be rejected with an appropriate EPP authorization error
- A trust relationship MUST exist between the EPP client and server, and provisioning of public key information MUST only be done after the identities of both parties have been confirmed using a strong authentication mechanism
- The child and parent zones MUST be consistent to secure the delegation properly
- Server operators SHOULD take steps to manage command load and command processing requirements to minimize the risk of a denial-of-service attack
- Server operators SHOULD seriously consider adopting implementation rules to limit the range of acceptable signature lifetime values to counter potential adverse situations
- Combined "the command MUST contain an element" with the following sentence in Section 5.2.1 and Section 5.2.5
- Added sentence "If the server does not support the element, a 2102 error MUST be returned" to Section 5.2.1 and Section 5.2.5
- Added clarification on when the extension MUST be included for each of the commands and responses (, , )
- Changed "In addition, the EPP element MUST contain a child element" to "In addition, the EPP element SHOULD contain a child element" and added "and based on server policy"
rfc5933
- The wire representation of a public key MUST contain 64 octets, where the first 32 octets contain the little-endian representation of x and the second 32 octets contain the little-endian representation of y
- The hash MUST be calculated with GOST R 34.11-94 parameters identified by id-GostR3411-94-CryptoProParamSet [RFC4357]
- The digest MUST always be calculated with GOST R 34.11-94 parameters identified by id-GostR3411-94-CryptoProParamSet [RFC4357]
- According to RFC 4357 [RFC4357], the key size of GOST public keys MUST be 512 bits
- DNSSEC-aware implementations MAY be able to support RRSIG and DNSKEY resource records created with the GOST algorithms as defined in this document
- Any DNSSEC-GOST implementation MUST support both NSEC [RFC4035] and NSEC3 [RFC5155]
- References Status 12 GOST R 34.10-2001 ECC-GOST Y * RFC 5933 OPTIONAL
- Value Algorithm Status 3 GOST R 34.11-94 OPTIONAL
rfc5936
- QR MUST be 0 (Query)
- OPCODE MUST be 0 (Standard Query)
- RCODE MUST be 0 (No error)
- QDCOUNT Number of entries in Question section; MUST be 1
- ANCOUNT Number of entries in Answer section; MUST be 0
- NSCOUNT Number of entries in Authority section; MUST be 0
- A server MUST reply using messages that use the same message ID to allow a client to have multiple queries outstanding concurrently over the same TCP connection -- see Note a) in Section 2.2.1 for more details
- For the client, it is RECOMMENDED that the value be zero
- The server MUST ignore this value
- c) "mbz" -- The client MUST set this bit to 0; the server MUST ignore it
- d) The client MUST set this field to the number of resource records it places into the Additional section
- In the absence of explicit specification of new RRs to be carried in the Additional section of AXFR queries, the value MAY be 0, 1, or 2
- The Question section of the AXFR query MUST conform to Section 4.1.2 of RFC 1035, and contain a single resource record with the following values:
- The Answer section MUST be empty
- The Authority section MUST be empty
- The client MAY include one OPT resource record [RFC2671]
- If the server does not support EDNS0, the client MUST send this section without an OPT resource record if there is a retry
- The client MAY include one transaction integrity and authentication resource record, currently a choice of TSIG [RFC2845] or SIG(0) [RFC2931]
- In general, if an AXFR client is aware that an AXFR server does not support a particular mechanism, the client SHOULD NOT attempt to engage the server using the mechanism (or engage the server at all)
- The range of permissible resource records that MAY appear in the Additional section might change over time
- In such a series, the first message MUST begin with the SOA resource record of the zone, and the last message MUST conclude with the same SOA resource record
- Intermediate messages MUST NOT contain the SOA resource record
- The AXFR server MUST copy the Question section from the corresponding AXFR query message into the first response message's Question section
- For subsequent messages, it MAY do the same or leave the Question section empty
- Although servers typically do attempt to send related RRs (such as the RRs forming an RRset, and the RRsets of a name) as a contiguous group or, when message space allows, in the same response message, they are not required to do so, and clients MUST accept any ordering and grouping of the non-SOA RRs
- Each RR SHOULD be transmitted only once, and AXFR clients MUST ignore any duplicate RRs received
- Each AXFR response message SHOULD contain a sufficient number of RRs to reasonably amortize the per-message overhead, up to the largest number that will fit within a DNS message (taking the required content of the other sections into account, as described below)
- To interoperate with such clients, the server MAY restrict response messages to a single RR
- Such a message terminates the AXFR session; it MUST contain a copy of the Question section from the AXFR query in its Question section, but the inclusion of the terminating SOA resource record is not necessary
- ID MUST be copied from request -- see Note a)
- QR MUST be 1 (Response)
- OPCODE MUST be 0 (Standard Query)
- Flags: AA normally 1 -- see Note b) TC MUST be 0 (Not truncated) RD RECOMMENDED: copy request's value; MAY be set to 0 RA SHOULD be 0 -- see Note c) Z "mbz" -- see Note d) AD "mbz" -- see Note d) CD "mbz" -- see Note d)
- QDCOUNT MUST be 1 in the first message; MUST be 0 or 1 in all following messages; MUST be 1 if RCODE indicates an error
- NSCOUNT MUST be 0
- New DNS servers MUST set this field to the value of the AXFR query ID in each AXFR response message for the session
- AXFR clients MUST be able to manage sessions resulting from the issuance of multiple outstanding queries, whether AXFR queries or other DNS queries
- A client SHOULD discard responses that do not correspond (via the message ID) to any outstanding queries
- Unless the client is sure that the server will consistently set the ID field to the query's ID, the client is NOT RECOMMENDED to issue any other queries until the end of the zone transfer
- A client MAY become aware of a server's abilities via a configuration setting
- b) If the RCODE is 0 (no error), then the AA bit MUST be 1
- For any other value of RCODE, the AA bit MUST be set according to the rules for that error code
- If in doubt, it is RECOMMENDED that it be set to 1
- It is RECOMMENDED that the value be ignored by the AXFR client
- c) It is RECOMMENDED that the server set the value to 0; the client MUST ignore this value
- The server MAY set this value according to the local policy regarding recursive service, but doing so might confuse the interpretation of the response, as AXFR cannot be retrieved recursively
- A client MAY note the server's policy regarding recursive service from this value, but SHOULD NOT conclude that the AXFR response was obtained recursively, even if the RD bit was 1 in the query
- d) "mbz" -- The server MUST set this bit to 0; the client MUST ignore it
- e) In the absence of an error, the server MUST set the value of this field to NoError(0)
- If a server is not authoritative for the queried zone, the server SHOULD set the value to NotAuth(9)
- (Reminder: Consult the appropriate IANA registry [DNSVALS].) If a client receives any other value in response, it MUST act according to the error
- f) The count of answer records MUST equal the number of resource records in the AXFR Answer section
- When a server is aware that a client will only accept response messages with a single resource record, then the value MUST be 1
- A server MAY be made aware of a client's limitations via configuration data
- g) The server MUST set this field to the number of resource records it places into the Additional section
- In the absence of explicit specification of new RRs to be carried in the Additional section of AXFR response messages, the value MAY be 0, 1, or 2
- In the first response message, this section MUST be copied from the query
- In subsequent messages, this section MAY be copied from the query, or it MAY be empty
- However, in an error response message (see Section 2.2), this section MUST be copied as well
- The content of this section MAY be used to determine the context of the message, that is, the name of the zone being transferred
- The Answer section MUST be populated with the zone contents
- The Authority section MUST be empty
- The contents of this section MUST follow the guidelines for the OPT, TSIG, and SIG(0) RRs, or whatever other future record is possible here
- If the client has supplied an EDNS OPT RR in the AXFR query and if the server supports EDNS as well, it SHOULD include one OPT RR in the first response message and MAY do so in subsequent response messages (see Section 2.2); the specifications of EDNS options to be carried in the OPT RR may impose stronger requirements
- If the client has supplied a transaction security resource record (currently a choice of TSIG and SIG(0)) and the server supports the method chosen by the client, it MUST place the corresponding resource record into the AXFR response message(s), according to the rules specified for that method
- If an AXFR client sends a query on a TCP connection and the connection is closed at any point, the AXFR client MUST consider the AXFR session terminated
- The message ID MAY be used again on a new connection, even if the question and AXFR server are the same
- Facing a dropped connection, a client SHOULD try to make some determination as to whether the connection closure was the result of network activity or due to a decision by the AXFR server
- It is up to the AXFR client to react, but the implemented reaction SHOULD NOT be either an endless cycle of retries or an increasing (in frequency) retry rate
- In the Answer section of AXFR response messages, the resource records within a zone for the given serial number MUST appear
- The AXFR response MUST contain the cut point NS resource record set registered with the zone whether it agrees with the authoritative set or not
- The AXFR response MUST contain the appropriate glue records as registered with the zone
- Hence, name compression in an AXFR message SHOULD be performed in a case-preserving manner, unlike how it is done for "normal" DNS responses
- Rules governing name compression of RDATA in an AXFR message MUST abide by the specification in "Handling of Unknown DNS Resource Record (RR) Types" [RFC3597], specifically, Section 4 on "Domain Name Compression"
- Occluded names MUST be included in AXFR responses
- An AXFR client MUST be able to identify and handle occluded names
- An AXFR client MAY request a connection to an AXFR server for any reason
- An AXFR client SHOULD close the connection when there is no apparent need to use the connection for some time period
- When a TCP connection is closed remotely (relative to the client), whether by the AXFR server or due to a network event, the AXFR client MUST cancel all outstanding sessions and non-AXFR transactions
- An AXFR client MAY use an already opened TCP connection to start an AXFR session
- Using an existing open connection is RECOMMENDED over opening a new connection
- (Non-AXFR session traffic can also use an open connection.) If in doing so the AXFR client realizes that the responses cannot be properly differentiated (lack of matching query IDs, for example) or the connection is terminated for a remote reason, then the AXFR client SHOULD NOT attempt to reuse an open connection with the specific AXFR server until the AXFR server is updated (which is, of course, not an event captured in the DNS protocol)
- An AXFR server MUST be able to handle multiple AXFR sessions on a single TCP connection, as well as to handle other query/response transactions over it
- If a TCP connection is closed remotely, the AXFR server MUST cancel all AXFR sessions in place
- Local policy MAY dictate that a TCP connection is to be closed
- Such an action SHOULD be in reaction to limits such as those placed on the number of outstanding open connections
- Closing a connection in response to a suspected security event SHOULD be done only in extreme cases, when the server is certain the action is warranted
- An isolated request for a zone not on the AXFR server SHOULD receive a response with the appropriate response code and not see the connection broken
- A DNS implementation SHOULD provide means to restrict AXFR sessions to specific clients
- An implementation SHOULD allow access to be granted to Internet Protocol addresses and ranges, regardless of whether a source address could be spoofed
- A general-purpose implementation is RECOMMENDED to implement access controls based upon "Secret Key Transaction Authentication for DNS (TSIG)" [RFC2845] and/or "DNS Request and Transaction Signatures ( SIG(0)s )" [RFC2931]
- A general-purpose implementation SHOULD allow access to be open to all AXFR requests
- A general-purpose implementation SHOULD NOT have a default policy for AXFR requests to be "open to all"
- An AXFR client MUST ensure that only a successfully transferred copy of the zone data can be used to serve this zone
- Previous description and implementation practice has introduced a two-stage model of the whole zone synchronization procedure: Upon a trigger event (e.g., when polling of a SOA resource record detects a change in the SOA serial number, or when a DNS NOTIFY request [RFC1996] is received), the AXFR session is initiated, whereby the zone data are saved in a zone file or database (this latter step is necessary anyway to ensure proper restart of the server); upon successful completion of the AXFR operation and some sanity checks, this data set is "loaded" and made available for serving the zone in an atomic operation, and flagged "valid" for use during the next restart of the DNS server; if any error is detected, this data set MUST be deleted, and the AXFR client MUST continue to serve the previous version of the zone, if it did before
- The externally visible behavior of an AXFR client implementation MUST be equivalent to that of this two- stage model
- If an AXFR client rejects data obtained in an AXFR session, it SHOULD remember the serial number and MAY attempt to retrieve the same zone version again
- Besides best attempts at securing TCP connections, DNS implementations SHOULD provide means to make use of "Secret Key Transaction Authentication for DNS (TSIG)" [RFC2845] and/or "DNS Request and Transaction Signatures ( SIG(0)s )" [RFC2931] to allow AXFR clients to verify the contents
- These techniques MAY also be used for authorization
- An implementation SHOULD, in its documentation, encourage operators to periodically review AXFR clients and servers it has made notes about repeatedly, as old software gets updated from time to time
- An implementation of an AXFR server MAY permit configuring, on a per AXFR client basis, the necessity to revert to a single resource record per message; in that case, the default SHOULD be to use multiple records per message
- Attempting to issue multiple DNS queries over a TCP transport for an AXFR session SHOULD be aborted if it interrupts the original request, and SHOULD take into consideration whether the AXFR server intends to close the connection immediately upon completion of the original (connection-causing) zone transfer
rfc6014
rfc6116
- If these mechanisms are used for dialing plans (or for other unrelated digit strings), the domain apex used for such translation MUST NOT be e164.arpa, to avoid conflict with this specification
- Also, the Application Unique String (see Section 3.1) used with dialing plans SHOULD be the full number as specified, without the leading '+' character
- Finally, if these techniques are used for dialing plans or other digit strings, implementers and operators of systems using these techniques for such purpose MUST NOT describe these schemes as "ENUM"
- Thus, DNS servers MAY interpret flag values and use that information to include appropriate resource records in the additional information section of the DNS packet
- If a client encounters a resource record with an unknown flag, it MUST ignore it and move to the next Rule
- If a Rule is non-terminal, then the result produced by this rewrite Rule MUST be an FQDN
- Clients MUST use this result as the new Key in the
- Where the NAPTR holds a non-terminal Rule, the Services field SHOULD be empty, and clients SHOULD ignore its content
- Such Enumservices MUST NOT be provisioned in any system that provides answers to DNS queries for NAPTR resource record sets (RRSets) from entities outside the private network context in which these Enumservices are intended for use
- that it is connected to the private network for which these NAPTRs are provisioned and intended, it MUST discard any NAPTR with an Enumservice type that starts with the "P-" facet
- Where ENUM clients can be exposed to NAPTR records that may hold field content of different capitalization, clients MUST use case- insensitive processing
- Only if a client is known to operate in an environment in which capitalization of all ENUM records it will encounter is known and controlled MAY that client use case sensitive processing
- An ENUM-compliant application MUST only pass numbers to the ENUM client query process that it believes are E.164 numbers (e.g., it MUST NOT pass dialed digit strings to the ENUM query process)
- o the domain apex used for purposes other than data associated with the E.164 number plan MUST NOT be e164.arpa
- o for use other than with E.164 numbers, the Application Unique String MUST NOT begin with the '+' character, whilst for ENUM use, the AUS MUST begin with this character
- o NAPTRs that are intended for other DDDS applications MUST NOT include the E2U token in their service field, whilst NAPTRs intended for ENUM use MUST include this token
- ENUM NAPTRs SHOULD NOT include characters outside the printable US- ASCII equivalent range (U+0020 to U+007E) unless it is clear that all ENUM clients they are designed to support will be able to process such characters correctly
- If ENUM zone provisioning systems require non-ASCII characters, these systems MUST encode the non-ASCII data to emit only US-ASCII characters by applying the appropriate mechanism (such as those in [RFC3492], [RFC3987])
- Non-printable characters SHOULD NOT be used, as ENUM clients may need to present NAPTR content in a human-readable form
- The case-sensitivity flag ('i') is inappropriate for ENUM, and SHOULD NOT be provisioned into the Regexp field of E2U NAPTRs
- The Registrant and the ENUM zone provisioning system he or she uses SHOULD NOT rely on ENUM clients solely taking account of the value of the ORDER and the PREFERENCE/PRIORITY fields in ENUM NAPTRs
- Thus, a Registrant SHOULD place into his or her zone only contacts that he or she is willing to support; even those with the worst ORDER and PREFERENCE/PRIORITY values MAY be selected by an end user
- All E2U NAPTRs SHOULD hold a default value in their ORDER field
- Multiple NAPTRs with identical ORDER and identical PREFERENCE/ PRIORITY field values SHOULD NOT be provisioned into an RRSet unless the intent is that these NAPTRs are truly identical and there is no preference between them
- Implementers SHOULD NOT assume that the DNS will deliver NAPTRs within an RRSet in a particular sequence
- An ENUM zone provisioning system SHOULD assume that, if it generates compound NAPTRs, the Enumservices will normally be processed in left- to-right order within such NAPTRs
- ENUM zone provisioning systems SHOULD assume that, once a non- terminal NAPTR has been selected for processing, the ORDER field value in a domain referred to by that non-terminal NAPTR will be considered only within the context of that referenced domain (i.e., the ORDER value will be used only to sort within the current RRSet and will not be used in the processing of NAPTRs in any other RRSet)
- ENUM zone provisioning systems SHOULD use '!' (U+0021) as their Regexp delimiter character
- If the Regexp delimiter is a character in the static text of the Repl sub-field, it MUST be "escaped" using the escaped-delimiter production of the BNF specification shown in Section 3.2 of [RFC3402] (i.e., "!", U+005C U+0021)
- If present in the ERE sub-field of an ENUM NAPTR, the literal character '+' MUST be escaped as "+" (i.e
- ENUM provisioning systems SHOULD be cautious in the use of multiple back-reference patterns in the Repl sub-field of NAPTRs they provision
- These provisioning systems SHOULD check the back-reference replacement patterns they use, ensuring that regular expression processing will not produce excessive-length URIs
- ENUM zones MUST NOT be provisioned with NAPTRs according to the obsolete syntax of [RFC2916], and MUST be provisioned with NAPTRs in which the Services field is according to Section 3.4.3 of this document
- Enumservices in which the Enumservice type starts with the facet "P-" MUST NOT be provisioned in any system that provides answers to DNS queries for NAPTR resource record sets from entities outside the private network context in which these Enumservices are intended for use
- As current support is limited, non-terminal NAPTRs SHOULD NOT be provisioned in ENUM zones unless it is clear that all ENUM clients that this environment supports can process these
- When populating a set of domains with NAPTRs, ENUM zone provisioning systems SHOULD NOT configure non-terminal NAPTRs so that more than 5 such NAPTRs will be processed in an ENUM query
- In a non-terminal NAPTR that may be encountered in an ENUM query (i.e., one with an empty Flags field), the Services field SHOULD be empty
- A non-terminal NAPTR MUST include its target domain in the (non-empty) Replacement field, as this field will be interpreted as holding the FQDN that forms the next key output from this non- terminal Rule
- The Regexp field MUST be empty in a non-terminal NAPTR intended to be encountered during an ENUM query
- If a NAPTR is discarded, this SHOULD NOT cause the whole ENUM query to terminate and processing SHOULD continue with the next NAPTR in the returned RRSet
- ENUM clients SHOULD NOT discard NAPTRs in which they detect characters outside the US-ASCII printable range (0x20 to 0x7E hexadecimal)
- ENUM clients MAY discard NAPTRs that have octets in the Flags, Services, or Regexp fields that have byte values outside the US-ASCII equivalent range (i.e., byte values above 0x7F)
- Clients MUST be ready to encounter NAPTRs with such values without failure
- ENUM clients MUST sort the records of a retrieved NAPTR RRSet into sequence using the ORDER and PREFERENCE fields of those records
- ENUM clients SHOULD NOT discard a NAPTR record until it is considered or a record previous to it in the evaluation sequence has been accepted
- Notably, if a record has a "worse" ORDER value than others in this RRSet, that record MUST NOT be discarded before consideration unless a record has been accepted as the result of this ENUM query
- Where the ENUM client presents a list of possible URLs to the end user for his or her choice, it MAY present all NAPTRs -- not just the ones with the lowest currently unprocessed ORDER field value
- The client SHOULD observe the ORDER and PREFERENCE/PRIORITY values specified by the Registrant
- ENUM clients SHOULD accept all NAPTRs with identical ORDER and identical PREFERENCE/PRIORITY field values, and process them in the sequence in which they appear in the DNS response
- ENUM clients SHOULD consider the ORDER field value only when sorting NAPTRs within a single RRSet
- The ORDER field value SHOULD NOT be taken into account when processing NAPTRs across a sequence of DNS queries created by traversal of non-terminal NAPTR references
- ENUM clients receiving compound NAPTRs (i.e., ones with more than one Enumservice) SHOULD process these Enumservices using a left-to-right sort ordering, so that the first Enumservice to be processed will be the leftmost one, and the last will be the rightmost one
- ENUM clients MUST be ready to process NAPTRs that use a different character from '!' as their Regexp Delimiter without failure
- ENUM clients SHOULD NOT assume that the delimiter is the last character of the Regexp field
- ENUM clients SHOULD discard NAPTRs that have more or less than 3 unescaped instances of the delimiter character within the Regexp field
- In the spirit of being liberal with what it will accept, if the ENUM client is sure how the Regexp field should be interpreted, it MAY choose to process the NAPTR even in the face of an incorrect number of unescaped delimiter characters
- If it is not clear how the Regexp field should be interpreted, the client MUST discard the NAPTR
- ENUM clients MUST be ready to process NAPTRs that have non-trivial patterns in their ERE sub-field values without failure
- ENUM clients MUST be ready to process NAPTRs with many copies of back-reference patterns within the Repl sub-field without failure
- ENUM clients MUST be ready to process NAPTRs with a DDDS Application identifier other than 'E2U' without failure
- When an ENUM client encounters a compound NAPTR (i.e., one containing more than one Enumservice) and cannot process or cannot recognize one of the Enumservices within it, that ENUM client SHOULD ignore this Enumservice and continue with the next Enumservice within this NAPTR's Services field, discarding the NAPTR only if it cannot handle any of the Enumservices contained
- These conditions SHOULD NOT be considered errors
- ENUM clients MUST support ENUM NAPTRs according to syntax defined in Section 3.4.3
- ENUM clients SHOULD also support ENUM NAPTRs according to the obsolete syntax of [RFC2916]; there are still zones that hold "old" syntax NAPTRs
- Unless an ENUM client is sure that it is connected to the private network for which these NAPTRs are provisioned and intended, it MUST discard any NAPTR with an Enumservice type that starts with the "P-" facet
- ENUM clients MUST be ready to process NAPTRs with an empty Flags field ("non-terminal" NAPTRs) without failure
- More generally, non- terminal NAPTR processing SHOULD be implemented, but ENUM clients MAY discard non-terminal NAPTRs they encounter
- ENUM clients SHOULD ignore any content of the Services field when encountering a non-terminal NAPTR with an empty Flags field
- ENUM clients receiving a non-terminal NAPTR with an empty Flags field MUST treat the Replacement field as holding the FQDN to be used in the next round of the ENUM query
- An ENUM client MUST discard such a non-terminal NAPTR if the Replacement field is empty or does not contain a valid FQDN
- If present in a non-terminal NAPTR, a non-empty Regexp field MUST be ignored by ENUM clients
- If a problem is detected when processing an ENUM query across multiple domains (by following non-terminal NAPTR references), the ENUM query SHOULD NOT be abandoned, but instead processing SHOULD
- If all NAPTRs in a domain traversed as a result of a reference in a non-terminal NAPTR have been discarded, the ENUM client SHOULD continue its processing with the next NAPTR in the "referring" RRSet (i.e., the one including the non-terminal NAPTR that caused the traversal)
- ENUM clients MUST be prepared to encounter a referential loop in which a sequence of non-terminal NAPTRs are retrieved within an ENUM query that refer back to an earlier FQDN
- ENUM clients MUST be able to detect and recover from such a loop, without failure
- ENUM clients MAY consider a chain of more than 5 "non-terminal" NAPTRs traversed in a single ENUM query as an indication that a referential loop has been entered
- When a domain is about to be entered as the result of a reference in a non-terminal NAPTR, and the ENUM client has detected a potential referential loop, the client SHOULD discard the non-terminal NAPTR from its processing and continue with the next NAPTR in its list
- It SHOULD NOT make the DNS query indicated by that non-terminal NAPTR
- Because of these threats, a deployed ENUM service SHOULD include mechanisms to mitigate these threats
- A service SHOULD always authenticate the entity to which it connects during the service setup phase, and not rely on address or identity data retrieved outside that service
- Finally, as an ENUM service will be implementing some type of security mechanism, software that implements ENUM MUST be prepared to receive DNSSEC and other standardized DNS security responses, including large responses and other EDNS0 signaling (see [RFC2671]), unknown resource records (see [RFC3597]), and so on
- In environments where changes to any of the chain of resource records or dynamic assignments to IP addresses occur, those systems provisioning this data SHOULD take care to minimize changes and to consider the respective times to live of resource records and/or DHCP lease times
- Users of this data SHOULD take care to detect and recover from unintended communications session attempts; in a transient environment, these may occur
rfc6117
- Introduction (REQUIRED)
- IANA Registration (REQUIRED)
- Examples (REQUIRED)
- Implementation Recommendations / Notes (OPTIONAL)
- DNS Considerations (REQUIRED)
- Security Considerations (REQUIRED)
- IANA Considerations (REQUIRED)
- Other Sections (OPTIONAL)
- To allow for interoperability, a complete Enumservice Specification MUST document the semantics of the Type and Subtype values to be registered, and MUST contain all sections listed in Section 5 of this document
- That means the Enumservice Specification MUST define how to use the NAPTR RR and the URI(s) the NAPTR RR resolves to
- Specifically, a registered Enumservice MUST specify the URI Scheme(s) that may be used for the Enumservice, and, when needed, other information that will have to be transferred into the URI resolution process itself
- The name of an Enumservice MUST be unique in order to be useful as a selection criteria:
- o The Type MUST be unique
- o The Subtype (being dependent on the Type) MUST be unique within a given Type
- Types and Subtypes MUST conform to the ABNF specified in Section 3.4.3 of [RFC6116]
- To avoid confusion with possible future prefixes, a "-" MUST NOT be used as the first nor as the second character of a Type nor a Subtype
- Furthermore, a "-" MUST NOT be used as the last character of a Type nor a Subtype
- In addition, Types and Subtypes are case insensitive and SHOULD be specified in lowercase letters
- To avoid confusion with Enumservice fields using a deprecated (obsolete) syntax, Type and Subtype MUST NOT start with the string "e2u"
- The Subtype for one Type MAY have the same identifier as a Subtype for another Type, but it is not sufficient to simply reference another Type's Subtype
- The functionality of each Subtype MUST be fully specified in the context of the Type being registered
- An analysis of security issues is REQUIRED for all registered Enumservices
- All descriptions of security issues MUST be as accurate and extensive as feasible
- Nevertheless, all known security risks MUST be identified in an Enumservice Specification
- Enumservices Specifications MUST be published according to the requirements for "Specification Required" set out in "Guidelines for Writing an IANA Considerations Section in RFCs" [RFC5226]
- Therefore, it is strongly RECOMMENDED to publish Enumservice Specifications as RFCs
- In case the Enumservice Specification is not published as an RFC, sufficient information that allows unique identification of the Enumservice Specification MUST be provided
- Service Types might also be displayed to end users in implementations, so meaningful Type strings having a clear relation to the protocols and applications used are strongly RECOMMENDED
- The Classification of each Enumservice MUST be listed in the Registration Document (see Section 5.2)
- If the Enumservice cannot be assigned to one of the classes outlined below, the Registration Document MUST contain a section on the difficulties encountered while trying to classify the service to help the experts in their decision
- To avoid confusion, the name of a URI Scheme MUST NOT be used as a Type string for an Enumservice that is not specifically about the respective protocol or URI Scheme
- If Subtypes are defined, the minimum number SHOULD be two (including the empty Subtype, if defined)
- In that case, however, the Enumservice with an empty Subtype SHOULD be specified to reflect the base service, while the other Enumservices SHOULD be specified to reflect variants
- The expected behavior of a system using this Enumservice MUST be clear from the protocol
- A protocol-based Enumservice SHOULD use the lowercase name of the protocol as its Type string
- Where there is a single URI Scheme associated with this protocol, a Subtype SHOULD NOT be specified for the Enumservice
- Where there are a number of different URI Schemes associated with this protocol, the Enumservice Specification MAY use the empty Subtype for all URI Schemes that it specifies as mandatory to implement
- For each URI Scheme that is not mandatory to implement, a distinct Subtype string MUST be used
- If Subtypes are defined, it is RECOMMENDED to use the URI Scheme name as the Subtype string
- The Enumservice Specification MUST describe the interaction and expected behavior in enough detail that an
- However, it is RECOMMENDED that the Enumservice be defined in a way that will allow others to use it at a later date
- Any such Enumservice Specification MUST define the options available by use of this NAPTR in enough detail that an implementation can decide whether or not it can use this Enumservice
- It is RECOMMENDED that the URI Scheme(s) used by the application be used as the Subtype string(s)
- Subtype strings MAY be shared between URI Schemes, if all the URI Schemes within the same Subtype are mandatory to implement
- If it is foreseen that there is only one URI Scheme ever to be used with the application, the empty Subtype string MAY be used
- It is RECOMMENDED to use the URI Schemes used to access the service as Subtype strings
- Subtype strings MAY be shared between URI Schemes, if all the URI Schemes within the same Subtype are mandatory to implement
- If there is only one URI Scheme foreseen to access the data type or format, the empty Subtype string MAY be used
- In case an Enumservice proposal cannot be assigned to any of the classes mentioned above, the element (Enumservice Class) in the IANA Registration Template (see Section 5.2) MUST be populated with "Other"
- In that case, the Enumservice Specification MUST contain a section elaborating on why the Enumservice does not fit into the classification structure
- There are several sections that MUST appear in an Enumservice Specification
- These sections are as follows, and they SHOULD be in the given order
- The following terms SHOULD begin with a capital letter, whenever they refer to the IANA Registration: o Class o Type o Subtype o URI Scheme
- An introductory section MUST be included
- The Introduction SHOULD start with a short sentence about ENUM, introduce the protocol used in the Enumservice, and discuss the Enumservice as it refers from the E.164 number to the protocol or service
- This section MUST be included in an Enumservice Specification
- Where a given Enumservice Type has multiple Subtypes, there MUST be a separate "IANA Registration" section for each Subtype
- Its value MUST be one of (without quotes):
- All Types SHOULD be listed in lower- case
- All Subtypes SHOULD be listed in lower-case
- Should the Enumservice not utilize a Subtype, then the element MUST be omitted in the IANA Registration Template
- If a given Enumservice Type has multiple Subtypes, then there MUST be a separate IANA Registration Template for each Subtype
- A colon MUST NOT be placed after the URI Scheme name
- If there is more than one URI Scheme, then one element per URI scheme MUST be used in the IANA Registration Template
- Applications SHOULD however expect to encounter legacy instances of this Enumservice
- If there is more than one requester, there MUST be one element per requester in the element, and one chunk per requester in the element
- This section MUST show at least one example of the Enumservice being registered, for illustrative purposes
- The example(s) MUST show the specific formatting of the intended NAPTRs (according to [RFC3403] and [RFC6116]), including one or more NAPTR example(s), AND a brief textual description, consisting of one or more sentences written in plain English, explaining the various parts or attributes of the record(s)
- The example(s) SHOULD contain a brief description how a client supporting this Enumservice could behave, if that description was not already given in, e.g., the Introduction or the Functional Specification
- The example(s) SHOULD follow any relevant IETF guidelines on the use of domain names, phone numbers, and other resource identifier examples, such as [RFC2606]
- Recommendations that pertain to implementation and/or operations SHOULD be included
- In case the inclusion of protocols and URI Schemes into ENUM specifically introduces new DNS issues, those MUST be described within this section
- A section explaining any potential security threats that are especially applicable to the given registration MUST be included
- This MUST also include any information about access to Personally Identifiable Information (PII)
- An Enumservice Specification SHOULD NOT include general and obvious security recommendations, such as securing servers with strong password authentication
- Enumservice Specifications do not need to and SHOULD NOT repeat considerations already listed in that document
- However, Enumservice Specifications SHOULD include a reference to that section
- Enumservice Specifications do not need to and SHOULD NOT repeat security considerations affecting those protocols and URI Schemes themselves
- In these cases, those issues or risks MUST be covered in the "Security Considerations" section of the Enumservice Specification
- Other sections beyond those required above MAY be included in an Enumservice Specification
- A use case SHOULD be included by the authors of the proposal, so that experts can better understand the problem the proposal seeks to solve (intended use of the Enumservice)
- As set out in Section 3.4 it is strongly RECOMMENDED that Enumservice Specifications be published RFCs
- These existing Enumservice Specifications MAY be revised to comply with the specifications contained herein
- All revisions of Enumservice Specifications MUST be compliant with the specifications contained herein
- Any Enumservice Specifications for existing Enumservices that are extended MUST comply with the specifications contained herein
- Updates of Enumservice Specifications MUST comply with the requirements described in this document
- As stated in Section 3.2, a "-" (dash) MUST NOT be used as the first nor as the second nor as the last character of a Type or a Subtype
- Furthermore, Type or Subtype of any Enumservice MUST NOT be set to, nor start with, "E2U"
rfc6147
- The implementation SHOULD support mapping of separate IPv4 address ranges to separate IPv6 prefixes for AAAA record synthesis
- DNS64 operation for classes other than IN is undefined, and a DNS64 MUST behave as though no DNS64 function is configured
- If there is (non-excluded) AAAA data available, DNS64 SHOULD NOT include synthetic AAAA RRs in the response (see Appendix A for an analysis of the motivations for and the implications of not complying with this recommendation)
- By default, DNS64 implementations MUST NOT synthesize AAAA RRs when real AAAA RRs exist
- A DNS64 implementation SHOULD provide a mechanism to specify IPv6 prefix ranges to be treated as though the AAAA containing them were an empty answer
- An implementation SHOULD include the ::ffff/96 network in that range by default
- When the DNS64 performs its initial AAAA query, if it receives an answer with only AAAA records containing addresses in the excluded range(s), then it MUST treat the answer as though it were an empty answer, and proceed accordingly
- If it receives an answer with at least one AAAA record containing an address outside any of the excluded range(s), then it by default SHOULD build an answer section for a response including only the AAAA record(s) that do not contain any of the addresses inside the excluded ranges
- Alternatively, it MAY treat the answer as though it were an empty answer, and proceed accordingly
- It MUST NOT return the offending AAAA records as part of a response
- If the SOA RR was not delivered with the negative response to the AAAA query, then the DNS64 SHOULD use the TTL of the original A RR or 600 seconds, whichever is shorter
- The DNS64 MUST check each A RR against configured IPv4 address ranges and select the corresponding IPv6 prefix to use in synthesizing the AAAA RR
- The DNS64 MAY perform the query for the AAAA RR and for the A RR in parallel, in order to minimize the delay
- o The same algorithm to create an IPv6 address from an IPv4 address MUST be used by both a DNS64 to create the IPv6 address to be returned in the synthetic AAAA RR from the IPv4 address contained in an original A RR, and by an IPv6/IPv4 translator to create the IPv6 address to be included in the source address field of the outgoing IPv6 packets from the IPv4 address included in the source address field of the incoming IPv4 packet
- o The algorithm MUST be reversible; i.e., it MUST be possible to derive the original IPv4 address from the IPv6 representation
- o The input for the algorithm MUST be limited to the IPv4 address; the IPv6 prefix (denoted Pref64::/n) used in the IPv6 representations; and, optionally, a set of stable parameters that are configured in the DNS64 and in the NAT64 (such as a fixed string to be used as a suffix)
- For each prefix Pref64::/n, n MUST be less than or equal to 96
- If one or more Pref64::/n are configured in the DNS64 through any means (such as manual configuration, or other automatic means not specified in this document), the default algorithm MUST use these prefixes (and not use the Well-Known Prefix)
- If no prefix is available, the algorithm MUST use the Well-Known Prefix 64:ff9b::/96 defined in [RFC6052] to represent the IPv4 unicast address range
- A DNS64 MUST support the algorithm for generating IPv6 representations of IPv4 addresses defined in Section 2 of [RFC6052]
- Moreover, the aforementioned algorithm MUST be the default algorithm used by the DNS64
- If a DNS64 server receives a PTR query for a record in the IP6.ARPA domain, it MUST strip the IP6.ARPA labels from the QNAME, reverse the address portion of the QNAME according to the encoding scheme outlined in Section 2.5 of [RFC3596], and examine the resulting address to see whether its prefix matches any of the locally configured Pref64::/n or the default Well-Known Prefix
- A DNS64 server MUST provide one of these, and SHOULD NOT provide both at the same time unless different IP6.ARPA zones require answers of different sorts:
- If the address prefix matches any Pref64::/n used in the site, either a NSP or the Well-Known Prefix (i.e., 64:ff9b::/96), then the DNS64 server MAY answer the query using locally appropriate RDATA
- The DNS64 server MAY use the same RDATA for all answers
- In this case, the DNS64 name server SHOULD ensure that there is RDATA at the PTR of the corresponding IN-ADDR.ARPA name, and that there is not an existing CNAME at that name
- If the address prefix does not match any Pref64::/n, then the DNS64 server MUST process the query as though it were any other query; i.e., a recursive name server MUST attempt to resolve the query as though it were any other (non-A/AAAA) query, and an authoritative server MUST respond authoritatively or with a referral, as appropriate
- DNS64 synthesis MUST NOT be performed on any records in the additional section of synthesized answers
- The DNS64 MUST pass the additional section unchanged
- All other RRs MUST be returned unchanged
- If CD is not set and DO is not set, vDNS64 SHOULD perform validation and do synthesis as needed
- In this case, however, vDNS64 MUST NOT set the AD bit in any response
- If CD is not set and DO is set, then vDNS64 SHOULD perform validation
- Whenever vDNS64 performs validation, it MUST validate the negative answer for AAAA queries before proceeding to query for A records for the same name, in order to be sure that there is not a legitimate AAAA record on the Internet
- If the negative response validates, and the response to the A query validates, then the vDNS64 MAY perform synthesis and SHOULD set the AD bit in the answer to the client
- In this case, the name server has reason to believe the RRSets are all authentic, so it SHOULD set the AD bit
- If the data does not validate, the vDNS64 MUST respond with RCODE=2 (Server failure)
- If the CD bit is set and DO is set, then vDNS64 MAY perform validation, but MUST NOT perform synthesis
- It MUST return the data to the query initiator, just like a regular recursive resolver, and depend on the client to do the validation and the synthesis itself
rfc6376
- The DKIM-Quoted-Printable encoding syntax resembles that described in Quoted-Printable [RFC2045], Section 6.7: any character MAY be encoded as an "=" followed by two hexadecimal digits from the alphabet "0123456789ABCDEF" (no lowercase characters permitted) representing the hexadecimal-encoded integer value of that character
- All control characters (those with values < %x20), 8-bit characters (values > %x7F), and the characters DEL (%x7F), SPACE (%x20), and semicolon (";", %x3B) MUST be encoded
- Note that all whitespace, including SPACE, CR, and LF characters, MUST be encoded
- After encoding, FWS MAY be added at arbitrary locations in order to avoid excessively long lines; such whitespace is NOT part of the value, and MUST be removed before decoding
- Use of characters not listed as "mail-safe" in [RFC2049] is NOT RECOMMENDED
- Unencoded semicolon (";") characters MUST NOT occur in the tag value, since that separates tag-specs
- Tags MUST be interpreted in a case-sensitive manner
- Values MUST be processed as case sensitive unless the specific tag description of semantics specifies case insensitivity
- Tags with duplicate names MUST NOT occur within a single tag-list; if a tag name does occur more than once, the entire tag-list is invalid
- Whitespace within a value MUST be retained unless explicitly excluded by the specific tag description
- Tag=value pairs that represent the default value MAY be included to aid legibility
- Unrecognized tags MUST be ignored
- Signers MUST implement and SHOULD sign using rsa-sha256
- Verifiers MUST implement both rsa-sha1 and rsa-sha256
- The hash MUST NOT be truncated or converted into any form other than the native binary form before being signed
- The signing algorithm SHOULD use a public exponent of 65537
- The hash MUST NOT be truncated or converted into any form other than the native binary form before being signed
- The signing algorithm SHOULD use a public exponent of 65537
- Since short RSA keys more easily succumb to off-line attacks, Signers MUST use RSA keys of at least 1024 bits for long-lived keys
- Verifiers MUST be able to validate signatures with keys ranging from 512 bits to 2048 bits, and they MAY be able to validate signatures with larger keys
- Other algorithms MAY be defined in the future
- Verifiers MUST ignore any signatures using algorithms that they do not implement
- A Signer MAY specify either algorithm for header or body when signing an email
- Verifiers MUST implement both canonicalization algorithms
- Further canonicalization algorithms MAY be defined in the future; Verifiers MUST ignore any signatures that use unrecognized canonicalization algorithms
- It MUST NOT change the transmitted data in any way
- Header fields MUST be presented to the signing or verification algorithm exactly as they are in the message being signed or verified
- In particular, header field names MUST NOT be case folded and whitespace MUST NOT be changed
- The "relaxed" header canonicalization algorithm MUST apply the following steps in order:
- o Unfold all header field continuation lines as described in [RFC5322]; in particular, lines with terminators embedded in continued header field values (that is, CRLF sequences followed by WSP) MUST be interpreted without the CRLF
- Implementations MUST NOT remove the CRLF at the end of the header field value
- The colon separator MUST be retained
- The "relaxed" body canonicalization algorithm MUST apply the following steps (a) and (b) in order:
- Implementations MUST NOT remove the CRLF at the end of the line
- The DKIM-Signature header field SHOULD be treated as though it were a trace header field as defined in Section 3.6 of [RFC5322] and hence SHOULD NOT be reordered and SHOULD be prepended to the message
- The DKIM-Signature header field being created or verified is always included in the signature calculation, after the rest of the header fields being signed; however, when calculating or verifying the signature, the value of the "b=" tag (signature value) of that DKIM- Signature header field MUST be treated as though it were an empty string
- Unknown tags in the DKIM-Signature header field MUST be included in the signature calculation but MUST be otherwise ignored by Verifiers
- Unrecognized tags MUST be ignored
- v= Version (plain-text; REQUIRED)
- It MUST have the value "1" for implementations compliant with this version of DKIM
- a= The algorithm used to generate the signature (plain-text; REQUIRED)
- Verifiers MUST support "rsa-sha1" and "rsa-sha256"; Signers SHOULD sign using "rsa-sha256"
- b= The signature data (base64; REQUIRED)
- Whitespace is ignored in this value and MUST be ignored when reassembling the original signature
- bh= The hash of the canonicalized body part of the message as limited by the "l=" tag (base64; REQUIRED)
- Whitespace is ignored in this value and MUST be ignored when reassembling the original signature
- c= Message canonicalization (plain-text; OPTIONAL, default is "simple/simple")
- d= The SDID claiming responsibility for an introduction of a message into the mail stream (plain-text; REQUIRED)
- The SDID MUST correspond to a valid DNS name under which the DKIM key record is published
- When presented with a signature that does not meet these requirements, Verifiers MUST consider the signature invalid
- Internationalized domain names MUST be encoded as A-labels, as described in Section 2.3 of [RFC5890]
- h= Signed header fields (plain-text, but see description; REQUIRED)
- The field MUST contain the complete list of header fields in the order presented to the signing algorithm
- The field MAY contain names of header fields that do not exist when signed; nonexistent header fields do not contribute to the signature computation (that is, they are treated as the null input, including the header field name, the separating colon, the header field value, and any CRLF terminator)
- The field MAY contain multiple instances of a header field name, meaning multiple occurrences of the corresponding header field are included in the header hash
- The field MUST NOT include the DKIM-Signature header field that is being created or verified but may include others
- Folding whitespace (FWS) MAY be included on either side of the colon separator
- Header field names MUST be compared against actual header field names in a case-insensitive manner
- This list MUST NOT be empty
- i= The Agent or User Identifier (AUID) on behalf of which the SDID is taking responsibility (dkim-quoted-printable; OPTIONAL, default is an empty local-part followed by an "@" followed by the domain from the "d=" tag)
- The syntax is a standard email address where the local-part MAY be omitted
- The domain part of the address MUST be the same as, or a subdomain of, the value of the "d=" tag
- Internationalized domain names MUST be encoded as A-labels, as described in Section 2.3 of [RFC5890]
- Notably, the domain name need not be registered in the DNS -- so it might not resolve in a query -- and the local-part MAY be drawn from a namespace unrelated to any mailbox
- The Signer MAY choose to use the same namespace for its AUIDs as its users' email addresses or MAY choose other means of representing its users
- However, the Signer SHOULD use the same AUID for each message intended to be evaluated as being within the same sphere of responsibility, if it wishes to offer receivers the option of using the AUID as a stable identifier that is finer grained than the SDID
- l= Body length count (plain-text unsigned decimal integer; OPTIONAL, default is entire body)
- This value MUST NOT be larger than the actual number of octets in the canonicalized message body
- q= A colon-separated list of query methods used to retrieve the public key (plain-text; OPTIONAL, default is "dns/txt")
- If there are multiple query mechanisms listed, the choice of query mechanism MUST NOT change the interpretation of the signature
- Implementations MUST use the recognized query mechanisms in the order presented
- Unrecognized query mechanisms MUST be ignored
- The only option defined for the "dns" query type is "txt", which MUST be included
- Verifiers and Signers MUST support "dns/txt"
- s= The selector subdividing the namespace for the "d=" (domain) tag (plain-text; REQUIRED)
- Internationalized selector names MUST be encoded as A-labels, as described in Section 2.3 of [RFC5890]
- t= Signature Timestamp (plain-text unsigned decimal integer; RECOMMENDED, default is an unknown creation time)
- Implementations SHOULD be prepared to handle values up to at least 10^12 (until approximately AD 200,000; this fits into 40 bits)
- To avoid denial-of-service attacks, implementations MAY consider any value longer than 12 digits to be infinite
- Implementations MAY ignore signatures that have a timestamp in the future
- x= Signature Expiration (plain-text unsigned decimal integer; RECOMMENDED, default is no expiration)
- Signatures MAY be considered invalid if the verification time at the Verifier is past the expiration date
- The value of the "x=" tag MUST be greater than the value of the "t=" tag if both are present
- Receivers MAY add a 'fudge factor' to allow for such possible drift
- z= Copied header fields (dkim-quoted-printable, but see description; OPTIONAL, default is null)
- After encoding, FWS MAY be added at arbitrary locations in order to avoid excessively long lines; such whitespace is NOT part of the value of the header field and MUST be removed before decoding
- The following definition MUST be used for any DKIM key represented in an otherwise unstructured textual form
- Other tags MAY be present and MUST be ignored by any implementation that does not understand them
- v= Version of the DKIM key record (plain-text; RECOMMENDED, default is "DKIM1")
- If specified, this tag MUST be set to "DKIM1" (without the quotes)
- This tag MUST be the first tag in the record
- Records beginning with a "v=" tag with any other value MUST be discarded
- h= Acceptable hash algorithms (plain-text; OPTIONAL, defaults to allowing all algorithms)
- Unrecognized algorithms MUST be ignored
- k= Key type (plain-text; OPTIONAL, default is "rsa")
- Signers and Verifiers MUST support the "rsa" key type
- (Note: the "p=" tag further encodes the value using the base64 algorithm.) Unrecognized key types MUST be ignored
- n= Notes that might be of interest to a human (qp-section; OPTIONAL, default is empty)
- p= Public-key data (base64; REQUIRED)
- Verifiers SHOULD return an error code for any DKIM-Signature header field with a selector referencing a revoked key
- s= Service Type (plain-text; OPTIONAL; default is "*")
- Verifiers for a given service type MUST ignore this record if the appropriate type is not listed
- Unrecognized service types MUST be ignored
- t= Flags, represented as a colon-separated list of names (plain- text; OPTIONAL, default is no flags set)
- Unrecognized flags MUST be ignored
- Verifiers MUST NOT treat messages from Signers in testing mode differently from unsigned email, even should the signature fail to verify
- Verifiers MAY wish to track testing mode results to assist the Signer
- s Any DKIM-Signature header fields using the "i=" tag MUST have the same domain value on the right-hand side of the "@" in the "i=" tag and the value of the "d=" tag
- That is, the "i=" domain MUST NOT be a subdomain of "d="
- Use of this flag is RECOMMENDED unless subdomaining is required
- All implementations MUST support this binding
- Strings in a TXT RR MUST be concatenated together before use with no intervening whitespace
- TXT RRs MUST be unique for a particular selector name; that is, if there are multiple records in an RRset, the results are undefined
- The Signer/Verifier MUST compute two hashes: one over the body of the message and one over the selected header fields of the message
- Signers MUST compute them in the order shown
- Verifiers MAY compute them in any order convenient to the Verifier, provided that the result is semantically identical to the semantics that would be the case had they been computed in this order
- In hash step 1, the Signer/Verifier MUST hash the message body, canonicalized using the body canonicalization algorithm specified in the "c=" tag and then truncated to the length specified in the "l=" tag
- In hash step 2, the Signer/Verifier MUST pass the following to the hash algorithm in the indicated order
- Each header field MUST be terminated with a single CRLF
- All tags and their values in the DKIM-Signature header field are included in the cryptographic hash with the sole exception of the value portion of the "b=" (signature) tag, which MUST be treated as the null string
- All tags MUST be included even if they might not be understood by the Verifier
- The header field MUST be presented to the hash algorithm after the body of the message rather than with the rest of the header fields and MUST be canonicalized as specified in the "c=" (canonicalization) tag
- The DKIM-Signature header field MUST NOT be included in its own "h=" tag, although other DKIM- Signature header fields MAY be signed (see Section 4)
- When calculating the hash on messages that will be transmitted using base64 or quoted-printable encoding, Signers MUST compute the hash after the encoding
- Likewise, the Verifier MUST incorporate the
- However, the hash MUST be computed before transport-level encodings such as SMTP "dot-stuffing" (the modification of lines beginning with a "." to avoid confusion with the SMTP end-of-message marker, as specified in [RFC5321])
- DKIM messages MAY be either in plain-text or in MIME format; no special treatment is afforded to MIME content
- Message attachments in MIME format MUST be included in the content that is signed
- Therefore, Signers and Verifiers SHOULD take reasonable steps to ensure that the messages they are processing are valid according to [RFC5322], [RFC2045], and any other relevant message format standards
- For each signature that verifies successfully or produces a TEMPFAIL result, output of the DKIM algorithm MUST include the set of:
- The output MAY include other signature properties or result meta- data, including PERMFAILed or otherwise ignored signatures, for use by modules that consume those results
- In order to limit the capability of such keys when this is not intended, the "s" flag MAY be set in the "t=" tag of the key record, to constrain the validity of the domain of the AUID
- If the referenced key record contains the "s" flag as part of the "t=" tag, the domain of the AUID ("i=" flag) MUST be the same as that of the SDID (d=) domain
- If this flag is absent, the domain of the AUID MUST be the same as, or a subdomain of, the SDID
- DKIM MAY optionally provide a single responsible Agent or User Identifier (AUID)
- Upon successfully verifying the signature, a receive-side DKIM Verifier MUST communicate the Signing Domain Identifier (d=) to a consuming Identity Assessor module and MAY communicate the Agent or User Identifier (i=) if present
- A Signer MAY sign previously existing DKIM-Signature header fields using the method described in Section 5.4 to sign trace header fields
- A Signer MAY add more than one DKIM-Signature header field using different parameters
- Signers SHOULD NOT remove any DKIM-Signature header fields from messages they are signing, even if they know that the signatures cannot be verified
- When evaluating a message with multiple signatures, a Verifier SHOULD evaluate signatures independently and on their own merits
- Verifiers MAY process signatures in any order of their choice; for example, some Verifiers might choose to process signatures corresponding to the From field in the message header before other signatures
- Verifiers SHOULD continue to check signatures until a signature successfully verifies to the satisfaction of the Verifier
- To limit potential denial-of-service attacks, Verifiers MAY limit the total number of signatures they will attempt to verify
- If a Verifier module reports signatures whose evaluations produced PERMFAIL results, Identity Assessors SHOULD ignore those signatures (see Section 6.1), acting as though they were not present in the message
- In order to minimize the chances of such breakage, Signers SHOULD convert the message to a suitable MIME content-transfer encoding such as quoted-printable or base64 as described in [RFC2045] before signing
- Such conversion is outside the scope of DKIM; the actual message SHOULD be converted to 7-bit MIME by an MUA or MSA prior to presentation to the DKIM algorithm
- If the message is submitted to the Signer with any local encoding that will be modified before transmission, that modification to canonical [RFC5322] form MUST be done before signing
- separator convention) MUST be converted to the SMTP-standard CRLF sequence before the message is signed
- Any conversion of this sort SHOULD be applied to the message actually sent to the recipient(s), not just to the version presented to the signing algorithm
- More generally, the Signer MUST sign the message as it is expected to be received by the Verifier rather than in some local or internal form
- A body length count MAY be specified to limit the signature calculation to an initial prefix of the body text, measured in octets
- The body length count MUST be calculated following the canonicalization algorithm; for example, any whitespace ignored by a canonicalization algorithm is not included as part of the body length count
- The From header field MUST be signed (that is, included in the "h=" tag of the resulting DKIM-Signature header field)
- Signers SHOULD NOT sign an existing header field likely to be legitimately modified or removed in transit
- Signers MAY include any other header fields present at the time of signing at the discretion of the Signer
- The DKIM-Signature header field is always implicitly signed and MUST NOT be included in the "h=" tag except to indicate that other preexisting signatures are also signed
- Signers MAY claim to have signed header fields that do not exist (that is, Signers MAY include the header field name in the "h=" tag even if that header field does not exist in the message)
- When computing the signature, the nonexisting header field MUST be treated as the null string (including the header field name, header field value, all punctuation, and the trailing CRLF)
- o From (REQUIRED; see Section 5.4)
- Signers SHOULD choose canonicalization algorithms based on the types of messages they process and their aversion to risk
- Signers choosing to sign an existing header field that occurs more than once in the message (such as Received) MUST sign the physically last instance of that header field in the header block
- Signers wishing to sign multiple instances of such a header field MUST include the header field name multiple times in the "h=" tag of the DKIM-Signature header field and MUST sign such header fields in order from the bottom of the header field block to the top
- The Signer MAY include more instances of a header field name in "h=" than there are actual corresponding header fields so that the signature will not verify if additional header fields of that name are added
- The Signer MUST compute the message hash as described in Section 3.7 and then sign it using the selected public-key algorithm
- Entities such as mailing list managers that implement DKIM and that modify the message or a header field (for example, inserting unsubscribe information) before retransmitting the message SHOULD check any existing signature on input and MUST make such modifications before re-signing the message
- Finally, the Signer MUST insert the DKIM-Signature header field created in the previous step prior to transmitting the email
- The DKIM-Signature header field MUST be the same as used to compute the hash as described above, except that the value of the "b=" tag MUST be the appropriately signed hash computed in the previous step, signed using the algorithm specified in the "a=" tag of the DKIM- Signature header field and using the private key corresponding to the selector given in the "s=" tag of the DKIM-Signature header field, as chosen above in Section 5.2
- The DKIM-Signature header field MUST be inserted before any other DKIM-Signature fields in the header block
- Since a Signer MAY remove or revoke a public key at any time, it is advised that verification occur in a timely manner
- A border or intermediate MTA MAY verify the message signature(s)
- An MTA who has performed verification MAY communicate the result of that verification by adding a verification header field to incoming messages
- A verifying MTA MAY implement a policy with respect to unverifiable mail, regardless of whether or not it applies the verification header field to signed messages
- Verifiers MUST produce a result that is semantically equivalent to applying the steps listed in Sections 6.1, 6.1.1, and 6.1.2 in order
- The order in which Verifiers try DKIM-Signature header fields is not defined; Verifiers MAY try signatures in any order they like
- Verifiers MUST NOT attribute ultimate meaning to the order of multiple DKIM-Signature header fields
- Therefore, a Verifier SHOULD NOT treat a message that has one or more bad signatures and no good signatures differently from a message with no signature at all
- A Verifier MAY limit the number of signatures it tries, in order to avoid denial-of-service attacks (see Section 8.4 for further discussion)
- In the following description, text reading "return status (explanation)" (where "status" is one of "PERMFAIL" or "TEMPFAIL") means that the Verifier MUST immediately cease processing that signature
- The Verifier SHOULD proceed to the next signature, if one
- A Verifier MAY either arrange to defer the message for later processing or try another signature; if no good signature is found and any of the signatures resulted in a TEMPFAIL status, the Verifier MAY arrange to defer the message for later processing
- Verifiers that are prepared to validate multiple signature header fields SHOULD proceed to the next signature header field, if one exists
- However, Verifiers MAY make note of the fact that an invalid signature was present for consideration at a later step
- Implementers MUST meticulously validate the format and values in the DKIM-Signature header field; any inconsistency or unexpected values MUST cause the header field to be completely ignored and the Verifier to return PERMFAIL (signature syntax error)
- Verifiers MUST return PERMFAIL (incompatible version) when presented a DKIM-Signature header field with a "v=" tag that is inconsistent with this specification
- If any tag listed as "required" in Section 3.5 is omitted from the DKIM-Signature header field, the Verifier MUST ignore the DKIM- Signature header field and return PERMFAIL (signature missing required tag)
- If the DKIM-Signature header field does not contain the "i=" tag, the Verifier MUST behave as though the value of that tag were "@d", where "d" is the value from the "d=" tag
- Verifiers MUST confirm that the domain specified in the "d=" tag is the same as or a parent domain of the domain part of the "i=" tag
- If not, the DKIM-Signature header field MUST be ignored, and the Verifier should return PERMFAIL (domain mismatch)
- If the "h=" tag does not include the From header field, the Verifier MUST ignore the DKIM-Signature header field and return PERMFAIL (From field not signed)
- Verifiers MAY ignore the DKIM-Signature header field and return PERMFAIL (signature expired) if it contains an "x=" tag and the signature has expired
- Verifiers MAY ignore the DKIM-Signature header field if the domain used by the Signer in the "d=" tag is not associated with a valid signing entity
- The list of unacceptable domains SHOULD be configurable
- Verifiers MAY ignore the DKIM-Signature header field and return PERMFAIL (unacceptable signature header) for any other reason, for example, if the signature does not sign header fields that the Verifier views to be essential
- The Verifier MUST validate the key record and MUST ignore any public-key records that are malformed
- When validating a message, a Verifier MUST perform the following steps in a manner that is semantically the same as performing them in the order indicated; in some cases, the implementation may parallelize or reorder these steps, as long as the semantics remain unchanged:
- If the query for the public key fails to respond, the Verifier MAY seek a later verification attempt by returning TEMPFAIL (key unavailable)
- If the query for the public key fails because the corresponding key record does not exist, the Verifier MUST immediately return PERMFAIL (no key for signature)
- If the result returned from the query does not adhere to the format defined in this specification, the Verifier MUST ignore the key record and return PERMFAIL (key syntax error)
- In particular, the Verifier MUST ignore keys with a version code ("v=" tag) that they do not implement
- If the "h=" tag exists in the public-key record and the hash algorithm implied by the "a=" tag in the DKIM-Signature header field is not included in the contents of the "h=" tag, the Verifier MUST ignore the key record and return PERMFAIL (inappropriate hash algorithm)
- If the public-key data (the "p=" tag) is empty, then this key has been revoked and the Verifier MUST treat this as a failed signature check and return PERMFAIL (key revoked)
- If the public-key data is not suitable for use with the algorithm and key types defined by the "a=" and "k=" tags in the DKIM- Signature header field, the Verifier MUST immediately return PERMFAIL (inappropriate key algorithm)
- When matching header field names in the "h=" tag against the actual message header field, comparisons MUST be case-insensitive
- If the hash does not match, the Verifier SHOULD ignore the signature and return PERMFAIL (body hash did not verify)
- If the signature does not validate, the Verifier SHOULD ignore the signature and return PERMFAIL (signature did not verify)
- Any such header field SHOULD be inserted before any existing DKIM-Signature or preexisting authentication status header fields in the header field block
- The Authentication-Results: header field ([RFC5451]) MAY be used for this purpose
- To circumvent this attack, Verifiers MAY wish to request deletion of existing results header fields after verification and before arranging to add a new header field
- In general, modules that consume DKIM verification output SHOULD NOT determine message acceptability based solely on a lack of any signature or on an unverifiable signature; such rejection would cause severe interoperability problems
- If an MTA does wish to reject such messages during an SMTP session (for example, when communicating with a peer who, by prior agreement, agrees to only send signed messages), and a signature is missing or does not verify, the handling MTA SHOULD use a 550/5.7.x reply code
- Where the Verifier is integrated within the MTA and it is not possible to fetch the public key, perhaps because the key server is not available, a temporary failure message MAY be generated using a 451/4.7.5 reply code, such as:
- Temporary failures such as inability to access the key server or other external service are the only conditions that SHOULD use a 4xx SMTP reply code
- In particular, cryptographic signature verification failures MUST NOT provoke 4xx SMTP replies
- Once the signature has been verified, that information MUST be conveyed to the Identity Assessor (such as an explicit allow/ whitelist and reputation system) and/or to the end user
- If the SDID is not the same as the address in the From: header field, the mail system SHOULD take pains to ensure that the actual SDID is clear to the reader
- If a selector cannot be found, is that because the selector has been removed, or was the value changed somehow in transit? If the signature line is missing, is that because it was never there, or was it removed by an overzealous filter? For diagnostic purposes, the exact reason why the verification fails SHOULD be made available and possibly recorded in the system logs
- If the email cannot be verified, then it SHOULD be treated the same as all unverified email, regardless of whether or not it looks like it was signed
- All registrations into these namespaces MUST include the name being registered, the document in which it was registered or updated, and an indication of its current status, which MUST be one of "active" (in current use) or "historic" (no longer in current use)
- Verifiers MUST thoroughly verify all key records retrieved from the DNS and be robust against intentionally as well as unintentionally malformed key records
- Verifiers MUST be prepared to receive messages with malformed DKIM- Signature header fields and thoroughly verify the header field before depending on any of its contents
- Note that a Verifier MAY ignore signatures that come from an unlikely domain such as ".com", as discussed in Section 6.1.1
- Although the "g=" tag has been deprecated in this version of the DKIM specification (and thus MUST now be ignored), Signers are advised not to include the "g=" tag in key records because some [RFC4871]- compliant Verifiers will be in use for a considerable period to come
rfc6604
- The RCODE in the ultimate DNS response MUST BE set based on the final query cycle leading to that response
rfc6605
- (Conversion of the integers to bit strings is described in Section C.2 of FIPS 186-3.) For P-256, each integer MUST be encoded as 32 octets; for P-384, each integer MUST be encoded as 48 octets
- Conformant implementations that create records to be put into the DNS MUST implement signing and verification for both of the above algorithms
- Conformant DNSSEC verifiers MUST implement verification for both of the above algorithms
- A DNSSEC validator that implements the signing algorithms defined in this document MUST be able to validate negative answers in the form of both NSEC and NSEC3 with hash algorithm 1, as defined in RFC 5155
- An authoritative server that does not implement NSEC3 MAY still serve zones that use the signing algorithms defined in this document with NSEC denial of existence
- Value 4 Digest Type SHA-384 Status OPTIONAL
rfc6641
- Future NFS services using other protocols MUST use another protocol name
- The "_udp" label MUST NOT be used to imply use of UDP with NFSv4, as neither RFC 3530 [RFC3530] nor RFC 5661 [RFC5661] defines NFSv4 over UDP
- In order to allow the NFSv4 servers as given to export a variety of file systems, those file servers MUST export the given domain's root file systems at "/.domainroot/{Name}" within their pseudo-file systems, where the "{Name}" is the name of the organization as used in the SRV RR
- For the rootpath field of fslocation, or the flifsroot field of fslocations_info, NFS servers MUST use the "/.domainroot/ {Name}" string
- Thus, the servers listed as targets for the SRV RRs MUST export the root of the organization's published file system as the directory "/.domainroot/{Name}" (for the given organization Name) in their exported NFS namespaces
- Thus, the NFS client SHOULD NOT insist on using a writable copy of the file system if read-only copies exist, or a zero-age copy rather than a copy that may be a little older
- The result of the DNS search SHOULD appear as a (pseudo-)directory in the client namespace
- A further refinement is RECOMMENDED: that only fully qualified domain names appear as directories
- The abbreviated form SHOULD be represented in the client's namespace cache as a symbolic link, pointing to the fully qualified name
- If DNS Security Extensions (DNSSEC) [RFC4033] is available, it SHOULD be used to avoid both such attacks
- To make use of RFC 5178's domain-based names, the syntax for "domain-based-name" MUST be used with a service of "nfs", a domain matching the name of the organization whose root file system is being sought, and a hostname given in the target of the DNS SRV RR
- Service name: nfs-domainroot Transport Protocol(s) TCP Assignee (REQUIRED) IESG (iesg@ietf.org) Contact (REQUIRED) IETF Chair (chair@ietf.org) Description (REQUIRED) NFS service for the domain root, the root of an organization's published file namespace
- Reference (REQUIRED) This document Port Number (OPTIONAL) Service Code (REQUIRED for DCCP only) Known Unauthorized Uses (OPTIONAL) Assignment Notes (OPTIONAL)
rfc6652
- ra= Reporting Address (plain-text; OPTIONAL; no default)
- MUST be a local-part (see Section 3.4.1 of [MAIL]) specifying an e-mail address to which a report SHOULD be sent when mail claiming to be from this domain (see Section 2.4 of [SPF] for a description of how domains are identified for SPF checks) has failed the evaluation algorithm described in [SPF], in particular because a message arrived via an unauthorized route
- ra= modifiers in a record that was reached by following an "include" mechanism (defined in Section 5.2 of [SPF]) MUST be ignored
- rp= Requested Report Percentage (plain-text; OPTIONAL; default is "100")
- The report generator SHOULD NOT issue reports for more than the requested percentage of incidents
- Report generators MAY make use of the "Incidents:" field in [ARF] to indicate that there are more reportable incidents than there are reports
- rr= Requested Reports (plain-text; OPTIONAL; default is "all")
- The value MUST be a colon-separated list of tokens representing those conditions under which a report is desired
- In the absence of an "ra=" tag in the SPF record, the "rp=" and "rr=" tags MUST be ignored, and the report generator MUST NOT issue a report
- Verifiers MUST NOT generate reports for incidents that do not match a requested report and MUST ignore requests for reports not included in this list
- New registrations and updates MUST contain the following information:
- New or updated status, which MUST be one of the following:
- If the [SMTP] return address to be used will not be the NULL return address, i.e., "MAIL FROM:<>", then the selected return address MUST be selected such that it will pass [SPF] MAIL FROM checks upon initial receipt
- If the report is passed to the Message Submission Agent (MSA) (MSA is described in [EMAIL-ARCH] using [SMTP]), the HELO/EHLO command parameter SHOULD also be selected so that it will pass [SPF] HELO checks
rfc6672
- Its RDATA is comprised of a single field, , which contains a fully qualified domain name that MUST be sent in uncompressed form [RFC1035] [RFC3597]
- The field MUST be present
- DNAME RRs MUST NOT appear at the same owner name as an NS RR unless the owner name is the zone apex; if it is not the zone apex, then the NS RR signifies a delegation point, and the DNAME RR must in that case appear below the zone cut at the zone apex of the child zone
- Resource records MUST NOT exist at any subdomain of the owner of a DNAME RR
- A server MAY refuse to load a zone that has data at a subdomain of a domain name owning a DNAME RR
- The DNAME RDATA target name MUST NOT be sent out in compressed form and MUST be downcased for DNS Security Extensions (DNSSEC) validation
- Servers MUST be able to answer a query for a synthesized CNAME
- If the server in question is a cache, the synthesized CNAME's TTL SHOULD be equal to the decremented TTL of the cached DNAME
- Resolvers MUST be able to handle a synthesized CNAME TTL of zero or a value equal to the TTL of the corresponding DNAME record (as some older, authoritative server implementations set the TTL of synthesized CNAMEs to zero)
- Thus, records of the form "*.example.com DNAME example.net" SHOULD NOT be used
- A server MAY give a warning that the behavior is unspecified if such a wildcarded DNAME is loaded
- The server MAY refuse it, refuse to load the zone, or refuse dynamic updates
- Recursive caching name servers MUST perform CNAME synthesis on behalf of clients
- If a recursive caching name server encounters a DNSSEC validated DNAME RR that contradicts information already in the cache (excluding CNAME records), it SHOULD cache the DNAME RR, but it MAY cache the CNAME record received along with it, subject to the rules for CNAME
- If the DNAME RR cannot be validated via DNSSEC (i.e., not BOGUS, but not able to validate), the recursive caching server SHOULD NOT cache the DNAME RR but MAY cache the CNAME record received along with it, subject to the rules for CNAME
- If a dynamic update message attempts to add a DNAME with a given owner name, but a CNAME is associated with that name, then the server MUST ignore the DNAME
- associated with that name, then the CNAME MUST be ignored
- In any negative response, the NSEC or NSEC3 [RFC5155] record type bitmap SHOULD be checked to see that there was no DNAME that could have been applied
- Below are examples of why DNSSEC validators MUST understand DNAME
- A validating resolver MUST understand DNAME, according to [RFC4034]
- o Recursive caching servers MUST perform CNAME synthesis on behalf of clients (Section 3.4)
- o Clients MUST be able to accept synthesized CNAME RR's with a TTL of either zero or the TTL of the DNAME RR that accompanies the CNAME RR
- o DNSSEC-aware clients SHOULD cache DNAME RRs and MAY cache synthesized CNAME RRs they receive in the same response
- DNSSEC- aware clients SHOULD also check the NSEC/NSEC3 type bitmap to verify that DNAME redirection is to be done
- DNSSEC validators MUST understand DNAME (Section 5.3)
rfc6698
- 0 -- Certificate usage 0 is used to specify a CA certificate, or the public key of such a certificate, that MUST be found in any of the PKIX certification paths for the end entity certificate given by the server in TLS
- The presented certificate MUST pass PKIX certification path validation, and a CA certificate that matches the TLSA record MUST be included as part of a valid certification path
- 1 -- Certificate usage 1 is used to specify an end entity certificate, or the public key of such a certificate, that MUST be matched with the end entity certificate given by the server in TLS
- The target certificate MUST pass PKIX certification path validation and MUST match the TLSA record
- 2 -- Certificate usage 2 is used to specify a certificate, or the public key of such a certificate, that MUST be used as the trust anchor when validating the end entity certificate given by the server in TLS
- The target certificate MUST pass PKIX certification path validation, with any certificate matching the TLSA record considered to be a trust anchor for this certification path validation
- 3 -- Certificate usage 3 is used to specify a certificate, or the public key of such a certificate, that MUST match the end entity certificate given by the server in TLS
- The target certificate MUST match the TLSA record
- o The certificate usage field MUST be represented as an 8-bit unsigned integer
- o The selector field MUST be represented as an 8-bit unsigned integer
- o The matching type field MUST be represented as an 8-bit unsigned integer
- o The certificate association data field MUST be represented as a string of hexadecimal characters
- The base domain name is the fully qualified DNS domain name [RFC1035] of the TLS server, with the additional restriction that every label MUST meet the rules of [RFC0952]
- The latter restriction means that, if the query is for an internationalized domain name, it MUST use the A-label form as defined in [RFC5890]
- The TLS session that is to be set up MUST be for the specific port number and transport name that was given in the TLSA query
- If a TLSA record has certificate usage 2, the corresponding TLS server SHOULD send the certificate that is referenced just like it currently sends intermediate certificates
- Determining whether a TLSA RRSet can be used MUST be based on the DNSSEC validation state (as defined in [RFC4033])
- o A TLSA RRSet whose DNSSEC validation state is secure MUST be used as a certificate association for TLS unless a local policy would prohibit the use of the specific certificate association in the secure TLSA RRSet
- o If the DNSSEC validation state on the response to the request for the TLSA RRSet is bogus, this MUST cause TLS not to be started or, if the TLS negotiation is already in progress, MUST cause the connection to be aborted
- o A TLSA RRSet whose DNSSEC validation state is indeterminate or insecure cannot be used for TLS and MUST be considered unusable
- Clients that validate the DNSSEC signatures themselves MUST use standard DNSSEC validation procedures
- Clients that rely on another entity to perform the DNSSEC signature validation MUST use a secure mechanism between themselves and the validator
- If a certificate association contains a certificate usage, selector, or matching type that is not understood by the TLS client, that certificate association MUST be considered unusable
- If the comparison data for a certificate is malformed, the certificate association MUST be considered unusable
- If a certificate association contains a matching type or certificate association data that uses a cryptographic algorithm that is considered too weak for the TLS client's policy, the certificate association MUST be considered unusable
- During the TLS handshake, if none of the certificate associations matches the certificate given by the TLS server, the TLS client MUST abort the handshake
- If a request for a TLSA record does not meet one of those two criteria but the application continues with the TLS handshake anyway, the application has gotten no benefit from TLSA and SHOULD NOT make any internal or external indication that TLSA was applied
- If an application has a configuration setting that has turned on TLSA use, or has any indication that TLSA is in use (regardless of whether or not this is configurable), that application either MUST NOT start a TLS connection or it MUST abort a TLS handshake if both of the two criteria above are not met
- TLS clients conforming to this specification MUST be able to correctly interpret TLSA records with certificate usages 0, 1, 2, and 3
- TLS clients conforming to this specification MUST be able to compare a certificate association with a certificate from the TLS handshake using selector types 0 and 1, and matching type 0 (no hash used) and matching type 1 (SHA-256), and SHOULD be able to make such comparisons with matching type 2 (SHA-512)
- In particular, implementations SHOULD rely on their DNS resolver for confirmation of an association between a TLSA record and a DNS name, rather than caching the result of previous domain name lookups
- Many platforms already can cache domain name lookups locally when appropriate, and they SHOULD be configured to do so
- If implementations cache the results of domain name lookups in order to achieve a performance improvement, they MUST observe the TTL information reported by DNS
- Section 4 of this document states that a TLSA RRSet whose validation state is secure MUST be used
rfc6725
rfc6731
- A resolver SHALL build a preference list of RDNSSes it will contact depending on the query
- To build the list in an optimal way, a node SHALL request for RDNSS selection information with the DHCP options defined in Sections 4.2 and 4.3 before any DNS queries need to be made
- The RDNSSes learned by other RDNSS address configuration methods can be considered as default RDNSSes, but preference-wise, they MUST be handled as medium preference RDNSSes (see also Section 4.6)
- When a DNS query needs to be made, the resolver MUST give highest preference to the RDNSSes explicitly known to serve a matching domain or network
- The resolver MUST take into account differences in trust levels (see Section 8.2) of pieces of received RDNSS selection information
- The resolver MUST prefer RDNSSes of trusted interfaces
- A resolver MUST prioritize between equally trusted RDNSSes with the help of the DHCP option preference field
- The resolver MUST NOT prioritize less trusted RDNSSes higher than trusted, even in the case when a less trusted RDNSS would apparently have additional information
- A node SHALL send requests to RDNSSes in the order defined by the preference list until an acceptable reply is received, all replies are received, or a timeout occurs
- In the case of a requested name matching to a specific domain or network rule accepted from any interface, a DNSSEC-aware resolver MUST NOT proceed with a reply that cannot be validated using DNSSEC until all RDNSSes on the preference list have been contacted or timed out
- A DNSSEC-aware node MAY always contact all RDNSSes in an attempt to receive a response that can be validated, but contacting all RDNSSes is not
- In the case of a validated NXDOMAIN response being received from an RDNSS that can provide answers for the queried name, a node MUST NOT accept non-validated replies from other RDNSSes (see Appendix B for considerations related to multiple trust anchors)
- MUST be set to zero and MUST be ignored on receipt
- Reserved preference value (10) MUST NOT be sent
- On receipt, the Reserved value MUST be treated as Medium preference (00)
- Field MUST be encoded as specified in Section 8 of [RFC3315]
- A node SHOULD include the Option Request Option (OPTIONORO [RFC3315]) in a DHCPv6 request with the OPTIONRDNSS_SELECTION option code to inform the DHCPv6 server about the support for the improved RDNSS selection logic
- The list of networks MUST cover all the domains configured in this option
- The length of the included networks SHOULD be as long as possible to avoid potential collision with information received on other option instances or with options received from DHCP servers of other network interfaces
- If OPTIONRDNSSSELECTION contains an RDNSS address already learned from other DHCPv6 servers of the same network and contains new domains or networks, the node SHOULD append the information to the information received earlier
- The node MUST NOT remove previously
- However, the node SHOULD NOT extend the lifetime of earlier information either
- When a conflicting RDNSS address is learned from a less trusted interface, the node MUST ignore the option
- Like the RDNSS options of [RFC3646], OPTIONRDNSSSELECTION MUST NOT appear in any other than the following DHCPv6 messages: Solicit, Advertise, Request, Renew, Rebind, Information-Request, and Reply
- The client SHALL periodically refresh information learned with OPTIONRDNSSSELECTION
- The information SHALL be refreshed on link- state changes, such as those caused by node mobility, and when renewing lifetimes of IPv6 addresses configured with DHCPv6
- MUST be set to zero and MUST be ignored on receipt
- Reserved preference value (10) MUST NOT be sent
- On receipt, the Reserved value MUST be treated as Medium preference (00)
- Field MUST be encoded as specified in Section 8 of [RFC3315]
- If the length of the domains and networks field causes option length to exceed the maximum permissible for a single option (255 octets), then multiple options MAY be used, as described in "Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)" [RFC3396]
- The list of networks MUST cover all the domains configured in this option
- The length of the included networks SHOULD be as long as possible to avoid potential collision with information received on other option instances or with options received from DHCP servers of other network interfaces
- If the RDNSS Selection option contains an RDNSS address already learned from other DHCPv4 servers of the same network and contains new domains or networks, the node SHOULD append the information to the information received earlier
- The node MUST NOT remove previously obtained information
- However, the node SHOULD NOT extend the lifetime of earlier information either
- When a conflicting RDNSS address is learned from a less trusted interface, the node MUST ignore the option
- The client SHALL periodically refresh information learned with the RDNSS Selection option
- The information SHALL be refreshed on link- state changes, such as those caused by node mobility, and when extending the lease of IPv4 addresses configured with DHCPv4
- The RDNSS selection option SHOULD NOT be enabled by default
- For RDNSS selection purposes, information received from all tools MUST be combined together into a single list, as discussed in Section 4.1
- In such a case, DHCPv6 MUST be preferred unless DHCPv4 is utilizing additional security frameworks for protecting the messages
- The RDNSSes learned via tools other than the DHCPv4 RDNSS Selection option and the DHCPv6 OPTIONRDNSSSELECTION MUST be handled as default RDNSSes, with medium preference, when building a list of RDNSSes to talk to (see Section 4.1)
- When the RDNSS selection option contains a default RDNSS address and other sources are providing RNDSS addresses, the resolver MUST make the decision about which one to prefer based on the RDNSS preference field value
- If the RDNSS selection option defines medium preference, then the RDNSS from the RDNSS selection option SHALL be selected
- If multiple sources are providing same RDNSS(es) IP address(es), each address MUST be added to the RDNSS list only once
- If a node had indicated support for OPTIONRDNSSSELECTION in a DHCPv6 request, the DHCPv6 server MAY omit sending of OPTIONDNSSERVERS
- Any follow-up queries that are performed on the basis of an answer received on an interface MUST continue to use the same interface, irrespective of the RDNSS selection settings on any other interface
- For example, if a node receives a reply with a canonical name (CNAME) or delegation name (DNAME), the follow-up queries MUST be sent to RDNSS(es) of the same interface, or to the same RDNSS, irrespectively of the FQDN received
- An implementation SHOULD ensure obsolete information is not retained in these events
- Private namespaces MUST be globally unique in order to keep DNS unambiguous and henceforth avoid caching-related issues and destination selection problems (see Section 2.3)
- Private namespaces MUST only consist of subdomains of domains for which the relevant operator provides authoritative name service
- It is RECOMMENDED for administrators utilizing this tool to deploy DNSSEC for their zone in order to counter attacks against private namespaces
rfc6761
- If it is determined that special handling of a name is required in order to implement some desired new functionality, then an IETF "Standards Action" or "IESG Approval" specification [RFC5226] MUST be published describing the new functionality
- The specification MUST state how implementations determine that the special handling is required for any given name
- The specification also MUST state, in each of the seven "Domain Name Reservation Considerations" categories below, what special treatment, if any, is to be applied
- However, since there is no central authority responsible for use of private addresses, users SHOULD be aware that these names are likely to yield different results on different networks
- Application software SHOULD NOT recognize these names as special, and SHOULD use these names as they would other reverse-mapping names
- Name resolution APIs and libraries SHOULD NOT recognize these names as special and SHOULD NOT treat them differently
- Name resolution APIs SHOULD send queries for these names to their configured caching DNS server(s)
- Caching DNS servers SHOULD recognize these names as special and SHOULD NOT, by default, attempt to look up NS records for them, or otherwise query authoritative DNS servers in an attempt to resolve these names
- Instead, caching DNS servers SHOULD, by default, generate immediate (positive or negative) responses for all such queries
- Caching DNS servers SHOULD offer a configuration option (disabled by default) to enable upstream resolution of such names, for use in private networks where private-address reverse-mapping names are known to be handled by an authoritative DNS server in said private network
- Authoritative DNS servers SHOULD recognize these names as special and SHOULD, by default, generate immediate negative responses for all such queries, unless explicitly configured by the administrator to give positive answers for private-address reverse-mapping names
- DNS server operators SHOULD, if they are using private addresses, configure their authoritative DNS servers to act as authoritative for these names
- DNS Registries/Registrars MUST NOT grant requests to register any of these names in the normal way to any person or entity
- However, since there is no central authority responsible for use of test names, users SHOULD be aware that these names are likely to yield different results on different networks
- Application software SHOULD NOT recognize test names as special, and SHOULD use test names as they would other domain names
- Name resolution APIs and libraries SHOULD NOT recognize test names as special and SHOULD NOT treat them differently
- Name resolution APIs SHOULD send queries for test names to their configured caching DNS server(s)
- Caching DNS servers SHOULD recognize test names as special and SHOULD NOT, by default, attempt to look up NS records for them, or otherwise query authoritative DNS servers in an attempt to resolve test names
- Instead, caching DNS servers SHOULD, by default, generate immediate negative responses for all such queries
- Caching DNS servers SHOULD offer a configuration option (disabled by default) to enable upstream resolving of test names, for use in networks where test names are known to be handled by an authoritative DNS server in said private network
- Authoritative DNS servers SHOULD recognize test names as special and SHOULD, by default, generate immediate negative responses for all such queries, unless explicitly configured by the administrator to give positive answers for test names
- DNS server operators SHOULD, if they are using test names, configure their authoritative DNS servers to act as authoritative for test names
- DNS Registries/Registrars MUST NOT grant requests to register test names in the normal way to any person or entity
- Application software MAY recognize localhost names as special, or MAY pass them to name resolution APIs as they would for other domain names
- Name resolution APIs and libraries SHOULD recognize localhost names as special and SHOULD always return the IP loopback address for address queries and negative responses for all other query types
- Name resolution APIs SHOULD NOT send queries for localhost names to their configured caching DNS server(s)
- Caching DNS servers SHOULD recognize localhost names as special and SHOULD NOT attempt to look up NS records for them, or otherwise query authoritative DNS servers in an attempt to resolve localhost names
- Instead, caching DNS servers SHOULD, for all such address queries, generate an immediate positive response giving the IP loopback address, and for all other query types, generate an immediate negative response
- Authoritative DNS servers SHOULD recognize localhost names as special and handle them as described above for caching DNS servers
- DNS server operators SHOULD be aware that the effective RDATA for localhost names is defined by protocol specification and cannot be modified by local configuration
- DNS Registries/Registrars MUST NOT grant requests to register localhost names in the normal way to any person or entity
- Users MAY assume that queries for "invalid" names will always return NXDOMAIN responses
- Application software MAY recognize "invalid" names as special or MAY pass them to name resolution APIs as they would for other domain names
- Name resolution APIs and libraries SHOULD recognize "invalid" names as special and SHOULD always return immediate negative responses
- Name resolution APIs SHOULD NOT send queries for "invalid" names to their configured caching DNS server(s)
- Caching DNS servers SHOULD recognize "invalid" names as special and SHOULD NOT attempt to look up NS records for them, or otherwise query authoritative DNS servers in an attempt to resolve "invalid" names
- Instead, caching DNS servers SHOULD generate immediate NXDOMAIN responses for all such queries
- Authoritative DNS servers SHOULD recognize "invalid" names as special and handle them as described above for caching DNS servers
- DNS server operators SHOULD be aware that the effective RDATA for "invalid" names is defined by protocol specification to be nonexistent and cannot be modified by local configuration
- DNS Registries/Registrars MUST NOT grant requests to register "invalid" names in the normal way to any person or entity
- Users SHOULD understand that example names are reserved for use in documentation
- Application software SHOULD NOT recognize example names as special and SHOULD use example names as they would other domain names
- Name resolution APIs and libraries SHOULD NOT recognize example names as special and SHOULD NOT treat them differently
- Name resolution APIs SHOULD send queries for example names to their configured caching DNS server(s)
- Caching DNS servers SHOULD NOT recognize example names as special and SHOULD resolve them normally
- Authoritative DNS servers SHOULD NOT recognize example names as special
- DNS server operators SHOULD be aware that example names are reserved for use in documentation
- DNS Registries/Registrars MUST NOT grant requests to register example names in the normal way to any person or entity
rfc6762
- Before claiming ownership of a unique resource record set, a responder MUST probe to verify that no other responder already claims ownership of that set, as described in Section 8.1, "Probing"
- (For fault-tolerance and other reasons, sometimes it is permissible to have more than one responder answering for a particular "unique" resource record set, but such cooperating responders MUST give answers containing identical rdata for these records
- If this happens, the computer (or its human user) MUST cease using the name, and SHOULD attempt to allocate a new unique name for use on that link
- Any DNS query for a name ending with ".local." MUST be sent to the mDNS IPv4 link-local multicast address 224.0.0.251 (or its IPv6 equivalent FF02::FB)
- Implementers MAY choose to look up such names concurrently via other mechanisms (e.g., Unicast DNS) and coalesce the results in some fashion
- DNS queries for names that do not end with ".local." MAY be sent to the mDNS multicast address, if no other conventional DNS server is available
- Any DNS query for a name ending with "254.169.in-addr.arpa." MUST be sent to the mDNS IPv4 link-local multicast address 224.0.0.251 or the mDNS IPv6 multicast address FF02::FB
- Likewise, any DNS query for a name within the reverse mapping domains for IPv6 link-local addresses ("8.e.f.ip6.arpa.", "9.e.f.ip6.arpa.", "a.e.f.ip6.arpa.", and "b.e.f.ip6.arpa.") MUST be sent to the mDNS IPv6 link-local multicast address FF02::FB or the mDNS IPv4 link-local multicast address 224.0.0.251
- Except in the rare case of a Multicast DNS responder that is advertising only shared resource records and no unique records, a Multicast DNS responder MUST also implement a Multicast DNS querier so that it can first verify the uniqueness of those records before it begins answering queries for them
- These queries are typically done using a high-numbered ephemeral UDP source port, but regardless of whether they are sent from a dynamic port or from a fixed port, these queries MUST NOT be sent using UDP source port 5353, since using UDP source port 5353 signals the presence of a fully compliant Multicast DNS querier, as described below
- Therefore, when retransmitting Multicast DNS queries to implement this kind of continuous monitoring, the interval between the first two queries MUST be at least one second, the intervals between successive queries MUST increase by at least a factor of two, and the querier MUST implement Known-Answer Suppression, as described below
- When the interval between queries reaches or exceeds 60 minutes, a querier MAY cap the interval to a maximum of 60 minutes, and perform subsequent queries at a steady-state rate of one query per hour
- To avoid accidental synchronization when, for some reason, multiple clients begin querying at exactly the same moment (e.g., because of some common external trigger event), a Multicast DNS querier SHOULD also delay the first query of the series by a randomly chosen amount in the range 20-120 ms
- After this interval has passed, the answer will no longer be valid and SHOULD be deleted from the cache
- Before the record expiry time is reached, a Multicast DNS querier that has local clients with an active interest in the state of that record (e.g., a network browsing window displaying a list of discovered services to the user) SHOULD reissue its query to determine whether the record is still valid
- A Multicast DNS querier MUST NOT perform this cache maintenance for records for which it has no local clients with an active interest
- An additional efficiency optimization SHOULD be performed when a Multicast DNS response is received containing a unique answer (as indicated by the cache-flush bit being set, described in Section 10.2, "Announcements to Flush Outdated Cache Entries")
- In this case, the Multicast DNS querier SHOULD plan to issue its next query for this record at 80-82% of the record's TTL, as described above
- A compliant Multicast DNS querier, which implements the rules specified in this document, MUST send its Multicast DNS queries from UDP source port 5353 (the well-known port assigned to mDNS), and MUST listen for Multicast DNS replies sent to UDP destination port 5353 at the mDNS link-local multicast address (224.0.0.251 and/or its IPv6 equivalent FF02::FB)
- A Multicast DNS querier sending its initial batch of questions immediately on wake from sleep or interface activation SHOULD set the unicast-response bit in those questions
- When a question is retransmitted (as described in Section 5.2), the unicast-response bit SHOULD NOT be set in subsequent retransmissions of that question
- Subsequent retransmissions SHOULD be usual "QM" questions
- In addition, the unicast-response bit SHOULD be set only for questions that are active and ready to be sent the moment of wake from sleep or interface activation
- New questions created by local clients afterwards should be treated as normal "QM" questions and SHOULD NOT have the unicast-response bit set on the first question of the series
- When receiving a question with the unicast-response bit set, a responder SHOULD usually respond with a unicast packet directed back to the querier
- However, if the responder has not multicast that record recently (within one quarter of its TTL), then the responder SHOULD instead multicast the response so as to keep all the peer caches up to date, and to permit passive conflict detection
- When a Multicast DNS responder receives a query via direct unicast, it SHOULD respond as it would for "QU" questions, as described above in Section 5.4
- Since it is possible for a unicast query to be received from a machine outside the local link, responders SHOULD check that the source address in the query packet matches the local subnet for that link (or, in the case of IPv6, the source address has an on-link prefix) and silently ignore the packet if not
- A Multicast DNS responder MUST NOT place records from its cache, which have been learned from other responders on the network, in the Resource Record Sections of outgoing response messages
- As with Unicast DNS, generally only DNS class 1 ("Internet") is used, but should client software use classes other than 1, the matching rules described above MUST be used
- A Multicast DNS responder MUST only respond when it has a positive, non-null response to send, or it authoritatively knows that a particular record does not exist
- For unique records, where the host has already established sole ownership of the name, it MUST return negative answers to queries for records that it knows not to exist
- For example, a host with no IPv6 address, that has claimed sole ownership of the name "host.local." for all rrtypes, MUST respond to AAAA queries for "host.local." by sending a negative answer indicating that no AAAA records exist for that name
- For shared records, NXDOMAIN and other error responses MUST NOT be sent
- Multicast DNS responses MUST NOT contain any questions in the Question Section
- Any questions in the Question Section of a received Multicast DNS response MUST be silently ignored
- A Multicast DNS responder on Ethernet [IEEE.802.3] and similar shared multiple access networks SHOULD have the capability of delaying its responses by up to 500 ms, as described below
- In the case where a Multicast DNS responder has good reason to believe that it will be the only responder on the link that will send a response (i.e., because it is able to answer every question in the query message, and for all of those answer records it has previously verified that the name, rrtype, and rrclass are unique on the link), it SHOULD NOT impose any random delay before responding, and SHOULD normally generate its response within at most 10 ms
- In any case where there may be multiple responses, such as queries where the answer is a member of a shared resource record set, each responder SHOULD delay its response by a random amount of time selected with uniform random distribution in the range 20-120 ms
- In the case where the query has the TC (truncated) bit set, indicating that subsequent Known-Answer packets will follow, responders SHOULD delay their responses by a random amount of time selected with uniform random distribution in the range 400-500 ms, to allow enough time for all the Known-Answer packets to arrive, as described in Section 7.2, "Multipacket Known-Answer Suppression"
- The source UDP port in all Multicast DNS responses MUST be 5353 (the well-known port assigned to mDNS)
- Multicast DNS implementations MUST silently ignore any Multicast DNS responses they receive where the source UDP port is not 5353
- The destination UDP port in all Multicast DNS responses MUST be 5353, and the destination address MUST be the mDNS IPv4 link-local multicast address 224.0.0.251 or its IPv6 equivalent FF02::FB, except when generating a reply to a query that explicitly requested a unicast response:
- Except for these three specific cases, responses MUST NOT be sent via unicast, because then the "Passive Observation of Failures" mechanisms described in Section 10.5 would not work correctly
- A Multicast DNS querier MUST only accept unicast responses if they answer a recently sent query (e.g., sent within the last two seconds) that explicitly requested unicast responses
- A Multicast DNS querier MUST silently ignore all other unicast responses
- To protect the network against excessive packet flooding due to software bugs or malicious attack, a Multicast DNS responder MUST NOT (except in the one special case of answering probe queries) multicast a record on a given interface until at least one second has elapsed since the last time that record was multicast on that particular interface
- In the special case of answering probe queries, because of the limited time before the probing host will make its decision about whether or not to use the name, a Multicast DNS responder MUST respond quickly
- Any time a responder receives a query for a name for which it has verified exclusive ownership, for a type for which that name has no records, the responder MUST (except as allowed in (a) below) respond asserting the nonexistence of that record using a DNS NSEC record [RFC4034]
- On receipt of a question for a particular name, rrtype, and rrclass, for which a responder does have one or more unique answers, the responder MAY also include an NSEC record in the Additional Record Section indicating the nonexistence of other rrtypes for that name and rrclass
- Implementers working with devices with sufficient memory and CPU resources MAY choose to implement code to handle the full generality of the DNS NSEC record [RFC4034], including bitmaps up to 65,536 bits long
- To facilitate use by devices with limited memory and CPU resources, Multicast DNS queriers are only REQUIRED to be able to parse a restricted form of the DNS NSEC record
- All compliant Multicast DNS implementations MUST at least correctly generate and parse the restricted DNS NSEC record format described below:
- Consequently, if a Multicast DNS responder were to have records with rrtypes above 255, it MUST NOT generate these restricted-form NSEC records for those names, since to do so would imply that the name has no records with rrtypes above 255, which would be false
- In such cases a Multicast DNS responder MUST either (a) emit no NSEC record for that name, or (b) emit a full NSEC record containing the appropriate Type Bit Map block(s) with the correct bits set for all the record types that exist
- If a Multicast DNS implementation receives an NSEC record where the 'Next Domain Name' field is not the record's own name, then the implementation SHOULD ignore the 'Next Domain Name' field and process the remainder of the NSEC record as usual
- In Multicast DNS the 'Next Domain Name' field is not currently used, but it could be used in a future version of this protocol, which is why a Multicast DNS implementation MUST NOT reject or ignore an NSEC record it receives just because it finds an unexpected value in the 'Next Domain Name' field
- If a Multicast DNS implementation receives an NSEC record containing more than one Type Bit Map, or where the Type Bit Map block number is not zero, or where the block length is not in the range 1-32, then the Multicast DNS implementation MAY silently ignore the entire NSEC record
- A Multicast DNS implementation MUST NOT ignore an entire message just because that message contains one or more NSEC record(s) that the Multicast DNS implementation cannot parse
- To help differentiate these synthesized NSEC records (generated programmatically on-the-fly) from conventional Unicast DNS NSEC records (which actually exist in a signed DNS zone), the synthesized Multicast DNS NSEC records MUST NOT have the NSEC bit set in the Type Bit Map, whereas conventional Unicast DNS NSEC records do have the NSEC bit set
- In general, the TTL given for an NSEC record SHOULD be the same as the TTL that the record would have had, had it existed
- A responder MUST only generate negative responses to queries for which it has legitimate ownership of the name, rrtype, and rrclass in question, and can legitimately assert that no record with that name, rrtype, and rrclass exists
- When a Multicast DNS responder sends a Multicast DNS response message containing its own address records, it MUST include all addresses that are valid on the interface on which it is sending the message, and MUST NOT include addresses that are not valid on that interface (such as addresses that may be configured on the host's other interfaces)
- When a Multicast DNS responder places an IPv4 or IPv6 address record (rrtype "A" or "AAAA") into a response message, it SHOULD also place any records of the other address type with the same name into the additional section, if there is space in the message
- In the event that a device has only IPv4 addresses but no IPv6 addresses, or vice versa, then the appropriate NSEC record SHOULD be placed into the additional section, so that queriers can know with certainty that the device has no addresses of that kind
- Other Multicast DNS responders may treat this case as logically two interfaces (one with one or more IPv4 addresses, and the other with one or more IPv6 addresses), but responders that operate this way MUST NOT put the corresponding automatic NSEC records in replies they send (i.e., a negative IPv4 assertion in their IPv6 responses, and a negative IPv6 assertion in their IPv4 responses) because this would cause incorrect operation in responders on the network that work the former way
- Multicast DNS responders MUST correctly handle DNS query messages containing more than one question, by answering any or all of the questions to which they have answers
- queries, where responding without delay is allowed in appropriate cases, for query messages containing more than one question, all (non-defensive) answers SHOULD be randomly delayed in the range 20-120 ms, or 400-500 ms if the TC (truncated) bit is set
- When possible, a responder SHOULD, for the sake of network efficiency, aggregate as many responses as possible into a single Multicast DNS response message
- For example, when a responder has several responses it plans to send, each delayed by a different interval, then earlier responses SHOULD be delayed by up to an additional 500 ms if that will permit them to be aggregated with other responses scheduled to go out a little later
- When responding to queries using qtype "ANY" (255) and/or qclass "ANY" (255), a Multicast DNS responder MUST respond with ALL of its records that match the query
- When responding to queries using qtype "ANY" (255) and/or qclass "ANY" (255), a Multicast DNS responder MUST respond with ALL of its records that match the query
- o If A's resource record is intended to be a member of a unique resource record set owned solely by that responder, then this is a conflict and MUST be handled as described in Section 9, "Conflict Resolution"
- o If the TTL of B's resource record given in the message is less than half the true TTL from A's point of view, then A MUST mark its record to be announced via multicast
- In this case, the Multicast DNS responder MUST send a UDP response directly back to the querier, via unicast, to the query packet's source IP address and port
- This unicast response MUST be a conventional unicast response as would be generated by a conventional Unicast DNS server; for example, it MUST repeat the query ID and the question given in the query message
- In addition, the cache-flush bit described in Section 10.2, "Announcements to Flush Outdated Cache Entries", MUST NOT be set in legacy unicast responses
- The resource record TTL given in a legacy unicast response SHOULD NOT be greater than ten seconds, even if the true TTL of the Multicast DNS resource record is higher
- A Multicast DNS responder MUST NOT answer a Multicast DNS query if the answer it would give is already included in the Answer Section with an RR TTL at least half the correct value
- If the RR TTL of the answer as given in the Answer Section is less than half of the true RR TTL as known by the Multicast DNS responder, the responder MUST send an answer so as to update the querier's cache before the record becomes in danger of expiration
- Therefore, a Multicast DNS querier SHOULD NOT include records in the Known-Answer list whose remaining TTL is less than half of their original TTL
- A Multicast DNS querier MUST NOT cache resource records observed in the Known-Answer Section of other Multicast DNS queries
- It MUST then set the TC (Truncated) bit in the header before sending the query
- It MUST immediately follow the packet with another query packet containing no questions and as many more Known-Answer records as will fit
- If the responder sees any of its answers listed in the Known-Answer lists of subsequent packets from the querying host, it MUST delete that answer from the list of answers it is planning to give (provided that no other host on the network has also issued a query for that record and is waiting to receive an answer)
- If the responder receives additional Known-Answer packets with the TC bit set, it SHOULD extend the delay as necessary to ensure a pause of 400-500 ms after the last such packet before it sends its answer
- If a host is planning to transmit (or retransmit) a query, and it sees another host on the network send a query containing the same "QM" question, and the Known-Answer Section of that query does not contain any records that this host would not also put in its own Known-Answer Section, then this host SHOULD treat its own query as having been sent
- If a host is planning to send an answer, and it sees another host on the network send a response message containing the same answer record, and the TTL in that record is not less than the TTL this host would have given, then this host SHOULD treat its own answer as having been sent, and not also send an identical answer itself
- Whenever a Multicast DNS responder starts up, wakes up from sleep, receives an indication of a network interface "Link Change" event, or has any other reason to believe that its network connectivity may have changed in some relevant way, it MUST perform the two startup steps below: Probing (Section 8.1) and Announcing (Section 8.3)
- The first startup step is that, for all those resource records that a Multicast DNS responder desires to be unique on the local link, it MUST send a Multicast DNS query asking for those resource records, to see if any of them are already in use
- All probe queries SHOULD be done using the desired resource record name and class (usually class 1, "Internet"), and query type "ANY" (255), to elicit answers for all types of records with that name
- When sending probe queries, a host MUST NOT consult its cache for potential answers
- Hence, it is important that when a device receives a probe query for a name that it is currently using, it SHOULD generate its response to defend that name immediately and send it as quickly as possible
- rules, the probes SHOULD be sent as "QU" questions with the unicast- response bit set, to allow a defending host to respond immediately via unicast, instead of potentially having to wait before replying via multicast
- During probing, from the time the first probe packet is sent until 250 ms after the third probe, if any conflicting Multicast DNS response is received, then the probing host MUST defer to the existing host, and SHOULD choose new names for some or all of its resource records as appropriate
- Apparently conflicting Multicast DNS responses received before the first probe packet is sent MUST be silently ignored (see discussion of stale probe packets in Section 8.2, "Simultaneous Probe Tiebreaking", below)
- In the case of a host probing using query type "ANY" as recommended above, any answer containing a record with that name, of any type, MUST be considered a conflicting response and handled accordingly
- If fifteen conflicts occur within any ten-second period, then the host MUST wait at least five seconds before each successive additional probe attempt
- If a responder knows by other means that its unique resource record set name, rrtype, and rrclass cannot already be in use by any other responder on the network, then it SHOULD skip the probing step for that resource record set
- Similarly, if a responder is acting as a proxy, taking over from another Multicast DNS responder that has already verified the uniqueness of the record, then the proxy SHOULD NOT repeat the probing step for those records
- In the case of resource records containing rdata that is subject to name compression [RFC1035], the names MUST be uncompressed before comparison
- The second startup step is that the Multicast DNS responder MUST send an unsolicited Multicast DNS response containing, in the Answer Section, all of its newly registered resource records (both shared records, and unique records that have completed the probing step)
- The Multicast DNS responder MUST send at least two unsolicited responses, one second apart
- To provide increased robustness against packet loss, a responder MAY send up to eight unsolicited responses, provided that the interval between unsolicited responses increases by at least a factor of two with every response sent
- A Multicast DNS responder MUST NOT send announcements in the absence of information that its network connectivity may have changed in some relevant way
- In particular, a Multicast DNS responder MUST NOT send regular periodic announcements as a matter of course
- Whenever a Multicast DNS responder receives any Multicast DNS response (solicited or otherwise) containing a conflicting resource record, the conflict MUST be resolved as described in Section 9, "Conflict Resolution"
- At any time, if the rdata of any of a host's Multicast DNS records changes, the host MUST repeat the Announcing step described above to update neighboring caches
- For example, if any of a host's IP addresses change, it MUST re-announce those address records
- In the case of shared records, a host MUST send a "goodbye" announcement with RR TTL zero (see Section 10.1, "Goodbye Packets") for the old rdata, to cause it to be deleted from peer caches, before announcing the new rdata
- In the case of unique records, a host SHOULD omit the "goodbye" announcement, since the cache-flush bit on the newly announced records will cause old rdata to be flushed from peer caches anyway
- A host may update the contents of any of its records at any time, though a host SHOULD NOT update records more frequently than ten times per minute
- Whenever a Multicast DNS responder receives any Multicast DNS response (solicited or otherwise) containing a conflicting resource record in any of the Resource Record Sections, the Multicast DNS responder MUST immediately reset its conflicted unique record to probing state, and go through the startup steps described above in
- The protocol used in the Probing phase will determine a winner and a loser, and the loser MUST cease using the name, and reconfigure
- It is very important that any host receiving a resource record that conflicts with one of its own MUST take action as described above
- As a general rule, the recommended TTL value for Multicast DNS resource records with a host name as the resource record's name (e.g., A, AAAA, HINFO) or a host name contained within the resource record's rdata (e.g., SRV, reverse mapping PTR record) SHOULD be 120 seconds
- In the case where a host knows that certain resource record data is about to become invalid (for example, when the host is undergoing a clean shutdown), the host SHOULD send an unsolicited Multicast DNS
- Queriers receiving a Multicast DNS response with a TTL of zero SHOULD NOT immediately delete the record from the cache, but instead record a TTL of 1 and then delete the record one second later
- In cases where the host has not been continuously connected and participating on the network link, it MUST first probe to re-verify uniqueness of its unique records, as described above in Section 8.1, "Probing"
- Having completed the Probing step, if necessary, the host MUST then send a series of unsolicited announcements to update cache entries in its neighbor hosts
- Any time a host sends a response packet containing some members of a unique RRSet, it MUST send the entire RRSet, preferably in a single packet, or if the entire RRSet will not fit in a single packet, in a quick burst of packets sent as close together as possible
- The host MUST set the cache-flush bit on all members of the unique RRSet
- The cache-flush bit MUST NOT be set in any resource records in a response message sent in legacy unicast responses to UDP ports other than 5353
- The cache-flush bit MUST NOT be set in any resource records in the Known-Answer list of any query message
- The cache-flush bit MUST NOT ever be set in any shared resource record
- When the cache receives this hint that it should reconfirm some record, it MUST issue two or more queries for the resource record in dispute
- If no response is received within ten seconds, then, even though its TTL may indicate that it is not yet due to expire, that record SHOULD be promptly flushed from the cache
- After seeing two or more of these queries, and seeing no multicast response containing the expected answer within ten seconds, then even though its TTL may indicate that it is not yet due to expire, that record SHOULD be flushed from the cache
- The host SHOULD NOT perform its own queries to reconfirm that the record is truly gone
- All Multicast DNS responses (including responses sent via unicast) SHOULD be sent with IP TTL set to 255
- A host sending Multicast DNS queries to a link-local destination address (including the 224.0.0.251 and FF02::FB link-local multicast addresses) MUST only accept responses to that query that originate from the local link, and silently discard any other response packets
- Since queriers will ignore responses apparently originating outside the local subnet, a responder SHOULD avoid generating responses that it can reasonably predict will be ignored
- If a responder receives a query addressed to the mDNS IPv4 link-local multicast address 224.0.0.251, from a source address not apparently on the same subnet as the responder (or, in the case of IPv6, from a source IPv6 address for which the responder does not have any address with the same prefix on that interface), then even if the query indicates that a unicast response is preferred (see Section 5.4, "Questions Requesting Unicast Responses"), the responder SHOULD elect to respond by multicast anyway, since it can reasonably predict that a unicast response with an apparently non-local source address will probably be ignored
- The option to fail-over to Multicast DNS for names not ending in ".local." SHOULD be a user-configured option, and SHOULD be disabled by default because of the possible security issues related to unintended local resolution of apparently global names
- A host SHOULD defend its dot-local host name on all active interfaces on which it is answering Multicast DNS queries
- Except in the case of proxying and other similar specialized uses, addresses in IPv4 or IPv6 address records in Multicast DNS responses MUST be valid for use on the interface on which the response is being sent
- For this reason, all Multicast DNS implementations SHOULD use the SOREUSEPORT and/or SOREUSEADDR options (or equivalent as appropriate for the operating system in question) so they will all be able to bind to UDP port 5353 and receive incoming multicast packets addressed to that port
- Accordingly, it adopts the simple obvious elegant solution: all names in Multicast DNS MUST be encoded as precomposed UTF-8 [RFC3629] "Net-Unicode" [RFC5198] text
- Multicast DNS names MUST NOT contain a "Byte Order Mark"
- Any occurrence of the Unicode character U+FEFF at the start or anywhere else in a Multicast DNS name MUST be interpreted as being an actual intended part of the name, representing (just as for any other legal unicode value) an actual literal instance of that character (in this case a zero-width non- breaking space character)
- Multicast DNS implementations MUST NOT use any other encodings apart from precomposed UTF-8 (US-ASCII being considered a compatible subset of UTF-8)
- In the case of a single Multicast DNS resource record that is too large to fit in a single MTU-sized multicast response packet, a Multicast DNS responder SHOULD send the resource record alone, in a single IP datagram, using multiple IP fragments
- Resource records this large SHOULD be avoided, except in the very rare cases where they really are the appropriate solution to the problem at hand
- Implementers should be aware that many simple devices do not reassemble fragmented IP datagrams, so large resource records SHOULD NOT be used except in specialized cases where the implementer knows
- A Multicast DNS packet larger than the interface MTU, which is sent using fragments, MUST NOT contain more than one resource record
- Even when fragmentation is used, a Multicast DNS packet, including IP and UDP headers, MUST NOT exceed 9000 bytes
- Multicast DNS implementations SHOULD listen for unsolicited responses issued by hosts booting up (or waking up from sleep or otherwise joining the network)
- Since these unsolicited responses may contain a useful answer to a question for which the querier is currently awaiting an answer, Multicast DNS implementations SHOULD examine all received Multicast DNS response messages for useful answers, without regard to the contents of the ID field or the Question Section
- Multicast DNS implementations MAY cache data from any or all Multicast DNS response messages they receive, for possible future use, provided of course that normal TTL aging is performed on these cached resource records
- In multicast query messages, the Query Identifier SHOULD be set to zero on transmission
- In multicast responses, including unsolicited multicast responses, the Query Identifier MUST be set to zero on transmission, and MUST be ignored on reception
- In legacy unicast response messages generated specifically in response to a particular (unicast or multicast) query, the Query Identifier MUST match the ID from the query message
- In query messages the QR bit MUST be zero
- In response messages the QR bit MUST be one
- In both multicast query and multicast response messages, the OPCODE MUST be zero on transmission (only standard queries are currently supported over multicast)
- Multicast DNS messages received with an OPCODE other than zero MUST be silently ignored
- In query messages, the Authoritative Answer bit MUST be zero on transmission, and MUST be ignored on reception
- In response messages for Multicast domains, the Authoritative Answer bit MUST be set to one (not setting this bit would imply there's some other place where "better" information may be found) and MUST be ignored on reception
- A responder SHOULD record this fact, and wait for those additional Known-Answer records, before deciding whether to respond
- In multicast response messages, the TC bit MUST be zero on transmission, and MUST be ignored on reception
- In legacy unicast response messages, the TC bit has the same meaning as in conventional Unicast DNS: it means that the response was too large to fit in a single packet, so the querier SHOULD reissue its query using TCP in order to receive the larger response
- In both multicast query and multicast response messages, the Recursion Desired bit SHOULD be zero on transmission, and MUST be ignored on reception
- In both multicast query and multicast response messages, the Recursion Available bit MUST be zero on transmission, and MUST be ignored on reception
- In both query and response messages, the Zero bit MUST be zero on transmission, and MUST be ignored on reception
- In both multicast query and multicast response messages, the Authentic Data bit [RFC2535] MUST be zero on transmission, and MUST be ignored on reception
- In both multicast query and multicast response messages, the Checking Disabled bit [RFC2535] MUST be zero on transmission, and MUST be ignored on reception
- In both multicast query and multicast response messages, the Response Code MUST be zero on transmission
- Multicast DNS messages received with non-zero Response Codes MUST be silently ignored
- When generating Multicast DNS messages, implementations SHOULD use name compression wherever possible to compress the names of resource records, by replacing some or all of the resource record name with a compact two-byte reference to an appearance of that data somewhere earlier in the message [RFC1035]
- When a query contains more than one question, successive questions in the same message often contain similar names, and consequently name compression SHOULD be used, to save bytes
- In addition, queries may also contain Known Answers in the Answer Section, or probe tiebreaking data in the Authority Section, and these names SHOULD similarly be compressed for network efficiency
- In addition to compressing the names of resource records, names that appear within the rdata of the following rrtypes SHOULD also be compressed in all Multicast DNS messages:
- Until future IETF Standards Action [RFC5226] specifying that names in the rdata of other types should be compressed, names that appear within the rdata of any type not listed above MUST NOT be compressed
- Implementations receiving Multicast DNS messages MUST correctly decode compressed names appearing in the Question Section, and compressed names of resource records appearing in other sections
- In addition, implementations MUST correctly decode compressed names appearing within the rdata of the rrtypes listed above
- Where possible, implementations SHOULD also correctly decode compressed names appearing within the rdata of other rrtypes known to the implementers at the time of implementation, because such forward- thinking planning helps facilitate the deployment of future implementations that may have reason to compress those rrtypes
- Since all Multicast DNS implementations were created after 1996, all Multicast DNS implementations are REQUIRED to decode compressed SRV records correctly
- In legacy unicast responses generated to answer legacy queries, name compression MUST NOT be performed on SRV records
- To avoid this, a host MUST NOT append the search suffix ".local.", if present, to any relative (partially qualified) host name containing two or more labels
- Since there is no central authority responsible for assigning dot-local names, and all devices on the local network are equally entitled to claim any dot-local name, users SHOULD be
- aware of this and SHOULD exercise appropriate caution
- In an untrusted or unfamiliar network environment, users SHOULD be aware that using a name like "www.local" may not actually connect them to the web site they expected, and could easily connect them to a different web page, or even a fake or spoof of their intended web site, designed to trick them into revealing confidential information
- Name resolution APIs and libraries SHOULD recognize these names as special and SHOULD NOT send queries for these names to their configured (unicast) caching DNS server(s)
- Caching DNS servers SHOULD recognize these names as special and SHOULD NOT attempt to look up NS records for them, or otherwise query authoritative DNS servers in an attempt to resolve these names
- Instead, caching DNS servers SHOULD generate immediate NXDOMAIN responses for all such queries they may receive (from misbehaving name resolver libraries)
- Authoritative DNS servers SHOULD NOT by default be configurable to answer queries for these names, and, like caching DNS servers, SHOULD generate immediate NXDOMAIN responses for all such queries they may receive
- DNS server software MAY provide a configuration option to override this default, for testing purposes or other specialized uses
- DNS server operators SHOULD NOT attempt to configure authoritative DNS servers to act as authoritative for any of these names
- Since name resolver libraries and caching DNS servers SHOULD NOT send queries for those names (see 3 and 4 above), such queries SHOULD be suppressed before they even reach the authoritative DNS server in question, and consequently it will not even get an opportunity to answer them
- DNS Registrars MUST NOT allow any of these names to be registered in the normal way to any person or entity
- Compliant Multicast DNS implementations MUST support names up to 255 bytes plus a terminating zero, i.e., 256 bytes total
rfc6763
- It MUST NOT contain ASCII control characters (byte values 0x00-0x1F and 0x7F) [RFC20] but otherwise is allowed to contain any characters, without restriction, including spaces, uppercase, lowercase, punctuation -- including dots -- accented characters, non-Roman text, and anything else that may be represented using Net-Unicode
- The portion of the name of a service being offered on the network SHOULD be configurable by the user setting up the service, so that he or she may give it an informative name
- However, the device or service SHOULD NOT require the user to configure a name before it can be used
- The default name should be short and descriptive, and SHOULD NOT include the device's Media Access Control (MAC) address, serial number, or any similar incomprehensible hexadecimal string in an attempt to make the name globally unique
- For discussion of why names don't need to be (and SHOULD NOT be) made unique at the factory, see Appendix D, "Choice of Factory-Default Names"
- In cases where the DNS server returns a negative response for the name in question, client software MAY choose to retry the query using the "Punycode" algorithm [RFC3492] to convert the UTF-8 name to an IDNA "A-label" [RFC5890], beginning with the top-level label, then issuing the query
- If client software takes the , , and portions of a Service Instance Name and internally concatenates them together into a single string, then because the portion is allowed to contain any characters, including dots, appropriate precautions MUST be taken to ensure that DNS label boundaries are properly preserved
- In the event that more than one SRV is returned, clients MUST correctly interpret the priority and weight fields -- i.e., lower- numbered priority servers should be used in preference to higher- numbered priority servers, and servers with equal priority should be selected randomly in proportion to their relative weights
- However, in the overwhelmingly common case, a single advertised DNS-SD service instance is described by exactly one SRV record, and in this common case the priority and weight fields of the SRV record SHOULD both be set to zero
- Every DNS-SD service MUST have a TXT record in addition to its SRV record, with the same name, even if the service has no additional data to store and the TXT record contains no more than a single zero byte
- DNS-SD implementations MUST NOT emit empty TXT records
- DNS-SD clients MUST treat the following as equivalent:
- Using TXT records larger than 1300 bytes is NOT RECOMMENDED at this time
- If an implementation sees unknown keys in a service TXT record, it MUST silently ignore them
- This information -- target host name and port number -- MUST NOT be duplicated using key/value attributes in the TXT record
- The key MUST be at least one character
- DNS-SD TXT record strings beginning with an '=' character (i.e., the key is missing) MUST be silently ignored
- The key SHOULD be no more than nine characters long
- The characters of a key MUST be printable US-ASCII values (0x20-0x7E) [RFC20], excluding '=' (0x3D)
- A given key SHOULD NOT appear more than once in a TXT record
- If a client receives a TXT record containing the same key more than once, then the client MUST silently ignore all but the first occurrence of that attribute
- The value MUST NOT
- Authors defining DNS-SD profiles SHOULD NOT generically convert binary attribute data types into printable text using hexadecimal representation, Base-64 [RFC4648], or Unix-to-Unix (UU) encoding, merely for the sake of making the data appear to be printable text when seen in a generic debugging tool
- Clients SHOULD ignore TXT records with a txtvers number higher (or lower) than the version(s) they know how to interpret
- Note: When used with Multicast DNS [RFC6762], the target host field of the placeholder SRV record MUST NOT be the empty root label
- Address-derived Domain Enumeration queries SHOULD NOT be done for IPv4 link-local addresses [RFC3927] or IPv6 link-local addresses [RFC4862]
- This section recommends which additional records SHOULD be generated to improve network efficiency, for both Unicast and Multicast DNS-SD responses
- Note that while servers SHOULD add these additional records for efficiency purposes, as with all DNS additional records, it is the client's responsibility to determine whether or not to trust them
- Clients MUST be capable of functioning correctly with DNS servers (and Multicast DNS Responders) that fail to generate these additional records automatically, by issuing subsequent queries for any further record(s) they require
- The additional-record generation rules in this section are RECOMMENDED for improving network efficiency, but are not required for correctness
- When including a DNS-SD Service Instance Enumeration or Selective Instance Enumeration (subtype) PTR record in a response packet, the server/responder SHOULD include the following additional records:
- When including an SRV record in a response packet, the server/responder SHOULD include the following additional records:
rfc6840
- The zone may be using either, and validators supporting these algorithms MUST support both NSEC3 and NSEC responses
- That guidance has changed: security-aware resolvers SHOULD implement a BAD cache as described in [RFC4035]
- Ancestor delegation NSEC or NSEC3 RRs MUST NOT be used to assume nonexistence of any RRs below that zone cut, which include all RRs at that (original) owner name other than DS RRs, and all RRs below that owner name regardless of type
- An NSEC or NSEC3 RR with the DNAME bit set MUST NOT be used to assume the nonexistence of any subdomain of that NSEC/NSEC3 RR's (original) owner name
- When validating a response to QTYPE=*, all received RRsets that match QNAME and QCLASS MUST be validated
- If there are no RRsets matching QNAME and QCLASS, that fact MUST be validated according to the rules in Section 5.4 of [RFC4035] (as clarified in this document)
- When validating a NOERROR/NODATA response, validators MUST check the CNAME bit in the matching NSEC or NSEC3 RR's type bitmap in addition to the bit for the query type
- The validator also MUST check for the presence of the NS bit in the matching NSEC (or NSEC3) RR (proving that there is, indeed, a delegation), or alternately make sure that the delegation is covered by an NSEC3 RR with the Opt-Out flag set
- In brief, DS records using unknown or unsupported message digest algorithms MUST be treated the same way as DS records referring to DNSKEY RRs of unknown or unsupported public key algorithms
- In these cases, the resolver MUST retrieve the corresponding DNSKEY for each private algorithm DS record and examine the public key field to determine the algorithm in use
- The security-aware resolver MUST ensure that the hash of the DNSKEY RR's owner name and RDATA matches the digest in the DS RR as described in Section 5.2 of [RFC4035], authenticating the DNSKEY
- This document specifies that a resolver SHOULD accept any valid RRSIG as sufficient, and only determine that an RRset is Bogus if all RRSIGs fail validation
- As stated in Section 3 of [RFC3225], the DNSSEC OK (DO) bit of the query MUST be copied in the response
- However, in order to interoperate with implementations that ignore this rule on sending, resolvers MUST ignore the DO bit in responses
- In order to interoperate with legacy stub resolvers and middleboxes that neither understand nor ignore the AD bit, validating resolvers SHOULD only set the AD bit when a response both meets the conditions listed in Section 3.2.3 of [RFC4035], and the request contained either a set DO bit or a set AD bit
- When processing a request with the Checking Disabled (CD) bit set, a resolver SHOULD attempt to return all response data, even data that has failed DNSSEC validation
- This document further specifies that validating resolvers SHOULD set the CD bit on every upstream query
- A signed zone MUST include a DNSKEY for each algorithm present in the zone's DS RRset and expected trust anchors for the zone
- The zone MUST also be signed with each algorithm (though not each key) present in the DNSKEY RRset
- Validators SHOULD accept any single valid path
- They SHOULD NOT insist that all algorithms signaled in the DS RRset work, and they MUST NOT insist that all algorithms signaled in the DNSKEY RRset work
- A validator MAY have a configuration option to perform a signature completeness test to support troubleshooting
- Validating resolvers MUST disregard RRSIGs in a zone that do not (currently) have a corresponding DNSKEY in the zone
- Similarly, a validating resolver MUST disregard RRSIGs with algorithm types that don't exist in the DNSKEY RRset
- Blocks with no types present MUST NOT be included
- Using this model is NOT RECOMMENDED
- Using this model is NOT RECOMMENDED
rfc6844
- Relying Applications MUST NOT use CAA records as part of certificate validation
- CAA records MAY be used by Certificate Evaluators as a possible indicator of a security policy violation
- Such use SHOULD take account of the possibility that published CAA records changed between the time a certificate was issued and the time at which the certificate was observed by the Certificate Evaluator
- Multiple properties MAY be associated with the same domain name by publishing multiple CAA RRs at that domain name
- Issuer Critical: If set to '1', indicates that the corresponding property tag MUST be understood if the semantics of the CAA record are to be correctly interpreted by an issuer
- Issuers MUST NOT issue certificates for a domain if the relevant CAA Resource Record set contains unknown property tags that have the Critical bit set
- iodef : Specifies a URL to which an issuer MAY report certificate issue requests that are inconsistent with the issuer's Certification Practices or Certificate Policy, or that a Certificate Evaluator may use to report observation of a possible policy violation
- If the domain name holder specifies one or more iodef properties, a certificate issuer MAY report invalid certificate requests to that address
- A certificate issuer MAY specify additional parameters that allow customers to specify additional parameters governing certificate issuance
- The critical flag is intended to permit future versions CAA to introduce new semantics that MUST be understood for correct processing of the record, preventing conforming CAs that do not recognize the new semantics from issuing certificates for the indicated domains
- Before issuing a certificate, a compliant CA MUST check for publication of a relevant CAA Resource Record set
- If such a record set exists, a CA MUST NOT issue a certificate unless the CA determines that either (1) the certificate request is consistent with the applicable CAA Resource Record set or (2) an exception specified in the relevant Certificate Policy or Certification Practices Statement applies
- A certificate request MAY specify more than one domain name and MAY specify wildcard domains
- Issuers MUST verify authorization for all the domains and wildcard domains specified in the request
- Use of DNSSEC to authenticate CAA RRs is strongly RECOMMENDED but not required
- An issuer MUST NOT issue certificates if doing so would conflict with the relevant CAA Resource Record set, irrespective of whether the corresponding DNS records are signed
- Verification of such archives MAY be an audit requirement to verify CAA record processing compliance
- Publication of such archives MAY be a transparency requirement to verify CAA record processing compliance
- A domain name MAY have multiple CAA RRs associated with it and a given property MAY be specified more than once
- Bit 0, Issuer Critical Flag: If the value is set to '1', 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 tag that for which the issuer critical flag is set
- To ensure compatibility with future extensions to CAA, DNS records compliant with this version of the CAA specification MUST clear (set to "0") all reserved flags bits
- Applications that interpret CAA records MUST ignore the value of all reserved flag bits
- The tag length MUST be at least 1 and SHOULD be no more than 15
- Tag values MAY contain US-ASCII characters 'a' through 'z', 'A' through 'Z', and the numbers 0 through 9
- Tag values SHOULD NOT contain any other characters
- Tag values submitted for registration by IANA MUST NOT contain any characters other than the (lowercase) US-ASCII characters 'a' through 'z' and the numbers 0 through 9
- Property values are encoded as binary values and MAY employ sub- formats
- An issuer MAY choose to specify issuer-parameters that further constrain the issue of certificates by that issuer, for example, specifying that certificates are to be subject to specific validation polices, billed to certain accounts, or issued under specific trust anchors
- issuewild properties MUST be ignored when processing a request for a domain that is not a wildcard domain
- If at least one issuewild property is specified in the relevant CAA record set, all issue properties MUST be ignored when processing a request for a domain that is a wildcard domain
- The mail message sent SHOULD contain a brief text message to alert the recipient to the nature of the attachment
- Domain name holders SHOULD verify that the CAs they authorize to issue certificates for their domains employ appropriate controls to ensure that certificates are issued only to authorized parties within their organization
- Where possible, issuers SHOULD perform DNSSEC validation to detect missing or modified CAA record sets
- In cases where DNSSEC is not deployed in a corresponding domain, an issuer SHOULD attempt to mitigate this risk by employing appropriate DNS security controls
- process SHOULD be performed against the authoritative name server
- Data cached by third parties MUST NOT be relied on but MAY be used to support additional anti-spoofing or anti-suppression controls
- In practice, such an attack would be of minimal effect since any competent competitor that found itself unable to issue certificates due to lack of support for a property marked critical SHOULD investigate the cause and report the reason to the customer
- The scope of Expert Review SHOULD be limited to the question of whether the specification provided is sufficiently clear to permit implementation and to avoid unnecessary duplication of functionality
rfc6891
- Extended labels remain defined, but their use is discouraged due to practical difficulties with deployment; their use in the future SHOULD only be considered after careful evaluation of the deployment hindrances
- Flags SHOULD be used only when necessary for DNS resolution to function
- As such, proposals that contemplate extended labels SHOULD weigh this deployment cost against the possibility of implementing functionality in other ways
- Finally, implementations MUST NOT generate or pass Binary Labels in their communications, as they are now deprecated
- An OPT pseudo-RR (sometimes called a meta-RR) MAY be added to the additional data section of a request
- If an OPT record is present in a received request, compliant responders MUST include an OPT record in their respective responses
- OPT RRs MUST NOT be cached, forwarded, or stored in or loaded from master files
- The OPT RR MAY be placed anywhere within the additional data section
- When an OPT RR is included within any DNS message, it MUST be the only OPT RR in that message
- If a query message with more than one OPT RR is received, a FORMERR (RCODE=1) MUST be returned
- +------------+--------------+------------------------------+ | Field Name | Field Type | Description | +------------+--------------+------------------------------+ | NAME | domain name | MUST be 0 (root domain) | | TYPE | uint16t | OPT (41) | | CLASS | uint16t | requestor's UDP payload size | | TTL | uint32t | extended RCODE and flags | | RDLEN | uint16t | length of all RDATA | | RDATA | octet stream | {attribute,value} pairs | +------------+--------------+------------------------------+
- Each option MUST be treated as a bit field
- MUST be treated as a bit field
- Any OPTION-CODE values not understood by a responder or requestor MUST be ignored
- For example, an option specification might say that if a responder sees and supports option XYZ, it MUST include option XYZ in its response
- A requestor's version numbering strategy MAY ideally be a run-time configuration option
- If a responder does not implement the VERSION level of the request, then it MUST respond with RCODE=BADVERS
- All responses MUST be limited in format to the VERSION level of the request, but the VERSION of each response SHOULD be the highest implementation level of the responder
- The OPT record MUST NOT be cached
- If a requestor detects that the remote end does not support EDNS(0), it MAY issue queries without an OPT record
- It MAY cache this knowledge for a brief time in order to avoid fallback delays in the future
- If an implementation detects that some servers for the zone support EDNS(0) while others would force the use of TCP to fetch all data, preference MAY be given to servers that support EDNS(0)
- Implementers SHOULD analyse this choice and the impact on both endpoints
- Values lower than 512 MUST be treated as equal to 512
- The requestor SHOULD place a value in this field that it can actually receive
- For example, if a requestor sits behind a firewall that will block fragmented IP packets, a requestor SHOULD NOT choose a value that will cause fragmentation
- Where fragmentation is not a concern, use of bigger values SHOULD be considered by implementers
- Implementations SHOULD use their largest configured or implemented values as a starting point in an EDNS transaction in the absence of previous knowledge about the destination server
- It MUST NOT be cached for use beyond the transaction in which it is advertised
- A requestor MAY choose to implement a fallback to smaller advertised sizes to work around firewall or other network limitations
- A requestor SHOULD choose to use a fallback mechanism that begins with a large size, such as 4096
- If that fails, a fallback around the range of 1280-1410 bytes SHOULD be tried, as it has a reasonable chance to fit within a single Ethernet frame
- Failing that, a requestor MAY choose a 512-byte packet, which with large answers may cause a TCP retry
- Values of less than 512 bytes MUST be treated as equal to 512 bytes
- Conformant middleboxes MUST NOT limit DNS messages over UDP to 512 bytes
- Middleboxes that simply forward requests to a recursive resolver MUST NOT modify and MUST NOT delete the OPT record contents in either direction
- Middleboxes that have additional functionality, such as answering queries or acting as intelligent forwarders, SHOULD be able to process the OPT record and act based on its contents
- These middleboxes MUST consider the incoming request and any outgoing requests as separate transactions if the characteristics of the messages are different
- Lack of presence of an OPT record in a request MUST be taken as an indication that the requestor does not implement any part of this specification and that the responder MUST NOT include an OPT record in its response
- Extended agents MUST be prepared for handling interactions with unextended clients in the face of new protocol elements and fall back gracefully to unextended DNS when needed
- Responders that choose not to implement the protocol extensions defined in this document MUST respond with a return code (RCODE) of FORMERR to messages containing an OPT record in the additional section and MUST NOT include an OPT record in the response
- If there is a problem with processing the OPT record itself, such as an option value that is badly formatted or that includes out-of-range values, a FORMERR MUST be returned
- If this occurs, the response MUST include an OPT record
- The minimal response MUST be the DNS header, question section, and an OPT record
- This MUST also occur when a truncated response (using the DNS header's TC bit) is returned
- Flags SHOULD be used only when necessary for DNS resolution to function
rfc6944
- Must Implement: The algorithm MUST be implemented to interoperate with other implementations of this specification
- Must Not Implement: The algorithm MUST NOT be implemented
- Recommended to Implement: The algorithm SHOULD be implemented
- Optional: The algorithm MAY be implemented, but all implementations MUST be prepared to interoperate with implementations that do or do not implement this algorithm
- No new security considerations are raised in this document, though prior description of algorithms as NOT RECOMMENDED (see [RFC4034]) has been recast as Must Not Implement
rfc6975
- These three new EDNS0 option codes are all OPTIONAL to implement and use
- These options can be used independently of each other and MAY appear in any order in the OPT RR
- The order of the code values can be arbitrary and MUST NOT be used to infer preference
- The validating end-system resolver MUST also set the DNSSEC OK bit [RFC4035] to indicate that it wishes to receive DNSSEC RRs in the response
- Likewise, clients MUST NOT include RESERVED codes in any of the options
- Additionally, a client is under no obligation to list every algorithm it implements and MAY choose to only list algorithms the client wishes to signal as understood
- Since the DAU, DHU, and/or N3U options are only set in the query, if a client sees these options in the response, no action needs to be taken and the client MUST ignore the option values
- Such validating resolvers SHOULD include the DAU, DHU, and/or the N3U option(s) in the OPT RR when sending a query
- The DAU, DHU, and N3U EDNS0 options MUST NOT be included by non-validating stub resolvers
- When the recursive server receives a query with one or more of the options set, the recursive server MUST set the algorithm list for any outgoing iterative queries for that resolution chain to a union of the stub client's list and the validating recursive resolver's list
- If the client included the DO and Checking Disabled (CD) bits, but did not include the DAU, DHU, and/or N3U option(s) in the query, the validating recursive resolver MAY include the option(s) with its own list in full
- If one or more of the options are missing, the validating recursive resolver MAY include the missing options with its own list in full
- Validating recursive resolvers MUST NOT set the DAU, DHU, and/or N3U option(s) in the final response to the stub client
- Recursive resolvers that do not do validation MUST copy the DAU, DHU, and/or N3U option(s) seen in received queries as they represent the wishes of the validating downstream resolver that issued the original query
- Intermediate proxies (see Section 4.4.2 of [RFC5625]) that understand DNS are RECOMMENDED to behave like a comparable recursive resolver when dealing with the DAU, DHU, and N3U options
- The options MUST NOT trigger any special processing (e.g., RRSIG filtering in responses) on the server side
- If the server sees one (or more) of the options set with RESERVED values, the server MAY ignore recoding of those values
- Authoritative servers MUST NOT set the DAU, DHU, and/or N3U option(s) on any responses
rfc7208
- Without explicit approval of the publishing ADMD, checking other identities against SPF version 1 records is NOT RECOMMENDED because there are cases that are known to give incorrect results
- To make the test, the mail receiver MUST evaluate the check_host() function with the arguments described in Section 4.1
- It is RECOMMENDED that SPF verifiers not only check the "MAIL FROM" identity but also separately check the "HELO" identity by applying the check_host() function (Section 4) to the "HELO" identity as the
- Checking "HELO" before "MAIL FROM" is the RECOMMENDED sequence if both are checked
- SPF verifiers MUST check the "MAIL FROM" identity if a "HELO" check either has not been performed or has not reached a definitive policy result by applying the check_host() function to the "MAIL FROM" identity as the
- The authorization check SHOULD be performed during the processing of the SMTP transaction that receives the mail
- SPF records MUST be published as a DNS TXT (type 16) Resource Record (RR) [RFC1035] only
- A domain name MUST NOT have multiple records that would cause an authorization check to select more than one record
- If a published record contains multiple character-strings, then the record MUST be treated as if those strings are concatenated together without adding spaces
- The published SPF record for a given domain name SHOULD remain small enough that the results of a query for it will fit within 512 octets
- In particular, the declaration MUST be repeated for any host that has any RR records at all, and for subdomains thereof
- A compliant SPF implementation MUST produce results semantically equivalent to this description
- Receiving ADMDs that perform this check MUST correctly evaluate the check_host() function as described here
- Implementations MAY use a different algorithm than the canonical algorithm defined here, so long as the results are the same in all cases
- Internationalized domain names MUST be encoded as A-labels, as described in Section 2.3 of [RFC5890]
- SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS
- If this limit is exceeded, the implementation MUST return "permerror"
- In addition to that limit, the evaluation of each "MX" record MUST NOT result in
- If this limit is exceeded, the "mx" mechanism MUST produce a "permerror" result
- In addition to that limit, the evaluation of each "PTR" record MUST NOT result in querying more than 10 address records -- either "A" or "AAAA" resource records
- If this limit is exceeded, all records other than the first 10 MUST be ignored
- MTAs or other processors SHOULD impose a limit on the maximum amount of elapsed time to evaluate check_host()
- Such a limit SHOULD allow at least 20 seconds
- If such a limit is exceeded, the result of authorization SHOULD be "temperror"
- SPF implementations SHOULD limit "void lookups" to two
- An implementation MAY choose to make such a limit configurable
- In this case, a default of two is RECOMMENDED
- Mechanisms listed after "all" MUST be ignored
- Any "redirect" modifier (Section 6.1) MUST be ignored when there is an "all" mechanism in the record, regardless of the relative ordering of the terms
- To prevent denial-of-service (DoS) attacks, the processing limits defined in Section 4.6.4 MUST be followed
- Note regarding implicit MXes: If the has no MX record, check_host() MUST NOT apply the implicit MX rules of [RFC5321] by querying for an A or AAAA record for the same name
- This mechanism SHOULD NOT be published
- To prevent DoS attacks, the PTR processing limits defined in Section 4.6.4 MUST be applied
- If used, proper PTR records have to be in place for the domain's hosts and the "ptr" mechanism SHOULD be one of the last mechanisms checked
- It is, however, still in use as part of the SPF protocol, so compliant check_host() implementations MUST support it
- The modifiers defined in this document ("redirect" and "exp") SHOULD appear at the end of the record, after all mechanisms, though syntactically they can appear anywhere in the record
- These two modifiers MUST NOT appear in a record more than once each
- Unrecognized modifiers MUST be ignored no matter where, or how often, they appear in a record
- For clarity, any "redirect" modifier SHOULD appear as the very last term in a record
- Any "redirect" modifier MUST be ignored if there is an "all" mechanism anywhere in the record
- If no "exp" modifier is present, then either a default explanation string or an empty explanation string MUST be returned to the calling application
- Implementations MAY limit the length of the resulting explanation string to allow for other protocol constraints and/or reasonable processing limits
- Since the explanation string is intended for an SMTP response and Section 2.4 of [RFC5321] says that responses are in [US-ASCII], the explanation string MUST be limited to [US-ASCII]
- Software SHOULD make it clear that the explanation string comes from a third party
- Note: During recursion into an "include" mechanism, an "exp" modifier from the MUST NOT be used
- In contrast, when executing a "redirect" modifier, an "exp" modifier from the original domain MUST NOT be used
- Some older implementations of SPF prohibit trailing dots in domain names, so trailing dots SHOULD NOT be published, although they MUST be accepted by implementations conforming to this document
- If a DIGIT is specified, the value MUST be nonzero
- Implementations MUST support at least a value of 127, as that is the maximum number of labels in a domain name (less the zero-length label at the end)
- If the is present in the list of validated domains, it SHOULD be used
- Otherwise, if a subdomain of the is present, it SHOULD be used
- This macro SHOULD NOT be published (see Section 5.5 for the discussion)
- This SHOULD be a fully qualified domain name, but if one does not exist (as when the checking is done by a Mail User Agent (MUA)) or if policy restrictions dictate otherwise, the word "unknown" SHOULD be substituted
- URL escaping MUST be performed for characters not in the "unreserved" set, which is defined in [RFC3986]
- A "neutral" result MUST be treated exactly like the "none" result; the distinction exists only for informational purposes
- If the checking software chooses to reject the mail during the SMTP transaction, then it SHOULD use an SMTP reply code of 550 (see [RFC5321]) and, if supported, the 5.7.1 enhanced status code (see [RFC3463], Section 3.8), in addition to an appropriate reply text
- If the checking software chooses not to reject the mail during the SMTP transaction, then it SHOULD add a Received-SPF or Authentication-Results header field (see Section 9) to communicate this result to downstream message processors
- Receiving software SHOULD NOT reject the message based solely on this result, but MAY subject the message to closer scrutiny than normal
- If the message is rejected during the SMTP transaction for this reason, the software SHOULD use an SMTP reply code of 451 and, if supported, the 4.4.3 enhanced status code (see Section 3.5 of [RFC3463])
- If the message is rejected during the SMTP transaction for this reason, the software SHOULD use an SMTP reply code of 550 and, if supported, the 5.5.2 enhanced status code (see [RFC3463], Section 3.6)
- To provide downstream agents, such as MUAs, with the information they might need in terms of evaluating or representing the apparent safety of the message content, it is RECOMMENDED that SMTP receivers record the result of SPF processing in the message header
- The Received-SPF header field is a trace field (see [RFC5322], Section 3.6.7) and SHOULD be prepended to the existing header, above the Received: field that is generated by the SMTP receiver
- It MUST appear above all other Received-SPF fields in the message
- The header field SHOULD include a "(...)" style comment after the result, conveying supporting information for the result, such as , , and
- SPF verifiers SHOULD give enough information so that the SPF results can be verified -- that is, at least "client-ip", "helo", and, if the "MAIL FROM" identity was checked, "envelope-from"
- Other keys MAY be defined by SPF verifiers
- SPF verifiers MUST make sure that the Received-SPF header field does not contain invalid characters, is not excessively long (see [RFC5322], Section 2.1.1), and does not contain malicious data that has been provided by the sender
rfc7216
- Alternative methods for determining other IP addresses MAY be used by the Device
- o For IP version 4, the resulting domain name SHOULD be shortened successively by one and two labels, and the query repeated
- o For IP version 6, the resulting domain SHOULD be shortened successively by 16, 18, 20, and 24 labels, and the query repeated
- The DHCP method described in [RFC5986] MUST be attempted on all local network interfaces before attempting this method
- An access network provider SHOULD provide NAPTR records for each public IP address that is used for Devices within the access network
- Any DNS server internal to a NAT SHOULD also include records for the private address range
- A network that operates network address translation SHOULD provide NAPTR records that reference a LIS endpoint with a public address
- A Device that discovers a LIS using the methods in this document MUST NOT provide that LIS with additional information that might reveal its position, such as the location measurements described in [RFC7105], unless it has a secondary method for determining the authenticity of the LIS, such as a white list
- A Device that relies on DNS records in the private address space portion of the ".in-addr.arpa." or ".ip6.arpa." trees MUST either use an alternative trust anchor for these records or rely on other means of ensuring the veracity of the DNS records
rfc7218
rfc7344
- The use of CDS/CDNSKEY is OPTIONAL
- If the Child publishes either the CDS or the CDNSKEY resource record, it SHOULD publish both
- If the Child knows which the Parent consumes, it MAY choose to only publish that record type (for example, some Children wish the Parent to publish a DS, but they wish to keep the DNSKEY "hidden" until needed)
- If the Child publishes both, the two RRsets MUST match in content
- This means that, once the Child and Parent are in sync, the Child DNS Operator MAY remove all CDS and CDNSKEY resource records from the zone
- o Location: MUST be at the Child zone apex
- o Signer: MUST be signed with a key that is represented in both the current DNSKEY and DS RRsets, unless the Parent uses the CDS or CDNSKEY RRset for initial enrollment; in that case, the Parent validates the CDS/CDNSKEY through some other means (see Section 6.1 and the Security Considerations)
- o Continuity: MUST NOT break the current delegation if applied to DS RRset
- If any these conditions fail, the CDS or CDNSKEY resource record MUST be ignored, and this error SHOULD be logged
- In order to be valid, the CDS/CDNSKEY RRset(s) MUST be compliant with the rules in Section 4.1
- When the Parent DS is in sync with the CDS/CDNSKEY RRset(s), the Child DNS Operator MAY delete the CDS/CDNSKEY RRset(s); the Child can determine if this is the case by querying for DS records in the Parent
- The CDS/CDNSKEY RRset(s) SHOULD be used by the Parental Agent to update the DS RRset in the Parent zone
- The Parent MUST choose to use either CDNSKEY or CDS resource records as its default updating mechanism
- The Parent MAY only accept either CDNSKEY or CDS, but it MAY also accept both so it can use the other in the absence of the default updating mechanism; it MUST NOT expect there to be both
- If the Parent zone does not contain DS for this delegation, then the "push" SHOULD be ignored
- If the Parental Agent displays the contents of the CDS/CDNSKEY to the user and gets confirmation that this represents their key, the Parental Agent MAY use this for initial enrollment (when the Parent zone does not contain the DS for this delegation)
- In either case, the Parental Agent MAY apply additional rules that defer the acceptance of a CDS/CDNSKEY change
- If the CDS/CDNSKEY RRset(s) do not exist, the Parental Agent MUST take no action
- Specifically, it MUST NOT delete or alter the existing DS RRset
- Regardless of how the Parental Agent detected changes to a CDS/ CDNSKEY RRset, the Parental Agent SHOULD use a DNSSEC validator to obtain a validated CDS/CDNSKEY RRset from the Child zone
- A NOT RECOMMENDED exception to this is if the Parent performs some additional validation on the data to confirm that it is the "correct" key
- The Parental Agent MUST ensure that previous versions of the CDS/ CDNSKEY RRset do not overwrite more recent versions
- This MAY be accomplished by checking that the signature inception in the Resource Record Signature (RRSIG) for CDS/CDNSKEY RRset is later and/or that the serial number on the Child's Start of Authority (SOA) is greater
- The Parental Agent MAY take extra security measures
- Once the Parental Agent has obtained a valid CDS/CDNSKEY RRset it MUST check the publication rules from Section 4.1
- In particular, the Parental Agent MUST check the Continuity rule and do its best not to invalidate the Child zone
- While it may be tempting, the techniques specified in this document SHOULD NOT be used for initial enrollment of keys since there is no way to ensure that the initial key is the correct one
- If it is used, strict rules for inclusion of keys -- such as hold-down times, challenge data inclusion, or similar -- MUST be used along with some kind of challenge mechanism
- As this introduces a new mechanism to update information in the Parent, it MUST be clear who is fetching the records and creating the appropriate records in the Parent zone
- Therefore, this mechanism SHOULD NOT be used to bypass intermediaries that might cache information and, because of that, get the wrong state
rfc7372
- If a receiving server performs multiple authentication checks and more than one of them fails, thus warranting rejection of the message, the SMTP server SHOULD use the code that indicates multiple methods failed rather than only reporting the first one that failed
rfc7477
- Child DNS operators wanting a parental agent to perform the synchronization steps outlined in this document MUST publish a CSYNC record at the apex of the child zone
- Parental agent implementations MAY choose to query
- Parental agents MUST process the entire set of child data indicated by the Type Bit Map field (i.e., all record types indicated along with all of the necessary records to support processing of that type) or else parental agents MUST NOT make any changes to parental records at all
- Errors due to unsupported Type Bit Map bits, or otherwise nonpunishable data, SHALL result in no change to the parent zone's delegation information for the child
- Parental agents MUST ignore a child's CSYNC RDATA set if multiple CSYNC resource records are found; only a single CSYNC record should ever be present
- The parental agent MUST perform DNSSEC validation ([RFC4033] [RFC4034] [RFC4035]), of the CSYNC RRType data and MUST perform DNSSEC validation of any data to be copied from the child to the parent
- Parents MUST NOT process any data from any of these records if any of the validation results indicate anything other than "Secure" [RFC4034] or if any the required data cannot be successfully retrieved
- If the soaminimum flag is set, parental agents querying children's authoritative servers MUST NOT act on data from zones advertising an SOA serial number less than this value
- If the soaminimum flag is not set, parental agents MUST ignore the value in the SOA Serial field
- A child SHOULD update the SOA Serial field in the CSYNC record every time the data being referenced by the CSYNC record is changed (e.g., an NS record or associated address record is changed)
- A child MAY choose to update the SOA Serial field to always match the current SOA Serial field
- Parental agents MAY cache SOA serial numbers from data they use and refuse to process data from zones older than the last instance from which they pulled data
- Undefined flags MUST be set to 0 by CSYNC publishers
- Parental agents MUST NOT process a CSYNC record if it contains a 1 value for a flag that is unknown to or unsupported by the parental agent
- If a bit has been set that a parental agent implementation does not understand, the parental agent MUST NOT act upon the record
- When the mnemonic is not known, the TYPE representation described in [RFC3597], Section 5, MUST be used
- Implementations that support parsing of presentation format records SHOULD be able to read and understand these TYPE representations as well
- If a parental agent fails to successfully query for any of the required records, the whole operation MUST be aborted
- Parental agents MAY:
- If the "immediate" flag is not set, the parental agent MUST NOT act until the zone administrator approves the operation through an out-of-band mechanism (such as through pushing a button via a web interface)
- The following shows a sequence of steps that SHOULD be used when collecting and processing CSYNC records from a child zone
- To ensure a single host is being addressed, DNS over TCP SHOULD be used to avoid conversing with multiple nodes at an anycast address
- Because of the additional operational complexity, parental agents MAY choose not to support this protocol with children making use of records that are authoritative in the grandchildren
- If the SOA records from the first, middle, and last steps for a given zone have different serial numbers (for example, because the zone was edited and republished during the interval between steps 1 and 4), then the CSYNC record obtained in the second set SHOULD NOT be processed (rapidly changing child zones may need special consideration or processing)
- The operation MAY be restarted or retried in the future
- If the soaminimum flag is set and the SOA serial numbers are equal but less than the CSYNC record's SOA Serial field [RFC1982], the record MUST NOT be processed
- If state is being kept by the parental agent and the SOA serial number is less than the last time a CSYNC record was processed, this CSYNC record SHOULD NOT be processed
- Similarly, if state is being kept by the parental agent and the SOA Serial field of the CSYNC record is less than the SOA Serial field of the CSYNC record from last time, then this CSYNC record SHOULD NOT be processed
- If a failure of any kind occurs while trying to obtain any of the required data, or if DNSSEC fails to validate all of the data returned for these queries as "secure", then this CSYNC record MUST NOT be processed
- NS records found within the child's zone should be copied verbatim (with the exception of the Time to Live (TTL) field, for which the parent MAY want to select a different value) and the result published within the parent zone should be a set of NS records that match exactly
- Parental agents MAY refuse to perform NS updates if the replacement records fail to meet NS record policies required by the parent zone (e.g., "every child zone must have at least two NS records")
- Parental agents MUST NOT perform NS updates if there are no NS records returned in a query, as verified by DNSSEC denial-of- existence protection
- The A and AAAA type flags indicates that the A and AAAA address glue records for in-bailiwick NS records within the child zone should be copied verbatim (with the exception of the TTL field, for which the parent MAY want to select a different value) into the parent's delegation information
- However, if the end result of processing would leave no glue records present in the parent zone for any of the of the in-bailiwick NS records, then the parent MUST NOT update the glue address records
- The procedure for querying for A and AAAA records MUST occur after the procedure, if required, for querying for NS records as defined in Section 3.2.1
- Parental agents MAY perform best-possible verification by querying all NS records for available data to determine which has the most recent SOA and CSYNC version (in an ideal world, they would all be equal, but this is not possible in practice due to synchronization delays and transfer failures)
- Thus, the child DNS operator MAY indicate that the NS records should be synchronized, and
- MAY set any glue record flags (A, AAAA) as well, but the parent will only update those glue records that are below the child's delegation point
- Children deploying NS records pointing to domain names within their own children (the "grandchildren") SHOULD ensure the grandchildren's associated glue records are properly set before publishing the CSYNC record
- Parental agents that support processing CSYNC records SHOULD publicly document the following minimum processing characteristics:
- Children MAY remove the CSYNC record upon noticing that the parent zone has published the required records, thus eliminating the need for the parent to continually query for the CSYNC record and all corresponding records
- Parental agents implementing CSYNC processing MUST ensure all DNS transactions are validated by DNSSEC as "secure"
- Clients deploying CSYNC MUST ensure their zones are signed, current and properly linked to the parent zone with a DS record that points to an appropriate DNSKEY of the child's zone
- Thus, implementations of this protocol MUST NOT use it to synchronize DS records, DNSKEY materials, CDS records, CDNSKEY records, or CSYNC records
- Similarly, future documents extending this protocol MUST NOT offer the ability to synchronize DS, DNSKEY materials, CDS records, CDNSKEY records, or CSYNC records
- To ensure that an older CSYNC record making use of the soaminimum flag cannot be replayed to revert values, the SOA serial number MUST NOT be incremented by more than 2^16 during the lifetime of the signature window of the associated RRSIGs signing the SOA and CSYNC records
rfc7671
- Clients SHOULD implement SHA2-512(2), but servers SHOULD NOT exclusively publish SHA2-512(2) digests
- The digest algorithm agility protocol defined in Section 9 SHOULD be used by clients to decide how to process TLSA RRsets that employ multiple digest algorithms
- Server operators MUST publish TLSA RRsets that are compatible (see Section 8) with digest algorithm agility (Section 9)
- This document specifies that TLS clients that support DANE/TLSA MUST support at least TLS 1.0 and SHOULD support TLS 1.2 or later
- TLS clients using DANE MUST support the SNI extension of TLS [RFC6066]
- Servers MAY support SNI and respond with a matching certificate chain but MAY also ignore SNI and respond with a default certificate chain
- When a server supports SNI but is not configured with a certificate chain that exactly matches the client's SNI extension, the server SHOULD respond with another certificate chain (a default or closest match)
- Simultaneous support for all four usages is NOT RECOMMENDED for DANE clients
- Designs in which clients support just the DANE-TA(2) and DANE-EE(3) certificate usages are RECOMMENDED
- The DNSSEC TLSA records for servers MAY include both sets of usages if the server needs to support a mixture of clients, some supporting one pair of usages and some the other
- However, if usable secure TLSA records are published, then authentication MUST succeed
- Because the PKIX-TA(0) and PKIX-EE(1) usages offer no more security and are more prone to failure, they are a poor fit for OS and SHOULD NOT be used in that context
- Therefore, when a TLS client authenticates the TLS server via a TLSA record with usage DANE-EE(3), CT checks SHOULD NOT be performed
- Since TLSA certificate usage DANE-TA(2) is generally intended to support non-public TAs, TLS clients SHOULD NOT perform CT checks with usage DANE-TA(2)
- The server MUST be considered authenticated even if none of the names in the certificate match the client's reference identity for the server
- Also, with DANE-EE(3), the expiration date of the server certificate MUST be ignored
- More specifically, it is RECOMMENDED that at most sites TLSA records published for DANE servers be "DANE-EE(3) SPKI(1) SHA2-256(1)" records
- Clients that employ DANE to authenticate the peer server SHOULD NOT negotiate the use of raw public keys unless the server's TLSA RRset includes "DANE-EE(3) SPKI(1)" TLSA records
- Also, with DANE-TA(2), server operators MUST ensure that the server is configured with a sufficiently complete certificate chain and need to remember to replace certificates prior to their expiration dates
- This section updates [RFC6698] by specifying a new operational requirement for servers publishing TLSA records with a usage of DANE-TA(2): such servers MUST include the TA certificate in their TLS server certificate message unless all such TLSA records are "2 0 0" records that publish the server certificate in full
- When hosting multiple unrelated Customer Domains (that can't all appear in a single certificate), such a server SHOULD employ SNI to select the appropriate certificate to present to the client
- TLSA records with a matching type of Full(0) are NOT RECOMMENDED
- Since the server will need to transmit the TA certificate in any case, server operators SHOULD publish TLSA records with a matching type other than Full(0) and avoid potential DNS interoperability issues with large TLSA records containing full certificates or keys (see Section 10.1.1)
- TLSA Publishers employing DANE-TA(2) records SHOULD publish records with a selector of Cert(0)
- In particular, when authenticating the peer certificate chain via such a TLSA record, the client SHOULD apply any relevant constraints from the TA certificate, such as, for example, path length constraints
- The sender's certificate MUST come first in the list
- Each following certificate MUST directly certify the one preceding it
- Because certificate validation requires that root keys be distributed independently, the self-signed certificate that specifies the root certificate authority MAY be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case
- TLSA Publishers that publish TLSA certificate usage DANE-TA(2) associations with a selector of SPKI(1) or with a digest-based matching type (not Full(0)) MUST ensure that the corresponding server is configured to also include the TA certificate in its TLS handshake certificate chain, even if that certificate is a self-signed root CA and would have been optional in the context of the existing public CA PKI
- This is also the only type of DANE-TA(2) record for which the client MUST be able to verify the server's certificate chain even if the TA certificate appears only in DNS and is absent from the TLS handshake server certificate message
- Servers employing "2 1 0" TLSA records MUST include the corresponding TA certificate in their certificate chain
- If none of the server's certificate chain elements match a public key specified in a TLSA record, and at least one "DANE-TA(2) SPKI(1) Full(0)" TLSA record is available, it is RECOMMENDED that clients check to see whether or not the topmost certificate in the chain is signed by the provided public key and has not expired, and in that case consider the server authenticated, provided the rest of the chain passes validation, including leaf certificate name checks
- Clients that trust intermediate certificates MUST be prepared to construct longer PKIX chains than would be required for PKIX alone
- Thus, this certificate usage is NOT RECOMMENDED when the Service Provider is not also the TLSA Publisher (at the TLSA base domain obtained via CNAMEs, SRV records, or MX records)
- so long as no matching certificate has yet been found, a client MUST continue extending the chain even after any locally trusted certificate is found
- If no TLSA records have matched any of the elements of the chain and the trusted certificate found is not self-issued, the client MUST attempt to build a longer chain in case a certificate closer to the root matches the server's TLSA record
- Therefore, DANE TLS clients connecting to a server whose domain name is a CNAME alias SHOULD follow the CNAME "hop by hop" to its ultimate target host (noting at each step whether or not the CNAME is DNSSEC validated)
- If at each stage of CNAME expansion the DNSSEC validation status is "secure", the final target name SHOULD be the preferred base domain for TLSA lookups
- Implementations failing to find a TLSA record using a base name of the final target of a CNAME expansion SHOULD issue a TLSA query using the original destination name
- That is, the preferred TLSA base domain SHOULD be derived from the fully expanded name and, failing that, SHOULD be the initial domain name
- When the TLSA base domain is the result of "secure" CNAME expansion, the resulting domain name MUST be used as the HostName in the client's SNI extension and MUST be the primary reference identifier for peer certificate matching with certificate usages other than DANE-EE(3)
- If they do, they SHOULD use the target hostname as the preferred TLSA base domain as described above (and, if the TLSA records are found there, also use the CNAME-expanded domain in SNI and certificate name checks)
- This section updates [RFC6698] by specifying that the TLSA Publisher MUST ensure that each combination of certificate usage, selector, and matching type in the server's TLSA RRset includes at least one record that matches the server's current certificate chain
- Such past or future records MUST NOT at any time be the only records published for any given combination of usage, selector, and matching type
- When employing a new digest algorithm in the TLSA RRset, for compatibility with digest algorithm agility as specified in Section 9 below, administrators SHOULD publish the new digest algorithm with each combination of certificate usage and selector for each associated key or chain used with any other digest algorithm
- Each digest algorithm employed SHOULD match the same set of chains (or raw public keys)
- Each combination of certificate usage, selector, and matching type in a server's TLSA RRset SHOULD NOT at any time (including unexpired RRsets in client caches) match only some combination of future or past certificate chains
- Such a protocol would allow the client and server to avoid exposure to deprecated weaker algorithms that are published for compatibility with less capable clients but that SHOULD be avoided when possible
- Client implementations SHOULD implement a default order of digest algorithms by strength
- This order SHOULD be configurable by the administrator or user of the client software
- If possible, a configurable mapping from numeric DANE TLSA matching types to underlying digest algorithms provided by the cryptographic library SHOULD be implemented to allow new matching types to be used with software that predates their introduction
- Configurable ordering of digest algorithms SHOULD be extensible to any new digest algorithms
- To make digest algorithm agility possible, all published DANE TLSA RRsets MUST conform to the requirements of Section 8
- Clients SHOULD use digest algorithm agility when processing the peer's DANE TLSA records
- For each usage and selector, the client SHOULD process only any usable records with a matching type of Full(0) and the usable records whose digest algorithm is considered by the client to be the strongest among usable records with the given usage and selector
- In this case, the client SHOULD accept a server public key that matches either the "3 1 0" record or the "3 1 2" record, but it SHOULD NOT accept keys that match only the weaker "3 1 1" record
- Deployments SHOULD avoid TLSA record sizes that cause UDP fragmentation
- Server operators SHOULD NOT publish TLSA records using both a TLSA selector of Cert(0) and a TLSA matching type of Full(0), as even a single certificate is generally too large to be reliably delivered via DNS over UDP
- Rather, servers SHOULD publish digest-based TLSA matching types in their TLSA records, in which case the complete corresponding certificate MUST be transmitted to the client in-band during the TLS handshake
- In summary, the use of a TLSA matching type of Full(0) is NOT RECOMMENDED, and a digest-based matching type, such as SHA2-256(1), SHOULD be used instead
- DANE clients MUST send the SNI extension with a HostName value of the base domain of the TLSA RRset
- With the exception of TLSA certificate usage DANE-EE(3), where name checks are not applicable (see Section 5.1), DANE clients MUST verify that the client has reached the correct server by checking that the server name is listed in the server certificate's SAN or CN (when still supported)
- The primary server name used for this comparison MUST be the TLSA base domain; however, additional acceptable names may be specified by protocol-specific DANE standards
- Nevertheless, servers publishing TLSA records MUST be configured to allow correctly configured clients to successfully authenticate their TLS certificate chains
- When authenticated TLS is mandatory, the client MUST NOT connect to the associated server
- If, on the other hand, the use of TLS and DANE is "opportunistic" [RFC7435], then when all TLSA records are unusable, the client SHOULD connect to the server via an unauthenticated TLS connection, and if TLS encryption cannot be established, the client MUST NOT connect to the server
- If expecting TLS support when unusable TLSA records are published is realistic for the application in question, then the application MUST avoid cleartext
- o Section 4 explains that application support for all four certificate usages is NOT RECOMMENDED
- o Section 5.2 updates [RFC6698] to require that servers publishing digest TLSA records with a usage of DANE-TA(2) MUST include the TA certificate in their TLS server certificate message
- The signature lifetime (length of the signature validity period) for TLSA records SHOULD NOT be too long
- When TLS is opportunistic, the client MAY proceed to use the server with mandatory unauthenticated TLS
- When TLS is not opportunistic, the client MUST NOT connect to the server
- Of course, when PKIX-TA(0) and PKIX-EE(1) are supported by the application protocol, clients MUST implement these certificate usages as described in [RFC6698] and this document
rfc7672
- When name checks are applicable, at least one of the reference identifiers MUST match an [RFC6125] DNS-ID (or, if none are present, the [RFC6125] CN-ID) of the server certificate (see Section 3.2.3)
- A security-aware resolver MUST be used for this specification
- All "insecure" RRsets MUST be handled identically: in either case, non-validated data for the query domain is all that is and can be available, and authentication using the data is impossible
- As noted in Section 4.3 of [RFC4035], a security-aware DNS resolver MUST be able to determine whether a given non-error DNS response is "secure", "insecure", "bogus", or "indeterminate"
- If a resolver does signal an [RFC4035] "indeterminate" security status, this MUST be treated by the SMTP client as though a "bogus" or error result had been returned
- An MTA using a non-validating security-aware stub resolver MAY use the stub resolver's ability, if available, to signal DNSSEC validation status based on information the stub resolver has learned from an upstream validating recursive resolver
- Security-oblivious stub resolvers [RFC4033] MUST NOT be used
- a security-aware stub resolver MUST NOT place any reliance on signature validation allegedly performed on its behalf, except when the security-aware stub resolver obtained the data in question from a trusted security-aware recursive name server via a secure channel
- When a DNS lookup failure (an error, "bogus", or "indeterminate", as defined above) prevents an SMTP client from determining which SMTP server or servers it should connect to, message delivery MUST be delayed
- When a particular SMTP server is securely identified as the delivery destination, a set of DNS lookups (Section 2.2) MUST be performed to locate any related TLSA records
- client MUST treat that server as unreachable and MUST NOT deliver the message via that server
- If any DNS failure occurs, the SMTP client MUST behave as described in this section, by "skipping" the SMTP server or destination that is problematic
- Queries for candidate TLSA records are explicitly part of "all relevant DNS queries", and SMTP clients MUST NOT continue to connect to an SMTP server or destination whose TLSA record lookup fails
- If at any stage of CNAME expansion an error is detected, the lookup of the original requested records MUST be considered to have failed
- Whether a chain of CNAME records was returned in a single stub resolver response or via explicit recursion by the SMTP client, if at any stage of recursive expansion an "insecure" CNAME record is encountered, then it and all subsequent results (in particular, the final result) MUST be considered "insecure", regardless of whether or not any earlier CNAME records leading to the "insecure" record were "secure"
- In contrast, DNSSEC-validated TLSA records MUST NOT be published for servers that do not support TLS
- A "secure" TLSA RRset with at least one usable record: Any connection to the MTA MUST employ TLS encryption and MUST authenticate the SMTP server using the techniques discussed in the rest of this document
- Failure to establish an authenticated TLS connection MUST result in falling back to the next SMTP server or delayed delivery
- A "secure" non-empty TLSA RRset where all the records are unusable: Any connection to the MTA MUST be made via TLS, but authentication is not required
- Failure to establish an encrypted TLS connection MUST result in falling back to the next SMTP server or delayed delivery
- An "insecure" TLSA RRset or DNSSEC-authenticated denial of existence of the TLSA records: A connection to the MTA SHOULD be made using (pre-DANE) opportunistic TLS; this includes using cleartext delivery when the remote SMTP server does not appear to support TLS
- The MTA MAY retry in cleartext when delivery via TLS fails during the handshake or even during data transfer
- Any lookup error: Lookup errors, including "bogus" and "indeterminate" as explained in Section 2.1.1, MUST result in falling back to the next SMTP server or delayed delivery
- An SMTP client MAY be configured to mandate DANE-verified delivery for some destinations
- MX records MUST be sorted by preference; an MX hostname with a worse (numerically higher) MX preference that has TLSA records MUST NOT preempt an MX hostname with a better (numerically lower) preference that has no TLSA records
- In other words, prevention of delivery loops by obeying MX preferences MUST take precedence over channel security considerations
- If the MX RRset (or any CNAME leading to it) is "insecure" (see Section 2.1.1) and DANE TLS for the given destination is mandatory (Section 6), delivery MUST be delayed
- Since the protocol in this memo is an Opportunistic Security protocol [RFC7435], the SMTP client MAY elect to use DANE TLS (as described in Section 2.2.2 below), even with MX hosts obtained via an "insecure" MX RRset
- Sending MTAs SHOULD log unexpanded MX hostnames when these result from "insecure" MX lookups
- Any successful authentication via an insecurely determined MX host MUST NOT be misrepresented in the mail logs as secure delivery to the intended next-hop domain
- In the absence of DNS lookup errors (Section 2.1.1), if the MX RRset is not "insecure", then it is "secure", and the SMTP client MUST treat each MX hostname as described in Section 2.2.2
- To avoid downgrade attacks, any errors during TLSA lookups MUST, as explained in Section 2.1.2, cause the SMTP server in question to be treated as unreachable
- These nameservers SHOULD provide "insecure" negative replies that indicate the nonexistence of the TLSA records, but instead they fail by not responding at all or by responding with a DNS RCODE [RFC1035] other than NXDOMAIN, e.g., SERVFAIL or NOTIMP [RFC2136]
- To avoid problems delivering mail to domains whose SMTP servers are served by these problematic nameservers, the SMTP client MUST perform any A and/or AAAA queries for the destination before attempting to locate the associated TLSA records
- If address records are found but the DNSSEC validation status of the first query response is "insecure" (see Section 2.1.3), the SMTP client SHOULD NOT proceed to search for any associated TLSA records
- And, as always, errors, "bogus" results, or "indeterminate" results for any query in the process MUST result in delaying or abandoning delivery
- For SMTP, the destination TCP port is typically 25, but this may be different with custom routes specified by the MTA administrator, in which case the SMTP client MUST use the appropriate number in the "" prefix in place of "25"
- Such shared end-entity TLSA records SHOULD be avoided unless the servers in question are functionally equivalent or employ mutually incompatible protocols (an active attacker gains nothing by diverting client traffic from one such server to another)
- The SMTP client MUST NOT deliver mail via the corresponding host unless a TLS session is negotiated via STARTTLS
- As noted previously (in Section 2.2.2), when no "secure" TLSA records are found at the fully CNAME-expanded name, the original unexpanded name MUST be tried instead
- The server MUST be considered authenticated even if none of the names in the certificate match the client's reference identity for the server
- The expiration date of the server certificate MUST be ignored: the validity period of the TLSA record key binding is determined by the validity interval of the TLSA record DNSSEC signature
- TLSA records published for SMTP servers SHOULD, in most cases, be "DANE-EE(3) SPKI(1) SHA2-256(1)" records
- The server MAY employ SNI to select the appropriate certificate to present to the client
- SMTP servers that rely on certificate usage DANE-TA(2) TLSA records for TLS authentication MUST include the TA certificate as part of the certificate chain presented in the TLS handshake server certificate message even when it is a self-signed root certificate
- Such servers either MUST publish DANE-TA(2) records for an intermediate certificate or MUST instead use DANE-EE(3) TLSA records
- Since the server will need to transmit the TA certificate in any case, server operators SHOULD publish TLSA records
- TLSA Publishers employing DANE-TA(2) records SHOULD publish records with a selector of Cert(0)
- In particular, the SMTP client SHOULD then apply any relevant constraints from the trust anchor certificate, such as, for example, path length constraints
- Therefore, TLSA records for the port 25 SMTP service used by client MTAs SHOULD NOT include TLSA RRs with certificate usage PKIX-TA(0) or PKIX-EE(1)
- As with any other unsupported certificate usage, SMTP clients MAY treat such records as "unusable"
- When at least one usable "secure" TLSA record is found, the SMTP client MUST use TLSA records to authenticate the SMTP server
- Messages MUST NOT be delivered via the SMTP server if authentication fails; otherwise, the SMTP client is vulnerable to MITM attacks
- The SMTP client MUST NOT perform certificate name checks with certificate usage DANE-EE(3) (Section 3.1.1)
- To match a server via a TLSA record with certificate usage DANE-TA(2), the client MUST perform name checks to ensure that it has reached the correct server
- In all DANE-TA(2) cases, the SMTP client MUST employ the TLSA base domain as the primary reference identifier for matching the server certificate
- TLSA records for MX hostnames: If the TLSA base domain was obtained indirectly via a "secure" MX lookup (including any CNAME-expanded name of an MX hostname), then the original next-hop domain used in the MX lookup MUST be included as a second reference identifier
- The CNAME-expanded original next-hop domain MUST be included as a third reference identifier if different from the original next-hop domain
- TLSA records for non-MX hostnames: If MX records were not used (e.g., if none exist) and the TLSA base domain is the CNAME-expanded original next-hop domain, then the original next-hop domain MUST be included as a second reference identifier
- Certificate name checks for delivery of mail to exchange.example.org via any of the associated SMTP servers MUST accept at least the names "exchange.example.org" and "example.com", which are, respectively, the original and fully expanded next-hop domain
- When the SMTP server is mx10.example.com, name checks MUST accept the TLSA base domain "mx10.example.com"
- If, despite the fact that MX hostnames are required to not be aliases, the MTA supports delivery via "mx15.example.com" or "mx20.example.com", then name checks MUST accept the respective TLSA base domains "mx15.example.com" and "mxbackup.example.net"
- SMTP clients MUST support wildcards that match the first label of the reference identifier, with the remaining labels matching verbatim
- SMTP clients MAY, subject to local policy, allow wildcards to match multiple reference identifier labels, but servers cannot expect broad support for such a policy
- Therefore, any wildcards in server certificates SHOULD match exactly one label in either the TLSA base domain or the next-hop domain
- Two TLSA records MUST be published before employing a new EE or TA public key or certificate: one matching the currently deployed key and the other matching the new key scheduled to replace it
- If a particular server's key is compromised, its TLSA CNAME SHOULD be replaced with a DANE-EE(3) association until the certificate for the compromised key expires, at which point it can return to using a CNAME record
- When stronger algorithms are an option, deprecated algorithms SHOULD be avoided
- SMTP clients and servers that implement this specification MUST comply with the requirements outlined in Section 9 of [RFC7671]
- To ensure that the server sends the right certificate chain, the SMTP client MUST send the TLS SNI extension containing the TLSA base domain
- Each SMTP server MUST present a certificate chain (see [RFC5246], Section 7.4.2) that matches at least one of the TLSA records
- The server MAY rely on SNI to determine which certificate chain to present to the client
- Servers MUST NOT enforce the use of SNI by clients, as the client may be using unauthenticated opportunistic TLS and may not expect any particular certificate from the server
- If the client sends no SNI extension or sends an SNI extension for an unsupported domain, the server MUST simply send some fallback certificate chain of its choice
- Since many SMTP servers either do not support or do not enable any anonymous TLS cipher suites, SMTP client TLS HELLO messages SHOULD offer to negotiate a typical set of non-anonymous cipher suites required for interoperability with such servers
- An SMTP client employing pre-DANE opportunistic TLS MAY also include one or more anonymous TLS cipher suites in its TLS HELLO
- SMTP servers that need to interoperate with opportunistic TLS clients SHOULD be prepared to interoperate with such clients by either always selecting a mutually supported non-anonymous cipher suite or correctly handling client connections that negotiate anonymous cipher suites
- Some implementations MAY support DANE TLS in an "audit only" mode in which failure to achieve the requisite security level is logged as a warning and delivery proceeds at a reduced security level
- client MUST NOT deliver mail via a server whose certificate chain fails to match at least one TLSA record when usable TLSA records are found for that server
- Server operators MUST NOT implement selective STARTTLS if they also want to support DANE TLSA
- TLSA Publishers MUST follow the guidelines in Section 8 of [RFC7671]
- TLSA Publishers SHOULD follow the TLSA publication size guidance found in Section 10.1 of [RFC7671]
- TLSA Publishers SHOULD follow the TLSA record TTL and signature lifetime recommendations found in Section 13 of [RFC7671]
rfc7673
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this memo are to be interpreted as described in [RFC2119]
- For this specification to apply, the entire chain of DNS RRset(s) returned MUST be "secure" according to DNSSEC validation (Section 5 of [RFC4035])
- In the case where the answer is obtained via a chain of CNAME and/or DNAME aliases, the whole chain of CNAME and DNAME RRsets MUST also be secure
- If the SRV lookup fails because the RRset is "bogus" (or the lookup fails for reasons other than no records), the client MUST abort its attempt to connect to the desired service
- If the lookup result is "insecure" (or no SRV records exist), this protocol does not apply and the client SHOULD fall back to its non-DNSSEC, non-DANE (and possibly non-SRV) behavior
- o If a returned RRSet is "secure", the client MUST perform a TLSA query for that target server connection endpoint, as described in the next section
- o If no returned RRsets are "secure", the client MUST NOT perform a TLSA query for that target server connection endpoint; the TLSA query will most likely fail or produce spurious results
- o If the address record lookup fails (a validation status of either "bogus" or "indeterminate"), the client MUST NOT connect to this connection endpoint; instead, it uses the next most appropriate SRV target
- The client SHALL construct the TLSA query name as described in Section 3 of [RFC6698], based on the fields from the SRV record: the port number from the SRV RDATA, the transport protocol from the SRV query name, and the TLSA base domain from the SRV target server hostname
- The client SHALL determine if the TLSA records returned in the previous step are usable according to Section 4.1 of [RFC6698]
- o If the TLSA response is "secure" and usable, then the client MUST use TLS when connecting to the target server
- o If the TLSA response is "bogus" or "indeterminate" (or the lookup fails for reasons other than no records), then the client MUST NOT connect to the target server (the client can still use other SRV targets)
- o If the TLSA response is "insecure" (or no TLSA records exist), then the client SHALL proceed as if the target server had no TLSA records
- It MAY connect to the target server with or without TLS, subject to the policies of the application protocol or client implementation
- When connecting to a server, the client MUST use TLS if the responses to the SRV and TLSA queries were "secure" as described above
- If the client received zero usable TLSA certificate associations, it SHALL validate the server's TLS certificate using the normal PKIX rules [RFC5280] or protocol-specific rules (e.g., following [RFC6125]) without further input from the TLSA records
- It SHOULD use the Server Name Indication extension (TLS SNI) [RFC6066] or its functional equivalent in the relevant application protocol (e.g., in the Extensible Messaging and Presence Protocol (XMPP) [RFC6120], this is the 'to' address of the initial stream header)
- The preferred name SHALL be chosen as follows, and the client SHALL verify the identity asserted by the server's certificate according to Section 6 of [RFC6125], using a list of reference identifiers constructed as follows (note again that in RFC 6125 the terms "source domain" and "derived domain" refer to the same things as "service domain name" and "target server hostname" in this document)
- SRV is insecure: The reference identifiers SHALL include the service domain name and MUST NOT include the SRV target server hostname (e.g., include "im.example.com" but not "xmpp23.hosting.example.net")
- SRV is secure: The reference identifiers SHALL include both the service domain name and the SRV target server hostname (e.g., include both "im.example.com" and "xmpp23.hosting.example.net")
- If the client received one or more usable TLSA certificate associations, it SHALL process them as described in Section 2.1 of [RFC6698]
- If the TLS server's certificate -- or the public key of the server's certificate -- matches a usable TLSA record with certificate usage DANE-EE, the client MUST ignore validation checks from [RFC5280] and reference identifier checks from [RFC6125]
- To conform to this specification, the published SRV records and subsequent address (A and AAAA) records MUST be secured with DNSSEC
- There SHOULD also be at least one TLSA record published that authenticates the server's certificate
- For TLSA records with certificate usage types other than DANE-EE, the certificate(s) MUST contain an identifier that matches:
rfc7686
- Application Software: Applications (including proxies) that implement the Tor protocol MUST recognize .onion names as special by either accessing them directly or using a proxy (e.g., SOCKS [RFC1928]) to do so
- Applications that do not implement the Tor protocol SHOULD generate an error upon the use of .onion and SHOULD NOT perform a DNS lookup
- Name Resolution APIs and Libraries: Resolvers MUST either respond to requests for .onion names by resolving them according to [tor-rendezvous] or by responding with NXDOMAIN [RFC1035]
- Caching DNS Servers: Caching servers, where not explicitly adapted to interoperate with Tor, SHOULD NOT attempt to look up records for .onion names
- They MUST generate NXDOMAIN for all such queries
- Authoritative DNS Servers: Authoritative servers MUST respond to queries for .onion with NXDOMAIN
- DNS Server Operators: Operators MUST NOT configure an authoritative DNS server to answer queries for .onion
- DNS Registries/Registrars: Registrars MUST NOT register .onion names; all such requests MUST be denied
rfc7766
- DNS resolvers and recursive servers MUST support UDP, and SHOULD support TCP, for sending (non-zone-transfer) queries
- This document therefore updates the core DNS protocol specifications such that support for TCP is henceforth a REQUIRED part of a full DNS protocol implementation
- Section 6.1.3.2 of [RFC1123] is updated: All general-purpose DNS implementations MUST support both UDP and TCP transport
- o Authoritative server implementations MUST support TCP so that they do not limit the size of responses to what fits in a single UDP packet
- o Recursive server (or forwarder) implementations MUST support TCP so that they do not prevent large responses from a TCP-capable server from reaching its TCP-capable clients
- o Stub resolver implementations (e.g., an operating system's DNS resolution library) MUST support TCP since to do otherwise would limit the interoperability between their own clients and upstream servers
- a DNS resolver or server that is sending a non-zone-transfer query MUST send a UDP query first
- Stub resolvers and recursive resolvers MAY elect to send either TCP or UDP queries depending on local operational reasons
- TCP MAY be used before sending any UDP queries
- If the resolver already has an open TCP connection to the server, it SHOULD reuse this connection
- In addition, it is noted that all recursive and authoritative servers MUST send responses using the same transport as the query arrived on
- In the case of TCP, this MUST also be the same connection
- To amortise connection setup costs, both clients and servers SHOULD support connection reuse by sending multiple queries and responses over a single persistent TCP connection
- When sending multiple queries over a TCP connection, clients MUST NOT reuse the DNS Message ID of an in-flight query on that connection in order to avoid Message ID collisions
- In order to achieve performance on par with UDP, DNS clients SHOULD pipeline their queries
- When a DNS client sends multiple queries to a server, it SHOULD NOT wait for an outstanding reply before sending the next query
- Clients SHOULD treat TCP and UDP equivalently when considering the time at which to send a particular query
- DNS servers (especially recursive) MUST expect to receive pipelined queries
- The server SHOULD process TCP queries concurrently, just as it would for UDP
- The server SHOULD answer all pipelined queries, even if they are received in quick succession
- To mitigate the risk of unintentional server overload, DNS clients MUST take care to minimize the number of concurrent TCP connections made to any individual server
- It is RECOMMENDED that for any given client/server interaction there SHOULD be no more than one connection for regular queries, one for zone transfers, and one for each protocol that is being used on top of TCP (for example, if the resolver was using TLS)
- Similarly, servers MAY impose limits on the number of concurrent TCP connections being handled for any particular client IP address or subnet
- These limits SHOULD be much looser than the client guidelines above, because the server does not know, for example, if a client IP address belongs to a single client, is multiple resolvers on a single machine, or is multiple clients behind a device performing Network Address Translation (NAT)
- To mitigate the risk of unintentional server overload, DNS clients MUST take care to minimise the idle time of established DNS-over-TCP sessions made to any individual server
- DNS clients SHOULD close the TCP connection of an idle session, unless an idle timeout has been established using some other signalling mechanism, for example, [edns-tcp-keepalive]
- To mitigate the risk of unintentional server overload, it is RECOMMENDED that the default server application-level idle period be on the order of seconds, but no particular value is specified
- In practice, the idle period can vary dynamically, and servers MAY allow idle connections to remain open for longer periods as resources permit
- Servers MAY use zero timeouts when they are experiencing heavy load or are under attack
- For this reason, servers SHOULD reset the idle timeout on the receipt of a full DNS message, rather than on receipt of any part of a DNS message
- DNS clients SHOULD retry unanswered queries if the connection closes before receiving all outstanding responses
- If a DNS server finds that a DNS client has closed a TCP session (or if the session has been otherwise interrupted) before all pending responses have been sent, then the server MUST NOT attempt to send those responses
- Of course, the DNS server MAY cache those responses
- Authoritative servers and recursive resolvers are RECOMMENDED to support the preparing of responses in parallel and sending them out of order, regardless of the transport protocol in use
- Stub and recursive resolvers MUST be able to process responses that arrive in a different order than that in which the requests were sent, regardless of the transport protocol in use
- In order to achieve performance on par with UDP, recursive resolvers SHOULD process TCP queries in parallel and return individual responses as soon as they are available, possibly out of order
- Since pipelined responses can arrive out of order, clients MUST match responses to outstanding queries on the same TCP connection using the Message ID
- If the response contains a question section, the client MUST match the QNAME, QCLASS, and QTYPE fields
- DNS clients and servers SHOULD pass the two-octet length field, and the message described by that length field, to the TCP layer at the same time (e.g., in a single "write" system call) to make it more likely that all the data will be transmitted in a single TCP segment
- To clarify, DNS servers MUST NOT close a connection simply because the first "read" from the TCP layer does not contain the entire DNS message, and servers SHOULD apply the connection timeouts as specified in Section 6.2.3
- TCP MAY be used before sending any UDP queries
- Section 6.2.1 adds a new recommendation that TCP connection reuse SHOULD be supported
- Section 6.2.1.1 adds a new recommendation that DNS clients SHOULD pipeline their queries and DNS servers SHOULD process pipelined queries concurrently
- Section 6.2.3 adds a new recommendation that DNS clients SHOULD close idle sessions unless using a signalling mechanism
- Section 7 clarifies that servers are RECOMMENDED to prepare TCP responses in parallel and send answers out of order
rfc7828
- DNS clients MUST NOT include the edns-tcp-keepalive option in queries sent using UDP transport
- DNS clients MAY include the edns-tcp-keepalive option in the first query sent to a server using TCP transport to signal their desire to keep the connection open when idle
- DNS clients MAY include the edns-tcp-keepalive option in subsequent queries sent to a server using TCP transport to signal their continued desire to keep the connection open when idle
- Clients MUST specify an OPTION-LENGTH of 0 and omit the TIMEOUT value
- A DNS client that receives a response using UDP transport that includes the edns-tcp-keepalive option MUST ignore the option
- A DNS client that receives a response using TCP transport that includes the edns-tcp-keepalive option MAY keep the existing TCP session open when it is idle
- It SHOULD honour the timeout received in that response (overriding any previous timeout) and initiate close of the connection before the timeout expires
- A DNS client that receives a response that includes the edns-tcp- keepalive option with a TIMEOUT value of 0 SHOULD send no more queries on that connection and initiate closing the connection as soon as it has received all outstanding responses
- A DNS client that sent a query containing the edns-keepalive-option but receives a response that does not contain the edns-keepalive- option SHOULD assume the server does not support keepalive and behave following the guidance in [RFC7766]
- A DNS server that receives a query using UDP transport that includes the edns-tcp-keepalive option MUST ignore the option
- A DNS server that receives a query using TCP transport that includes the edns-tcp-keepalive option MAY modify the local idle timeout associated with that TCP session if resources permit
- A DNS server that receives a query sent using TCP transport that includes an OPT RR (with or without the edns-tcp-keepalive option) MAY include the edns-tcp-keepalive option in the response to signal the expected idle timeout on a connection
- Servers MUST specify the TIMEOUT value that is currently associated with the TCP session
- The DNS server SHOULD send an edns-tcp-keepalive option with a timeout of 0 if it deems its local resources are too low to service more TCP keepalive sessions or if it wants clients to close currently open connections
- Lack of presence of an OPT record in a request MUST be taken as an indication that the requestor does not implement any part of this specification and that the responder MUST NOT include an OPT record in its response
- If a client includes the edns-tcp-keepalive option in the first query, it SHOULD include an EDNS0 OPT RR periodically in any further messages it sends during the TCP session
- DNS clients and servers MAY close a TCP session at any time in order to manage local resource constraints
- A fallback strategy similar to that described in [RFC6891], Section 6.2.2 SHOULD be employed to avoid persistent interference due to non-clean paths
- It is RECOMMENDED that DNS intermediaries that terminate TCP connections implement edns-tcp-keepalive
- When a DNS server detects abusive behaviour, it SHOULD immediately close the TCP connection and free the resources used
rfc7830
- The "Padding" option MUST occur at most, once per OPT meta-RR (and hence, at most once per message)
- The PADDING octets SHOULD be set to 0x00
- Other values MAY be used, for example, in cases where there is a concern that the padded message could be subject to compression before encryption
- PADDING octets of any value MUST be accepted in the messages received
- However, padded DNS messages MUST NOT exceed the number of octets specified in the Requestor's Payload Size field encoded in the RR Class Field (see Sections 6.2.3 and 6.2.4 of [RFC6891])
- Responders MUST pad DNS responses when the respective DNS query included the "Padding" option, unless doing so would violate the maximum UDP payload size
- Responders MAY pad DNS responses when the respective DNS query indicated EDNS(0) support of the Requestor and the "Padding" option was not included
- Responders MUST NOT pad DNS responses when the respective DNS query did not indicate EDNS(0) support
- Therefore, implementations MUST NOT use this option if the DNS transport is not encrypted
- Therefore (as described in Section 3.3 of [RFC7525]), implementations and deployments SHOULD disable compression at the Transport Layer Security (TLS) level
rfc7858
- By default, a DNS server that supports DNS over TLS MUST listen for and accept TCP connections on port 853, unless it has mutual agreement with its clients to use a port other than 853 for DNS over TLS
- By default, a DNS client desiring privacy from DNS over TLS from a particular server MUST establish a TCP connection to port 853 on the server, unless it has mutual agreement with its server to use a port other than port 853 for DNS over TLS
- Such another port MUST NOT be port 53 but MAY be from the "first-come, first-served" port range
- The first data exchange on this TCP connection MUST be the client and server initiating a TLS handshake using the procedure described in [RFC5246]
- DNS clients and servers MUST NOT use port 853 to transport cleartext DNS messages
- DNS clients MUST NOT send and DNS servers MUST NOT respond to cleartext DNS messages on any port used for DNS over TLS (including, for example, after a failed TLS handshake)
- DNS clients SHOULD remember server IP addresses that don't support DNS over TLS, including timeouts, connection refusals, and TLS handshake failures, and not request DNS over TLS from them for a reasonable period (such as one hour per server)
- DNS clients following an out-of-band key-pinned privacy profile (Section 4.2) MAY be more aggressive about retrying DNS-over-TLS connection failures
- All messages (requests and responses) in the established TLS session MUST use the two-octet length field described in Section 4.2.2 of [RFC1035]
- For reasons of efficiency, DNS clients and servers SHOULD pass the two-octet length field, and the message described by that length field, to the TCP layer at the same time (e.g., in a single "write" system call) to make it more likely that all the data will be transmitted in a single TCP segment ([RFC7766], Section 8)
- In order to minimize latency, clients SHOULD pipeline multiple queries over a TLS session
- Since pipelined responses can arrive out of order, clients MUST match responses to outstanding queries on the same TLS connection using the Message ID
- If the response contains a Question Section, the client MUST match the QNAME, QCLASS, and QTYPE fields
- To avoid excess TCP connections, each with a single query, clients SHOULD reuse a single TCP connection to the recursive resolver
- In order to amortize TCP and TLS connection setup costs, clients and servers SHOULD NOT immediately close a connection after each response
- Instead, clients and servers SHOULD reuse existing connections for subsequent queries as long as they have sufficient resources
- An implementor of DNS over TLS SHOULD follow best practices for DNS over TCP, as described in [RFC7766]
- Clients and servers that keep idle connections open MUST be robust to termination of idle connection by either party
- As with current DNS over TCP, DNS servers MAY close the connection at any time (perhaps due to resource constraints)
- As with current DNS over TCP, clients MUST handle abrupt closes and be prepared to reestablish connections and/or retry queries
- Underlining the requirement for sending only encrypted DNS data on a DNS-over-TLS port (Section 3.2), when using TCP Fast Open, the client and server MUST immediately initiate or resume a TLS handshake (cleartext DNS MUST NOT be exchanged)
- DNS servers SHOULD enable fast TLS session resumption [RFC5077], and this SHOULD be used when reestablishing connections
- When closing a connection, DNS servers SHOULD use the TLS close- notify request to shift TCP TIME-WAIT state to the clients
- With this out-of-band key-pinned privacy profile, client administrators SHOULD deploy a backup pin along with the primary pin, for the reasons explained in [RFC7469]
- After a change of keys on the server, an updated pin set SHOULD be distributed to all clients in some secure way in preparation for future key rollover
- Techniques such as those used by DNSSEC-trigger [DNSSEC-TRIGGER] MAY be used during network configuration, with the intent to transition to the designated DNS provider after authentication
- The user MUST be alerted whenever possible that the DNS is not private during such bootstrap
- Otherwise, the client MUST treat the SPKI validation failure as a non-recoverable error
- Implementations of this privacy profile MUST support the calculation of a fingerprint as the SHA-256 [RFC6234] hash of the DER-encoded ASN.1 representation of the SPKI of an X.509 certificate
- Implementations MUST support the representation of a SHA-256 fingerprint as a base64-encoded character string [RFC4648]
- Additional fingerprint types MAY also be supported
- Number of connections: To minimize state on DNS servers and connection startup time, clients SHOULD minimize the creation of new TCP connections
- Clients and servers MUST adhere to the TLS implementation recommendations and security considerations of [BCP195]
- For this reason, clients MAY
rfc7873
- The Client Cookie SHOULD be a pseudorandom function of the Client IP Address, the Server IP Address, and a secret quantity known only to the client
- This Client Secret SHOULD have at least 64 bits of entropy [RFC4086] and be changed periodically (see Section 7.1)
- In order to provide minimal authentication, a client MUST send Client Cookies that will usually be different for any two servers at different IP addresses
- The Server Cookie SHOULD consist of or include a 64-bit or larger pseudorandom function of the request source (client) IP address, a secret quantity known only to the server, and the request Client Cookie
- (See Section 6 for a discussion of why the Client Cookie is used as input to the Server Cookie but the Server Cookie is not used as an input to the Client Cookie.) This Server Secret SHOULD have at least 64 bits of entropy [RFC4086] and be changed periodically (see Section 7.1)
- In order to provide minimal authentication, a server MUST send Server Cookies that will usually be different for clients at any two different IP addresses or with different Client Cookies
- DNS clients and servers SHOULD implement DNS Cookies to decrease their vulnerability to the threats discussed in Section 2
- If the server responds choosing (2) or (3) above, it SHALL generate its own COOKIE option containing both the Client Cookie copied from the request and a Server Cookie it has generated, and it will add this COOKIE option to the response's OPT record
- Servers MUST, at least occasionally, respond to such requests to inform the client of the correct Server Cookie
- If the request was received over TCP, the server SHOULD take the authentication provided by the use of TCP into account and SHOULD choose (3)
- The server SHALL process the request as if the invalid Server Cookie was not present, as described in Section 5.2.3
- The server SHALL process the request and include a COOKIE option in the response by (a) copying the complete COOKIE option from the request or (b) generating a new COOKIE option containing both the Client Cookie copied from the request and a valid Server Cookie it has generated
- A DNS client where DNS Cookies are implemented and enabled examines the response for DNS Cookies and MUST discard the response if it contains an illegal COOKIE option length or an incorrect Client Cookie value
- If the client is expecting the response to contain a COOKIE option and it is missing, the response MUST be discarded
- The client SHOULD retry the request using the new Server Cookie from the response
- If the reply to a retried request with a fresh Server Cookie is BADCOOKIE, the client SHOULD retry using TCP as the transport, since the server will likely process the request normally based on the security provided by TCP (see Section 5.2.3)
- If such a query provided just a Client Cookie and no Server Cookie, the response SHALL have the RCODE NOERROR
- In this case, the response SHALL have the RCODE BADCOOKIE if the Server Cookie sent with the query was invalid and the RCODE NOERROR if it was valid
- For simplicity, it is RECOMMENDED that the same Server Secret be used by each DNS server in a set of anycast servers
- To be precise and to make it practical to stay within limits despite long holiday weekends, daylight saving time shifts, and the like, clients and servers MUST NOT continue to use the same secret in new requests and responses for more than 36 days and SHOULD NOT continue to do so for more than 26 hours
- To avoid rollover synchronization and predictability, it is RECOMMENDED that pseudorandom jitter in the range of plus zero to minus at least 40% be applied to the time until a scheduled rollover of a COOKIE secret
- It is RECOMMENDED that a client keep the Client Cookie it is expecting in a reply until there is no longer an outstanding request associated with that Client Cookie that the client is tracking
- It is RECOMMENDED that a server retain its previous secret after a rollover to a new secret for a configurable period of time not less than 1 second or more than 300 seconds, with a default configuration of 150 seconds
- When a server responds to a request containing an old Server Cookie that the server is treating as correct, the server MUST include a new Server Cookie in its response
- It is RECOMMENDED that implementations include counters of the occurrences of the various types of requests and responses described in Section 5
- The cookie computation algorithm for use in DNS Cookies SHOULD be based on a pseudorandom function at least as strong as 64-bit FNV (Fowler/Noll/Vo [FNV]), because an excessively weak or trivial algorithm could enable adversaries to guess cookies
- (If the order of the items concatenated above is changed to put the Server IP Address last, it might be possible to further reduce the computational effort by pre-computing FNV64 through the bytes of both the Client IP Address and the Client Secret, but this would reduce the strength of the Client Cookie and is NOT RECOMMENDED.)
- (If the order of the items concatenated was changed, it might be possible to reduce the computational effort by pre-computing FNV64 through the bytes of the Server Secret and Client Cookie, but this would reduce the strength of the Server Cookie and is NOT RECOMMENDED.)
rfc8005
- If the query for the HIP type was responded to with a DNS answer with RCODE=3 (Name Error), then the Responder's information is not present in the DNS, and further queries for the same owner name SHOULD NOT be made
- Upon return of a HIP RR, a host MUST always calculate the HI-derivative HIT to be used in the HIP exchange, as specified in Section 3 of the HIP specification [RFC7401], while the HIT included in the HIP RR SHOULD only be used as an optimization (e.g., table lookup)
- The Rendezvous Server field of the HIP RR stored at a given owner name MAY include the owner name itself
- On a HIP node, a HIP exchange SHOULD be initiated whenever a ULP attempts to communicate with an entity, and the DNS lookup returns HIP RRs
- When the number of seconds that passed since the record was retrieved exceeds the record's TTL, the record MUST be considered no longer valid and deleted by the entity that retrieved it
- If access to the record is necessary to initiate communication with the entity to which the record corresponds, a new query MUST be made to retrieve a fresh copy of the record
- information may be copied and aligned across multiple RRs, or may be different for each one; a host MUST check that the RVS used is associated with the HI being used, when multiple choices are present
- The HIT length, PK algorithm, PK length, HIT, and Public Key fields are REQUIRED
- The Rendezvous Server field is OPTIONAL
- The domain names MUST NOT be compressed
- When multiple HIP RRs are present at the same owner name, this implicit order of RVSs within an RR MUST NOT be used to infer a preference order between RVSs stored in different RRs
- The encoding MUST NOT contain whitespaces to distinguish it from the Public Key field
- The encoding MUST NOT contain whitespace(s) to distinguish it from the Rendezvous Server field
- A HIP node SHOULD obtain HIP RRs from a trusted party through a secure channel ensuring data integrity and authenticity of the RRs
- Therefore, the RRSIG of the HIP RRSet MUST NOT be misinterpreted as a certificate binding the HI and/or the HIT to the owner name
- HIP end-node implementation SHOULD NOT authenticate its HIP peers based solely on a HIT retrieved from the DNS, but rather SHOULD use HI-based authentication
rfc8028
- (A) A host MUST silently discard an incoming datagram whose destination address does not correspond to the physical interface through which it is received
- (B) A host MUST restrict itself to sending (non-source-routed) IP datagrams only through the physical interface that corresponds to the IP source address of the datagrams
- Since the host derives fundamental default routing information from the Router Advertisement, this implies that, in any network with hosts using multiple prefixes, each prefix SHOULD be advertised via a Prefix Information Option (PIO) [RFC4861] by one of the attached routers, even if addresses are being assigned using DHCPv6
- If SLAAC is not wanted (A=0) and there is no reason to announce an on-link prefix (L=0), a PIO SHOULD be sent to inform hosts that they should use the router in question as the first hop for packets with source addresses in the PIO prefix
- o A host SHOULD NOT ignore a PIO simply because both L and A flags are cleared (extending Section 6.3.4 of [RFC4861])
- o A router SHOULD be able to send such a PIO (extending Section 6.2.3 of [RFC4861])
- In a multi-prefix network with multiple exits, the host's characterization of each default router SHOULD include the prefixes it has announced (extending Section 6.3.4 of [RFC4861])
- If Bob-B has advertised an RIO for Alice's prefix and Bob-A has not, Bob MAY take that fact into account in address selection -- choosing an address that would allow him to make use of the RIO
- Default Router Selection (Section 6.3.6 of [RFC4861]) is extended as follows: A host SHOULD select default routers for each prefix it is assigned an address in
- Routers that have advertised the prefix in their Router Advertisement message SHOULD be preferred over routers that do not advertise the prefix, regardless of Default Router Preference
- As a result of this, when a host sends a packet using a source address in one of those prefixes and has no history directing it otherwise, it SHOULD send it to the indicated default router
- Therefore, this selection rule SHOULD be implemented in a host following the recommendation in the previous section
- Hosts SHOULD apply off-link redirects only for the specific pair of source and destination addresses concerned, so the host's Destination Cache
- When such a host makes a successful exchange with a remote destination using a particular address pair, and the host has previously received a PIO that matches the source address, then the host SHOULD include the prefix in such history, whatever the setting of the L and A flags in the PIO
- On subsequent attempts to communicate with that destination, if it has an address in that prefix at that time, a host MAY use an address in the remembered prefix for the session
rfc8078
- Parents SHOULD NOT refuse CDS/ CDNSKEY updates that do not (yet) have a matching DNSKEY in the child zone
- The contents of the CDS or CDNSKEY RRset MUST contain one RR and only contain the exact fields as shown below
- Once the parent has verified the CDS/CDNSKEY RRset and it has passed other acceptance tests, the parent MUST remove the DS RRset
- A parent SHOULD ensure that when it is allowing a child to become securely delegated, it has a reasonable assurance that the CDS/ CDNSKEY RRset used to bootstrap the security is visible from a geographically and topologically diverse view
- It SHOULD also ensure that the zone validates correctly if the parent publishes the DS record
rfc8080
- A private key used for a DNSSEC zone MUST NOT be used for any other purpose than for that zone
rfc8106
- Hosts conforming to this specification MUST extract DNS information from RA messages, unless static DNS configuration has been specified by the user
- If there is DNS information available from multiple RAs and/or from DHCP, the host MUST maintain an ordered list of this information as specified in Section 5.3.1
- The maximum time in seconds (relative to the time the packet is received) over which these RDNSS addresses MAY be used for name resolution
- The value of Lifetime SHOULD by default be at least 3 * MaxRtrAdvInterval, where MaxRtrAdvInterval is the maximum RA interval as defined in [RFC4861]
- A value of zero means that the RDNSS addresses MUST no longer be used
- Note: The addresses for RDNSSes in the RDNSS option MAY be link-local addresses
- Such link-local addresses SHOULD be registered in the Resolver Repository along with the corresponding link zone indices of the links that receive the RDNSS option(s) for them
- The link-local addresses MAY be represented in the Resolver Repository with their link zone indices in the textual format for scoped addresses as described in [RFC4007]
- When a resolver sends a DNS query message to an RDNSS identified by a link-local address, it MUST use the corresponding link
- The maximum time in seconds (relative to the time the packet is received) over which these DNSSL domain names MAY be used for name resolution
- That is, Lifetime SHOULD by default be at least 3 * MaxRtrAdvInterval
- A value of zero means that the DNSSL domain names MUST no longer be used
- Domain Names of DNS Search List One or more domain names of the DNSSL that MUST be encoded as described in Section 3.1 of [RFC1035]
- Note that for the simple decoding, the domain names MUST NOT be encoded in the compressed form described in Section 4.1.4 of [RFC1035]
- Because the size of this field MUST be a multiple of 8 octets, for the minimum multiple including the domain name representations, the remaining octets other than the encoding parts of the domain name representations MUST be padded with zeros
- o If the DNS options are valid, the host SHOULD copy the values of the options into the DNS Repository and the Resolver Repository in order
- Otherwise, the host MUST discard the options
- In the case where the DNS information of RDNSS and DNSSL can be obtained from multiple sources, such as RAs and DHCP, the IPv6 host SHOULD keep some DNS options from all sources
- However, in the case of multiple sources, the ability to store a total of at least three RDNSS addresses (or DNSSL domain names) from the multiple sources is RECOMMENDED
- The DNS options from RAs and DHCP SHOULD be stored in the DNS Repository and Resolver Repository so that information from DHCP appears there first and therefore takes precedence
- On the other hand, for DNS options announced by RAs, if some RAs use the Secure Neighbor Discovery (SEND) protocol [RFC3971] for RA security, they MUST be preferred over those that do not use SEND
- Also, DNS options announced by RAs via SEND MUST be preferred over those announced by unauthenticated DHCP [RFC3118]
- For DNS repository management, the following two data structures SHOULD be synchronized with the Resolver Repository: (i) the DNS Server List, which keeps the list of RDNSS addresses and (ii) the DNSSL, which keeps the list of DNS search domain names
- The corresponding technique for network devices is RECOMMENDED to block rogue RA messages that include the RDNSS and DNSSL options from unauthorized nodes [RFC6104] [RFC6105]
- o The key words "SHOULD" and "RECOMMENDED" (RFC 2119) are removed in the recommendation of using SEND as a security mechanism for ND
rfc8145
- Each of these new signaling mechanisms is OPTIONAL to implement and use
- The validating resolver SHOULD also set the DNSSEC OK bit (also known as the DO bit) [RFC4035] to indicate that it wishes to receive DNSSEC RRs in the response
- A DNS client MUST NOT include the edns-key-tag option for non-DNSKEY queries
- A DNS client SHOULD include the edns-key-tag option when issuing a DNSKEY query for a zone corresponding to a trust anchor
- A DNS client MAY include the edns-key-tag option when issuing a DNSKEY query for a non-trust anchor zone (i.e., Key Tags learned via DS records)
- A DNS client MUST NOT include Key Tag(s) for keys that are not learned via either a trust anchor or DS records
- Since the edns-key-tag option is only set in the query, if a client sees these options in the response, no action needs to be taken and the client MUST ignore the option values
- Such validating resolvers SHOULD include the edns-key-tag option in the OPT RR when sending a DNSKEY query
- The edns-key-tag option MUST NOT be included by non-validating stub resolvers
- Thus, a recursive resolver SHOULD include the edns-key-tag option in its DNSKEY queries as described above
- When a validating recursive resolver receives a query that includes the edns-key-tag option with a Key Tag list that differs from its own, it SHOULD forward both the client's Key Tag list and its own list
- When doing so, the recursive resolver SHOULD transmit the two Key Tag lists using separate instances of the edns-key-tag option code in the OPT RR
- A validating recursive resolver MAY combine stub/client Key Tag values from multiple incoming queries into a single outgoing query
- It is RECOMMENDED that implementations place reasonable limits on the number of Key Tags to include in the outgoing edns-key-tag option
- If the client included the DNSSEC OK and Checking Disabled (CD) bits but did not include the edns-key-tag option in the query, the validating recursive resolver MAY include the option with its own Key Tag values in full
- Validating recursive resolvers MUST NOT set the edns-key-tag option in the final response to the stub client
- Recursive resolvers that do not validate responses SHOULD copy the edns-key-tag option seen in received queries, as they represent the wishes of the validating downstream resolver that issued the original query
- An authoritative name server receiving queries with the edns-key-tag option MAY log or otherwise collect the Key Tag values to provide information to the zone operator
- A responder MUST NOT include the edns-key-tag option in any DNS response
- Hexadecimal values MUST be zero-padded to four hexadecimal digits
- When representing multiple Key Tag values, they MUST be sorted in order from smallest to largest
- A validating DNS resolver (stub or recursive) SHOULD originate a Key Tag query whenever it also originates a DNSKEY query for a trust anchor zone
- A validating DNS resolver SHOULD NOT originate Key Tag queries when also originating DNSKEY queries for non-trust anchor zones
- A non-validating DNS resolver MUST NOT originate Key Tag queries
- DNS resolvers with caches SHOULD cache and reuse the response to a Key Tag query just as it would any other response
- An authoritative name server receiving Key Tag queries MAY log or otherwise collect the Key Tag values to provide information to the zone operator
- An authoritative name server MUST generate an appropriate response to the Key Tag query
- Recall that when multiple Key Tags are present, the originating client MUST sort them from smallest to largest in the query name
- Zone operators relying on the edns-key-tag mechanism SHOULD take care to ensure that new keys have unique Key Tag values
- Due to privacy concerns, such a resolver MAY choose to transmit the Key Tags for a subset of queries (e.g., every 25th time) or by random chance with a certain probability (e.g., 5%)
- Implementations of this specification MAY be administratively configured to only transmit the Key Tags for certain zones
- Since the primary motivation for this specification is to provide operational measurement data for root zone key rollovers, it is RECOMMENDED that implementations at least include the edns-key-tag option for root zone DNSKEY queries
rfc8198
- If the negative cache of the validating resolver has sufficient information to validate the query, the resolver SHOULD use NSEC, NSEC3, and wildcard records to synthesize answers as described in this document
- Otherwise, it MUST fall back to send the query to the authoritative DNS servers
- As long as the validating resolver can determine that a name would not exist without the wildcard match, determined according to the rules set out in Section 5.3.4 of [RFC4035] (NSEC), or in Section 8.8 of [RFC5155], it SHOULD synthesize an answer (or NODATA response) for that name using the cache-deduced wildcard
- If the corresponding wildcard record is not in the cache, it MUST fall back to send the query to the authoritative DNS servers
- It is RECOMMENDED that validating resolvers limit the maximum effective TTL value of negative responses (NSEC/NSEC3 RRs) to this same value
- A resolver that supports aggressive use of NSEC and NSEC3 SHOULD reduce the TTL of NSEC and NSEC3 records to match the SOA.MINIMUM field in the authority section of a negative response, if SOA.MINIMUM is smaller
- +-----------------------------------------------------------------+ | Once the records are validated, DNSSEC-enabled validating | | resolvers SHOULD use wildcards and NSEC/NSEC3 resource records | | to generate positive and negative responses until the | | effective TTLs or signatures for those records expire
- o If errors happen in an aggressive negative caching algorithm, resolvers MUST fall back to resolve the query as usual
rfc8301
- Due to the recognized weakness of the SHA-1 hash algorithm (see [RFC6194]) and the wide availability of the SHA-256 hash algorithm (it has been a required part of DKIM [RFC6376] since it was originally standardized in 2007), the SHA-1 hash algorithm MUST NOT be used
- Signers MUST sign using rsa-sha256
- Verifiers MUST be able to verify using rsa-sha256
- rsa-sha1 MUST NOT be used for signing or verifying
- Since short RSA keys more easily succumb to off-line attacks, Signers MUST use RSA keys of at least 1024 bits for all keys
- Signers SHOULD use RSA keys of at least 2048 bits
- Verifiers MUST be able to validate signatures with keys ranging from 1024 bits to 4096 bits, and they MAY be able to validate signatures with larger keys
- Verifiers MUST NOT consider signatures using RSA keys of less than 1024 bits as valid signatures
rfc8310
- That is, the mechanism for SPKI pin sets as described in [RFC7858] MAY be used with DNS over (D)TLS
- o MUST implement DNS over TLS [RFC7858]
- o MAY implement DNS over DTLS [RFC8094]
- o SHOULD offer at least one of the credentials described in Section 8
- Clients using the Opportunistic Privacy profile SHOULD try for the best case but MAY fall back to the intermediate case and, eventually, the worst- case scenario, in order to obtain a response
- The Strict Privacy profile provides the best attack mitigation and therefore SHOULD always be implemented in DNS clients that implement the Opportunistic Privacy profile
- A DNS client that implements DNS over (D)TLS SHOULD NOT be configured by default to use only cleartext
- A DNS server that implements DNS over (D)TLS SHOULD provide at least one credential (Section 2) so that those DNS clients that wish to use the Strict Privacy profile are able to do so
- A DNS client SHOULD select a particular usage profile when resolving a query
- A DNS client MUST NOT fall back from Strict Privacy to Opportunistic Privacy during the resolution of a given query, as this could invalidate the protection offered against attackers
- A DNS client that is configured with both an authentication domain name and an SPKI pin set for a DNS server SHOULD match on both a valid credential for the authentication domain name and a valid SPKI pin set (if both are available) when connecting to that DNS server
- In this case, the client SHOULD treat individual SPKI pins as specified in Section 2.6 of [RFC7469] with regard to user-defined trust anchors
- The overall authentication result SHOULD only be considered successful if both authentication mechanisms are successful
- An Opportunistic Privacy Profile (based on Opportunistic Security [RFC7435]) that MAY be used for DNS over (D)TLS is described in [RFC7858] and is further specified in this document
- DNS clients that issue queries under an Opportunistic Privacy profile and that know authentication information for a given privacy-enabling DNS server SHOULD try to authenticate the server using the mechanisms described here
- A DNS client requiring Strict Privacy MUST use either (1) one of the sources listed in Section 7, to obtain an authentication domain name for the server it contacts or (2) an SPKI pin set as described in [RFC7858]
- A DNS client requiring Strict Privacy MUST only attempt to connect to DNS servers for which at least one piece of authentication information is known
- The client MUST use the available verification mechanisms described in Section 8 to authenticate the server and MUST abort connections to a server when no verification mechanism succeeds
- With Strict Privacy, the DNS client MUST NOT commence sending DNS queries until at least one of the privacy-enabling DNS servers becomes available
- Techniques such as those used by dnssec-trigger [dnssec-trigger] MAY be used during network configuration, with the intent to transition to the designated privacy-enabling DNS servers after captive-portal registration
- If using a Strict Privacy profile, the system MUST alert by some means that the DNS is not private during such a bootstrap operation
- A DNSSEC-validating client SHOULD apply the same validation policy to the A/AAAA meta-queries as it does to other queries
- A client that does not validate DNSSEC SHOULD apply the same policy (if any) to the A/AAAA meta-queries as it does to other queries
- A DNS client so configured that successfully connects to a privacy- enabling DNS server MAY choose to locally cache the server host IP addresses in order to not have to repeat the meta-query
- When using a Strict Privacy profile, the dynamic discovery technique used as a source of authentication domain names MUST be considered secure and trustworthy
- In order to ensure proper authentication, DNS clients MUST verify the entire certification path per [RFC5280]
- A compliant DNS client MUST only inspect the certificate's subjectAltName extension for the reference identifier
- In particular, it MUST NOT inspect the Subject field itself
- Clients that validate the DNSSEC signatures themselves MUST use standard DNSSEC validation procedures
- Clients that rely on another entity to perform the DNSSEC signature validation MUST use a secure mechanism between themselves and the validator
- The DNS client MAY choose to perform the DNS meta-queries to retrieve the required DANE records itself
- The DNS meta-queries for such DANE records MAY use the Opportunistic Privacy profile or be in the clear to avoid trust recursion
- The records MUST be validated using DNSSEC as described in [RFC6698]
- The DNS client MAY offer the TLS extension described in [TLS-DNSSEC-Chain-Ext]
- If the DNS client offers the TLS DNSSEC chain extension, it MUST be capable of validating the full DNSSEC authentication chain down to the leaf
- If the supplied DNSSEC chain does not validate, the client MUST ignore the DNSSEC chain and validate only via other supplied credentials
- Clients and servers MUST adhere to the (D)TLS implementation recommendations and security considerations of [RFC7525], except with respect to the (D)TLS version
- Since encryption of DNS using (D)TLS is a greenfield deployment, DNS clients and servers MUST implement only (D)TLS 1.2 or later
- Implementations MUST NOT offer or provide TLS compression, since compression can leak significant amounts of information, especially to a network observer capable of forcing the user to do an arbitrary DNS lookup in the style of the Compression Ratio Info-leak Made Easy (CRIME) attacks [CRIME]
- Implementations compliant with this profile MUST implement the following items:
- A client MUST only indicate support for raw public keys if it has an SPKI pin set pre-configured (for interoperability reasons)
- Implementations compliant with this profile SHOULD implement the following items:
- DNS clients SHOULD implement (1) support for the mechanisms described in Section 8.2 and (2) offering a configuration option that limits authentication to using only those mechanisms (i.e., with no fallback to pure PKIX-based authentication) such that authenticating solely via the PKIX infrastructure can be avoided
- DNS-over-(D)TLS clients and servers SHOULD implement the following relevant DNS extensions:
- DNS-over-(D)TLS clients SHOULD implement the following relevant DNS extensions:
rfc7385
rfc8463
- Signers SHOULD implement and verifiers MUST implement the Ed25519-SHA256 algorithm
rfc8484
- DoH servers MAY support more than one URI Template
- A DoH client MUST NOT use a different URI simply because it was discovered outside of the client's configuration (such as through HTTP/2 server push) or because a server offers an unsolicited response that appears to be a valid answer to a DNS query
- Future specifications for new media types for DoH MUST define the variables used for URI Template processing with this protocol
- DoH servers MUST implement both the POST and GET methods
- The DoH client SHOULD include an HTTP Accept request header field to indicate what type of content can be understood in response
- Irrespective of the value of the Accept request header field, the client MUST be prepared to process "application/dns-message" (as described in Section 6) responses but MAY also process other DNS- related media types it receives
- In order to maximize HTTP cache friendliness, DoH clients using media formats that include the ID field from the DNS message header, such as "application/dns-message", SHOULD use a DNS ID of 0 in every DNS request
- A DoH server MUST be able to process "application/dns-message" request messages
- This protocol MUST be used with the https URI scheme [RFC7230]
- In particular, DoH servers SHOULD assign an explicit HTTP freshness lifetime (see Section 4.2 of [RFC7234]) so that the DoH client is more likely to use fresh DNS data
- The assigned freshness lifetime of a DoH HTTP response MUST be less than or equal to the smallest TTL in the Answer section of the DNS response
- A freshness lifetime equal to the smallest TTL in the Answer section is RECOMMENDED
- If the DNS response has no records in the Answer section, and the DNS response has an SOA record in the Authority section, the response freshness lifetime MUST NOT be greater than the MINIMUM field from that SOA record (see [RFC2308])
- DoH clients MUST account for the Age response header field's value [RFC7234] when calculating the DNS TTL of a response
- HTTP/2 [RFC7540] is the minimum RECOMMENDED version of HTTP for use with DoH
- Before using DoH response data for DNS resolution, the client MUST establish that the HTTP request URI can be used for the DoH query
- In order to maximize interoperability, DoH clients and DoH servers MUST support the "application/dns-message" media type
- Other media types MAY be used as defined by HTTP Content Negotiation (see Section 3.4 of [RFC7231])
- Those media types MUST be flexible enough to express every DNS query that would normally be sent in DNS over UDP (including queries and responses that use DNS extensions, but not those that require multiple responses)
- DoH clients using this media type MAY have one or more Extension Mechanisms for DNS (EDNS) options [RFC6891] in the request
- DoH servers using this media type MUST ignore the value given for the EDNS UDP payload size in DNS requests
- When using the GET method, the data payload for this media type MUST be encoded with base64url [RFC4648] and then provided as a variable named "dns" to the URI Template expansion
- Padding characters for base64url MUST NOT be included
- When using the POST method, the data payload for this media type MUST NOT be encoded and is used directly as the HTTP message body
- HTTP cookies SHOULD NOT be accepted by DOH clients unless they are explicitly required by a use case
- To mitigate the possibility of deadlock, the authentication given DoH servers SHOULD NOT rely on DNS-based references to external resources in the TLS handshake
index