domingo, 25 de noviembre de 2012

Cambiar la Subnet Mask en VMware

 Para Versiones de GNU-Linux

En VMware Workstation 9 y anteriores el menú de configuración del editor de redes virtuales no permite cambiar la máscara de la red. 

Para resolver este problema hacemos lo siguiente:
 
Paramos la tarjetas virtuales:


   /usr/bin/vmware-networks --stop -v


Creamos una copia de ellas, por si acaso: 
 
       cp -p /etc/vmware/networking /etc/vmware/networking.backup

   cp -p /etc/vmware/vmnet{x}/dhcpd/dhcpd.conf 
   /etc/vmware/vmnet{x}/dhcpd/dhcpd.conf.old


 Donde {x} es la vmnet que queremos modificar.


   vim /etc/vmware/networking


Si nuestra vmnet nos proporciona IP por dhcp:


   
   vim /etc/vmware/vmnet{x}/dhcpd/dhcpd.conf



Iniciamos de nuevo las vmnets:


   /usr/bin/vmware-networks --start -v 


Comprobamos los cambios:


   /usr/bin/vmware-netcfg


domingo, 11 de noviembre de 2012

Montar un RAID 5 en Ubuntu 12.04

Montar un RAID 5 en Ubuntu 12.04

Montaje de un RAID 5 mediante (mdadm) por software.

Se realizará el proceso en una máquina Ubuntu 12.04 sobre una máquina virtual VMware workstation 9.

1.- Adición 4 discos virtuales de 1 GB cada uno.

2.- Creamos las particiones con fdisk:

fdisk /dev/sd(X)

Command (m for help): n
Partition type:
   p   primary (0 primary, 0 extended, 4 free)
   e   extended
Select (default p):
Using default response p
Partition number (1-4, default 1):
Using default value 1
First sector (2048-2097151, default 2048):
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-2097151, default 2097151):
Using default value 2097151

------------------------------------------------------------------------------------------------------------------

Command (m for help): t
Selected partition 1
Hex code (type L to list codes): l

Nos interesa esta línea: fd  Linux raid auto

Hex code (type L to list codes): fd
Changed system type of partition 1 to fd (Linux raid autodetect)

-------------------------------------------------------------------------------------------------------------------

Realizamos esta operación con el resto de discos.

Para crear un RAID 5 con tres discos, hacemos lo siguiente:

#mdadm --create /dev/md127 --l 5 --raid-devices=3 /dev/sd[XYZ]1

Una vez creado podemos ver su estado con esto:

       #mdadm --detail /dev/md127

-------------------------------------------------------------------------------------------------------------------

root@ubuntu:/home/daniel# mdadm --detail /dev/md127
/dev/md127:
        Version : 1.2
  Creation Time : Wed Nov  7 11:33:13 2012
     Raid Level : raid5
     Array Size : 2093056 (2044.34 MiB 2143.29 MB)
  Used Dev Size : 1046528 (1022.17 MiB 1071.64 MB)
   Raid Devices : 3
  Total Devices : 4
    Persistence : Superblock is persistent

    Update Time : Thu Nov  8 01:13:40 2012
          State : clean
 Active Devices : 3
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 1

         Layout : left-symmetric
     Chunk Size : 512K

           Name : ubuntu:0  (local to host ubuntu)
           UUID : 57a3f039:f2dad432:0ed3cdcf:f9b78cb6
         Events : 41

    Number   Major   Minor   RaidDevice State
       0       8       17        0      active sync   /dev/sdb1
       1       8       33        1      active sync   /dev/sdc1
       4       8       65        2      active sync   /dev/sde1


------------------------------------------------------------------------------------------------------------------

Con el parámetro "manage", podemos añadir o quitar discos al arreglo y dejarlo en espera de posibles fallos, pasando a estado activo cuando falle uno de ellos, o se haya eliminado del arreglo. Todo los procesos que se realizan con "manage" son en "caliente".

------------------------------------------------------------------------------------------------------------------


       mdadm --manage /dev/md127 --add /dev/sdd1

Number   Major   Minor   RaidDevice State
       0       8       17        0      active sync   /dev/sdb1
       1       8       33        1      active sync   /dev/sdc1
       4       8       65        2      active sync   /dev/sde1

       3       8       49        -      spare   /dev/sdd1

 


------------------------------------------------------------------------------------------------------------------

