Could not get an SOA record for the zone at a particular IP.

An authoritative nameserver for a zone must have an SOA record for that zone.

Could not look up an IP address for a nameserver found in the submitted domain object. The delegation checker uses nameservers 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 delegated nameserver provided is not listed for the zone by the nameserver. Each nameserver for the zone should list delegated nameservers.

The label in the domain name is too long. The maximum length is 63 octets as specified in RFC 2181, section 11.

The domain name you provided contains zero length labels. The minimum length of such a label is 1 octet, as specified in RFC 2181, section 11.

The domain name is too long. It's more than the maximum of 255 octets permitted by RFC 2181, section 11.

More than one nameserver name in the list of nameservers provided had the same IP address.

The nameserver name appears more than once in the list of delegated nameservers submitted.

The nameserver name appears more than once in the list of nameservers found in the zone.

The expire value in the SOA record returned by this nameserver is less than the refresh value in the same record.

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 label in the hostname contains illegal characters. A hostname label must consist of the characters A-Z, a-z, 0-9 or '-'. Please see RFC 1912, section 2.1, for more information on hostname restrictions.

The label in the hostname does not start and end with a letter or digit. Please see RFC 1912, section 2.1, for more information on hostname restrictions.

Servers return inconsistent nameserver lists. All nameservers should have a consistent set of nameservers listed for the zone.

The nameserver has an IPv6 address which is not a valid address type for a (public) nameserver.

A nameserver was found listed for the zone but was not one of the delegated nameservers provided. Only the delegated nameservers should be listed anywhere for the zone.

The delegated nameserver returned non-authoritative records for the zone.

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...

• It has not been set up to be a nameserver for the zone and is simply returning answers from it's cache
• There is a syntax error in the zone file for the zone at the nameserver. A quick check of the log file should establish whether this is the case

The delegated nameserver name is not canonical.

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.

The rname (email contact) field in the SOA record returned from this nameserver contains an '@' sign!

You should do this to convert an email address to the required rname format...

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 (.)

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

The rname (email contact) field in the SOA record returned by this server is syntactically bad.

The rname (email contact) field in the SOA record returned from this nameserver containsthe zone name twice. This probably results from a missing '.' on the end of the rname in the master zone file.

The serial number in the SOA record returned by this server is not all numeric digits (0-9).

Please see, for example, RFC 1912, section 2.2 for more information on serial number formats.

Found differing serial numbers in the SOA records returned for the zone

If two nameservers which are supposed to serve a zone do not return the same serial number for the zone, then they have different versions of the zone file. This is probably because either:

• one of the secondary servers has not yet updated from the master nameserver because the refresh time has not yet been reached. In this case, you should wait till all secondaries have the same serial number and try again
• the master nameserver is not returning authoritative answers for the zone. In this case, the secondary will not attempt to pick up a new copy of the zone and so it will keep an old serial number. This will be recorded in the nameserver log on the secondary
• the secondary could not pick up it's copy of the zone for some other reason e.g. network problems between master and secondary or access control lists at the master. Again, this should be visible in the nameserver logs on the secondary

The SOA record field returned by this nameserver was undefined or empty. This field should always have a value!

Found differing values in the SOA records returned for the zone.

This error only occurs when the serial numbers for the zone at two nameservers are the same, but other value(s) in the SOA record are different.

Since equal serial numbers should indicate equal zone data, there's a problem somewhere. The possibilities 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.

The expire value in the SOA record returned by this nameserver is less than the sum of the refresh and retry values in the same record.

If the expire value is less than the sum of the refresh and retry values, then the nameserver will expire the zone before it gets a chance to retry in the event of it failing after the refresh period.

The expire value in the SOA record returned by this nameserver is not within the suggested range. RFC 1912 suggests between 2 and 4 weeks for this value.

The previous version of this software used RFC 1537 to recommend values for the SOA record fields. In that document, the expire value was recommended at 604800 (1 week). However, RFC 1537 has been obsoleted by RFC 1912, which now recommends a much higher value for expire (between 2 and 4 weeks).

Could not find a PTR record mapping the IP of a nameserver to the host.

For every IP address there should be a matching PTR record registered (Please see:RFC 1912, section 2.1).

