Subtitles of the Movie

With the BIND DNS server, it's far easier to make mistakes than it is with Microsoft windows, as the configuration file and zone files are all edited manually. Even the simplest typo such as a forgotten semicolon or quotation mark can stop BIND from loading. This is even more of a problem on a production system, as you can cause the DNS server to halt if your configuration file has bad syntax, even when you reload the server. BIND provides tools to check your configuration before you reload the server to ensure that it is correct. BIND also uses the UNIX syslog facility to log errors and information by default. If you do have problems, this allows you to trouble shoot and repair your system. First we can have a look at two tools that can be used to trouble shoot your configuration and zone files before you have a major problem with your DNS server. When you edit your named.conf file and restart your DNS server, the file must be syntactically correct or the server won't start. If the zone file has incorrect syntax, that particular zone won't load but the server will still start. To prevent problems from occurring, BIND provides two utilities named-checkconf and named-checkzone. Named-checkconf is used to check the named.conf file after your make changes. If your named.conf file is in /etc, all you need to do is run the named-checkconf utility, typically located in the user local sbin directory. If there are syntax errors in your configuration file, the errors will be listed along with the appropriate line numbers. When you run named-checkconf against a configuration file with no errors, no output is shown. If you are running BIND in a jail, as discussed in the earlier lesson jailing BIND, you should specify the -t option followed by the jail directory. If your configuration file is in a location other than /etc, specify the full path including the file name following the named-checkconf command and the -t option if required. There is also a utility available to check the syntax of zone files. To check a zone file, run the command named-checkzone, again typically located in the /user/local/sbin directory, followed by the zone name and zone file name. If the zone file is ok, the utility will indicate the serial number and ok. If there is a problem, it will indicate the problem and a line number on which the problem occurs. The named-checkzone command can also accept the -d option to print extended debugging information and the -j option to load the journal file of the zone if any. The journal file is used to store dynamic updates to a zone which are written to the actual zone file periodically. If you aren't using dynamic updates, you will never need the -j option. While using the named-checkconf and named-checkzone commands should prevent any problems from occurring, if you do have a problem, you need to know where to look. By default all errors and informational events are logged to the UNIX syslog facility. You can find the syslog in LINUX in \var\log\messages and in Solaris in \var\adm\messages. You may want to use the tail command to look at the log files as they can be large. If you look at the syslog after BIND starts, you will see the messages generated by the BIND startup process. If there are problems during BIND startup, they will be indicated in this log. Errors in the log will almost always indicate the type of error and the line number on which the error occurs if the problem is in the syntax of a configuration file. The only case where this behavior may differ is if you have alternate logging conflict. Look in your BIND configuration file for a logging statement; this is often omitted as logging to the syslog facility is fine, but in some cases alternate logging may be used. If there is a logging statement in your configuration file, look at where the channels point. If any of the channel options in the logging statements contains a file option, the specified file will be used for that type of log, instead of the syslog. In this case, check the specified files for log entries.