Delegation Checker Error Codes

This problem can be caused by a programming error or by a server returning corrupt packets (e.g. with empty RDATA sections for A records).

Please notify inaddr _at_ ripe _dot_ net with details about the zone and server that caused this error to occur.

The delegation checker uses a number of nameserver names that it has obtained either from the users input (e.g. a Domain object) or from getting the delegation NS resource records from the parent domain.

This error indicates that an IP address could not be found for one of these nameservers.

The delegation checker uses a number of nameserver names that it has obtained either from the users input (e.g. a Domain object) or from getting the delegation NS resource records from the parent domain.

This error indicates that one or more of these nameservers are not present in the set of nameservers listed in the zone.

It almost certainly doesn't make sense for the expire value to be less than the refresh value. All secondary servers would expire the zone before they had a chance to refresh it.

The mname prameter is the first field in the SOA resource record data and indicates which server is the master server for the zone.

In order for secondary servers to fetch the zone this name should be resolvable.

A possible cause could be that the dot (.) on the end of the rname field has been forgotten and that the name completed with the origin. For example forgetting the dot in

      ;; BAD EXAMPLE AHEAD.
      $ORIGIN 4.0.192.in-addr.arpa.
	
      @  IN 3600 SOA  ns.example.com bert.example.com (
					2004010100 
					28800 
					14400 
					2592000 
					14400 )
    
    

This is an indication of a broken server implementation or a program error on our side.

You can test the server by performing a query and checking that only one SOA is returned using.
dig @<servername> <zonename> SOA

If the result of the query is only a single record than please contact inaddr _at_ ripe _dot_ net with details the name of the server and the zone you where testing.

If a nameserver thinks it is authoritative for a zone, it will set the AA flag in answers it gives involving data within the zone. If it doesn't then it's not setup correctly to serve the zone.

There are two likely explanations for a delegated nameserver returning non-authoritative answers for a zone...

An authoritative nameserver for a zone must have an SOA record for that zone. If you're sure you've updated the nameserver configuration to include the zone, then perhaps...

• you forgot to reload the nameserver
• you just added the zone to the nameserver configuration very recently and it has not yet loaded the zone
• you have not setup your firewall correctly to allow DNS traffic
• The zone has expired. If this is the case it should be clear from the nameserver log

A name is not canonical if it defines an alias via a CNAME record in the DNS. Nameserver names should always be canonical. Please see RFC 1912, section 2.4 for more information on why this may cause problems.

For IPv4: If your zone is a /16 reverse zone you will need to set up ns.ripe.net as a secondary server.

For IPv6: If your zone is a /32 reverse zone you may use ns.ripe.net as a secondary.

The use of ns.ripe.net as a secondary is not allowed in other cases.

For IPv4: If your zone is a /16 reverse zone you will need to set up ns.ripe.net as a secondary server.

For IPv6: If your zone is a /32 reverse zone you may use ns.ripe.net as a secondary.

In both cases you have to allow AXFR queries from the RIPE NCC addresses (193.0.0/22 and 2001:610:240::/48) to the nameserver listed in the SOA resource record.

The rname parameter, the second parameter in the SOA resource record represents the e-mail address of the person responsible for maintaining the zone.

To convert an e-mail address to the required rname format you should do this:

1. replace any dot (.) characters in the local part of the email address (the part before the '@' sign) with a backslash then a dot (\.)
2. replace the '@' sign with a dot (.)

The e-mail address should be reachable.

Please see RFC 1912, section 2.2 for more information on the rname field.

The rname parameter, the second parameter in the SOA resource record represents the e-mail address of the person responsible for maintaining the zone.

To convert an e-mail address to the required rname format you should do this:

1. replace any dot (.) characters in the local part of the email address (the part before the '@' sign) with a backslash then a dot (\.)
2. replace the '@' sign with a dot (.)

The e-mail address should be reachable.

Please see RFC 1912, section 2.2 for more information on the rname field.

This error occurs when two parameters other than the serial numbers are different for the SOA fetched from two different nameservers.

The difference of serial numbers can be due to to high frequency dynamic update and coincidental timing of the test. As the other parameters in the SOA record do not tend to change often differences in those parameters is a very strong indication of outdated zones on one of the servers.

Some reasons for this error to occur are:

• the SOA record on the primary has been updated but the serial number was not incremented
• the SOA record on the secondary was updated manually by mistake. Only the data on the primary should be changed by hand
• something more serious, such as that a secondary nameserver is not updating properly from the primary

mname is the primary nameserver for the zone. rname is the contact address for the zone administrator.

Please see RFC 1912, section 2.2 for more information on SOA record fields. RFC 2181, section 7.3 has a useful clarification as regards the mname field.

At least 2 nameservers are required for each properly delegated zone, and at least three is recommended. Please see RFC 2182, section 5 for more information on this.

Glue record is used to keep the information about the IP address for the nameserver in the parent zone. For this at least one IPv4 or IPv6 address must be specified.

Glue record is used to keep the information about the IP address for the nameserver in the parent zone. Currently the only glue record accepted are the names of the servers inside the domain. For instance, if the delegation of the zone 1.127.in-addr.arpa is requested, the glue nameserver(s) must have names in the format ns1.1.127.in-addr.arpa, test.1.127.in-addr.arpa, etc.

Glue record is used to keep the information about the IP address for the nameserver in the parent zone. If the glue nameserver is being used, that nameserver must be authoritative for at least one of its own A/AAAA records. For instance, if glue nameserver ns1.1.168.in-addr.arpa with IP 168.192.0.1 is being used, the nameserver ns1.1.168.in-addr.arpa must return the A record for ns1.1.168.in-addr.arpa, that matches the supplied glue IP address (168.192.0.1).

We have queried for a SOA record. The query contained the flag that instructs the server to return DNSSEC data. Since this zone is supposed to be signed we expected RRSIGs in the answer.

The lack of RRSIGs can be explained by the fact that you simply did not sign your zone or because the above mentioned server is not configured to serve DNSSEC data.

N.B. In BIND DNSSEC needs to be enabled using the "dnssec-enable yes" directive.

Each authoritative server should have exactly the same DNSKEY RRset. Inconsistency between the DNSKEY RRset could happen if the authoritative servers have not yet synchronized their content. We advise you to try submitting your request again when the authoritative servers are in sync.

Note that we are not comparing the signatures over the DNSKEY RR set, only the content of the RR set.