Supongamos que uno de los discos (sde) falla. De nuevo con el parámetro manage, lo marcamos como "fail":

       #mdadm --manage /dev/md127 --fail /dev/sde1

El fichero "mdstat" almacena el log de sucesos de los arreglos instalados en el sistema.

------------------------------------------------------------------------------------------------------------------



root@ubuntu:/home/daniel# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md127 : active raid5 sdd1[3] sdc1[1] sde1[4](F) sdb1[0]
      2093056 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
      [=============>.......]  recovery = 69.3% (726648/1046528) finish=0.2min speed=25056K/sec
 


Al tener un disco en spare, de manera automática el sistema lo añade al arreglo y reconstruye el RAID.

------------------------------------------------------------------------------------------------------------------


  Number   Major   Minor   RaidDevice State
       0       8       17        0      active sync   /dev/sdb1
       1       8       33        1      active sync   /dev/sdc1
       3       8       49        2      active sync   /dev/sdd1

       4       8       65        -      faulty spare   /dev/sde1





------------------------------------------------------------------------------------------------------------------

Eliminamos el disco marcado como faulty con:

        #mdadm --manage /dev/md127 --remove /dev/sde1

Esta es la ventaja de tener discos en "spare". En caso de no tener discos en espera, un RAID 5 de 3 discos, por su naturaleza, permite que en caso de avería o fallo de uno de ellos el RAID  siga en marcha. Por ejemplo:

------------------------------------------------------------------------------------------------------------------

        #mdadm --manage /dev/md127 --fail /dev/sdd1

Update Time : Thu Nov  8 23:55:25 2012
          State : clean, degraded
 Active Devices : 2
Working Devices : 2
 Failed Devices : 1
  Spare Devices : 0
 
 Number   Major   Minor   RaidDevice State
       0       8       17        0      active sync   /dev/sdb1
       1       8       33        1      active sync   /dev/sdc1
       2       0        0        2      removed

       3       8       49        -      faulty spare   /dev/sdd1

------------------------------------------------------------------------------------------------------------------

En este caso, vemos como "sde1" ha sido eliminado del arreglo y "sdd1" esta marcado como "fallo". Además, nos marcar el arreglo en estado "degradado".

Eliminamos pues el disco con fallo:
 
       #mdadm --manage /dev/md127 --remove /dev/sdd1


Cambiamos la unidad por una nueva y repetimos la operación de añadir partición y dar formato. Agregamos la nueva unidad:

       #mdadm --manage /dev/md127 --add /dev/sdd1 

------------------------------------------------------------------------------------------------------------------

Number   Major   Minor   RaidDevice State
       0       8       17        0      active sync   /dev/sdb1
       1       8       33        1      active sync   /dev/sdc1
       3       8       49        2      active sync   /dev/sdd1


------------------------------------------------------------------------------------------------------------------

Es importante almacenar la configuración, para ello utilizamos la siguiente expresión:

      
       #mdadm --detail --scan >> /etc/mdadm/mdadm.conf


Es posible detener un array, para ello solo debemos introducir el siguiente comando:

      #mdadm --stop /dev/md127

Esto no significa la pérdida del arreglo. Para volver a ensamblar las unidades al arreglo, utilizamos "--asemble".

      #mdadm --asemble /dev/md127 /dev/sd[bcd]1

Podemos añadir discos activos a nuestro arreglo de la siguiente manera:

           #mdadm --manage /dev/md127 --add /dev/sde1

Ahora podemos usar --grow para añadir un disco activo: 

      #mdadm --grow  --raid-devices=4 /dev/md127

 ------------------------------------------------------------------------------------------------------------------

 Update Time : Sun Nov 11 14:53:31 2012
          State : clean
 Active Devices : 4
Working Devices : 4

 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 512K

           Name : ubuntu:0  (local to host ubuntu)
           UUID : 57a3f039:f2dad432:0ed3cdcf:f9b78cb6
         Events : 103

    Number   Major   Minor   RaidDevice State
       0       8       17        0      active sync   /dev/sdb1
       1       8       33        1      active sync   /dev/sdc1
       3       8       49        2      active sync   /dev/sdd1
       4       8       65        3      active sync   /dev/sde1



------------------------------------------------------------------------------------------------------------------

* Es posible añadir o quitar unidades simplemente con:

