Skip to main content

DNS check

Zonemaster is a tool that validates the quality of DNS delegation.

Zonemaster sends multiple DNS queries to the name servers hosting the domain name being tested and also to the name servers hosting the parent zone of that domain name.

If you find ERROR or CRITICAL in your report, domain name will not be delegated to DNS.

Before delegating a domain name to the .si zone, nameservers must pass predelegation tests. You can test your domain name by entering its name (e.g. domain.si) and the IP address of the primary nameserver for the domain name in the fields below (if the primary nameserver is within a domain name that is already delegated, you can use the nameserver’s name instead of its IP address).

Verification regimes:

  1. the first 8 hours after the change of domain name servers every 10 minutes;
  2. 8-24 hours after the change every 1 hour;
  3. 24 hours after the change once a day.

Every update (adding or deleting a nameserver) will reset the regime, meaning a domain name will go through a predelegation test every 10 minutes.

Upon successful check of domain the technical contact gets a notice. They also receive a report in case of an error in the domain verification process. In the report there is also a number of unsuccessful check and the date and time of next scheduled check.

Basic technical requirements

Requirements for Name Servers

These tests are performed for the set of NS records and any associated IP addresses for those name servers. For each individual hostname, tests are performed against each IP address and protocol pair.

Minimum number of name servers

There must be at least two NS records listed in a delegation, it is not advised that hosts resolve to the same IP address.

Valid hostnames

The hostnames used for the name servers must comply with the requirements for valid hostnames described in RFC 1123, section 2.1.

Name server reachability

The name servers must answer DNS queries over both the UDP and TCP protocols on port 53.

Answer authoritatively

The name servers must answer authoritatively for the designated zone. Responses to queries to the name servers for the designated zone must have the “AA”-bit set.

This will be tested by querying for the SOA record of the designated zone with no “RD”-bit set.

Network diversity

It is advised that name servers be in at least two topologically separate networks.

Consistency between glue and authoritative data

For name servers that have IP addresses listed as glue, the IP addresses must match the authoritative A and AAAA records for that host.

Consistency between delegation and zone

The set of NS records served by the authoritative name servers must match those proposed for the delegation in the parent zone.

Consistency between authoritative name servers

The data served by the authoritative name servers for the designated zone must be consistent.

All authoritative name servers must serve the same NS record set for the designated domain.

All authoritative name servers must serve the same SOA record for the designated domain.

If for operational reasons the zone content fluctuates rapidly, the serial numbers need only be loosely coherent.

No truncation of referrals

Referrals from the parent zone’s name servers must fit into a non-EDNS0 UDP DNS packet. This means that the DNS response payload must not exceed 512 octets.

The required delegation information in the referral is a complete set of NS records and the minimal set of requisite glue records. The response size is assessed as a response to a query with a maximum-sized QNAME.

The minimal set of requisite glue records is considered to be:

  • One A record, if all authoritative name servers are in-bailiwick of the parent zone; and,
  • One AAAA record, if there are any IPv6-capable authoritative name servers and all IPv6- capable authoritative name servers are in-bailiwick of the parent zone.

No open recursive name service

The authoritative name servers must not provide recursive name service. This requirement is tested by sending a query outside the jurisdiction of the authority with the “RD”-bit set.

Same source address

Responses from the authoritative name servers must contain the same source IP address as the destination IP address of the initial query.

Requirements for Delegation Signer (DS) records

These requirements must be met for signed delegations, which is when one or more DS records are supplied. If no DS records are supplied, the delegation is unsigned and none of these tests are performed.

DS record format

Trust anchors must be provided as complete DS records. This means providing the key tag, the key algorithm, the digest hash type, and the digest hash, with legal values for each component.

Supported signing algorithm

  • DSA/SHA-1 (type 3)
  • RSA/SHA-1 (type 5)
  • DSA/SHA-1 z NSEC3 (type 6)
  • RSA/SHA-1 z NSEC3 (type 7)
  • RSA/SHA-256 (type 8)
  • RSA/SHA-512 (type 10)
  • GOST R 34.10-2001 (type 12)
  • ECDSA Curve P-256 with SHA-256 (type 13)
  • ECDSA Curve P-384 with SHA-384 (type 14)
  • Ed25519 (type 15)
  • Ed448 (type 16)

Supported digest type

Digest types 1-4 are allowed:

  • SHA-1
  • SHA-256
  • GOST R 34.11-94
  • SHA-384

Matching DNSKEY records

At the time of the listing request there must be a DNSKEY present in the child zone that matches each DS record.

While exceptions can be considered based on compelling operational circumstances to list DS records without a matching DNSKEY, it is strongly discouraged. Cross-validating all DS records is a safeguard to reduce a future risk of rolling the domain’s signatures to an invalid state.

Validation of RRSIG

Validation of the zone must be possible using the DS record set that has been provided for listing in the parent zone. We test this by querying the apex SOA record for the domain with the “DO”-bit set and ensuring its RRSIG records can be validated based on the proposed DS resource set.