DHCP ahorra mucho trabajo en la configuración de las estaciones de trabajo, ya que permite administrar la configuración de la red desde el servidor. Esta configuración actualiza el DNS (que debe estar configurado al efecto) con los datos de la estación de trabajo que solicitó una lease; asimismo, configura el navegador de la estación de trabajo con la información para el proxy:

# Sample configuration file for ISC dhcpd for Debian
#
# $Id: dhcpd.conf,v 1.1.1.1 2002/05/21 00:07:44 peloy Exp $
#

# The ddns-updates-style parameter controls whether or not the server will
# attempt to do a DNS update when a lease is confirmed. We default to the
# behavior of the version 2 packages ('none', since DHCP v2 didn't
# have support for DDNS.)
# ddns-update-style none;
   

# option definitions common to all supported networks...
   option domain-name "lordbasex.com.ar";
   ddns-update-style interim;
   option domain-name-servers dns.lordbasex.com.ar;
   option subnet-mask 255.255.255.0;
   option broadcast-address 192.168.10.255;
   option ntp-servers time.lordbasex.com.ar;
   option routers srv1.lordbasex.com.ar;
   option netbios-name-servers samba.lordbasex.com.ar;
   option wpad code 252 = text;
   option wpad "http://wpad.lordbasex.com.ar/wpad.dat\n"; 

   subnet 192.168.10.0 netmask 255.255.255.0 {
   range 192.168.10.2 192.168.10.10;
   } 
   
   default-lease-time 600;
   max-lease-time 7200;


# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
#authoritative;

# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
  log-facility local7;

# No service will be given on this subnet, but declaring it helps the 
# DHCP server to understand the network topology.

#subnet 10.152.187.0 netmask 255.255.255.0 {
#}

# This is a very basic subnet declaration.

#subnet 10.254.239.0 netmask 255.255.255.224 {
#  range 10.254.239.10 10.254.239.20;
#  option routers rtr-239-0-1.example.org, rtr-239-0-2.example.org;
#}

# This declaration allows BOOTP clients to get dynamic addresses,
# which we don't really recommend.

#subnet 10.254.239.32 netmask 255.255.255.224 {
#  range dynamic-bootp 10.254.239.40 10.254.239.60;
#  option broadcast-address 10.254.239.31;
#  option routers rtr-239-32-1.example.org;
#}

# A slightly different configuration for an internal subnet.
#subnet 10.5.5.0 netmask 255.255.255.224 {
#  range 10.5.5.26 10.5.5.30;
#  option domain-name-servers ns1.internal.example.org;
#  option domain-name "internal.example.org";
#  option routers 10.5.5.1;
#  option broadcast-address 10.5.5.31;
#  default-lease-time 600;
#  max-lease-time 7200;
#}

# Hosts which require special configuration options can be listed in
# host statements.   If no address is specified, the address will be
# allocated dynamically (if possible), but the host-specific information
# will still come from the host declaration.

#host passacaglia {
#  hardware ethernet 0:0:c0:5d:bd:95;
#  filename "vmunix.passacaglia";
#  server-name "toccata.fugue.com";
#}

# Fixed IP addresses can also be specified for hosts.   These addresses
# should not also be listed as being available for dynamic assignment.
# Hosts for which fixed IP addresses have been specified can boot using
# BOOTP or DHCP.   Hosts for which no fixed address is specified can only
# be booted with DHCP, unless there is an address range on the subnet
# to which a BOOTP client is connected which has the dynamic-bootp flag
# set.
#host fantasia {
#  hardware ethernet 08:00:07:26:c0:a5;
#  fixed-address fantasia.fugue.com;
#}

# You can declare a class of clients and then do address allocation
# based on that.   The example below shows a case where all clients
# in a certain class get addresses on the 10.17.224/24 subnet, and all
# other clients get addresses on the 10.0.29/24 subnet.

#class "foo" {
#  match if substring (option vendor-class-identifier, 0, 4) = "SUNW";
#}

#shared-network 224-29 {
#  subnet 10.17.224.0 netmask 255.255.255.0 {
#    option routers rtr-224.example.org;
#  }
#  subnet 10.0.29.0 netmask 255.255.255.0 {
#    option routers rtr-29.example.org;
#  }
#  pool {
#    allow members of "foo";
#    range 10.17.224.10 10.17.224.250;
#  }
#  pool {
#    deny members of "foo";
#    range 10.0.29.10 10.0.29.230;
#  }
#}
   
  group {
  use-host-decl-names on;
  authoritative;
  ddns-updates on;
  }
				
# Configuración de una estación de trabajo
# con IP fija

host esta01 {
    hardware ethernet 00:d0:59:c6:b5:af;
    fixed-address esta02;
}

host esta02 {
hardware ethernet 00:0C:29:4D:17:FA ;
fixed-address esta01;
}

Nota: esta configuración crea un DDNS (Dynamic DNS). Para que el DHCP pueda actualizar el DNS, el directorio de configuración del DNS debe tener el mismo usuario con el que se ejecuta su proceso. Por ejemplo, en Debian, el usuario es “bind”, entonces ejecutar “chown -R bind: /etc/bind”.

Para que la configuración automática de proxy funcione en las estaciones de trabajo, se debe realizar lo siguiente:

1. Configurar un servidor web (como Apache)
2. Poner en la raíz del servidor el proxy.pac, y un hard link a él llamado wpad.dat. Se puede ver un ejemplo de proxy.pac en este lugar.
3. Configurar el DNS con un host llamado “wpad”, para que Mozilla Firefox no tenga problemas para encontrar el proxy.pac

Nota: esta tarea debe hacerse más o menos rápido, para evitar que las estaciones que están pidiendo una IP se queden sin configuración de red y por lo tanto sin conexión.

1. Detener el demonio DHCP
2. Agregar la declaración del host en dhcpd.conf:

   host esta14 {
       hardware ethernet 00:1A:4D:25:3B:34;
       fixed-address esta14;
   }
   

3. Bind: los cambios en Bind que figuran a continuación deben hacerse sin errores, ya que en caso contrario la intranet se queda sin DNS y por lo tanto sin ningún servicio.
4. Borrar los archivos de journaling:

   rm /etc/bind/*.jnl
   

5. Editar los archivos de resolución forward y reverse, eliminando en ambos la IP dinámica asignada, incluyendo el registro TXT que se encuentra inmediatamente debajo del registro A
6. Agregar en el archivo de resolución forward el registro A de la IP fija correspondiente al host:

   esta14                  A       192.168.10.74
   

7. Agregar en el archivo de resolución inversa el registro PTR de la IP fija correspondiente al host:

   74                      PTR     esta14.dominio.
   

8. Reiniciar el servicio Bind
9. Reiniciar el servicio DHCP
10. Controlar que la estación de trabajo tome la nueva IP sin problemas