Xunta de Galicia


Powered by MediaWiki

Servidor de nomes (Bind)

Servidor de nomes (BIND)

Licenza

O servidor de nomes BIND distribúese baixo os termos da Berkeley Software Distribution License.

Resumo sobre a comunidade de desenvolvemento

Trátase dun dos moitos casos de servizos troncais para a infraestrutura de Internet, que están presentes dende case os seus comezos. Neste caso, podemos atopar a primeira versión de Bind alá polos primeiros anos 80 do século pasado. Pódese atopar unha historia completa na páxina da ISC (Consorcio de Sistemas de Internet). A día de hoxe estase traballando coa versión 9.

Inicialmente foi un desenvolvemento financiado pola DARPA (Axencia de Proxectos de Investigación de Defensa Avanzada). A versión 9 foi unha reescritura completa do código, para facer fronte a moitos problemas de seguridade que presentaba, é do ano 2000. A día de hoxe o financiamento do seu desenvolvemento está en mans da ISC, con axuda das máis grandes empresas de tecnoloxía. Para facérmonos unha idea da magnitude e importancia do traballo de Bind na Internet, abonda apuntar que o 70% dos servidores DNS da Rede son Bind.

Conceptos básicos de DNS

Domain Name Service, ou Servizo de Nomes de Dominio. Dende os comezos de Internet os computadores tiveron nomes, e tiveron enderezos numéricos. Os nomes para emprego dos seres humanos, máis dados a empregar palabras, e os números para as máquinas. Cando as redes eran pequenas, e as listas de equivalencias entre número e palabra eran relativamente pequenas, era traballo do equipo administrador mantelas no arquivo /etc/hosts de cada máquina. Se unha persoa usuaria quería acceder a un servizo situado nunha máquina remota empregando o seu nome, o sistema local tiña que ter a tradución nese arquivo. Hoxe en día aínda temos ese arquivo como fonte primeira para atopar o enderezo IP que corresponde a un nome.

Pero segundo foi crecendo Internet, aínda moito antes da gran explosión dos 90, fíxose preciso un sistema centralizado, unha base de datos de consulta xeral e coordinada, que contivese todas as equivalencias existentes. Foi así como xurdiu o servizo DNS, e o servidor Bind.

Instalación do servidor BIND

O nome do paquete que temos que instalar é “bind9”. Instalámolo dende a liña de ordes con apt-get, ou dende o escritorio co Synaptic. Despois da instalación podemos verificar que o servizo esta activo empregando nmap:

# nmap localhost  
Starting Nmap 4.53 ( http://insecure.org ) at 2008-08-30 10:28 UTC 
Interesting ports on localhost (127.0.0.1): 
Not shown: 1708 closed ports 
PORT STATE SERVICE 
53/tcp open domain 
  
Nmap done: 1 IP address (1 host up) scanned in 0.289 seconds 

Tamén é interesante instalar o paquete dnsutils, que contén ferramentas de consulta e diagnose.

Configuración básica de BIND

Os arquivos de configuración de Bind atópanse en /etc/bind/. O principal deles é named.conf. Imos facer unha configuración sinxela de Bind que se encargue de responder as peticións DNS dunha rede local, para optimizar o tráfico da Internet e obter resposta máis rápida e faga caché desta información; e despois ímoslle engadir un dominio real.

Dentro dos arquivos de configuración que definen as zonas (conxuntos de rexistros relativos a máquinas e enderezos en particular), os rexistros poden ser de moitos tipos:

  • Enderezo (A). Son os máis empregados. Xuntan un nome cun enderezo IP.
www IN A 1.2.3.4
  • Alias (CNAME). Serven para crear un alias doutro nome.
mail IN CNAME www
www IN A 1.2.3.4
  • Correo (MX). Indican a onde hai que mandar o correo para o dominio.
IN MX mail.example.com.

[...]

mail IN A 1.2.3.4
  • Servidor de Nomes (NS). Apunta ao enderezo IP do servidor onde esta o Bind que coñece a información toda do dominio.
IN NS ns.example.com.

[...]

ns IN A 1.2.3.4

Para o primeiro exemplo, un servidor de DNS con almacenamento intermedio para as máquinas da rede local só temos que facer un pequeno cambio no arquivo named.conf.options. Consiste en engadir despois da liña “forwarders” as direccións IP dos servidores DNS do noso ISP:

[...]

forwarders {
1.2.3.4;
5.6.7.8;
};
[...]

Feito o cal, só temos que reiniciar o Bind (invoke-rc.d bind9 restart) e facer algunhas probas:

dig -x 127.0.0.1

e obteremos unha resposta semellante a:

; <<>> DiG 9.4.2-P1 <<>> -x 127.0.0.1 
;; global options: printcmd 
;; Got answer: 
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 32217 
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 

;; QUESTION SECTION: 
;1.0.0.127.in-addr.arpa.INPTR 

;; AUTHORITY SECTION: 
127.in-addr.arpa.86400INSOA127.in-addr.arpa. . 0 28800 7200 604800 86400 

;; Query time: 14 msec 
;; SERVER: 212.51.32.254#53(212.51.32.254) 
;; WHEN: Sat Aug 30 15:27:44 2008 
;; MSG SIZE rcvd: 75 


Tamén podemos pedir información sobre dominios na Internet, como por exemplo:

dig mancomun.org


e obteremos:

; <<>> DiG 9.4.2-P1 <<>> mancomun.org 
;; global options: printcmd
;; Got answer: 
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31799 
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 1 

;; QUESTION SECTION: 
;mancomun.org.INA 

;; ANSWER SECTION: 
mancomun.org.286INA91.117.125.12 

;; AUTHORITY SECTION: 
mancomun.org.286INNSns3.cesga.es. 
mancomun.org.286INNSns2.cesga.es. 
mancomun.org.286INNSns1.cesga.es. 

;; ADDITIONAL SECTION: 
ns3.cesga.es.22INA193.144.34.209 

;; Query time: 89 msec 
;; SERVER: 212.51.32.254#53(212.51.32.254) 
;; WHEN: Sat Aug 30 15:28:27 2008 
;; MSG SIZE rcvd: 124 

Se repetimos a operación, veremos que o “Query time” descende de forma considerábel, debido ao traballo que está a facer o noso servidor DNS, que almacena a información localmente e reduce o tempo de espera.

Xa temos, pois, o noso servidor cache de DNS para a rede local. Os PCs da nosa rede local deberán cambiar na súa configuración de rede o enderezo dos servidores DNS, e poñer a IP do servidor no que temos o Bind. Nos GNU/Linux esta configuración aparece no arquivo /etc/resolv.conf.

O seguinte paso será engadirlle a este mesmo Bind a información precisa para responder ante Internet dun dominio real. Para exemplificar esta configuración, é preciso contar cun nome de dominio efectivo e real, e como mínimo un enderezo IP visíbel dende a Internet. No exemplo seguinte imos empregar como IP 65.99.199.155, e como nome de dominio, capacitacion.com.

O primeiro que temos que facer é engadir referencia ao noso dominio no named.conf. Engadimos unhas liñas como as seguintes ao final:

zone "capacitacion.com" {
type master;
file "/etc/bind/db.capacitacion.com";
};

E, como vemos, teremos que crear un arquivo novo chamado db.capacitacion.com. Tomamos como modelo un dos xa existentes:

cp /etc/bind/db.local /etc/bind/db.capacitacion.com

Procedemos a facer cambios nel. Cambiamos localhost polo nome do noso dominio, mantendo o punto final, e en lugar de 127.0.0.1 empregamos a nosa IP. Engadimos un rexistro de tipo A para o servidor DNS. Tamén temos que cambiar o campo “Serial”, incrementándoo. O arquivo debe quedar como o seguinte:

; 
; BIND data file for capacitacion.com 
; 
$TTL 604800 
@ IN SOA ns.capacitacion.com. root.capacitacion.com. ( 
3 ; Serial 
604800 ; Refresh 
86400 ; Retry 
2419200 ; Expire 
604800 ) ; Negative Cache TTL 
; 
@ IN NS ns.capacitacion.com. 
@ IN A 65.99.199.155
ns IN A 65.99.199.155

Feitos os cambios, xa podemos reiniciar o Bind e facer probas. Un “ping capacitacion.com” deberá mostrar unha resposta como:

PING capacitacion.com (65.99.199.155) 56(84) bytes of data.

O que indica que a tradución de nome a números esta ben feita, e que a fixo o noso servidor.

Unha vez tendo a resolución directa (de nome a número), precisamos da resolución inversa (de número a nome). A importancia da resolución inversa é moi grande, pois serve entre outras cousas para a comprobación dos destinos de correo no tráfico SMTP, e moitos outros aplicativos fan emprego dela para asegurar a orixe das comunicacións.

Para configurar a resolución inversa do noso dominio, engadimos unha zona ao ficheiro named.conf.local:

zone "199.99.65.in-addr.arpa" { 
type master; 
notify no; 
file "/etc/bind/db.65"; 
}; 

Como vemos os catro bytes do enderezo IP ordénanse en sentido contrario. Facemos unha copia do db.127, para empregar como modelo, e chamámoslle db.65, polo primeiro byte do noso enderezo. Facemos nel os seguintes cambios para que concorde cos nosos datos:

; 
; BIND reverse data file for capacitacion.com 
; 
$TTL 604800 
@ IN SOA ns.capacitacion.com. root.capacitacion.com. ( 
2 ; Serial 
604800 ; Refresh 
86400 ; Retry 
2419200 ; Expire 
604800 ) ; Negative Cache TTL 
;
@ IN NS ns. 
155.199.99 IN PTR ns.capacitacion.com. 

É interesante, por dar estabilidade ao conxunto e facer fronte a posíbeis problemas de dispoñibilidade do servidor, ter un servidor de DNS secundario, que responde as peticións cando o primeiro non está accesíbel. Para que os dous servidores estean coordinados hailles que facilitar os enderezos IP mutuos. Imaxinemos que o enderezo IP do noso servidor DNS secundario fora 91.117.125.13. No servidor principal temos que engadir unha liña nas definicións das zonas directa e inversa, dentro do named.conf.local:

allow-transfer { @91.117.125.13; };

No servidor secundario facemos unha instalación de bind9 semellante á do principal, pero no named.conf.local a declaración das zonas será:

[...]
zone "capacitacion.com" {
type slave;
file "/etc/bind/db.capacitacion.com";
masters { 91.117.125.12; };
}; 
[...]
zone "199.99.65.in-addr.arpa"; {
type slave;
file "/etc/bind/db.65";
masters { 91.117.125.12; };
};
[...]

Ao reiniciar o servizo no servidor secundario, producirase a transferencia de información dende o principal. Unha boa forma de verificar o funcionamento do servidor DNS secundario é parar o servizo do principal e ver se o outro aínda é quen de responder.

Máis alá desta breve introdución, o servizo DNS ten moitas e moi variadas posibilidades. Entre os textos de referencia que é recomendábel ter a man atópase o Manual de Referencia do Administrador de BIND9, e para aclarar ideas sobre o servizo DNS, o DNS-Howto.


Licenza desta guía

Esta guía forma parte da documentación de apoio para a capacitación TIC en SwL e foi elaborada pola empresa TEGNIX para o Centro de Referencia e Servizos de Software Libre de Galiza – Mancomún. Distribúese baixo as condicións dunha Licenza Creative Commons: Recoñecemento-CompartirIgual 3.0