One of the hosts queried accepts bad UDP checksums.

Hosts should disregard received UDP packets with bad checksums without doing any further processing. The checker uses the program ckudpcksum to test whether all the delegated nameservers respond correctly in this respect, to ensure that they are not ignoring the checksums entrirely.

The retry value in the SOA record returned by this nameserver is not within the recommended range. RFC 1912 recommends a fraction of the refresh for this value.

The rname (email contact) field in the SOA record returned by this server is in a reverse domain (in-addr.arpa. or ip6.int) !

Although sometimes intentional, in most cases it's not and occurs due to a mistake when creating the SOA record on the primary nameserver for the zone.

The most likely explanation is that...

• it's a reverse zone and
• the dot (.) on the end of the rname field has been forgotten and
• only the local part of the zone administrators email address has been put in the rname field

None of the PTR records found for the nameserver IP mapped back to the host.

For every IP address there should be a matching PTR record registered (Please see RFC 1912, section 2.1).

Missed out several tests at this nameserver because it had serial number for the zone, which has already been checked previously. Please refer to the report for that nameserver.

Could not make a TCP connection to the nameserver.

A common reason for a lookup failure is a timeout, for instance if there is a slow or busy network connection to a server. In this case, you could try again at less busy times.

If the server is constantly unreachable, then it's not a good candidate to be a nameserver for a zone, and you should try to arrange a different one.

The delegated nameservers you provided may be on the same subnet. Please ignore if this isn't the case.

It is wise to have nameservers for a zone as network-topographically dispersed as possible, in order to maximise the chances of information about the zone being available in event of a server failure or network problem. It's therefore a bad idea to have serverson the same physical subnet, since any problem affecting the subnet will likely cause problems to both servers. and so nameservers should be at a minumum at different physical sites.

Please see RFC 2182 for more details.

The checker got back an IP address that is syntactically invalid and so unusable.

The delegation checker encountered an error when looking up records.

Problems with a DNS query can occur for a wide variety of reasons. The checker does not treat these as errors, but just makes a note of them. However, the data which could not be retrieved might be the cause of another problem elsewhere in the report.

A common reason for a lookup failure is a timeout, for instance if there is a slow or busy network connection to a server. In this case, you could try again at less busy times.

If the server is constantly unreachable, then it's not a good candidate to be a nameserver for a zone, and you should try to arrange a different one.

A firewall can also result in DNS queries timing out. Please check your firewall setup if this is a possiblity.

For some query failures the checker will try ping and traceroute (see the diagnostic output).

The minimim value in the SOA record returned by this nameserver is not within the suggested range. RFC 1912 suggest 1-5 days as typical values.

Please note that if you are using this field as the negative cache TTL as per RFC 2308, your minimum value should instead probably be less than one day.

The most widespread meaning of the minimum field is currently default TTL i.e. the TTL value for records in the zone for which no explicit TTL has been given with the record itself.

RFC 2308 has redefined the meaning to be default negative TTL i.e. the time that the non-existence of a record in the zone may be cached.

This latter usage of the minimum value is now spreading as the server software implements it, but currently there are two coexistent meanings. If you are using minimum as the negative cache value, the you should be aware that RFC 2308 has the following to say...

"Values of one to three hours have been found to work well and would make a sensible default. Values exceeding one day have been found to be problematic."

The mname (primary nameserver) in the SOA record listed at this server is not in the list of servers at this nameserver.

RFC 2181, section 7.3 has a useful clarification as regards how the the mname field should be used. However, if this concerns a zone in which the primary master is a stealth server, you may ignore this note.

The refresh value in the SOA record returned by this nameserver is not within the recommended range. RFC 1912 recommends 20 minutes to 12 hours for this value.

Although 20 minutes to 12 hours are recommended, if all the nameservers support DNS NOTIFY (and it's enabled) then larger values are reasonable.

Please see RFC 1996 for more information on DNS NOTIFY. Incidentally, the feature is is not available in BIND 4.X.

The serial number in the SOA record returned by this server is not in the recommended YYYYMMDDnn format, or YYYY, MM or DD had an unexpected value. For instance, DD should be between 1 and 31.

Please see, for example, RFC 1912, section 2.2 or RIPE 203, section 4.3 for more information on serial number formats.