Supporting Information for the RIPE NCC Delegation Checker Error Codes
Contents
Introduction
The delegation checker performs a large number of consistency checks. When it
finds a certain problem it will generate an error that is identified with
a problem code.
Below is a list of the problem codes that the delegation checker
generates together with the "severity scores" that are used to
determine if the RIPE NCC will create a delegation or not.
If you are puzzled by any aspect of the delegation checker output, the
information below may help. As always, if you can't find the answer to
your question below, then please don't hesitate to contact the
maintainer...
<webmaster@ripe.net>
The checker is currently in a beta stage. We are very grateful for
all bug reports and suggestions, please direct them to the same address.
References
In rough order of relevance...
- RFC 1912, Common DNS Operational and Configuration Errors, February 1996
HTML -
Original Text
- RFC 2182, Selection and Operation of Secondary DNS Servers, July 1997
HTML -
Original Text
- RFC 2181, Clarifications to the DNS Specification, July 1997
HTML -
Original Text
- RIPE 203, Recommendations for DNS SOA Values, June 1999
HTML -
Text
- RFC 1123, Requirements for Internet Hosts -- Application and Support, October 1989
Original Text
- RFC 2317, Classless IN-ADDR.ARPA delegation, March 1998
HTML -
Original Text
- RFC 2308, Negative Caching of DNS Queries (DNS NCACHE), March 1998
HTML -
Original Text
- Other DNS related RFC's
DNSRD
Table of possible responses
Below is a list of all the possible problem codes that can be returned during
a delegation check. Note that some errors could be returned multiple times.
&You can always link to a page directly by using an URL like http://www.ripe.net/rs/reverse/delcheck/delcheck_descr.html#PROBLEM_CODE_NAME
|
Bad IP address encountered |
|
PROBLEM_BAD_IP |
|
Score: 20
(Error) |
|
The checker returned the IP
address 345.16.12.12 for ns2.example.com. This is
syntactically bad and unusable.
|
|
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.
|
|
|
Bad port for DNS encountered |
|
PROBLEM_BAD_PORT |
|
Score: 20
(Error) |
|
Port !0 was specified for
(ns1.example.com:!0). This is syntactically invalid and
unusable.
|
|
|
Could not lookup NS addresses |
|
PROBLEM_COULDNT_LOOKUP_NS_ADDRESS |
|
Score: 20
(Error) |
|
Could not look up an IP address for nameserver
ns1.example.com found in the submitted domain object.
|
|
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.
|
|
|
Lame delegation, nameserver is listed in the zone. |
|
PROBLEM_DELEGATED_NS_NOT_LISTED_AT_ZONE |
|
Score: 20
(Error) |
|
The submitted nameserver
ns1.example.com is not listed for the zone by the nameserver at
ns3.example.com (192.0.4.2).
|
|
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.
|
|
|
Nameservers on the same subnet |
|
PROBLEM_DELEGATED_NS_ON_SAME_SUBNET |
|
Score: 0
(Information) |
|
The delegated nameservers
ns2.example.com (192.0.4.1) and ns4.example.com (192.0.4.3)
may not be on the same subnet.
|
|
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.
|
|
|
The domain name contains an empty label |
|
PROBLEM_DOMAIN_NAME_LABEL_EMPTY |
|
Score: 20
(Error) |
|
The domain name bla..example.com of <where the domain name was found>
contains zero length labels. A domain name is formed by labels
separated by dots. The minimum length of such a label is 1 octet,
as specified in RFC 2181, section 11.
|
|
|
Label in domain name is too long |
|
PROBLEM_DOMAIN_NAME_LABEL_TOO_LONG |
|
Score: 20
(Error) |
|
The label <verylonglabel> in the domain
name <verylonglabel> of <where the domain name was found> is too long.
It is 75 octets, the maximum is 63 octets.
A domain name is formed by labels separated by dots.
The maximum length of such a label is 63 octets, specified in
RFC 2181, section 11.
|
|
|
Domain name is too long |
|
PROBLEM_DOMAIN_NAME_TOO_LONG |
|
Score: 20
(Error) |
|
The domain name some.very.long.name of <where the domain name was found>
is too long. It is 265 octets compared to the maximum of
255 octets permitted by RFC 2181, section 11.
|
|
|
Duplicate IPs for nameservers in the domain object |
|
PROBLEM_DUPLICATE_DELEGATED_NS_IP |
|
Score: 20
(Error) |
|
The IP address 192.0.4.1 is identical
for the nameserver(s) <list of nameservers>
found in the submitted domain object.
|
|
|
Duplicated nameserver names in domain object |
|
PROBLEM_DUPLICATE_DELEGATED_NS_NAME |
|
Score: 20
(Error) |
|
The nameserver name ns1.example.com appears more
than once in the submitted domain object.
|
|
|
Duplicate ns rrs in the zone |
|
PROBLEM_DUPLICATE_NS_NAME_LISTED_AT_ZONE |
|
Score: 20
(Error) |
|
The nameserver name ns1.example.com was listed
more than once in this zone at ns3.example.com (192.0.4.2).
|
|
|
Expire parameter is less than refresh |
|
PROBLEM_EXPIRE_LESS_THAN_REFRESH |
|
Score: 20
(Error) |
|
The expire value 1800 in the SOA
record returned by this
nameserver is less than the refresh value 3600 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.
|
|
|
SOA expire parameter is to small |
|
PROBLEM_EXPIRE_LESS_THAN_REFRESH_RETRY_SUM |
|
Score: 7
(Warning) |
|
The expire value 7200 in the SOA record
returned by this nameserver is less than the sum of the
refresh (4800) and
retry (5600) 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.
|
|
|
SOA Expiry value out of range of recommended values |
|
PROBLEM_EXPIRE_OUT_OF_RANGE |
|
Score: 0
(Information) |
|
The expire value 3600 (1 hour)
in the SOA record returned by this
nameserver is not within the suggested range.
RFC 1912 recommends between two and four weeks for this value.
|
|
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).
|
|
|
Hostname has a numeric TLD |
|
PROBLEM_HOSTNAME_IN_NUMERIC_TLD |
|
Score: 20
(Error) |
|
The hostname ns.10.0.10.10 of
<where the domain name was found> has a numeric Top Level Domain.
This is probably because you entered the IP address instead of the hostname.
|
|
|
Hostname contains illegal characers |
|
PROBLEM_HOSTNAME_LABEL_ILLEGAL_CHARACTERS |
|
Score: 20
(Error) |
|
The label examp!e in the
hostname bla.examp!e.com of <where the domain name was found> 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.
|
|
|
Hostname starts or ends with an illegal character |
|
PROBLEM_HOSTNAME_LABEL_ILLEGAL_START_OR_END |
|
Score: 20
(Error) |
|
The label _foo in the hostname
_foo.example.com of <where the domain name was found> does not
start and end with a letter or digit. Please see RFC 1912,
section 2.1, for more information on hostname restrictions.
|
|
|
Hostname contains illegal characers |
|
PROBLEM_HOSTNAME_ONE_LABEL |
|
Score: 20
(Error) |
|
The hostname example of <where the domain name was found> only
has one label. A domain name is formed by labels separated by dots.
|
|
|
Servers return inconsistent nameserver lists |
|
PROBLEM_INCONSISTENT_NS_LISTING |
|
Score: 20
(Error) |
|
Nameserver ns1.example.com is listed at:
ns3.example.com (192.0.4.2),
but not at:
ns5.example.com (192.0.4.4).
All nameservers should have a consistent set of nameservers listed
for the zone.
|
|
|
Nameserver is not being delegated to |
|
PROBLEM_LISTED_NAMESERVER_NOT_IN_DELEGATED_LIST |
|
Score: 0
(Information) |
|
The nameserver ns1.example.com was
found listed for the zone
at ns3.example.com (192.0.4.2), but was not one of the
delegated nameservers
(<list of delegated nameservers>).
|
|
|
Problem with DNS query |
|
PROBLEM_LOOKUP |
|
Score: 0
(Information) |
|
The checker encountered an error when looking up
<qname> records for the name <qtype> at
<list of name servers>:
<Some error message>
|
|
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.
|
|
|
Could not lookup A records for MTA |
|
PROBLEM_MAILCHECK_A_LOOKUP |
|
Score: 2
(Warning) |
|
We could not lookup the A address for mta.example.com
The resolver returened the folowing RCODE: <an error message>
|
|
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.
|
|
|
Could not connect to MTA |
|
PROBLEM_MAILCHECK_CONNECTION_FAILED |
|
Score: 0
(Information) |
|
We could not set up a TCP connection to port 25 of 192.0.4.1 which
supposedly is the receiving MTA for bla@example.com
(<Error returned by Perl Library>)
|
|
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.
|
|
|
Could not lookup MX records |
|
PROBLEM_MAILCHECK_MX_LOOKUP |
|
Score: 2
(Warning) |
|
We could not lookup the MX address for example.com
The resolver returened the folowing RCODE: <an error message>
|
|
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.
|
|
|
Failure during the SMTP session with the rname MTA |
|
PROBLEM_MAILCHECK_SMTP_FAILURE |
|
Score: 0
(Information) |
|
A failure occured during the SMTP session with mta.example.com
This one of the mail servers that accepts mails for the
email address in the SOA rname field bert@example.com
The MTA returned: <An SMTP Error message
|
|
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.
|
|
|
The Negative Caching TTL (SOA minimum) out of range of recommended values |
|
PROBLEM_MINIMUM_OUT_OF_RANGE |
|
Score: 0
(Information) |
|
The minimum value 60 (1 minute)
in the SOA record returned by this
nameserver is not within the suggested range. RFC 2308
suggests 1-3 hours as typical values.
|
|
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 does not resolve |
|
PROBLEM_MNAME_DOESNT_RESOLVE |
|
Score: 20
(Error) |
|
Could not look up an IP address for the
mname (primary nameserver) ns1.example.com listed in the
SOA record at this server.
|
|
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 )
Would yield ns.example.com.4.0.192.in-addr.arpa. as mname.
|
|
|
SOA mname not present in the nameserver set |
|
PROBLEM_MNAME_NOT_LISTED_AS_NS |
|
Score: 0
(Information) |
|
The mname (primary nameserver) ns1.example.com in the SOA record
listed at this server is not in the list of servers
at this nameserver (<list of nameservers>).
|
|
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.
|
|
|
Multiple SOA RRs returned by server |
|
PROBLEM_MULTIPLE_SOA_AT_SERVER |
|
Score: 20
(Error) |
|
The server at ns1.example.com
(192.0.4.2) returns multiple SOA records.
|
|
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.
|
|
|
Nameserver is not authoritative |
|
PROBLEM_NON_AA_NAMESERVER |
|
Score: 20
(Error) |
|
The delegated nameserver
ns2.example.com (192.0.4.1) 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...
|
|
|
No reverse mapping |
|
PROBLEM_NO_REVERSE_MAPPING |
|
Score: 0
(Information) |
|
Could not find a PTR record mapping 192.0.4.1
to ns2.example.com.
For every IP address there should be a matching PTR record
registered Please see RFC1912, section 2.1 for more information.
|
|
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.
|
|
|
No SOA returned by server |
|
PROBLEM_NO_SOA_AT_SERVER |
|
Score: 20
(Error) |
|
Could not get an SOA record from
ns2.example.com (192.0.4.1).
|
|
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
|
|
|
Nameserver does not have a canonical name |
|
PROBLEM_NS_NAME_NOT_CANONICAL |
|
Score: 20
(Error) |
|
The delegated nameserver
name ns1.example.com 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.
|
|
|
Found a prohibited nameserver in domain object |
|
PROBLEM_PROHIBITED_NAMESERVER_PRESENT |
|
Score: 20
(Error) |
|
The nameserver ns.ripe.net is present in the
submitted list of delegated nameservers
for this zone (example.com). The RIPE NCC does not
run secondary for zones of this type/size.
|
|
This problem is only generated by the WHOIS updata mechanism, the web based delegation checker does not check on it.
|
|
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.
|
|
|
SOA Refresh out of range of recommended value |
|
PROBLEM_REFRESH_OUT_OF_RANGE |
|
Score: 0
(Information) |
|
The refresh value 43200 (1 day) 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.
|
|
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.
|
|
|
Required nameserver missing. |
|
PROBLEM_REQUIRED_NAMESERVER_MISSING |
|
Score: 20
(Error) |
|
The nameserver(s) ns.ripe.net
was/were not present in the
submitted list of delegated nameservers
for this zone. This is required by the
RIPE NCC for this type/size of zone.
|
|
This problem is only generated by the WHOIS updata mechanism, the web based delegation checker does not check on it.
|
|
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.
|
|
|
SOA Retry out of range of recommended values |
|
PROBLEM_RETRY_OUT_OF_RANGE |
|
Score: 0
(Information) |
|
The retry value 1800 (30 minutes) 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. We
have interpreted this as a fraction between 0.05 to 1.0 times the
refresh value i.e. between x minutes and y hours.
|
|
|
A reverse domain found in the RNAME field |
|
PROBLEM_REVERSE_DOMAIN_IN_RNAME |
|
Score: 2
(Warning) |
|
The rname (e-mail contact) field bert.4.0.192.in-addr.arpa.
in the SOA record returned by this server is in a reverse domain
(in-addr.arpa, ip6.int or ip6.arpa).
|
|
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
as in:
;; BAD EXAMPLE AHEAD.
$ORIGIN 4.0.192.in-addr.arpa.
@ IN 3600 SOA ns.example.com. bert (
2004010100
28800
14400
2592000
14400 )
|
|
|
The SOA e-mail field has a bad syntax |
|
PROBLEM_RNAME_BAD_SYNTAX |
|
Score: 20
(Error) |
|
The rname (e-mail contact) field <rname-with-bad-syntax>
in the SOA record returned by this server is
syntactically incorrect.
|
|
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:
- replace any dot (.) characters in the local part of the email
address (the part before the '@' sign) with a backslash
then a dot (\.)
- 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.
|
|
|
Duplicated name in the SOA email field |
|
PROBLEM_RNAME_DUPLICATE_ZONE |
|
Score: 10
(Warning) |
|
The rname (e-mail contact) field example.com.example.com.
in the SOA record returned from this nameserver contains
the zone name twice. This probably results from a missing '.'
on the end of the rname in the master zone file.
|
|
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 )
where the rname would be expanded to bert.example.com.example.com.
|
|
|
SOA e-mail field contains an @-sign |
|
PROBLEM_RNAME_HAS_AT_SIGN |
|
Score: 20
(Error) |
|
The rname (e-mail contact) field bert@example.com
in the SOA record returned from this nameserver contains
an '@' sign.
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:
- replace any dot (.) characters in the local part of the email
address (the part before the '@' sign) with a backslash
then a dot (\.)
- 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 SOA Serial field lives in the future |
|
PROBLEM_SERIAL_IN_FUTURE |
|
Score: 0
(Information) |
|
The serial number 2133842201
in the SOA record returned
by this server is a time in the future.
|
|
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.
|
|
|
SOA serial not in the recommended YYYYMMDDnn format |
|
PROBLEM_SERIAL_NOT_RECOMMENDED_FORMAT |
|
Score: 0
(Information) |
|
The serial number 1234 in the SOA record returned by
this server is not in the recommended YYYYMMDDnn format.
|
|
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.
|
|
|
SOA serial numbers differ between servers |
|
PROBLEM_SERIAL_NUMBERS_DIFFER |
|
Score: 10
(Warning) |
|
Found differing serial numbers in the SOA records
returned for the zone at the nameservers:
ns2.example.com (192.0.4.1) : 2001011800
ns5.example.com (192.0.4.4) : 2004012900
|
|
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
|
|
|
Skipped test because of equal serial number |
|
PROBLEM_SKIPPED_SERIAL_NUMBER |
|
Score: 0
(Information) |
|
Several tests were skipped for one of more servers
having the version of the zone with serial number
2001011802, which had already been checked.
|
|
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.
|
|
|
One of the fields in the SOA record is empty |
|
PROBLEM_SOA_RECORD_FIELD_EMPTY |
|
Score: 20
(Error) |
|
The < One of the SOA RR fields> field in the SOA
record returned by this nameserver
was undefined or empty. This field should always have a value.
|
|
|
SOA parameters differ between servers |
|
PROBLEM_SOA_VALUES_DIFFER |
|
Score: 20
(Error) |
|
Found differing values in the SOA records returned
for the zone at ns2.example.com (192.0.4.1) and
ns4.example.com (192.0.4.3).
The following values were different:
[< One of the SOA RR fields>]
|
|
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.
|
|
|
To few nameservers |
|
PROBLEM_TOO_FEW_DELEGATED_NAMESERVERS |
|
Score: 20
(Error) |
|
At least d nameservers are
required for each properly delegated zone. We found only 1
in your submission.
|
|
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.
|
|
|
Unusable hostname encountered |
|
PROBLEM_UNUSABLE_HOSTNAME |
|
Score: 20
(Error) |
|
The hostname localhost of
<where the domain name was found> is unusable.
|
|
|
Unusable IP address encountered |
|
PROBLEM_UNUSABLE_IP |
|
Score: 20
(Error) |
|
The checker returned the IP
address 192.0.4.1 for
ns2.example.com. This is unusable as a
nameserver IP because <Reason why the prefix is found to be invallid>.
|
|
|
Wrong reverse mapping |
|
PROBLEM_WRONG_REVERSE_MAPPING |
|
Score: 0
(Information) |
|
None of the PTR records found for
192.0.4.1 mapped back to ns2.example.com.
For every IP address there should be a matching PTR record
registered Please see RFC1912, section 2.1 for more information.
|
|
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
|
|
|
TTLs for the NS RRs in the NS RR set not equal |
|
PROBLEM_RRSET_TTLS_NOT_EQUAL |
|
Score: 5
(Warning) |
|
The nameserver records in the NS set should all have the exact same
TTL (see RFC2181).
We found at least two differing TTLs (300 and 350)
The offending RRs are:
ns1.example.com IN 300 A 193.0.4.1
ns1.example.com IN 350 A 193.0.4.2
|
|
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.
|
|
|
TTL on NS set is to short |
|
PROBLEM_NS_TTL_TOO_SHORT |
|
Score: 4
(Warning) |
|
The TTL on the NS RRs is to short.
We found it to be 10.
To avoid excesive load on the DNS parent server the TTL should be
60 or more.
|
|
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.
|
|
|
The IP address for the glue record is missing |
|
PROBLEM_GLUE_IP_MISSING |
|
Score: 20
(Error) |
|
The glue nameserver ns1.1.127.in-addr.arpa
is specified without the IPv4 or IPv6 address.
Every glue nameserver must have at least one IPv4 or IPv6 address.
|
|
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.
|
|
|
The glue nameserver is outside the domain to be delegated |
|
PROBLEM_GLUE_OUTSIDE_ZONE |
|
Score: 20
(Error) |
|
The glue nameserver ns.test.net
must be within the domain that is being delegated.
The glue IP address has been ignored.
|
|
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.
|
|
|
The glue nameserver must be authoritative for at least one of its own A/AAAA records. |
|
PROBLEM_GLUE_IP_RR_MISSING |
|
Score: 20
(Error) |
|
The glue nameserver ns.test.net
must be authoritative for at least one of its own A/AAAA records.
|
|
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).
|
|
|
Not all servers return DNSSEC data |
|
PROBLEM_NOT_ALL_SERVERS_RETURN_DNSSECDATA |
|
Score: 20
(Error) |
|
Nameserver ns1.example.com did not return DNSSEC data.
Either your zone is nog signed or the server is not configured
with DNSSEC
|
|
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.
|
|
|
Not all servers return the same DNSKEY RR set |
|
PROBLEM_INCONSISTENT_DNSKEY_LISTING |
|
Score: 20
(Error) |
|
DNSKEY RR
is listed at:
ns3.example.com
(
192.0.4.2
),
but not at:
ns5.example.com
(
192.0.4.4
).
|
|
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.
|
|
|
|
PROBLEM_NO_MATCHING_DNSKEY_FOR_DS |
|
Score: 20
(Error) |
|
The submitted DS RR:
doesn't have corresponding DNSKEY record listed for the zone.
|
|
|
|
|
|
PROBLEM_DS_POINTING_TO_NON_SEP_DNSKEY |
|
Score: 4
(Warning) |
|
Although some of your keys in your DNSKEY RRset have a SEP flag set
we observed that the following DS RR
is pointing to
()
That DNSKEY is not marked as a Secure Entry Point key
|
|
|
|
|
|
PROBLEM_SEP_FLAG_NOT_USED |
|
Score: 0
(Information) |
|
None of your DNSKEYs is marked as a Secure Entry Point key
|
|
|
|
|
|
PROBLEM_SEP_KEY_NOT_SELF_SIGNED |
|
Score: 20
(Error) |
|
The following DS RR
<content of ds-rdata attribute>
is pointing to
<DNSKEY RR>
(<keyid>)
Any key that a DS points to should sign the DNSKEY RRset
|
|
|
|
|
|
PROBLEM_DS_DIGEST_ALGORITHM_NOT_KNOWN |
|
Score: 0
(Information) |
|
<content of ds-rdata attribute>
uses a Digest type that is not implemented by this checker.
We cannot verify if the chain of trust is intact.
You should be conciously using digest types other than SHA1
|
|
|
|
|
|
PROBLEM_DS_AND_DNSKEYRR_DO_NOT_MATCH |
|
Score: 20
(Error) |
|
the digest in
<content of ds-rdata attribute>
does not properly match the digest calculated over
<DNSKEY RR>
Your input may be corrupted.
|
|
|
|
|
|
PROBLEM_DNSSEC_ALGORITHM_NOT_IMPLEMENTED |
|
Score: 0
(Information) |
|
The signature over <RR type(SOA|DNSKEY)>
is made with algorithm code 666
The checker does not implement this algorithm and can therefore not
validate the chain of trust
It is assumed that using algoritm type 666 is a conscious choice.
|
|
|
|
|
|
PROBLEM_CHAIN_OF_TRUST_DOES_NOT_VALIDATE |
|
Score: 0
(Information) |
|
The chain of trust starting with
<content of ds-rdata attribute>
and terminating with a signature made overt the SOA RR made with DNSKEY of key id .
does not validate
|
|
|
|
|
|
PROBLEM_NO_CHAINS_OF_TRUST_VALIDATE |
|
Score: 20
(Error) |
|
We have tried all possible chains of trust from the supplied
DS RRs to the SOA RR.
All possible trust paths failed to verify. Errors on the individual
trust paths are reported elsewhere in this report.
|
|
|
|
|
|
PROBLEM_SIGNATURE_VALIDITY_NEARS_EXPIRATION |
|
Score: 0
(Information) |
|
The signature made with key id
Has a signature validity interval between
and
4/5th of this interval has expired.
You probably need to resign your data
|
|
|
|
|
|
PROBLEM_TTL_LARGE_FRACTION_OF_SIGNATURE_VALIDITY |
|
Score: 0
(Information) |
|
The SOA TTL () is
larger than half the RRSIG validity interval ()
|
|
|
|
|
you are here: home -> Internet Resources -> Reverse DNS Delegations