mdadm --{add,remove} /dev/sd{x}y
 
Solo queda crear una partición con "fdisk".
 
       #fdisk /dev/md127
 
Y montar la partición o añadir una línea al fichero "fstab".

 
       #vim /etc/fstab 
  
 

martes, 6 de noviembre de 2012

Transferencias de zona seguras BIND9

Transferencias de zona seguras BIND9

TSIG - Transaction SIGnature.

BIND9 dispone de un mecanismo para asegurar las transmisiones de datos entre servidores. Este mecanismo firma la información enviada asegurando que el servidor maestro cifra la información mediante una clave compartida con el receptor, consiguiendo asegurar que la información no ha sido alterada por el camino.

Nos posicionamos en el servidor maestro.

Para ello generamos una clave con el comando dnnsec-keygen:

       dnssec-keygen -a HMAC-MD5 -b 256 -n HOST tsig.miempresa.com

Donde "-a" indica el algoritmo de encriptación y -b la "fortaleza" del mismo.

Nos genera los siguientes ficheros:

      Ktsig.miemrpesa.com.+157+42018.key
      Ktsig.miemrpesa.com.+157+42018.private

Editamos Ktsig.miemrpesa.com.+157+42018.private:

       cat Kclave-key.+157+21621.private 

        Private-key-format: v1.3
       Algorithm: 157 (HMAC_MD5)
       Key: qYqPgrdJoEiqrzangQDomQ3oW/VWYy/7mqbcCuTgJ3k=
       Bits: AAA=
       Created: 20121106210305
       Publish: 20121106210305
       Activate: 20121106210305

Editamos named.conf.options:

      vim named.conf.options

Fuera de "options" añadimos lo siguiente:

 key tsig.miempresa.com {

        algorithm hmac-md5;
        secret "Sp+HVFPou2ckGUlmJa4fuluEbrtI2TTEa7Ujet/PU30=";

};
server 192.168.1.5 {
        keys { tsig.miempresa.com };
};

Donde llamamos a la clave creada anteriormente y le indicamos que para el server esclavo (192.168.1.5) utilice la clave para hacer la transferencia.

Reiniciamos named:

        service bind9 restart

Hemos de editar el fichero named.conf.options en el servidor esclavo y añadir fuera de "options" lo siguiente:

key tsig.miempresa.com {

       algorithm hmac-md5;
       secret "Sp+HVFPou2ckGUlmJa4fuluEbrtI2TTEa7Ujet/PU30=";

};

 server 192.168.1.6 {
        keys { tsig.miempresa.com };
};

Indicando en este caso la IP del servidor maestro.

Reiniciamos el servidor maestro.

Posible error:


Este error se produce por no haber sincronización en las horas de los servidores. Si no tenemos el servicio NTP (Network Time Protocol) instalado, lo instalamos con:

       aptitude install ntp

Sincronizamos la hora con los servidores. (se pueden cambiar editando un fichero)

       ntpq -p  

Este paso lo repetimos en el server esclavo.

Comprobamos syslog en el servidor esclavo:


  Listo.










     

DNSSEC BIND9 2ª Parte

DNSSEC BIND9 2ª Parte

key-rolling.

Hasta ahora hemos creado las claves para "firmar"  nuestra zona directa, generando la "ksk", pudiéndose esta utilizar como una "true anchor" en servidores caché. El único inconveniente que podemos encontrar es el tiempo de vida que posee la clave, unos 30 días. Es posible a la hora de generar las claves con "zonesigner", utilizar el parámetro "-endtime", o si se deja por defecto, cambiar este valor inicial en el fichero "dnnsec-tools.conf.

Aquí se puede ver el tiempo de vida.



Para realizar el cambio de claves, o "key Rolling", utilizaremos el siguiente "daemon" que automatizará esto por nosotros: rollerd.

Primero nos dirigimos a  /etc/bind/
       cd  /etc/bind/

Como Super Usuario (sudo su, no nos sirve ejecutarlo como su)

      rollinit -zonefile db.miempresa.com.signed -keyrec miempresa.com.krf -admin           root@miempresa.com miempresa.com >> all.rollrec

rollinit nos guardará en "all.rollrec"  ( >> all.rollrec), los datos relativos a la zona (db.miempresa.com.signed), los datos del admin (miempresa.com.krf).

Con rollerd corremos el demonio en background.

       rollerd -rrfile all.rollrec -directory /etc/bind

