Fichero /etc/named.conf:

aorviz@taquimar:/etc/bind$ cat named.conf
// This is the primary configuration file for the BIND DNS server named.
//
// Please read /usr/share/doc/bind9/README.Debian.gz for information on the
// structure of BIND configuration files in Debian, *BEFORE* you customize
// this configuration file.
//
// If you are just adding zones, please do that in /etc/bind/named.conf.local

include "/etc/bind/named.conf.options";

// prime the server with knowledge of the root servers
zone "." {
        type hint;
        file "/etc/bind/db.root";
};

// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912

zone "localhost" {
        type master;
        file "/etc/bind/db.local";
};

zone "127.in-addr.arpa" {
        type master;
        file "/etc/bind/db.127";
};

zone "0.in-addr.arpa" {
        type master;
        file "/etc/bind/db.0";
};

zone "255.in-addr.arpa" {
        type master;
        file "/etc/bind/db.255";
};

// zone "com" { type delegation-only; };
// zone "net" { type delegation-only; };

// From the release notes:
//  Because many of our users are uncomfortable receiving undelegated answers
//  from root or top level domains, other than a few for whom that behaviour
//  has been trusted and expected for quite some length of time, we have now
//  introduced the "root-delegations-only" feature which applies delegation-only
//  logic to all top level domains, and to the root domain.  An exception list
//  should be specified, including "MUSEUM" and "DE", and any other top level
//  domains from whom undelegated responses are expected and trusted.
// root-delegation-only exclude { "DE"; "MUSEUM"; };

include "/etc/bind/named.conf.local";

Fichero named.conf.options:

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

        // If there is a firewall between you and nameservers you want
        // to talk to, you might need to uncomment the query-source
        // directive below.  Previous versions of BIND always asked
        // questions using port 53, but BIND 8.1 and later use an unprivileged
        // port by default.

        // query-source address * port 53;

        // 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;
        // };

        forwarders {
                172.16.0.10;
        };

        auth-nxdomain no;    # conform to RFC1035

};

Fichero 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 "sotrondio.cursolinux.ccoo" {
        type master;
        file "/etc/bind/db.sotrondio.cursolinux.ccoo";
};

Fichero /etc/dind/zones.rfc1918:

aorviz@taquimar:/etc/bind$ cat zones.rfc1918
zone "10.in-addr.arpa"      { type master; file "/etc/bind/db.empty"; };

zone "16.172.in-addr.arpa"  { type master; file "/etc/bind/db.empty"; };
zone "17.172.in-addr.arpa"  { type master; file "/etc/bind/db.empty"; };
zone "18.172.in-addr.arpa"  { type master; file "/etc/bind/db.empty"; };
zone "19.172.in-addr.arpa"  { type master; file "/etc/bind/db.empty"; };
zone "20.172.in-addr.arpa"  { type master; file "/etc/bind/db.empty"; };
zone "21.172.in-addr.arpa"  { type master; file "/etc/bind/db.empty"; };
zone "22.172.in-addr.arpa"  { type master; file "/etc/bind/db.empty"; };
zone "23.172.in-addr.arpa"  { type master; file "/etc/bind/db.empty"; };
zone "24.172.in-addr.arpa"  { type master; file "/etc/bind/db.empty"; };
zone "25.172.in-addr.arpa"  { type master; file "/etc/bind/db.empty"; };
zone "26.172.in-addr.arpa"  { type master; file "/etc/bind/db.empty"; };
zone "27.172.in-addr.arpa"  { type master; file "/etc/bind/db.empty"; };
zone "28.172.in-addr.arpa"  { type master; file "/etc/bind/db.empty"; };
zone "29.172.in-addr.arpa"  { type master; file "/etc/bind/db.empty"; };
zone "30.172.in-addr.arpa"  { type master; file "/etc/bind/db.empty"; };
zone "31.172.in-addr.arpa"  { type master; file "/etc/bind/db.empty"; };

