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@ripe.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 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 servers on 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.

In the case of IPv4 addresses, it's difficult to check automatically whether two particular addresses are on the same physical subnet, so the checker simply reports if two addresses share the same first three octets i.e. have the same /24 prefix.

In the case of IPv6 addresses, the checker will report if two addresses share the same subnet identifier.

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.

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 indicates how long a server should remain serving data in the case it can not connect to other authoritative servers to check on new versions of the zone.

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

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.

The RNAME parameter of the SOA should contain a valid email address. The server tries to determine, via an MX query, what the address is to which this mail should be delivered and actually tries to engage in an SMTP session with the receiving MTA.

This problem occures when the lookup for the A record of the MTA with the lowest preference (as returned from an MX query) for the email domain fails.

The RNAME parameter of the SOA should contain a valid email address. The server tries to determine, via an MX query, what the address is to which this mail should be delivered and actually tries to engage in an SMTP session with the receiving MTA.

This problem occures when a TCP connection to the MTA cannot be established. That could be due to a temporary failure.

The RNAME parameter of the SOA should contain a valid email address. The server tries to determine, via an MX query, what the address is to which this mail should be delivered and actually tries to engage in an SMTP session with the receiving MTA.

This problem occures when the lookup for the MX record for the email domain fails. This is an indication for the rname record not being properly configured.

The RNAME parameter of the SOA should contain a valid email address. The server tries to determine, via an MX query, what the address is to which this mail should be delivered and actually tries to engage in an SMTP session with the receiving MTA.

This problem occures when during the SMTP session an error message of some sort is received. There are many reasons why this could happen. The server could for instance use grey listing or other MAIL FROM: envelope filtering which pushes back on the email address used during the session.

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.

Previously we used interpret this vallue as the "default TTL" and followed the 1-5 days value recommendation from RFC 1912. But since server implementations that use this value as the default TTL are becoming wide spread we have modified the test to follow the recommendations from RFC 2308:

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

It is understood that for zones in which names are added and deleted with high frequency the default negative caching value may even be lower. If you get this problem reported and you run such "dynamic" zone you can safely ignore 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 )
    
    

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

RFC 2181, section 7.3 has a useful clarification as regards how the the mname field should be used.

Not having the server from the mname the NS resource record set is common in setups with so called "hidden" or "stealth" masters, .In this setup the name server that is the "source" of the data is not available for answering queries from the Internet.

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

• 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

RFC 1912 section 2.1 reads: " Make sure your PTR and A records match. For every IP address, there should be a matching PTR record in the in-addr.arpa domain. If a host is multi-homed, (more than one IP address) make sure that all IP addresses have a corresponding PTR record (not just the first one). Failure to have matching PTR and A records can cause loss of Internet services similar to not being registered in the DNS at all " In practice we have seen that nameservers are not mapped in the reverse space. The test provides warnings for each server that does not have a reverse mapping and thereby discriminates against sites tha have multiple servers for a zone. Currently we allow for 5 servers without reverse mapping until you collected to many severity points.

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.

The refresh value is an indication for the secondary servers on when to contact the primary server to look for changes. If the values are large than zone changes may not be picked up in a reasonalbe time and different DNS clients will get different results in case DNS data has changed.

If your nameservers are all configured to use "DNS NOTIFY" (see RFC 1996) than the refresh value is less relevant.

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.

Strictly speaking there is no rule agains having MX records for your reverse domains and to run an mail server that accepts mails directed to your reverse domain.

So 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

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

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.

In our experience duplicate domain names in the rname are always the cause of an error caused when the zone administrators email address has been fully expanded in the the rname field but the dot (.) on the end of the rname field has been forgotten.
as in:

      ;; BAD EXAMPLE AHEAD.
	$example.com.
	
	@  IN 3600 SOA  ns.example.com. bert.example.com  (
					2004010100 
					28800 
					14400 
					2592000 
					14400 )
	
      

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.

DNS servers do not care about the SOA serial number being in a specific format. They use the serial number to track if zones are changed.

To ease operational troubleshooting the YYYYMMDDnn format is recommended.

This problem is returned in conjunction with PROBLEM_SERIAL_NOT_RECOMMENDED_FORMAT as the serial is not only not in the recommended format but also seems to be in the future.

If you are conciously not using the YYYYMMDDnn format you can ignore this error.

DNS servers do not care about the SOA serial number being in a specific format. They use the serial number to track if zones are changed.

To ease operational troubleshooting the YYYYMMDDnn format is recommended.

If you are conciously not using the YYYYMMDDnn format you can ignore this error.

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 DelChecker library will test consistency of SOA RRs between servers and will, if all the zones on the servers have the same serial number, assume that all the zones are equal and perform aditional tests only on the results from one particular server.

This is not a problem but a feature of the testing code.

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.

A mapping for the IP address is available but it does not map to the name of the nameserver.

Reasons for this could be that your nameserver is known under many names and that you only have one PTR record in the reverse zone.

We suggest adding multiple PTR records or using the name that is in the reverse zone

The TTLs from all the records of a record set need to be the same (by definition see RFC2181 5.2). This error occuring is an indication that something is wrong with your nameserver.

Once the NS RR has expired from a forwarding nameserver, that nameserver will need to requery the parent when it receive a new query for a particular domain. A low TTL puts load on the parent server. There is little reason to have a TTL on the nameserver shorter than a few minutes.