Y listo.







viernes, 2 de noviembre de 2012

DNSSEC en BIND9

DNSSEC en BIND9


Configurar DNSSEC (Domain Name System Security Extensions) en BIND9.


Esta suite contiene especificaciones para proveer a los DNS de seguridad a través de protocolo IP. Autentifica los datos de un DNS y garantiza la integridad de los mismos. Está pensado para proteger a los "resolvers" contra ataques de tipo "dns cache spoofing" 

Para ello, instalamos en el servidor maestro lo siguiente:

       aptitude  install dnssec-tools libnet-dns-sec-perl libmailtools-perl libcrypt-openssl-random-perl

Editamos named.conf.options

       vim /etc/bind/named.options

 
E insertamos "dnssec-enable yes;", "dnssec-validation auto;" y "dnssec-lookaside auto;" dentro de options.


dnssec-lookaside. No todos los TLD están firmados (por ejemplo .to), es por ello que syslog puede mostrar el error "chain broken". Con esta opción, si tenemos un TLD sin firmar, podremos agregar nuestras claves (DLV) en https://div.isc.org.

En este caso, ".com." está firmado y tiene un registro DS en root.

En versiones anteriores de BIND9 9.7 y otras anteriores, hay que agregar las claves de root incluidas en "bind.keys" a "named.conf.options" o bien añadir la línea "include "/etc/bind/bind.keys" FUERA DE options. En el caso de la versión 9.8 con "dnssec-validation auto;" se incluyen automáticamente.

En caso de cambiar la ubicación de este fichero será necesaria la inclusión de esta línea.

Firmamos la zona con "zonesigner". El man de este comando contiene la información necesaria para firmar una zona. 

Una forma aceptada de firmar las zonas es:

       zonesigner -genkeys -usensec3 -zone miempresa.com db.miempresa.com

donde:

genkeys genera las claves "zsk" (zone signing key) y ksk (key signing key). zsk es usada para firmar la zona y ksk para conectar con el exterior.

nsec3 es, básicamente un método que controla que entre dos servicios dns no se encuentra otro servicio. Controlando la clave RRSIG se puede comprobar si entre dos servicios se ha "colado" algún registro falso.

Esto nos genera 3 pares de claves (pública/privada), 1 par ksk, y dos pares zsk , dos activas y dos pasivas.




También el fichero miepresa.com.krf que contiene los detalles para la administración de las claves generadas y el fichero dsset.miempresa.com que contiene los registros DS para la zona.

Podemos comprobar el estado de la zona firmada con el comando "donuts"

      donuts  --level 8 -v db.miempresa.com.signed miempresa.com


Este comando en su nivel 8 de registro de errores, nos mostrará 2: uno por solo tener una entrada NS en la zona y otro por no encontrar un registro de correo MX. Si ejecutamos donuts sin "--level" toma su valor por defecto 5 y no muestra errores.

Modificamos "named.conf.local" cambiamos el contenido de file para la zona "miempresa.com" con el fichero generado al firmar la zona:

      file "/etc/bind/db.miempresa.com.signed

reiniciamos BIND9


Modificamos el servidor secundario. Editamos named.conf.options y agregamos las mismas líneas como en el caso del servidor primario.

Editamos named.conf.local y como en el primario, agregamos a file el fichero "signed".

Eliminamos los ficheros generados en /var/cache/bind/

      rm -f /var/cache/bind/db.miempresa.com

Reiniciamos BIND9

Comprobamos que DNSSEC está operando bien.



root@server1:/etc/bind# dig +dnssec miempresa.com

; <<>> DiG 9.8.1-P1 <<>> +dnssec miempresa.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64141
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;miempresa.com.            IN    A

;; ANSWER SECTION:
miempresa.com.        604800    IN    A    192.168.1.6
miempresa.com.        604800    IN    RRSIG    A 8 2 604800 20121127065338 20121028065338 41670 miempresa.com. KmqkzrVT8lBJlvspF89FaID6f4hB9pMeOSHAo4nIg/mg8639PULdS1rW ss2oUHA4WZLr80yHIdcFX9GrK9j2SUDiQfF1UTOU2RnuWmVfvda/SdhO E36litQHVkODB4ggYkSrL9hSOzCYcgeEDKZj4uNcnfiB7C4aNQa74PlZ Neo=