zone "168.192.in-addr.arpa" { type master; file "/etc/bind/db.192.168"; };

Fichero db.sotrondio.cursolinux.ccoo:

aorviz@taquimar:/etc/bind$ cat db.sotrondio.cursolinux.ccoo
;
; BIND reverse data file for broadcast zone
;
$TTL    604800
@       IN      SOA     sotrondio.cursolinux.ccoo. aorviz.telecable.es. (
                      2005100401                ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
@       IN      NS      sotrondio.cursolinux.ccoo.

www     IN A    192.168.1.100

;
; BIND reverse data file for local loopback interface
;
$TTL    604800
@       IN      SOA     localhost. aorviz.telecable.es. (
                        2005100502      ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
@       IN      NS      localhost.
100.1   IN      PTR     sotrondio.cursolinux.ccoo.
101.1   IN      PTR     machine.cursolinux.ccoo.

Ejemplo de configuración de una zona, también con delegaciones:

$TTL    86400
$ORIGIN xyz.com.    ; If not specified, it's taken from named.conf

;  ns1 is a nameserver for the domain.  root is the
;  e-mail address of the owner of the domain.  The domain
;  is appended to each of these values since they don't
;  end with a period. (e.g. they become ns1.xyz.com
;  and root.xyz.com);
@           1D IN SOA ns1 root (
                            2002011901      ; serial
                            3H              ; refresh
                            15M             ; retry
                            1W              ; expire
                            1D )            ; minimum


; These two lines specify the same domain.
; @ means take it from the $ORIGIN or the zone
; specified in named.conf
@                        IN NS     ns1.xyz.com.
xyz.com.                 IN NS     ns2.xyz.com.

ns1                      IN A      192.168.1.20
ns2                      IN A      192.168.1.21

www                      IN A      192.168.1.22
kashyyyk                 IN CNAME  www
coruscant                IN CNAME  kashyyyk      # BAD IDEA!!

www1.xyz.com.            IN A      192.168.1.23
endor                    IN CNAME  www1

mail                     IN A      192.168.1.24
backup-mail              IN A      192.168.1.25

@                        IN MX 5   mail          # Both lines reference
xyz.com.                 IN MX 20  backup-mail   # the same domain

support.xyz.com.         IN NS     ns.support.xyz.com.     # Zone delegation
ns.support               IN A      192.168.2.20

development.xyz.com.     IN NS     ns.development.xyz.com. # Zone delegation
ns.development.xyz.com.  IN A      192.168.3.20

Dudas sobre la actualización dinámica

Durante las pruebas de laboratorio apareció la figura de la
actualización dinámica de registros en el DNS. Actualmente, muchas
conexiones a Internet tienen direccionamiento dinámico que va cambiando
con el tiempo. Existen empresas que facilitan un software a sus
clientes para que al conectarse a Internet, conctacten con el servidor
DNS de su empresa y actualicen su registro tipo A contrado.

¿Qué ocurre con otros registros importantes como puede ser el NS que define el servidor autoritativo para la zona?

Los documentos en los que se basa el estandar para estas actualizaciones indican que no debería  permitirse
a los usuarios normales actualizar este tipo de registros. Lo cual no
implica que ciertas empresas lo permitan con el fin de ofrecer
servicios avanzados a sus clientes.

El RFC se puede encontrar en http://www.faqs.org/rfcs/rfc3007.html y dice:

3.1.1 - User types

   User types include all data types except SOA, NS, SIG, and NXT.  SOA
   and NS records SHOULD NOT be modified by normal users, since these
   types create or modify delegation points.  The addition of SIG
   records can lead to attacks resulting in additional workload for
   resolvers, and the deletion of SIG records could lead to extra work
   for the server if the zone SIG was deleted.  Note that these records
   are not forbidden, but not recommended for normal users.

   NXT records MUST NOT be created, modified, or deleted by dynamic
   update, as their update may cause instability in the protocol.  This
   is an update to RFC 2136.