ns named[111]: Lame server on 'www.example.com' (in 'example.com'?): [192.168.0.2].53 'ns2.example.com'
This is a harmless error message. It means that the server at 192.168.0.2 ( ns2.example.com ) is listed as a nameserver for " example.com ", but it doesn't really know anything about example.com .
If this is a zone under your control, check each of the nameservers to ensure that they are configured to answer questions properly.
If it's a zone out on the Internet, it would be nice to notify the owners of the domain in question so that they can take a look at it. In practice, though, not many people have time to do this.
ns named[111]: bad referral (other.com !< subdomain.other.com)
This indicates that your nameserver ( ns.example.com ) queried the nameserver for example2.com to find out how to get to subdomain.example2.com . The name server example2.com told your nameserver that subdomain.example2.com was delegated to some other.example2.com , so your nameserver queried that.
someother.example2.com didn't think that subdomain.example2.com had been delegated to it, so it referred your server ( ns.example.com ) back to the example2.com nameserver.
ns named-xfer[111]: [192.168.0.1] not authoritative for example.com, SOA query got rcode 0, aa 0, ancount 1, aucount 0
This error usually shows up on a slave server. It indicates that the master server is not answering authoritatively for the zone. This usually happens when the zone is rejected (while
named
is loading) on the master server. Check the logs on the master server. If ancount -- 0, you may be pointing at the wrong master server for the zone.
ns named[111]: master zone "example.com" (IN) rejected due to errors (serial111)
This indicates that the
example.com
zone was rejected because of an error in the zone file. Check the lines above this error.
named
will usually tell you what it didn't like and where to find it in the zone file.
ns named[111]: Zone "example.com" (file example.com.db): no NS RRs found at zonetop
The example.com.db file is missing NS records at the top of the zone (in the SOA section). Check to make sure they exist and that there is white space (spaces or tabs) in front of them. White spaces matter here.
ns named[111]: Zone "example.com" (file example.com.db): No default TTL set using SOA minimum instead
You will need to add a
$TTL
to the top of the
example.com.db
zone file. See RFC 2308, or
Setting TTLs
for information on how to use
$TTL
.
findns: No root nameservers for class IN?
Your nameserver is having problems finding the root nameservers. Check your root hints file to make sure it is not corrupted. Also, make sure that your nameserver can reach the Internet.
If you are running an internal root nameserver, make sure it is configured properly and is answering queries.
ctl_server: bind: Address already in use
This usually indicates that another copy of BIND is already running. Verify that you have killed old copies of the daemon.
This can also pop up if you originally ran named as "root" and now run it as a regular user. named may have left behind an ndc control socket that is owned by root if it crashed, or was not killed gracefully.
This means that the regular user wouldn't be able to delete it, so it would think named is still running. The solution is to remove any ndc sockets in /usr/local/etc , or /var/run , etc.
The best solution to solving installation and configuration issues is to take preventative measures by setting up logging files beforehand (see the sample configurations in Sample Configuration and Logging. ). The log files provide a source of hints and information that can be used to figure out what went wrong and how to fix the problem.
Zone serial numbers are just numbers--they aren't date related. A lot of people set them to a number that represents a date, usually of the form YYYYMMDDRR. A number of people have been testing these numbers for Y2K compliance and have set the number to the year 2000 to see if it will work. They then try to restore the old serial number. This will cause problems, because serial numbers are used to indicate that a zone has been updated. If the serial number on the secondary server is lower than the serial number on the primary, the secondary server will attempt to update its copy of the zone.
Setting the serial number to a lower number on the primary server than the secondary server means that the secondary will not perform updates to its copy of the zone.
The solution to this is to add 2147483647 (2^31-1) to the number, reload the zone and make sure all secondaries have updated to the new zone serial number, then reset the number to what you want it to be, and reload the zone again.
The Internet Software Consortium (ISC) offers a wide range of support and service agreements for BIND and DHCP servers. Four levels of premium support are available and each level includes support for all ISC programs, significant discounts on products and training, and a recognized priority on bug fixes and non-funded feature requests. In addition, ISC offers a standard support agreement package which includes services ranging from bug fix announcements to remote support. It also includes training in BIND and DHCP.
To discuss arrangements for support, contact
info@isc.org
or visit the ISC web page at
http://www.isc.org/services/support/
to read more.
Return to BINDv9 Administrator Reference Manual