Enabling DNS logging -
Use logging (named.conf(4)) to cause the named process to write to a log file that you specify. Add the following to the top of the primary DNS system's /etc/named.conf file and restart the named daemon:
logging {
channel logfile {
file "/var/named/bind-log";
print-time yes;
severity debug 9;
print-category yes;
print-severity yes;
};
category default { default_syslog; logfile; };
category queries { logfile; };
};
Logging starts as soon as the logging statement in the /etc/named.conf file is parsed, so the
logging statement should be the first entry in that file.
A logging channel controls the destination of the logged data. Following is a description of each of the example entries:
* /var/named/bind-log - File to hold logged data
* print-time yes - Print time of the event
* severity debug 9 - Debug output of level 9 and below to be logged
* print-category yes - Log category information
* print-severity yes - Log severity information
The category section describes how the channel information is used. Following is a description of each of the example entries:
* category default { default_syslog; logfile; } - Log to syslog and logfile
* category queries { logfile; } - Log queries
The named daemon sends messages to the syslogd daemon by using the daemon facility. Messages that
are sent with level notice or higher are written to the /var/adm/messages file by default. The
contents of this file often show where configuration errors were made.
----
Before the Solaris 9 OS, the primary test tool bundled with BIND was the nslookup utility. As of the Solaris 9 OS, the domain information groper (dig) utility was also bundled with the Solaris OS. In the Solaris 10 OS, the nslookup utility is included, but is marked as obsolete with a notification that it might be removed in a future release. The dig utility is now preferred and does the following:
* Sends queries and displays replies for any of the valid resource record types
* Queries the DNS server of your choice
* Debugs almost any domain that is not protected by a firewall
Executing Forward Queries
The syntax used for forward queries is as follows:
dig @DNS_server domain_name system_name
A typical debug query testing forward resolution might look like the following:
# dig @192.168.1.2 one.edu sys11.one.edu
; <<>> DiG 9.2.4 <<>> @192.168.1.2 one.edu sys11.one.edu
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1334
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;one.edu. IN A
;; AUTHORITY SECTION:
one.edu. 86400 IN SOA sys12.one.edu. root.sys12.one.edu. 2005010101 3600
1800 6048000 86400
;; Query time: 4 msec
;; SERVER: 192.168.1.2#53(192.168.1.2)
;; WHEN: Wed Jan 12 16:56:12 2005
;; MSG SIZE rcvd: 72
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1440
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;sys11.one.edu. IN A
;; ANSWER SECTION:
sys11.one.edu. 86400 IN A 192.168.1.1
;; AUTHORITY SECTION:
one.edu. 86400 IN NS sys12.one.edu.
one.edu. 86400 IN NS sys13.one.edu.
;; ADDITIONAL SECTION:
sys12.one.edu. 86400 IN A 192.168.1.2
sys13.one.edu. 86400 IN A 192.168.1.3
;; Query time: 3 msec
;; SERVER: 192.168.1.2#53(192.168.1.2)
;; WHEN: Wed Jan 12 16:56:12 2005
;; MSG SIZE rcvd: 119
The ANSWER SECTION lists the answer retrieved from the DNS server. An answer number (on the flags
line) greater than zero usually indicates success.
Executing Reverse Queries
The syntax used for reverse queries is as follows:
dig @DNS_server domain_name -x IP_address
A typical debug query testing reverse resolution might look like the following:
dig @192.168.1.2 one.edu -x 192.168.1.1
; <<>> DiG 9.2.4 <<>> @192.168.1.2 one.edu -x 192.168.1.1
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1881
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;one.edu. IN A
;; AUTHORITY SECTION:
one.edu. 86400 IN SOA sys12.one.edu. root.sys12.one.edu. 2005010101 3600
1800 6048000 86400
;; Query time: 4 msec
;; SERVER: 192.168.1.2#53(192.168.1.2)
;; WHEN: Wed Jan 12 16:55:11 2005
;; MSG SIZE rcvd: 72
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1932
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;1.1.168.192.in-addr.arpa. IN PTR
;; ANSWER SECTION:
1.1.168.192.in-addr.arpa. 86400 IN PTR sys11.one.edu.
;; AUTHORITY SECTION:
1.168.192.in-addr.arpa. 86400 IN NS sys13.one.edu.
1.168.192.in-addr.arpa. 86400 IN NS sys12.one.edu.
;; ADDITIONAL SECTION:
sys12.one.edu. 86400 IN A 192.168.1.2
sys13.one.edu. 86400 IN A 192.168.1.3
;; Query time: 3 msec
;; SERVER: 192.168.1.2#53(192.168.1.2)
;; WHEN: Wed Jan 12 16:55:11 2005
;; MSG SIZE rcvd: 141
----
The remote name daemon controller command, rndc, is used to dump the currently cached contents of the server.
sys12# rndc dumpdb
All of the options for the rndc utility are listed when it is invoked without any as follows:
# rndc
Usage: rndc [-c config] [-s server] [-p port]
[-k key-file ] [-y key] [-V] command
command is one of the following:
reload Reload configuration file and zones.
reload zone [class [view]]
Reload a single zone.
refresh zone [class [view]]
Schedule immediate maintenance for a zone.
reconfig Reload configuration file and new zones only.
stats Write server statistics to the statistics file.
querylog Toggle query logging.
dumpdb Dump cache(s) to the dump file (named_dump.db).
stop Save pending updates to master files and stop the server.
halt Stop the server without saving pending updates.
trace Increment debugging level by one.
trace level Change the debugging level.
notrace Set debugging level to 0.
flush Flushes all of the server's caches.
flush [view] Flushes the server's cache for a view.
status Display status of the server.
*restart Restart the server.
* == not yet implemented
Version: 9.2.4
Clearing the Cache
Clear the server's cached data by restarting the named daemon. For example:
sys12# svcs -a | grep dns
online 5:09:02 svc:/network/dns/client:default
online 5:09:25 svc:/network/dns/server:default
sys12# svcadm disable svc:/network/dns/server:default
sys12# svcs -a | grep dns
disabled 6:54:30 svc:/network/dns/server:default
online 5:09:02 svc:/network/dns/client:default
sys12# svcadm enable svc:/network/dns/server:default
sys12# svcs -a | grep dns
online 5:09:02 svc:/network/dns/client:default
online 6:54:45 svc:/network/dns/server:default
Verify that the cache has been cleared using the rndc command:
sys12# rndc dumpdb
sys12# cat /var/named/named_dump.db
;
; Cache dump of view '_default'
;
$DATE 20050112135516
You can use the rndc utility with the reconfig command to cause the named process to reload its configuration file and implement any changes to the zone files as follows:
sys12# rndc reconfig
-----
S10
Administrators use the remote name daemon control program (rndc) to control the operation of a name server. Name servers have always been controlled by administrators sending signals, such as SIGHUP and SIGINT. The rndc utility provides a finer granularity of control, and it can be used both interactively and non-interactively.
As of the Solaris 10 OS, the rndc utility replaces the ndc utility as the name daemon control
application. A significant difference between ndc in BIND 8 and rndc in BIND 9 is that rndc uses its own configuration file, rndc.conf.
Securing Control Sessions
The rndc utility supports security using key-based authentication. Remote clients are authorized
specifically to control the daemon by establishing, configuring and using secret keys. Implementing this security requires an rndc-key reference entry in the /etc/name.conf file and the appropriate key information in the rndc.conf file.
Without a rndc-key reference in the /etc/named.conf file, the following messages appear in the
/var/adm/messages file:
Jan 12 08:22:12 sys12 named[1346]: [ID 873579 daemon.notice] /
command channel listening on 127.0.0.1#953
Jan 12 08:22:12 sys12 named[1346]: [ID 873579 daemon.notice] /
couldn't add command channel ::1#953: address not available
You can continue to use the rndc utility, albeit in a non-secure manner.
Use the rndc-confgen utility to generate the proper contents for the rndc.conf and /etc/named.conf
files. The rndc.conf file specifies which server controls and algorithm the server should use. You
need only a rndc.conf file in place if the named.conf file has an entry for a rndc-key.
sys12# /usr/sbin/rndc-confgen
# Start of rndc.conf
key "rndc-key" {
algorithm hmac-md5;
secret "jZOP5nh//i9t7BwHivvNzA==";
};
options {
default-key "rndc-key";
default-server 127.0.0.1;
default-port 953;
};
# End of rndc.conf
# Use with the following in named.conf, adjusting the allow list as needed:
# key "rndc-key" {
# algorithm hmac-md5;
# secret "jZOP5nh//i9t7BwHivvNzA==";
# };
#
# controls {
# inet 127.0.0.1 port 953
# allow { 127.0.0.1; } keys { "rndc-key"; };
# };
# End of named.conf
sys12#
Copy the rndc-key section into a new file called /etc/rndc.conf.
sys12# cat /etc/rndc.conf
key "rndc-key" {
algorithm hmac-md5;
secret "jZOP5nh//i9t7BwHivvNzA==";
};
options {
default-key "rndc-key";
default-server 127.0.0.1;
default-port 953;
};
Add the named.conf section to the /etc/named.conf file. Be sure to remove the comment indentifiers
(#). The following is an example of a finished /etc/named.conf file:
sys12# cat /etc/named.conf
options
{
directory "/var/named";
};
// added to stop couldn't add command channel ::1#953 messages
// from showing up in /var/adm/messages
// following is output from /usr/sbin/rndc-confgen
key "rndc-key" {
algorithm hmac-md5;
secret "jZOP5nh//i9t7BwHivvNzA==";
};
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndc-key"; };
};
// end of rndc.key addition
...
Testing
Test the rndc.key by stopping and starting the named process, using the rndc utility, and examining the resulting /var/adm/messages file entries:
sys12# svcadm disable svc:/network/dns/server:default
sys12# svcadm enable svc:/network/dns/server:default
sys12# tail -4 /var/adm/messages
Jan 12 08:58:48 sys12 named[1402]: [ID 873579 daemon.notice] /
starting BIND 9.2.4
Jan 12 08:58:48 sys12 named[1402]: [ID 873579 daemon.notice] /
command channel listening on 127.0.0.1#953
Jan 12 08:58:48 sys12 named[1402]: [ID 873579 daemon.notice] running
The daemon starting without the command channel message implies a successful key configuration The rndc command can now be used securely.
You will see an error message similar to the following if either there is a problem with the
contents of the rndc.conf file:
sys12# rndc dumpdb
Jan 12 10:13:40 sys12 named[1431]: invalid command from 127.0.0.1#32839: bad auth
rndc: connection to remote host closed
This may indicate that the remote server is using an older version of the command protocol, this host is not authorized to connect, or the key is invalid.
sys12#
Server Status
The rndc utility can be used to query server status and report statistics.
Now test to verify that the rndc utility works as expected:
sys12# rndc status
number of zones: 5
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is ON
server is up and running
Flushing the Memory Cache
You can use the rndc utility to flush the memory cache.
sys12# rndc flush
sys12# rndc dumpdb
sys12# cat /var/named/named_dump.db
;
; Cache dump of view '_default'
;
$DATE 20050113141237
sys12#
Changing the Debug Level of the Daemon
Use the rndc utility to change the debug level of the server. Before making any changes, determine the current debug level of the daemon.
sys12# rndc status
number of zones: 5
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is ON
server is up and running
Increment the debug level by one.
sys12# rndc trace
sys12# rndc status
number of zones: 5
debug level: 1
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is ON
server is up and running
Assign the debug level to a specific level.
sys12# rndc trace 8
sys12# rndc status
number of zones: 5
debug level: 8
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is ON
server is up and running
sys12#
If logging is enabled, the debug level is shown along with the logged messages:
sys12# tail -f /var/named/bind-log
Jan 13 07:12:37.548 general: debug 1: received control channel command 'dumpdb'
Jan 13 07:17:02.598 general: debug 1: received control channel command 'status'
Jan 13 07:17:15.249 general: debug 1: received control channel command 'trace'
No hay comentarios:
Publicar un comentario