1. Introduction
1.1. Background
This documentation specifies the requirements across DNS related nameservers and their managed zones. These requirements must be fulfilled in order to guarantee that an existing DENIC domain can be delegated properly. Therefore, the following sections describe nameserver policies as well as the corresponding predelegation check requirements.
1.2. Theories of Motivation
The Domain Name System (DNS) represents a hierarchical, distributed and highly available database used for any kind of IP address translations within IT networking and infrastructure sector. Therefore, DNS enforces high redundancy and fault resilience. However, due to faulty networking or human miss-configuration invalid domain resolving still might occur as described in RFC46971. In order to guarantee stable zone delegation on any level, TLD administration defines requirements and criteria that must or should be fulfilled within proper DNS operation. Based on that, this document describes a pre-staged procedure named as Predelegation Check which is used to validate the compliance in zone delegation of a corresponding user domain effectively and securely.
2. General Checks
2.1. Nameserver Policy
Different issue types (i.e. warning, error) are used to describe violations within check execution. Therefore each check requirement represents a criterion that MUST or SHOULD be fulfilled. According to this, the relation between check requirement and issues type is defined as follows:
WARNING: This issue covers the violation of a requirement that SHOULD be fulfilled. Any occurrence of this type is treated as a recommendation and non-critical. It will not affect the overall result of predelegation checks themselves.
ERROR: This issue covers the violation of a requirement that MUST be fulfilled. Hence, any occurrence of this type is treated as critical and results in failure of the overall predelegation check procedure.
2.1.1. Authoritative Nameservers Only
All corresponding nameservers of the requested domain MUST be addressable and configured in authoritative mode towards the domain’s final delegated zone. Any violation results in ERROR.
ERROR:
| Code | Message |
|---|---|
116 |
SOA record response must be authoritative |
133 |
Answer must be authoritative |
Further explanation: Requesting authoritative nameservers only ensures the agreement towards the final zone delegation of the requested domain. This is necessary because nameservers can be operated by any uncontracted third party (i.e. non-members) of DENIC eG- Additional notes can be found in RFC1034 and RFC1035.
2.1.2. Redundant Connectivity
At least two different nameservers MUST be addressable via IPv4 or IPv6 for the requested domain. Furthermore, at least one given nameserver MUST be addressable via IPv4. Any violation results in corresponding ERROR below.
ERROR:
| Code | Message |
|---|---|
107 |
Insufficient diversity of nameserver' s IP addresses |
125 |
Insufficient diversity of nameserver' s IPv4 addresses |
127 |
Insufficient number of nameservers reachable |
129 |
Invalid IPv4 or IPv6 address |
132 |
Could not resolve any IP address for this nameserver |
Further explanation: One nameserver differs completely from another by using different IPv4 and IPv6 addresses. Besides, all available IP addresses of every nameserver will be resolved and considered within predelegation check. According to RFC1035, each zone must be delegable by two-levelled redundancy setup by at least two different nameservers that can be addressed by distinguished IP addresses.
Example: Valid set of nameservers
| Nameservers | IP addresses |
|---|---|
ns1.nic.nast |
172.31.1.1', 'fd00:10:10::1:1 |
ns2.nic.nast |
'fd00:10:10::2:2 |
Example: Invalid set of nameservers
| Nameservers | IP addresses |
|---|---|
ns1.nic.nast |
172.31.1.1', 'fd00:10:10::1:1 |
ns2.nic.nast |
172.31.1.1', 'fd00:10:10::2:2 |
2.1.3. Glue Records
The predelegation check uses narrow glue policy. Hence, glue records need to be available in .de zone (i.e. 9.4.164.arpa) if the name of any corresponding nameserver is located within the delegated zone only.
Based on that the following requirements can be derived:
2.1.3.1. Nameserver in Zone
At least one IP address (i.e. IPv4 or IPv6) MUST be specified in the check request for any nameserver located within the delegated zone. Any violation results in corresponding ERROR below.
ERROR:
| Code | Message |
|---|---|
101 |
Missing glue record for the nameserver |
Further explanation: Considering both addressing cases IPv4 and IPv6 at least one glue record is required.
2.1.3.2. Nameserver NOT in Zone
No IP address (i.e. IPv4 or IPv6) SHOULD be specified in the check request for any nameserver NOT located within delegated zone. Otherwise WARNING.
WARNING:
| Code | Message |
|---|---|
102 |
Provided glue records not applicable |
Further explanation: The narrow glue policy is applied for .de as well as for 9.4.e164.arpa. Hence, glue records are only allowed for the limited case that the nameserver is located in the delegated zone. Any additionally provided IP addresses are dispensable. The warning shall point out possible input errors.
2.1.3.3. IP addresses and RRSet Consistency
For each specified IP address of any nameserver in the check request the corresponding A and AAAA RRSet MUST be retrievable in authoritative mode and match with the request’s specified IP addresses. Otherwise ERROR.
ERROR:
| Code | Message |
|---|---|
106 |
Inconsistent set of nameserver IP addresses |
Further explanation: Since glue records as well as authoritative data coexist in DNS both need to be accessible and consistent. Therefore, the retrieved IP addresses from DNS must match the request’s origin IP addresses. Besides, this requirement ensures equivalence between glue records and the A and AAAA RRSet related data (e.g. missing IP addresses in glue records).
2.1.4. SOA Zone Data
According to the SOA record data fields the following value-based requirements are specified:
2.1.4.1. Refresh
The value SHOULD be in range of [3600,86400] seconds. Otherwise WARNING.
WARNING:
| Code | Message |
|---|---|
108 |
Refresh value out of range |
Further explanation: This value specifies the refresh interval in data sync between master/slave nameservers. Lower rates will cause higher DNS traffic and load on corresponding systems. On the opposite, high rates will lead to more outdated data. Therefore, any violation results in warning because the setting is defined by the nameserver operators.
2.1.4.2. Retry
The value SHOULD be in range of [900,28800] seconds AND SHOULD be a fractional part between 1/8 and 1/3 of Refresh. Otherwise a corresponding WARNING will be issued.
WARNING:
| Code | Message |
|---|---|
109, 110 |
Retry value out of range |
Further explanation: This value overrules the refresh value if SOA sync between nameservers fails and will continue until sync is achieved or expiry threshold is reached. Hence, the value needs to be lower than Refresh. Keep in mind that smaller values will increase load. Besides, the requirement ensures balance between Refresh and Retry and guarantees advantage in switchover between those.
2.1.4.3. Expire
The value SHOULD be in range of [604800,3600000] seconds. Otherwise WARNING.
WARNING:
| Code | Message |
|---|---|
111 |
Expire value out of range |
Further explanation: This value defines the limit for failed syncs until a corresponding slave will stop delegation of the requested zone. Values less than one week lead to early loss of zone delegation and are marked as critical. Hence, a common value of 3600000 seconds (i.e. 1000 hours) seems to be good tradeoff between sync failure occurrence and trigger of further root cause investigation.
2.1.4.4. NegTTL
The value SHOULD be in range of [180,86400] seconds. Otherwise WARNING.
WARNING:
| Code | Message |
|---|---|
112 |
Minimum TTL out of range |
Further explanation: This values specifies the lifetime of any invalid SOA record response. It represents the counterpart of the usual TTL according to RFC2308. Higher values barely reduce DNS traffic because of DNS caches. Values beneath the lower boundary (i.e. 180 seconds) will disable the functionality of NegTTL completely.
2.1.5. Additional Zone Data
2.1.5.1. NS RRSet Consistency
The NS RRSet of the delegated zone MUST match the request’s nameserver list completely. Otherwise ERROR.
ERROR:
| Code | Message |
|---|---|
118 |
Inconsistent set of NS RRs |
Further explanation: RFC1034 specifies consistency between authoritative nameservers of the delegating and delegated zone.
2.1.5.2. No CNAME RR
The delegated zone MUST be free of any CNAME RR. Otherwise ERROR.
ERROR:
| Code | Message |
|---|---|
115 |
SOA record response must be direct |
Further explanation: CNAME RR must be unique on every node within the DNS tree. Hence, any further CNAME RR within the delegated zone violates this specification.
2.1.5.3. Referral Response Size
The referral response size MUST fit the max DNS UDP packet size of 512 Bytes (including large QNAMEs, all address entries and glue records). Otherwise ERROR.
ERROR:
| Code | Message |
|---|---|
104 |
Calculated referral response larger than allowed |
Further explanation: All DENIC nameserver query responses cover a referral (i.e. link) towards the corresponding, next-level nameserver in the zone delegation hierarchy. Hence, this requirement is used to avoid high loads of TCP based fallback retries due to truncation of former UDP requests.
2.1.5.4. Primary Nameserver Consistency
The primary nameserver (i.e. MNAME RR) of the delegated zone SHOULD be consistent in the SOA RR of any related nameserver. Otherwise WARNING.
WARNING:
| Code | Message |
|---|---|
113 |
Primary Master (MNAME) inconsistent across SOA records |
Further explanation: This requirement co-insures the consistency requirements of former section SOA Zone Data
2.1.6. Miscellaneous
Additional ungrouped requirements are summarized below:
2.1.6.1. IPv6
All IPv6 addresses of any nameserver MUST be located within the same global unicast address scope, allocated and routable. Any violation results in the corresponding ERROR below.
ERROR:
| Code | Message |
|---|---|
130 |
IPv6 address is not allocated |
131 |
IPv6 address is not routable |
Further explanation: IPv6 is restricted to different address scopes. In order to ensure common reachability of any nameserver via IPv6 just global scoped addresses are accepted.
2.1.6.2. Recursive Queries not Allowed
The execution of recursive DNS queries SHOULD not be allowed. Otherwise WARNING.
WARNING:
| Code | Message |
|---|---|
120 |
Recursive queries should not be allowed |
Further explanation: Separation of authoritative and recursive nameservers is necessary on namespace level and due to security reasons.
2.1.6.3. TCP Reachability
Any nameserver in check request SHOULD be reachable via TCP connection. Otherwise the corresponding WARNING will be issued.
WARNING:
| Code | Message |
|---|---|
902 |
Timeout |
908 |
Connection refused |
Further explanation: Within RFC1034 and RFC1035 TCP based DNS requests are supported too, but should be used as a fallback approach towards prior failed UDP requests only. Hence, if a UDP request fails on first level (e.g. due to truncation etc.) a switchover to TCP can be possible as mentioned in RFC123.
3. DNSSEC Checks
3.1. Fundamentals
In order to perform DNSSEC based validations in zone delegations, additional security data (i.e. keys) need to be provided within the corresponding zones.
Therefore, the Key Signing Key (KSK) of the delegated zone reflects the major Secure Entry Point (SEP). This key is placed within the DNSKEY RRSet of the delegated zone, which is signed by the key, too. Besides, the key’s fingerprint is placed as DS RR (Delegation Signer Resource Record) on higher delegation levels to avoid additional resource consumption.
All public-key-related data is provided as DNSKEY RR in wire-text format. The max number of possible keys in check requests is limited to 5. Within zone signing procedure all signatures and DS RRs are generated for each KSK automatically and are distributed with the delegated zone finally.
3.2. DNSKEY Resource Record
Each DNSKEY RR is provided in wire-text format as described in RFC4034 and shown below:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Protocol | Algorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / Public Key / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The "Flags" field covers the bits for DNSKEY related ZONE, REVOKE and SEP settings. The field "Algorithm" covers the keys cryptographic format. The "Public Key" part is kept as last field within RR.
3.3. DNSKEY Types & Signing
Introducing DS RR within RFC3658 recommends paired separation between the Zone Signing Key (ZSK) and the Key Signing Key (KSK). While a ZSK is used to sign any record data within zone (excluding DNSKEY RRSet), the KSK is used to authenticate ZSK by signing its corresponding DNSKEY RRSet. Hence, changing the ZSK implies less effort while changing the KSK leads to further changes on higher-level zones. Therefore, a KSK reflects larger keys than a ZSK to ensure longer periods of usage. This also means less consumption of zone data and finally smaller package sizes in DNS responses as explained in RFC4641. Hence, the separation of keys improves security, resource consumption as well as flexibility in key management but leads to a higher complexity in the DNS protocol, too. For that reason, key separation is not mandatory and usage of a single key instead of key pairs is possible in DNSSEC. Usually common use cases as ZSK+KSK and ZSK=KSK are feasible. Nevertheless, any key used for DNSSEC related zone signing must be covered within DNSKEY RRSet.
3.4. DNSKEY RR Visibility
The notion "visible DNSKEY RR" is defined as follows: A DNSKEY RR given in the check request is visible if it is included in the DNSKEY RRSet of the delegated zone.
3.5. Validation Concept
Within DNSSEC validation Proof of Possession and Chain of Trust must be satisfied and considered as follows.
Proof of Possession: The check request contains at least one public signing key (i.e. KSK) that validates the signature of the delegated zone’s DNSKEY RRSet. This ensures integrity and authenticity of the DNSKEY RRSet itself.
Chain of Trust: The check request or the DNSKEY RRSet contains at least one public signing key (i.e. ZSK) that validates the signature of the delegated zone’s SOA RR. Further trust verification on higher zone levels is not considered.
Based on this, corresponding criteria are defined in Requirements.
3.6. Requirements
As a first step in DNSSEC-related predelegation checks, the DNSKEY RRs of request are pre-checked according on the key format correctness (i.e. flags, algorithm, public key etc.). In the second step, further checks across zones and nameservers are carried out.
3.6.1. DNSKEY: Parameters
All DNSKEY RRs of the request MUST be distinct. Hence, the key’s field parameter MUST be unique among all other keys. Besides, a maximum of 5 DNSKEY RR can be handed over in a request. Otherwise a corresponding ERROR is issued.
ERROR:
| Code | Message |
|---|---|
208 |
Duplicate DNSKEY RR |
210 |
Max 5 DNSKEY RR allowed |
3.6.2. DNSKEY: Flags
The "Flags" field is specified as single numeric value in range of [0,65535] and shall match the following requirements.
3.6.2.1. ZONE Bit
Bit 7 (ZONE) MUST be SET. Otherwise ERROR.
ERROR:
| Code | Message |
|---|---|
200 |
DNSKEY RR ZONE flag (bit 7) must be set |
Further explanation: This requirement is specified in RFC4034.
3.6.2.2. REVOKE Bit
Bit 8 (REVOKE) MUST not be set. Otherwise ERROR.
ERROR:
| Code | Message |
|---|---|
201 |
DNSKEY RR REVOKE flag (bit 8) must not be set |
Further explanation: Revoked keys cannot be used as trust anchors as described in RFC5011.
3.6.2.3. SEP Bit
Bit 15 (SEP) SHOULD be set. Otherwise a WARNING is returned.
WARNING:
| Code | Message |
|---|---|
202 |
DNSKEY RR SEP flag (bit 15) should be set |
3.6.2.4. Final Values
According to the former requirements, a numeric value out of [256,257] MUST be chosen for ZONE Bit, REVOKE Bit and SEP Bit. All other values result in ERROR.
ERROR:
| Code | Message |
|---|---|
221 |
Unknown flags in DNSKEY RR are set |
3.6.3. DNSKEY: Protocol
The "Protocol" field is considered as an immutable value of 3 as specified in RFC4034. Otherwise an ERROR is returned.
ERROR:
| Code | Message |
|---|---|
209 |
DNSKEY RR has invalid protocol |
3.6.4. DNSKEY: Algorithm
The "Algorithm" field value MUST be chosen according to the following subset list of IANA Registry.
Supported algorithms: 3, 5, 6, 7, 8, 10, 12, 13 ,14
Any violation of this requirement results in ERROR.
ERROR:
| Code | Message |
|---|---|
220 |
DNSKEY RR has invalid algorithm |
REMARK: Algorithms 3, 5, 7 and 12 are deprecated and future support will end in upcoming releases.
3.6.5. DNSKEY: Public Key
The public key field MUST cover the base64 encoded key value. Otherwise ERROR.
ERROR:
| Code | Message |
|---|---|
207 |
DNSKEY RR public key must be base64 encoded |
Furthermore, the internal key format depends on the selected cryptographic algorithm and enforces specific requirements as shown below.
3.6.5.1. RSA
The RSA related algorithms 5,7,8 and 10 cover the requirements below.
3.6.5.1.1. Modulus
The modulu’s bit length MUST be in range of [512,4096]. Otherwise ERROR.
ERROR:
| Code | Message |
|---|---|
203 |
DNSKEY RR RSA key modulus length in bits out of range |
3.6.5.2. DSA
DSA based algorithms 3 and 6 consider the requirements below.
3.6.5.2.1. T Parameter
The T parameter MUST be in range of [0,8]. Otherwise ERROR.
ERROR:
| Code | Message |
|---|---|
205 |
DNSKEY RR DSA public key parameter T out of range |
3.6.5.2.2. Length
The byte length must be equal to (213+T*24). Otherwise ERROR.
ERROR:
| Code | Message |
|---|---|
206 |
DNSKEY RR DSA public key has invalid size |
3.6.5.3. ECDSA
The ECDSA algorithm 13 and 14 differ in key’s bit length:
-
In ECDSAP256SHA256 (13) the bit length MUST be 512. Otherwise ERROR.
-
In ECDSAP384SHA384 (14) the bit length MUST be 768. Otherwise ERROR.
ERROR:
| Code | Message |
|---|---|
226 |
DNSKEY RR ECDSA public key has invalid size |
Further explanation: All length parameter are specified in RFC6605.
3.6.5.4. GOST
The key bit length of algorithm 12 MUST be 512. Otherwise ERROR.
ERROR:
| Code | Message |
|---|---|
227 |
DNSKEY RR GOST public key has invalid size |
Further explanation: All length parameter are specified in RFC5933.
3.6.6. DNSKEY RRSet
3.6.6.1. Status
The DNSKEY RRSet of the delegated zone MUST be identical on all authoritative nameservers. Otherwise ERROR.
ERROR:
| Code | Message |
|---|---|
211 |
Inconsistent DNSKEY RR in nameserver response |
3.6.6.2. Visibility
At least one DNSKEY RR of request MUST be VISIBLE within the DNSKEY RRSet. Otherwise ERROR.
ERROR:
| Code | Message |
|---|---|
213 |
Did not find any DNSKEY RR from request in all nameserver responses |
Besides, for any invisible DNSKEY RR of request a WARNING is returned.
WARNING:
| Code | Message |
|---|---|
212 |
Did not find DNSKEY RR from request in all nameserver responses |
Further explanation: Additional DNSKEY RR in RRSet are neglected and accordance in DNSKEY RRSet signature is assumed but not tested explicitly. This allows online signing for DSA and ECDSA based algorithms.
3.6.7. Validation Proof of Possession
At least one visible DNSKEY RR of request MUST validate the signature of the DNSKEY RRSet. Otherwise ERROR.
ERROR:
| Code | Message |
|---|---|
216 |
No visible DNSKEY found signing the DNSKEY RR obtained in response |
Further explanation: This requirement enforces named proof of possession of section Validation Concept.
3.6.8. Validation Chain of Trust
For the SOA RR of the delegated zone a valid chain of trust MUST exist. This means at least one visible DNSKEY RR of request or within the DNSKEY RRSet must validate the signature of the SOA RR. Otherwise ERROR.
ERROR:
| Code | Message |
|---|---|
217 |
No visible DNSKEY found in signing directly or indirectly the SOA RR obtained in response |
Further explanation: This requirement enforces chain of trust towards the delegated zone and prevents security lameness. Trust validation is limited to delegated zone level to allow predelegation check for unregistered domains, too.
3.6.9. Cross Checks
According to the grouped DNSSEC requirements of the aforementioned sections further cross requirements can be derived.
3.6.9.1. EDNS0 Support
All authoritative nameservers MUST support the EDNS0 protocol. Hence, nameservers MUST respond with DNSSEC data (i.e. signatures) to DO-Bit signed queries. Otherwise ERROR.
ERROR:
| Code | Message |
|---|---|
218 |
Received invalid answer to a DO-Bit query |
3.6.9.2. UDP related EDNS0
All authoritative nameservers SHOULD support UDP sufficiently according to the EDNS0 extended package size and connectivity. Otherwise a corresponding WARNING is returned.
WARNING:
| Code | Message |
|---|---|
214 |
Querying some authoritative nameservers via EDNS0 UDP failed |
3.6.9.3. TCP connection reuse
All authoritative nameservers SHOULD support TCP connection reuse to lower connection setup costs according to RFC7766. Otherwise a corresponding WARNING is returned.
WARNING:
| Code | Message |
|---|---|
229 |
TCP connection reuse should be allowed |
3.6.9.4. Availability of DNSKEY RRSet
The DNSKEY RRSet MUST be retrievable from DNS via TCP or UDP with attached DNSSEC signature data (EDNS0). Otherwise ERROR.
ERROR:
| Code | Message |
|---|---|
219 |
Unable to retrieve DNSKEY RR with TCP or EDNS0 |
902 |
Timeout |
908 |
Connection refused |
4. Glossary
4.1. Issues
| Code | Severity | Message | Section ref. |
|---|---|---|---|
101 |
ERROR |
Missing glue record for the nameserver |
|
102 |
WARNING |
Provided glue records not applicable |
|
104 |
ERROR |
Calculated referral response larger than allowed |
|
106 |
ERROR |
Inconsistent set of nameserver IP addresses |
|
107 |
ERROR |
Insufficient diversity of nameserver’s IP addresses |
|
108 |
WARNING |
Refresh value out of range |
|
109 |
WARNING |
Retry value out of range |
|
110 |
WARNING |
Retry value out of range |
|
111 |
WARNING |
Expire value out of range |
|
112 |
WARNING |
Minimum TTL out of range |
|
113 |
WARNING |
Primary Master (MNAME) inconsistent across SOA records |
|
115 |
ERROR |
SOA record response must be direct |
|
116 |
ERROR |
SOA record response must be authoritative |
|
118 |
ERROR |
Inconsistent set of NS RRs |
|
120 |
WARNING |
Recursive queries should not be allowed |
|
ERROR |
Insufficient diversity of nameserver' s IPv4 addresses |
||
ERROR |
Insufficient number of nameservers reachable |
||
129 |
ERROR |
Invalid IPv4 or IPv6 address |
|
ERROR |
IPv6 address is not allocated |
||
ERROR |
IPv6 address is not routable |
||
132 |
ERROR |
Could not resolve any IP address for this nameserver |
|
133 |
ERROR |
Answer must be authoritative |
|
200 |
ERROR |
DNSKEY RR ZONE flag (bit 7) must be set |
|
201 |
ERROR |
DNSKEY RR REVOKE flag (bit 8) must not be set |
|
202 |
WARNING |
DNSKEY RR SEP flag (bit 15) should be set |
|
203 |
ERROR |
DNSKEY RR RSA key modulus length in bits out of range |
|
204 |
ERROR |
DNSKEY RR RSA public key exponent length in bits must not exceed 128 bits |
|
205 |
ERROR |
DNSKEY RR DSA public key parameter T out of range |
|
206 |
ERROR |
DNSKEY RR DSA public key has invalid size |
|
207 |
ERROR |
DNSKEY RR public key must be base64 encoded |
|
208 |
ERROR |
Duplicate DNSKEY RR |
|
209 |
ERROR |
DNSKEY RR has invalid protocol |
|
210 |
ERROR |
Max 5 DNSKEY RR allowed |
|
211 |
ERROR |
Inconsistent DNSKEY RR in nameserver response |
|
212 |
WARNING |
Did not find DNSKEY RR from request in all nameserver responses |
|
213 |
ERROR |
Did not find any DNSKEY RR from request in all nameserver responses |
|
WARNING |
Querying some authoritative nameservers via EDNS0 UDP failed |
||
216 |
ERROR |
No visible DNSKEY found signing the DNSKEY RR obtained in response |
|
217 |
ERROR |
No visible DNSKEY found in signing directly or indirectly the SOA RR obtained in response |
|
218 |
ERROR |
Received invalid answer to a DO-Bit query |
|
219 |
ERROR |
Unable to retrieve DNSKEY RR with TCP or EDNS0 |
|
220 |
ERROR |
DNSKEY RR has invalid algorithm |
|
221 |
ERROR |
Unknown flags in DNSKEY RR are set |
|
227 |
ERROR |
DNSKEY RR GOST public key has invalid size |
|
228 |
ERROR |
DNSKEY RR ED public key has invalid size |
|
229 |
WARNING |
TCP connection reuse should be allowed |
|
901 |
ERROR |
Unexpected RCODE |
|
ERROR |
Timeout |
||
903 |
ERROR |
Timeout with recursive resolver |
|
904 |
ERROR |
Port unreachable |
|
ERROR |
Connection refused |
||
909 |
ERROR |
Host unreachable |
|
910 |
ERROR |
Broken pipe |
|
911 |
ERROR |
Connection aborted |
|
999 |
WARNING |
Unexpected exception |
4.1.1. Issue Adaptions
4.1.1.1. Removed Issues
| Code | Severity | Message | Section ref. | Remarks |
|---|---|---|---|---|
103 |
WARNING |
Nameservers having IPv6 glue records should have IPv4 glue records too (NS, # of IPv4 glues, # of IPv6 glues)" RECURSION_AVAILABLE ⇒ "Recursive queries should not be allowed (resolver) |
Obsolete |
|
114 |
ERROR |
Inconsistent serial number across SOA records |
Obsolete |
|
118 |
ERROR |
NS query response is empty |
Obsolete |
|
215 |
ERROR |
Timeout after switching from UDP to TCP - switch to TCP due to truncation |
Obsolete |
|
222 |
WARNING |
Querying some authoritative nameservers via EDNS0 UDP causes timeout |
Obsolete |
|
223 |
ERROR |
Timeout after switching from UDP to TCP - switch to TCP due to timeout |
Obsolete |
|
224 |
WARNING |
Querying some authoritative nameservers via EDNS0 UDP causes unreachable |
Obsolete |
|
225 |
ERROR |
Timeout after switching from UDP to TCP |
Obsolete |
|
905 |
ERROR |
Invalid DNSKEY RR public key - conversion problem |
Obsolete |
|
906 |
ERROR |
Invalid DNSKEY RR DSA public key - conversion problem |
Obsolete |
|
907 |
ERROR |
DNSKEY RR from nameserver response cannot be compared with DNSKEY RR from request - conversion problem |
Obsolete |
4.1.1.2. Changed Issues
| Code | Severity | Message | Section ref. | Change |
|---|---|---|---|---|
105 |
ERROR |
All IPv6 Addresses must be Global Unicast dedicated, allocated and routable |
||
107 |
ERROR |
Insufficient diversity of nameserver' s IPv4 addresses |
Moved to new issue: 125 |
|
107 |
ERROR |
Insufficient number of nameservers reachable via IPv4 |
Moved to new issue: 127 |
|
107 |
ERROR |
Insufficient number of nameservers reachable |
Moved to new issue: 127 |
|
119 |
WARNING |
Some nameservers not reachable via TCP |
||
121 |
WARNING |
Received a truncated response |
Moved to new issue: 214 |
|
209 |
ERROR |
At least one DNSKEY RR must be specified in request |
Message: DNSKEY RR has invalid protocol |
|
212 |
WARNING |
Did not find DNSKEY RR from request in nameserver response |
Message: Did not find DNSKEY RR from request in all nameserver responses |
|
213 |
ERROR |
No DNSKEY RR from request found in nameserver response |
Message: Did not find any DNSKEY RR from request in all nameserver responses |
|
214 |
WARNING |
Some nameservers not reachable via EDNS0 with sufficient packet size |
Message: Querying some authoritative nameservers via EDNS0 UDP failed |
|
908 |
ERROR |
TCP Connection refused |
Message: Connection refused |
|
909 |
ERROR |
Socket error |
Message: Host unreachable |
4.1.1.3. New Issues
| Code | Severity | Message | Section ref. |
|---|---|---|---|
133 |
ERROR |
Answer must be authoritative |
|
228 |
ERROR |
DNSKEY RR ED public key has invalid size |
|
910 |
ERROR |
Broken pipe |
|
911 |
ERROR |
Connection aborted |