;; AUTHORITY SECTION:
miempresa.com.        604800    IN    NS    server.miempresa.com.
miempresa.com.        604800    IN    RRSIG    NS 8 2 604800 20121127065338 20121028065338 41670 miempresa.com. ROgI4RDvyvOyVZqsUsAlUsWXMD2Bes4yrqt/5BGZz/BD/7BH6mkk/kg5 sWiHIWP45VoeK8sdLjjyBQhz52ZSWg5nHcmAc352oBcaS9UjqSafiu/d c3cif5xUpjGUul2ZmohIz8Eql0T7cVYoQcZRRtLdvSaE9l6w4UE9Cz0W jcM=

;; ADDITIONAL SECTION:
server.miempresa.com.    604800    IN    A    192.168.1.6
server.miempresa.com.    604800    IN    RRSIG    A 8 3 604800 20121127065338 20121028065338 41670 miempresa.com. vK6Exqikh5A2d6s/0Z/5zJY/P3GRCgQagoMLSJ2A83ztEk6blPPdktkc EtNmPxuGs7s9vJZJg4gHpa4AtlEh6RpyABVDWAECVLMLx+H2KThz2CsF hDhJeTCL2nCnbtUdOBp7VN8uSOw1+tJEbhMPsGLm+nAEPrfTgM9zhTlm mFA=

;; Query time: 5 msec
;; SERVER: 192.168.1.5#53(192.168.1.5)
;; WHEN: Fri Nov  2 18:54:36 2012
;; MSG SIZE  rcvd: 614

root@server1:/etc/bind#



 Ahora podemos subir las claves al repositorio DLV de isc.org y añadir los registros DS (dsset.miempresa.com) a la zona.
 



   








Instalación de servidor esclavo BIND9

Instalación de servidores dns BIND9 (2ª Parte)


Instalación de un servidor esclavo no autoritativo.


Para realizar esto solo debemos de situarnos en otra distro ubuntu 12.04 server que hayamos instalado para ello. Una vez actualizado el sistema e instalado BIND9, modificamos "dnssec-validation" a no de momento.

       cd /etc/bind/
       vim named.conf.options

options {
        directory "/var/cache/bind";

        // If there is a firewall between you and nameservers you want
        // to talk to, you may need to fix the firewall to allow multiple
        // ports to talk.  See http://www.kb.cert.org/vuls/id/800113

        // If your ISP provided one or more IP addresses for stable
        // nameservers, you probably want to use them as forwarders.
        // Uncomment the following block, and insert the addresses replacing
        // the all-0's placeholder.

        // forwarders {
        //      0.0.0.0;
        // };

        //========================================================================
        // If BIND logs error messages about the root key being expired,
        // you will need to update your keys.  See https://www.isc.org/bind-keys
        //========================================================================
        auth-nxdomain no;    # conform to RFC1035
        //listen-on-v6 { any; };
        dnssec-validation no;
        
};

Creamos las zonas, en este caso las dos  que creamos con anterioridad en el master de la siguiente manera:

//
// Do any local configuration here
//

// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";

zone "miempresa.com" {

        type slave;                                -> Debe ser de tipo slave

        file "db.miempresa.com";   -> Por defecto se guarda en /var/cache/bind

        masters { 192.168.1.6; };      -> Indica cuál o cuáles son los masters
};

zone "1.168.192.in-addr.arpa" {
        type slave;
        file "db.192";
        masters { 192.168.1.6; };
};

Reiniciamos BIND9 y listo.

Syslog debe devolver datos relativos a la primera transferencia de zonas. Si realizamos dig a nuestro dominio hemos de recibir lo siguiente:

root@server1:/etc/bind# dig miempresa.com

; <<>> DiG 9.8.1-P1 <<>> miempresa.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29364
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;miempresa.com.            IN    A

;; ANSWER SECTION:
miempresa.com.        604800    IN    A    192.168.1.6

;; AUTHORITY SECTION:
miempresa.com.        604800    IN    NS    server.miempresa.com.


;; ADDITIONAL SECTION:
server.miempresa.com.    604800    IN    A    192.168.1.6

;; Query time: 4 msec
;; SERVER: 192.168.1.5#53(192.168.1.5)
;; WHEN: Fri Nov  2 16:50:02 2012
;; MSG SIZE  rcvd: 84

