sun.com docs.sun.com My Sun Worldwide Sites

Previous Previous     Contents     Index     Next Next

ProcedureHow to Enable and Disable DHCP Transaction Logging (DHCP Manager)

This procedure enables and disables transaction logging for all subsequent DHCP server sessions.

  1. In DHCP Manager, choose Modify from the Service menu.

    See How to Start and Stop DHCP Manager for information about DHCP Manager.

  2. Select Log Transactions to Syslog Facility.

    To disable transaction logging, deselect this option.

  3. (Optional) Select a local facility from 0 to 7 to use for logging DHCP transactions.

    By default, DHCP transactions are logged to the location where system notices are logged, which depends on how syslogd is configured. If you want the DHCP transactions to be logged to a file separate from other system notices, see How to Log DHCP Transactions to a Separate syslog File.

    Message files can quickly become very large when transaction logging is enabled.

  4. Select Restart Server.

  5. Click OK.

    The daemon logs transactions to the selected syslog facility for this session and each subsequent session until you disable logging.

ProcedureHow to Enable and Disable DHCP Transaction Logging (Command Line)

  1. Become superuser or assume a role or user name that is assigned to the DHCP Management profile.

    For more information about the DHCP Management profile, see Setting Up User Access to DHCP Commands.

    Roles contain authorizations and privileged commands. For more information about roles, see "Configuring RBAC (Task Map)" in System Administration Guide: Security Services.

  2. Choose one of the following steps:

    • To enable DHCP transaction logging, type the following command:

      # /usr/sbin/dhcpconfig -P LOGGING_FACILITY=syslog-local-facility

      syslog-local-facility is a number from 0 through 7. If you omit this option, 0 is used.

      By default, DHCP transactions are logged to the location where system notices are logged, which depends on how syslogd is configured. If you want the DHCP transactions to be logged to a file separate from other system notices, see How to Log DHCP Transactions to a Separate syslog File.

      Message files can quickly become very large when transaction logging is enabled.

    • To disable DHCP transaction logging, type the following command:

      # /usr/sbin/dhcpconfig -P LOGGING_FACILITY=

      Note that you supply no value for the parameter.

ProcedureHow to Log DHCP Transactions to a Separate syslog File

  1. Become superuser or assume an equivalent role on the DHCP server system.

    Roles contain authorizations and privileged commands. For more information about roles, see "Configuring RBAC (Task Map)" in System Administration Guide: Security Services.

    A role that is assigned to the DHCP Management profile might not be sufficient for this task. The role must have permission to edit syslog files.

  2. Edit the /etc/syslog.conf file on the server system to add a line of the following format:

    localn.notice     path-to-logfile

    n is the syslog facility number you specified for transaction logging, and path-to-logfile is the complete path to the file to use for logging transactions.

    For example, you might add the following line:

    local0.notice /var/log/dhcpsrvc

    See the syslog.conf(4) man page for more information about the syslog.conf file.

Enabling Dynamic DNS Updates by a DHCP Server

DNS provides name-to-address and address-to-name services for the Internet. Once a DNS mapping is made, a system can be reached through its host name or its IP address. The system is also reachable from outside its domain.

The DHCP service can use DNS in two ways:

  • The DHCP server can look up the host name that is mapped to an IP address that the server is assigning to the client. The server then returns the client's host name along with the client's other configuration information.

  • The DHCP server can attempt to make a DNS mapping on a client's behalf, if the DHCP server is configured to update DNS. The client can supply its own host name when requesting DHCP service. If configured to make DNS updates, the DHCP server attempts to update DNS with the client's suggested host name. If the DNS update is successful, the DHCP server returns the requested host name to the client. If the DNS update is not successful, the DHCP server returns a different host name to the client.

You can enable the DHCP service to update the DNS service for DHCP clients that supply their own host names. For the DNS update feature to work, the DNS server, the DHCP server, and the DHCP client must be set up correctly. In addition, the requested host name must not be in use by another system in the domain.

The DHCP server's DNS update feature works if the following statements are true:

  • The DNS server supports RFC 2136.

  • The DNS software is based on BIND v8.2.2, patch level 5 or later, whether on the DHCP server system or the DNS server system.

  • The DNS server is configured to accept dynamic DNS updates from the DHCP server.

  • The DHCP server is configured to make dynamic DNS updates.

  • DNS support is configured for the DHCP client's network on the DHCP server.

  • The DHCP client is configured to supply a requested host name in its DHCP request message.

  • The requested host name corresponds to a DHCP-owned address. The host name could also have no corresponding address.

ProcedureHow to Enable Dynamic DNS Updating for DHCP Clients


Note - Be aware that dynamic DNS updates are a security risk.

By default, the Solaris DNS daemon (in.named) does not allow dynamic updates. Authorization for dynamic DNS updates is granted in the named.conf configuration file on the DNS server system. No other security is provided. You must carefully weigh the convenience of this facility for users against the security risk created when you enable dynamic DNS updates.


  1. On the DNS server, edit the /etc/named.conf file as superuser.

  2. Find the zone section for the appropriate domain in the named.conf file.

  3. Add the DHCP server's IP addresses to the allow-update keyword.

    If the allow-update keyword does not exist, insert the keyword.

    For example, if the DHCP server resides at addresses 10.0.0.1 and 10.0.0.2, a named.conf file for the dhcp.domain.com zone should be modified as follows:

    zone "dhcp.domain.com" in {
                 type master;
                 file "db.dhcp";
                 allow-update { 10.0.0.1; 10.0.0.2; }; 
    };  
     
    zone "10.IN-ADDR.ARPA" in {
                 type master;
                 file "db.10"; 
                 allow-update { 10.0.0.1; 10.0.0.2; };
    }; 

    Note that allow-update for both zones must be enabled to allow the DHCP server to update both A and PTR records on the DNS server.

  4. On the DHCP server, start DHCP Manager.

    # /usr/sadm/admin/bin/dhcpmgr &

    See How to Start and Stop DHCP Manager for more detailed information.

  5. Choose Modify from the Service menu.

    The Modify Service Options dialog box opens.

  6. Select Update DNS Host Information Upon Client Request.

  7. Specify the number of seconds to wait for a response from the DNS server before timing out, then click OK.

    The default value of 15 seconds should be adequate. If you have time out problems, you can increase the value later.

  8. Click the Macros tab, and ensure that the correct DNS domain is specified.

    The DNSdmain option must be passed with the correct domain name to any client that expects dynamic DNS update support. By default, DNSdmain is specified in the server macro, which is used as the configuration macro bound to each IP address.

  9. Set up the DHCP client to specify its host name when requesting DHCP service.

    If you use the Solaris DHCP client, see How to Enable a Solaris Client to Request a Specific Host Name. If your client is not a Solaris DHCP client, see the documentation for your DHCP client for information about how to specify a host name.

Previous Previous     Contents     Index     Next Next
Company Info Contact Terms of Use Privacy Copyright 1994-2007 Sun Microsystems, Inc.