root@server1:/etc/bind#

Donde el texto resaltado en naranja indica que la respuesta es AUTORIZADA por nuestro server master (192.168.1.6) y el texto resaltado en rojo muestra desde que servidor se ha realizado la petición dns; el servidor esclavo.

root@server1:/etc/bind# dig -x 192.168.1.6

; <<>> DiG 9.8.1-P1 <<>> -x 192.168.1.6
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38540
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;6.1.168.192.in-addr.arpa.    IN    PTR

;; ANSWER SECTION:
6.1.168.192.in-addr.arpa. 604800 IN    PTR    server.miempresa.com.

;; AUTHORITY SECTION:
1.168.192.in-addr.arpa.    604800    IN    NS    server.

;; Query time: 4 msec
;; SERVER: 192.168.1.5#53(192.168.1.5)
;; WHEN: Fri Nov  2 16:57:44 2012
;; MSG SIZE  rcvd: 96

root@server1:/etc/bind# 

Lo mismo para la zona inversa.



martes, 30 de octubre de 2012

Instalación de servidor primario BIND9 en una distribución Ubuntu server 12.04

Servidores DNS Ubuntu Server 12.04

Instalación y configuración de servidores DNS.

  • Server Primario o master. - Autorizado para la zona
  • Server secundario o slave. - No autorizado.
  • Servidor Caché.


A tener en cuenta:

hostname debe contener el nombre de la máquina: en este caso "server".

hosts debe contener ip_de_la_máquina  nombre_máquina.dominio   alias:


      192.168.1.6 (o 127.0.1.1)   server.miempresa.com         server




Instalación de servidor primario BIND9 en una distribución Ubuntu server 12.04



       ~$sudo aptitude install bind9 bind9utils

       ~$cd /etc/bind

Editamos named.conf.options. Cambiamos "dnssec-validation" a "no" de momento, para que syslog no nos dé la "lata".

options {
        directory "/var/cache/bind";

        // If there is a firewall between you and nameservers you want
        // to talk to, you may need to fix the firewall to allow multiple
        // ports to talk.  See http://www.kb.cert.org/vuls/id/800113

        // If your ISP provided one or more IP addresses for stable
        // nameservers, you probably want to use them as forwarders.
        // Uncomment the following block, and insert the addresses replacing
        // the all-0's placeholder.

        // forwarders {
        //      8.8.8.8;
        //      8.8.4.4;
        // };

        //======================================================================$
        // If BIND logs error messages about the root key being expired,
        // you will need to update your keys.  See https://www.isc.org/bind-keys
        //======================================================================$
        auth-nxdomain no;    # conform to RFC1035
        //listen-on-v6 { any; };
        dnssec-validation no;
        

};

Editamos "named.conf.local:

 //
// Do any local configuration here
//

// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";

zone "miempresa.com" {    -> El nombre de la zona directa.
        type master;
        file "/etc/bind/db.miempresa.com"; -> Zona directa.
        allow-transfer { 192.168.1.5; };   -> Esclavo permitido.
        also-notify { 192.168.1.5; };      -> Notificaciones.
};

zone "1.168.192.in-addr.arpa" {  -> El nombre de la zona inversa.
        type master;
        file "/etc/bind/db.192"; -> Zona inversa.
        allow-transfer { 192.168.1.5; };
        also-notify { 192.168.1.5; };
};


Creamos las zonas en el directorio:

        ~$cp db.local db.miempresa.com

       ~$cp db.127 db.192


Editamos db.miempresa.com


Ejemplo de zona directa:


;
; BIND data file for local miempresa.com interface
;
$TTL    604800
@       IN      SOA     miepresa.com. root.miempresa.com. (
                        2012102602      ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL

        IN      NS      server.miempresa.com.
;       IN      NS      server1.miempresa.com.


;hosts

@               IN      A       192.168.1.6
server          IN      A       192.168.1.6
server1         IN      A       192.168.1.5



Editamos db.192

Ejemplo de zona inversa:

;
; BIND reverse data file for local 192.168.1.xxx interface
;
$TTL    604800
@       IN      SOA     server.miempresa.com. root.miempresa.com. (
                        2012102607      ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL

;
        IN      NS      server.
;

6       IN      PTR     server.miempresa.com.
5       IN      PTR     server1.miempresa.com.




       ~$sudo service bind9 restart

Listo el servidor primario.