Instal·lació i administració de serveis de noms de domini

El sistema de noms de domini o DNS (Domain Name System) proporciona un mecanisme eficaç per fer la resolució de noms de domini a adreces IP. Com a usuaris (humans) ens és més fàcil adreçar-nos a un nom de domini (de host, de web, de servidor de correu…) utilitzant un text identificatiu com per exemple www.ioc.cat que no pas l’adreça IP 213.73.40.230. El servei DNS no solament permet fer la resolució de noms de domini a adreces IP, sinó també la resolució inversa. És a dir, a partir d’una adreça IP esbrinar el nom de domini del host.

El servei DNS proporciona independència del nom de domini respecte a l’adreça IP. Així un domini pot canviar d’adreça IP de manera transparent per als usuaris del domini. Fins i tot és usual que un domini s’identifiqui amb més d’una adreça IP com a mesura de redundància contra la caiguda del sistema o com a balanceig de càrregues. Altres serveis proporcionats pel DNS són la identificació dels servidors de correu d’un domini, de cada un dels hosts que pertanyen a la xarxa, servidors d’impressió…

El servei de resolució de noms

El problema d’identificar els equips es produeix des de bon principi de l’existència de les xarxes d’ordinadors i no és específic de les xarxes TCP/IP. Cal un mecanisme en “llenguatge humà” per identificar els equips de la xarxa. En especial els que proporcionen serveis als altres equips i usuaris. En la xarxa inicial Arpanet, els equips ja rebien un nom. Aquests noms es feien públics per mitjà d’un fitxer centralitzat que contenia els noms de tots els equips de la xarxa i la seva identificació. Aquest fitxer era hosts.txt, conegut en sistemes GNU/Linux com a /etc/hosts.

Un sistema de noms pla es basa en la utilització d’un fitxer de text que descriu cada host amb la seva corresponent adreça IP. Es pot usar per definir àlies per equips locals en xarxes petites, però no és escalable a xarxes grans, i molt menys a Internet.

En una xarxa petita es pot generar un fitxer amb el nom i l’adreça IP de tots els hosts centralitzat en un servidor, i encarregar-se de distribuir còpies d’aquest fitxer a tots els equips de la xarxa. Però aquest model de coneixement no és escalable. Si la xarxa creix és impossible de mantenir. Utilitzar aquest model significaria que hi ha un equip que centralitza els noms de tots els hosts d’Internet en un sol fitxer! D’altra banda, també significaria que aquest fitxer s’ha de repartir entre tots els equips d’Internet perquè sàpiguen com es diuen els altres equips cada cop que hi ha una actualització. Evidentment cal una altra solució.

Problemes d'actualització d'una xarxa

Imagineu els problemes que es presenten en voler fer arribar un mateix fitxer a tots els hosts. Hi haurà inconsistències entre els equips que han rebut l’actualització i els que no. El procés de copiar el fitxer en cada equip és molt laboriós/feixuc. Un nou equip a Internet vol dir escriure de nou el fitxer i tornar-lo enviar a tothom!

El 1983 sorgeix el Domain Name System (DNS) per aportar una solució escalable i pràctica. El DNS es fonamenta en una base de dades de noms de domini jeràrquica i distribuïda. És jeràrquica perquè s’organitza en una estructura de dominis que es poden compondre de subdominis que també es poden dividir en subdominis i així fins a 127 nivells (originàriament). Aquests dominis són gestionats per servidors DNS responsables de cada zona. I és una base de dades distribuïda perquè la informació no està tota junta en un sol repositori central, sinó que es troba repartida per parts en els servidors DNS d’Internet. Cada servidor DNS autoritari conté la base de dades de la seva zona.

Classificació dels mecanismes de resolució

Els administradors de xarxes tenen la tasca d’establir el mecanisme d’identificació de hosts que volen usar. Determinar quins noms usaran i com es farà per identificar cada nom amb l’adreça IP corresponent. Els mecanismes per anomenar els hosts pot ser local a cada host, local i intern a una organització i global a Internet.

Un cop posats els noms cal saber-los resoldre, trobar-ne l’adreça IP apropiada. La resolució pot ser local en un host usant un fitxer d’associacions o implementada usant el servei de noms DNS. Aquest servei es basa en l’estructura client/servidor, de manera que caldrà aprendre a configurar tant l’un com l’altre. Primerament es descriurà com configurar el client o resolver i el servidor serà tractat al llarg dels apartats posteriors. Aquests dos mecanismes, local i DNS, es poden combinar i determinar-ne la precedència.

El servei DNS proporciona múltiples maneres de treballar. Segons quina sigui la seva configuració actuarà de manera diferent en fer la resolució. Caldrà estudiar què és un servidor només cau, què fa quan es permet la utilització de la memòria cau, la utilització d’un forwarder i quina diferència hi ha entre usar recursió o no utilitzar-la. La gestió de dominis i zones pròpies, la creació de subdominis i la delegació són aspectes clau del funcionament d’un servidor de noms de domini que també es tractaran més endavant.

Noms de 'host' locals, dominis locals i dominis d'Internet

Sabem que els hosts s’identifiquen en una xarxa i a Internet per la seva adreça IP, però en general els usuaris desconeixen quina és aquesta adreça. Els usuaris estan habituats a connectar-se per exemple a un altre dels ordinadors de casa seva posant un nom local que s’han inventat (per exemple, pcJocs, portatilMarta…).

A la feina, els mateixos usuaris accedeixen a diversos equips que tenen noms que els hi han posat els administradors del sistema. Així, per exemple, els informes estan en un ordinador anomenat watergate, la gestió de la comptabilitat en un servidor que es diu blackhole i les nòmines es gestionen des del servidor minix. Tots aquests ordinadors pertanyen a la xarxa de l’empresa, que s’identifica amb el nom de domini local empresa.cat.

A més a més, resulta que tant des de casa com des de la feina aquests usuaris treballen habitualment consultant serveis a hosts com gmail.com, youtube.com, ara.cat… És a dir, consulten serveis i hosts de dominis d’Internet.

Aquests tres casos exposats permeten observar tres tipus diferents de resolució de noms:

  • Resolució de noms de host locals
  • Resolució de noms d’un domini local (no integrat a Internet)
  • Resolució de noms global (domini integrat a Internet)

Les tres resolucions no són excloents, sinó que s’implementen totes a la vegada combinant la resolució local i la resolució via DNS. Existeix també un mecanisme per indicar la precedència de la resolució, és a dir, indicar si es prefereix primer la resolució local i després la de DNS o a l’inrevés.

El client DNS: 'resolver'

Un equip client que vol resoldre un nom de host té diferents maneres de fer-ho. Es pot fer localment mitjançant un fitxer de hosts (típicament /etc/hosts) o de manera distribuïda usant DNS (el resolver). De fet, es poden aplicar tots dos mètodes conjuntament indicant-ne la precedència en algun fitxer de configuració del sistema (en sistemes GNU/Linux, el fitxer /etc/ nsswitch.conf).

Criteri de resolució

Per defecte, quan cal resoldre un nom de host (i no s’ha especificat la directiva search), el resolver fa el següent: si el nom de host inclou un punt (pc30.inf) mira de resoldre’l tal qual, i si no pot hi aplica el nom de domini (pc30.inf.inf.fpoberta.net.). Si el nom de host no conté cap punt (pc30), primer li afegeix el domini i el mira de resoldre (pc30.inf.fpoberta.net.), i si no el troba el mira de resoldre tal qual (pc30).

El resolver és la part client del sistema de noms de dominis DNS, que està organitzat en una estructura client/servidor. Cada resolver implementa les seves opcions, però n’hi ha que són suficientment genèriques per descriure-les aquí. En la majoria de sistemes GNU/Linux, aquestes opcions es defineixen en el fitxer /etc/resolv.conf.

Les següents són les directives del fitxer /etc/resolv.conf:

  • domain (local domain name o nom de domini local) indica el nom de domini del host al qual pertany el resolver. Serveix per completar els noms de domini no qualificats (FQDN).
  • search permet modificar el comportament per defecte indicant explícitament la llista de dominis a aplicar. El primer d’aquests és aplicat com el nom del domini local (local domain name) i és per això que la directiva search és excloent de la directiva domain.
  • nameserver permet especificar el servidor de noms a utilitzar. Se’n poden indicar fins a tres per si no hi ha accés al servidor. El resolver intenta connectar amb el primer servidor i si ho aconsegueix realitza les consultes a aquest servidor.

Servidor de noms d'una altra organització

Es poden configurar els hosts perquè utilitzin el servidor de noms d’una altra organització (perquè és més ràpida, per estalviar-se feina…), però no és una bona pràctica.

# Exmple de fitxer de configuració client /etc/resolv.conf
[root@host ~]$ cat /etc/resolv.conf 
; generated by /sbin/dhclient-script 
search ioc.cat
nameserver 80.58.61.250 
nameserver 80.58.61.254

La figura mostra una interfície gràfica que permet configurar els servidors DNS. En aquest exemple s’observa que s’han definit dos servidors de noms, un de primari i un de secundari. La directiva search correspon al valor local.lan. Tal com és habitual en sistemes GNU/Linux aquesta miniaplicació gràfica (applet) simplement modifica el fitxer de configuració.

Figura Miniaplicació gràfica de configuració del resolver

Funcionalitat del sistema de noms jeràrquics

Sabem que tenim la necessitat de poder-nos adreçar als diversos hosts, servidors i dominis que hi ha a les xarxes i en especial a Internet. Com podem identificar en llenguatge natural (no les punyeteres adreces IP) cada nom?

Un mecanisme és posar als hosts i als dominis noms plans, noms independents els uns dels altres sense cap mena d’estructura ni de jerarquia. Amb tota seguretat aquest mecanisme provocaria noms duplicats i un caos organitzatiu important.

El sistema de noms de domini permet identificar qualsevol equip en la xarxa i assegurar-se que no hi ha col·lisions, és a dir, noms duplicats. Es basa en una estructura jeràrquica de noms en forma d’arbre on l’arrel és el node o domini arrel del qual deriven tots els altres nodes. Aquest es divideix en altres dominis com, per exemple, .com, .edu, .org, .cat… Al seu torn, cada domini es pot dividir en subdominis i així successivament. Les rutes s’indiquen començant pel subdomini més intern i anant cap al node arrel, com per exemple mail.ioc.cat.

El sistema de noms jeràrquic

Caràcters en els noms de domini

L’estàndard DNS indica que els noms de domini han de ser de 64 caràcters com a màxim, i només poden incloure caràcters llatins, dígits del 0 al 9 i el guió. Les majúscules són indiferents.

Hi ha mecanismes com l’IDNA (Internationalized Domain Name o noms de domini internacionalitzats) que permeten utilitzar altres alfabets en els noms de domini.

En un sistema de noms jeràrquic cada node de l’arbre s’identifica per un text (el nom de domini) que no es pot repetir en el mateix nivell, però sí en altres llocs de l’arbre de l’espai de noms. El mateix passa amb els fitxers: no hi pot haver dos fitxers amb el mateix nom en el mateix directori, però sí en ubicacions diferents. Un domini està format pel propi node i la resta de l’arbre que penja d’aquest node. Penseu en l’exemple d’un directori: si es vol copiar un directori s’entén que està format pel mateix directori i tots els subdirectoris que conté.

Anomenem espai de noms al conjunt de tots els dominis que formen l’arbre de noms DNS. Continuant l’analogia amb el sistema de fitxers diríem que l’espai de noms és equivalent a tot el sistema de fitxers i directoris.

El sistema de noms de domini d’Internet DNS està format pels elements següents:

  • Espai de noms: el conjunt de tots els noms de domini d’Internet (tot l’arbre).
  • Domini: text identificatiu d’un domini (un node i tots els seus descendents).
  • FQDN: nom de domini absolut començant pel node i acabant en l’arrel.
  • Domini absolut: és un sinònim d’FQDN. Es la ruta sencera que va del node a l’arrel. Els dominis absoluts acaben en punt.
  • Domini relatiu: nom de domini sense qualificar (no acaba en punt). S’entén que un nom de domini és relatiu al domini al que pertany.
  • Domini arrel: domini del qual deriven tots els altres. S’indica amb un punt o amb la cadena buida.

Exemples de noms de domini:

El punt final en els noms de domini

La majoria de vegades escrivim els dominis com si fossin absoluts, però són relatius al node arrel perquè no posem el punt final. Un altre cop es pot fer l’analogia amb les rutes relatives i les rutes absolutes del sistema de fitxers.

  • ioc.cat.: nom de domini absolut que, per exemple, inclou mail.ioc.cat i inf.ioc.cat.
  • pc01.inf.ioc.cat.: nom de host absolut o FQDN.
  • pc01: nom de host relatiu al domini on pertanyi.
  • pc02.inf: nom de domini relatiu al domini on pertany.
  • com: nom de domini relatiu. Usualment ens hi referim en lloc de com., que és el FQDN apropiat.
  • .: domini arrel.

L’estructura d’arbre (jeràrquica) de l’espai de noms proporciona un mecanisme d’identificació únic d’un domini. No pot existir cap domini que tingui exactament el mateix nom absolut o FQDN (Fully Qualified Domain Name o nom de domini complet). Els dominis es llegeixen des del node a l’arrel. Així, un domini que correspongui al departament d’administració de l’organització IOC dins del domini cat s’identifica, per exemple, com a admin.ioc.cat. Si ens fixem en el domini anterior, veurem que acaba en punt: és una manera d’indicar el domini arrel. El domini arrel es defineix com un domini sense etiqueta o, millor dit, amb la cadena buida com a etiqueta. Això provoca que els dominis que s’indiquin de manera absoluta acabin amb el caràcter punt.

Un domini absolut o FQDN és el que inclou tots els nodes des del domini fins a l’arrel (inclosa en forma de punt final). Un domini relatiu no inclou l’arrel i pot ser relatiu al domini actual. Per exemple, dins del domini de l’IOC el domini inf (del departament d’informàtica) és un nom relatiu que fa referència al nom absolut inf.ioc.cat.

Els noms de domini d'Internet

Origen dels noms de domini

Si ens fixem en els primers dominis d’alt nivell, estaven basats en una visió estatunidenca del món (de fet la xarxa Arpanet, base de l’actual Internet, va ser desenvolupada pel Departament de Defensa del govern dels EUA). En estendre’s Internet globalment i aparèixer dominis d’alt nivell geogràfics, moltes organitzacions es van registrar en més d’un domini (per exemple, empresa.com i empresa.cat).

A Internet els noms de dominis segueixen una estructura basada en els seus inicis però que ha anat evolucionant. El node arrel es va dividir en un conjunt de subdominis anomenats TLD (Top Level Domains o dominis d’alt nivell). Aquests dominis eren com, edu, gov, mil, org, net i int. Posteriorment se’n van afegir d’altres com cat, name, biz, info, pro, aero, coop i museum. Es volien organitzar els dominis per funcionalitat posant les empreses en els .com, les organitzacions en els .org…

Es va veure, però, la necessitat de poder agrupar els dominis de manera geogràfica i van sorgit els famosos identificadors de país. Per a cada país es va generar un TLD de dos caràcters utilitzant el preexistent estàndard internacional ISO 3166 (els famosos .es, .fr, .us…).

Els servidors arrel són crucials per al funcionament del DNS, ja que coneixen tots els dominis de primer nivell. Han d’admetre un gran volum de consultes i per això n’hi ha tretze repartits per tot el món. A més a més, d’aquests tretze, alguns tenen rèpliques en diversos continents utilitzant un sistema anomenat anycast.

Dominis d'alt nivell

Els següents són exemples de dominis d’alt nivell:

  • cat: Catalunya
  • ad: Andorra
  • aq: Antàrtida
  • gb: Gran Bretanya
  • im: Illa de Man
  • ms: Montserrat
  • pf: Polinèsia Francesa
  • ps: autoritat palestina
  • uk: Regne Unit

Així, doncs, hi ha un node arrel del qual deriven múltiples nodes de primer nivell, com per exemple com., cat., es., org. … Aquests dominis són gestionats per institucions o empreses amb forts lligams amb la indústria informàtica i Internet. A continuació trobem dominis de segon nivell, com per exemple ioc.cat., gmail.com., rediris.es. o escoladeltreball.org., que corresponen a empreses o institucions que han demanat disposar d’un domini propi de segon nivell. Com ho han fet? Doncs demanant donar-se d’alta al gestor apropiat del domini de primer nivell d’on volen formar part. I pagant per aquest servei, és clar!

El model es va repetint de manera que cada gestor d’un domini pot crear (o vendre) subdominis del seu domini. Així, si per exemple els gestors del domini imaginari bonrotllo.org. permeten fer subdominis, es podria crear el subdomini parxis.bonrotllo.org. on poder divulgar la nostra afició al parxís.

A vegades els dominis es classifiquen per nivells, indicant el seu grau de profunditat:

  • Arrel: el domini pare de tots els dominis, el punt.
  • TLD o primer nivell: domini fill de l’arrel o de primer nivell. En són exemples cat., es., com., org. …
  • Segon nivell: format pels dominis fills dels dominis de primer nivell. Per exemple, ioc.cat., gencat.cat., gmail.com., python.org. …
  • Altres: a partir d’aquí cada domini de segon nivell genera els subdominis que creu apropiats, alguns gestionats per ells mateixos i d’altres delegats a altres entitats.

Els dominis inclouen hosts, impressores, servidors de correu… És a dir, noms d’una màquina. Tot nom de host és també un nom que es podrà identificar i resoldre usant el DNS. Els noms de host pertanyen a un domini, però no són dominis. Sovint els usuaris desconeixen la diferència entre un nom de host (un element) i un nom de domini (una àrea que abasta subdominis i que conté hosts). Veurem més endavant la relació entre els dominis i les zones, que són les bases de dades que descriuen els hosts que formen part del domini.

Per exemple, gmail.com. és un domini, però www.gmail.com. és un host (o més d’un en cas de ser multihomed). El mateix passa amb inf.ioc.cat., que fa referència al domini format per tots els hosts del departament d’informàtica de l’IOC i els possibles subdominis que tingui. En canvi, pc01.inf.ioc.cat., printer.inf.ioc.cat. o ftp.inf.ioc.cat. són noms de hosts que pertanyen a aquest domini.

Molt sovint a Internet es confon entre un nom de host com ftp.rediris.es., que identifica la màquina de RedIRIS que proporciona el servei FTP, i el nom de domini, que identifica una àrea de l’espai de noms de domini que inclou els seus subdominis.

Els dominis contenen descripcions dels hosts i la seva organització.

Alguns exemples són:

  • www.gmail.com. és un nom de host.
  • gmail.com. és un nom de domini.
  • www.ioc.cat. és un nom de host.
  • ioc.cat. és un nom de domini.
# Llistat de l'adreça IP d'un host concret ("eines") del domini ioc.cat
[user@host ~]$ host eines.ioc.cat
eines.ioc.cat has address 85.192.111.246

# Llistat d'informació global del domini ioc.cat
[user@host ~]$ host ioc.cat
ioc.cat mail is handled by 30 aspmx3.googlemail.com.
... output suprimit...

Dominis, subdominis i zones

Exemple d'administració de subdomini

El domini .cat és administrat per una entitat que gestiona la zona .cat. Aquest domini conté el subdomini ioc.cat, però ha delegat l’administració d’aquest subdomini a l’IOC. Els administradors de l’IOC disposen d’un servidor que gestiona el seu domini com una zona. El domini .cat és l’arbre que inclou tots els dominis que en deriven, inclòs ioc.cat. Però la zona .cat i la zona ioc.cat no són la mateixa zona. Són administrades per entitats diferents.

Sabem que el sistema de noms de domini està basat en una arquitectura client/servidor en què els clients fan preguntes del tipus “Quina IP té aquest domini?” i els servidors miren de contestar-les. Els servidors de noms DNS són els programes que emmagatzemen i gestionen la informació de la base de dades d’una part de l’espai de noms anomenada zona.

Primerament hem de descriure què és una zona. Una zona és la part de l’espai de noms de domini gestionada per un o més servidors DNS. Els servidors que gestionen la zona tenen informació completa sobre ella i es diu que hi tenen autoritat. Podríem pensar que un servidor DNS gestiona un domini i que una zona és el mateix que un domini, però això no és necessàriament així. Un domini es divideix en subdominis per facilitar-ne l’administració. Cada part administrada per un o més servidors DNS és una zona. El domini és l’arbre de l’espai de noms (ell i els seus descendents) i la zona és la part de l’arbre administrada per un servidor de noms de domini concret.

En la figura es pot veure un espai de noms amb quatre zones i catorze dominis. Cada lletra és un domini. El nom de domini corresponent a cada zona (s’anomenen segons el seu node superior) és A, B.A, C.A i I.C.A respectivament. Cada una d’aquestes quatre zones tindrà un o més servidors DNS per gestionar-la.

En general, podem dir que una zona conté la informació completa dels equips que formen el domini corresponent a la zona i dels equips dels subdominis que no s’han delegat. Aquesta informació s’emmagatzema en la base de dades de zona.

Figura Exemple de zones i dominis

Convé tenir clar en tot moment que domini i zona no són equivalents (tot i que poden coincidir).

  • El domini és l’arbre de l’espai de noms que inclou el node i els seus descendents.
  • La zona és la part de l’arbre administrada per un servidor DNS concret.
  • La base de dades de zona la formen els fitxers que emmagatzemen la descripció dels equips que pertanyen a la zona.
  • La delegació consisteix a passar l’autoritat de la gestió d’un subdomini a una altra entitat. Aquesta serà qui s’encarregarà de gestionar-lo.

Delegar l’administració d’un subdomini no és més que traspassar l’autoritat sobre aquest subdomini a una altra entitat (a uns altres servidors DNS). Aquesta entitat és la responsable de l’administració de la zona delegada. Té tota l’autoritat per fer i desfer al seu criteri. La zona pare perd el control administratiu de la zona delegada i simplement apunta als servidors de noms de la zona delegada per obtenir informació quan la requereix.

L’estàndard que defineix el DNS estableix que cal configurar dos o més servidors autoritaris per a cada zona, anomenats servidor primari i servidor secundari. El motiu és proporcionar un mecanisme de redundància, robustesa, rendiment i còpia de seguretat. Si el servidor de noms falla i és únic, possiblement la xarxa caurà, serà inoperativa.

Els servidors primari (o master) i secundari/s (o slave/s) són autoritat. Només el primari té els fitxers de zona amb les dades in situ. Els servidors secundaris obtenen una còpia de les dades per transferència.

El protocol DNS

El servei de noms de domini utilitza el protocol DNS per fer les consultes i les respostes. Es tracta d’un protocol de capa d’aplicació que pot utilitzar tant UDP (User Datagram Protocol) com TCP (Transmission Control Protocol) en la capa de transport. Usualment, tant les consultes del client com les respostes del servidor es poden encabir en un datagrama (512 bytes) i s’utilitza UDP (de fet, generalment es diu que el DNS usa UDP). Però si la informació a transmetre és àmplia (per exemple, una resposta amb una llista amb molta informació), la comunicació es passa automàticament a TCP. Un altre cas en què la informació usa TCP és quan es realitza la transferència d’informació d’una zona entre servidors primaris i secundaris. El servidor DNS utilitza el port privilegiat 53.

El protocol DNS usu habitualment UDP, però pot usar TCP i UDP. Es tracta d’un protocol de capa d’aplicació i utilitza el port 53.

Els datagrames DNS es componen de diversos apartats, tal com es pot veure en la consulta host següent:

[user@host ~]$ host -a uoc.es 

La comunicació DNS és un mecanisme de consulta/resposta entre el client i el servidor. Els datagrames, doncs, seran de query (consulta) o answer (resposta).

Els apartats que componen un missatge DNS són:

  • HEADER. Capçalera del missatge que indica si és una consulta o una resposta. Conté l’ID (identificador) del missatge, flags i un resum de quines seccions del missatge porten informació i quanta.
  • QUESTION. Aquesta secció conté la consulta que s’ha efectuat. És a dir, quina dada s’ha demanat al servidor. Pot ser una resolució d’adreça IP a un domini, demanar la llista de servidors de correu…
  • ANSWER. Secció que conté la resposta obtinguda del servidor. S’entén que aquesta secció conté la resposta no autoritativa. A vegades en les utilitats de consulta aquesta secció es mostra com a non-authority answer.
  • AUTHORITY. Aquesta secció conté les respostes que són autoritatives per a la consulta efectuada. Evidentment pot estar buida.
  • ADDITIONAL. Conté informació addicional per completar la resposta. En l’exemple s’observa que completa la resolució dels noms de màquina que hi ha a la secció answer tot indicant la seva adreça IP corresponent.

Instal·la i configura el servidor DNS

El servei de xarxa DNS està estructurat en forma de servei client/servidor; per tant, caldrà disposar del programari apropiat per adoptar cada un d’aquests rols. El programari que fa la funció de client usualment ja està integrat en el sistema operatiu (la part que gestiona la xarxa) o en les mateixes aplicacions (per exemple, Firefox). És a dir, per disposar de la part client del servei DNS normalment no cal instal·lar res, tot i que sí que cal configurar-la correctament.

Així, doncs, quan parlem d’instal·lar un servei DNS fem referència al procés d’instal·lació i configuració del programari del servidor.

La instal·lació del programari que proporciona el servei DNS es fa de manera molt similar (per no dir idèntica) a la d’altres serveis de xarxa com el DHCP, l’HTTP o l’FTP. Es tracta d’instal·lar el programari de l’aplicació servidor i fer-ne la configuració apropiada. Senzill, oi?

Per fer tot això cal fer les reflexions i passos següents:

  • Quin programari proporciona aquest servei? Quines característiques té? Com es pot adquirir?
  • Obtenir l’aplicació que proporciona el servei DNS.
  • Observar l’estat de la xarxa actual. Està el servei ja en funcionament? Existeix ja una configuració DNS activa?
  • Instal·lar l’aplicació servidor.
  • Comprovar que la instal·lació s’ha efectuat correctament.
  • Configurar el servei en el servidor i activar els clients perquè la utilitzin.
  • Comprovar que el servei funciona correctament.

Aplicacions servidor DNS

Sempre que l’administrador vol posar en funcionament un nou servei de xarxa cal que primerament analitzi quines aplicacions hi ha en el mercat que ofereixen aquest servei. És feina seva estudiar les característiques de les diverses aplicacions, com per exemple avaluar-ne l’eficiència, el cost, el que en diuen els altres… La manera més fàcil de fer això és navegar per Internet, consultar les revistes especialitzades o demanar consell a un dels gurus informàtics coneguts.

Cerca de DNS a Internet

Usualment l’administrador s’informa mitjançant el seu cercador preferit, per exemple Google, i de webs com la Viquipèdia. Proveu a buscar “DNS” o “DNS server” al Google i a la Wikipedia (en anglès).

Usualment, però, l’administrador acaba utilitzant l’aplicació servidor DNS que li proporciona el mateix sistema operatiu. Si utilitzeu Windows, l’empresa Microsoft disposa d’una aplicació pròpia, però també en podeu trobar d’altres a Internet. Igualment, si utilitzeu GNU/Linux, segurament la mateixa distribució ja proporciona un servidor DNS o bé n’existeix algun de clàssic provinent de l’Unix. De totes maneres, també en podeu obtenir d’altres a Internet. En la figura es pot veure quin servidor utilitzen els nodes arrels. La llista ha estat extreta de la Wikipedia. S’hi poden observar els 13 servidors o nodes arrel del servei DNS, l’entitat que els gestiona, el tipus de difusió que fan i el programari que utilitzen.

Figura Llista de servidors arrel DNS i programari que utilitzen

Instal·lar l'aplicació servidor

Els usuaris de GNU/Linux poden buscar fàcilment per Internet paquets del client i del servidor DHCP usant eines com yum, apt-get i els repositoris de paquets apropiats segons quina sigui la distribució que utilitzin. A més, sempre hi ha l’omnipresent eina Google per ajudar a localitzar tot allò que faci falta.

Un cop instal·lat el programari caldrà identificar què s’ha instal·lat. Quins paquets i què contenien. A vegades no s’instal·laran paquets sinó fitxers .tar, dels quals també caldrà saber-ne examinar el contingut. És important saber identificar quins dels components instal·lats corresponen a fitxers executables, quins a fitxers de configuració i quins a fitxers de documentació.

Tot servei instal·lat s’ha de configurar apropiadament i posar en marxa. Per tant, caldrà saber gestionar l’estat del servei (engegat, aturat…) i definir l’estat que ha de tenir en els diferents runlevels del sistema.

En definitiva, el procediment d’instal·lar usualment inclourà:

  • Buscar el programari del servei (sigui en format de paquets .deb, .rpm o .tar) i descarregar-lo utilitzant l’eina apropiada segons quina sigui la distribució.
  • Examinar el sistema per identificar quin programari i quins paquets relacionats amb el servei hi ha instal·lats.
  • Identificar els components del servei: quins són els fitxers executables, de configuració i de documentació.
  • Consultar i establir l’estat del servei (engegar i aturar) i saber establir l’estat per defecte per a cada runlevel.

Configuració per defecte del servei instal·lat

El servei DNS disposa usualment d’una configuració bàsica per defecte en instal·lar-se que acostuma a ser la apropiada per a un servidor de noms només cau. A vegades simplement vindrà amb els fitxers de configuració buits, de manera que caldrà editar-los apropiadament abans de posar el servei en funcionament. En qualsevol cas cal saber identificar cadascun dels conceptes que es descriuen a continuació (es mostren els valors apropiats per al servidor BIND):

  • El nom del servei: named (localitzat a /etc/init.d/named).
  • El fitxer de configuració: /etc/named.conf.
  • El directori dels fitxers de zona: /var/named.
  • El llistat dels fitxers de zona predefinits que conté el directori anterior.
  • La ubicació de fitxers d’exemple i pàgines de manual d’on poder obtenir una configuració inicial bàsica.

El paquet named conté un fitxer d’exemple de configuració d’una zona en el directori /user/share/doc/bind*/sample/etc/named.conf. Aquest fitxer es pot copiar a /etc/named.conf i passarà a ser la configuració bàsica del servidor DNS.

[user@host ~]# head /usr/share/doc/bind-9.4.2/sample/etc/named.conf 
// Sample named.conf BIND DNS server ‚named' configuration file
.... output suprimit ...

En la configuració per defecte es poden analitzar els diversos elements que es configuren:

  • options: s’hi defineixen les opcions genèriques del servidor DNS.
  • logging: es defineix com serà el procés d’enregistrament dels logs del servei.
  • localhost_resolver: permet definir el servidor DNS com un servidor només cau. És a dir, no és autoritari de cap domini, no gestiona cap domini, cap zona, no té fitxers de zona; l’única funció que fa és de servidor DNS cau.
  • internal: permet definir les zones i zones delegades que es volen gestionar amb el servidor. Es donarà servei a les xarxes locals internes que es defineixen en aquesta secció.
  • external: defineix el servei a oferir a clients externs al domini. És per oferir serveis DNS a clients exteriors.

La figura mostra una eina gràfica que permet la configuració del servei de noms. En sistemes GNU/Linux és usual que els servidors es gestionin editant directament els fitxers de configuració. Es disposa, però, de miniaplicacins (applets) que permeten fer aquesta mateixa tasca des d’un entorn gràfic. Usualment no fan res de nou, és a dir, simplement serveixen per modificar els fitxers de text de configuració mitjançant un entorn gràfic més amable.

Figura Miniaplicació gràfica de gestió del servidor BIND

Podem observar les zones que s’instal·len per defecte llistant el directori de treball per defecte del servei. Amb tota seguretat hi trobarem els fitxers corresponents a les zones arrel, localhost i loopback. A més, el paquet del servei segurament disposa de fitxers d’exemple de zona igual que disposava d’un exemple de fitxer de configuració del servei.

[root@host ~]# ll //var/named/

A continuació es mostra un fragment del llistat del fitxer de zona que conté la descripció dels nodes arrel DNS a Internet.

# Fragment del llistat del fitxer de zona que conté la descripció dels nodes arrel
[user@host named]$ head named.cat

# LListat del fitxer de zona que descriu la resolució directa del localhost
[user@host named]$ cat named.localhost

Exemple de configuració bàsica

En aquest apartat veurem com engegar un servidor de noms amb la mínima configuració possible. Crearem un servidor només caché que no gestionarà cap domini. La seva funció seran emmagatzemar en la memòria cau les consultes i les respostes que es rebin per tal d’optimitzar-ne el rendiment. Quan es rep una consulta ja resolta anteriorment es respon amb la informació del caché. Quan no es disposa de la resposta es realitza la consulta seguint el procediment de resolució externa normal.

Per tant, no caldrà crear cap fitxer de zona per a la resolució directa ni per a la resolució inversa. Simplement posarem en marxa el servei amb les opcions apropiades per configurar-lo de la menera més senzilla possible.

Vegem tot seguit quins són els aspectes més importants d’aquesta configuració:

Port d’escolta del servei: cal configurar el servei indicant-li el port i les adreces IP del servidor per on ha d’escoltar. Això s’ha indicat amb la directiva listen-on port:

	listen-on port 53 { 127.0.0.1; 192.168.4.1};
	listen-on-v6 port 53 { ::1; };

Aquestes dues línies d’opcions habiliten el port 53 (el port clàssic del DNS) tant per al loopback (adreça IP 127.0.0.1) com per a l’adreça IP 192.168.4.1. Fixeu-vos que es defineix tant per a IPv4 com per a IPv6.

Directori de treball: les opcions següents de configuració especifiquen el directori de treball del servei i els diferents fitxers de monitorització a utilitzar. S’estableix el directori /var/named com a directori per defecte del servei. Per tant s’espera que els fitxers de zona siguin dins d’aquest directori. Podem observar que:

	directory 	"/var/named";
	dump-file 	"/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";

A més es defineixen fitxers per a volcats (dump), estadístiques (statistics) i estadístiques de memòria (memstatistics).

Mode de funcionament: aquestes opcions són el nucli que descriu el mode de funcionament del servidor. Indiquen el tipus de consultes que es poden permetre, si es treballa usant memòria cau o no, si es realitzen consultes a altres servidors de noms o no i altres modes de funcionament que es descriuran al llarg de les properes seccions.

        allow-query-cache { any; };
	allow-query       { any; };
	recursion yes;

Podem observar que l’opció allow-query-cache permet que s’emmagatzemi en la memòria cau qualsevol tipus de consulta i resposta que es realitzi. Per tant, aquesta línia indica que el servidor serà de memòria cau.

L’opció allow-query indica quines consultes es permeten; en aquest cas totes (any). Això significa que tots els hosts poden realitzar consultes a aquest servidor de noms. Si per exemple tingués el valor {192.168.4.0/24}:, significaria que només es permet als hosts d’aquesta xarxa usar el servidor DNS.

Finalment, l’opció recursion yes indica que es permet la resolució de noms consultant altres servidors de noms (la resolució DNS normal). Aquesta és l’opció que permet que aquest servidor de noms pugui resoldre les consultes que se li fan, ja que com recordeu no gestiona cap zona pròpia i ha de fer totes les consultes externament.

Hem vist en les opcions anteriors que s’utilitzava el valor any per indicar qualsevol consulta o qualsevol host. Aquest valor pot ser substituït per:

  • none, si no es vol permetre cap consulta.
  • Una adreça IP si només es volen permetre consultes des d’aquesta adreça.
  • Una xarxa, com per exemple 192.168.4.0/24, indicaria permetre totes les consultes procedents de hosts d’aquesta xarxa.
  • I finalment una llista de hosts vàlida (una mena d’ACL) indicaria permetre l’accés a tots els indicats en la llista.

L’exemple següent mostra diverses maneres d’indicar una llista de hosts:

# Exemples bàsics de llista de noms:
{ any; };  es permet tot
{ none; }; no es permet res
{ 192.168.4.1; 192.168.4.10; 192.168.4.11; }; només als hosts indicats
{ 192.168.4.0/24; 172.17.0.0/16; 192.168.5.1;} a les xarxes i hosts indicats
# Exemple amb definicions de llista. Es defineix una llista amb les xarxes locals i una llista amb xarxes i hosts 'amics', i s'apliquen a l'allow query:
acl xarxalocal { 192.168.4.0/24; 192.168.5.0/24; };
acl colegues { 172.16.1.0/24; 192.168.6.1; 10.10.10.1; };
allow-query{ xarxalocal; colegues; 10.100.6.2; };

Definir el mecanisme de log: podem observar en el fitxer de configuració un bloc dedicat a establir el mecanisme de monitorització o log que usarà el servei. En aquest cas el PID del servei es desarà en un fitxer anomenat named.run i el nivell de log a usar és el severity dynamic.

logging {
  channel default_debug {
    file "data/named.run";
    severity dynamic;
  };
};

Fitxers de zona: finalment, el fitxer de configuració conté els blocs que descriuen cada una de les zones administrades pel servidor de noms. En aquest exemple hem dit que el servidor és només cau i que per tant no administra cap zona. Tot i això, podem observar que per defecte es carrega la zona arrel, identificada per un punt. Usualment n’existeix una còpia local en el servidor amb els noms i les adreces IP dels servidors arrel del servei de noms a Internet. En aquest cas correspon al fitxer named.ca.

zone "." IN {
  type hint;
  file "named.ca";
};

Resolució, 'forwarding' i memòria cau

Tot sovint, en les aplicacions d’usuari i de sistema s’accedeix a recursos pel seu nom de domini. Per exemple, un client web requereix una determinada pàgina web, un navegador de fitxers vol accedir a unes carpetes d’una màquina remota que s’identifiquen pel nom de domini, el sistema ha de validar l’usuari en un servidor LDAP remot… En cada un d’aquests casos caldrà respondre una pregunta del tipus “A quina adreça IP correspon aquest domini?”, “Quins són els servidors de noms del domini tal?”, “Quins són els servidors de correus?”. Aquestes preguntes no les responen les aplicacions individualment (el navegador web, el client d’autenticació…), sinó que utilitzen el resolver per fer-ho.

El resolver és la part client de l’arquitectura client/servidor del DNS. Ha d’atendre les necessitats de les aplicacions, confeccionar una consulta o query, enviar-la a un servidor DNS, obtenir la resposta i passar-la a l’aplicació pertinent. El resolver no és usualment una aplicació sinó un conjunt de biblioteques de funcions. Les aplicacions client es compilen i enllacen conjuntament amb aquestes biblioteques.

Els servidors que reben l’encàrrec de fer la resolució d’una consulta es poden comportar de maneres diferents en funció de com s’han configurat. Poden obtenir la resposta de la seva memòria cau, sol·licitar a un altre servidor de noms que sigui ell qui faci tota la feina de resolució (forwarding) o encarregar-se de fer la resolució pas a pas pel seu compte (recursion), consultant tans servidors de noms externs com faci falta.

En general podem catalogar el funcionament de la resolució en:

  • memòria cau sí/no
  • recursiu sí/no (recursiu/iteratiu)
  • forward sí/no, combinat amb forward only

Fem una ullada al funcionament del mecanisme de resolució.

La resolució de noms

El mecanisme de resolució de noms DNS consta d’un client o resolver que realitzarà consultes (o queries) a uns servidors DNS.

Si el servidor disposa de la informació perquè forma part de la base de dades de la seva zona, emetrà una resposta autoritativa. Si disposa de la resposta perquè la té emmagatzemada temporalment (en un procés anomenat cau) també emetrà la resposta, però aquest cop de manera no autoritativa. Si no té informació del domini buscat, el servidor pot fer la consulta a altres servidors en un procés que pot ser recursiu o iteratiu. Sempre existeix un camí per trobar el domini buscat, que és preguntar als nodes arrel (root servers) de l’espai de noms de domini. Partint dels nodes arrel i recorrent l’arbre cap avall, es pot arribar al domini buscat, si és que existeix.

Sempre hi ha un camí a un domini existent partint del node arrel. Quan un servidor és consultat sobre un domini que desconeix (no és de la seva zona ni té la resposta en la memòria cau) pot escalar la pregunta a un servidor l’arrel (root name server). Això significa que els servidors arrel són crucials per al funcionament del DNS.

Exemple de resolució de noms DNS

Quina adreça IP té el host ns1.ioc.cat.? Si un estudiant australià intenta esbrinar això des del seu servidor de noms de Sydney, probablement acabarà preguntant per aquest domini a un dels nodes arrel. El node arrel desconeix el host ns1 del domini de l’IOC, però sí que coneix tots els dominis de primer nivell (TLD). Per tant, l’arrel proporcionarà una llista amb els servidors de noms del domini cat. A continuació, el servidor de Sydney preguntarà a algun dels servidors de noms de la llista (del domini cat.) i obtindrà la llista de servidors DNS del domini ioc.cat. Preguntant als servidors d’aquest domini obtindrà l’adreça IP del host ns1 per al qual el domini ioc.cat. és autoritari (forma part de la seva zona).

Recursió i iteració

Quan el client o resolver emet una consulta al servidor DNS local (el servidor de noms que té configurat), aquest la pot tractar de manera recursiva o iterativa. De fet, el client resolver ja farà la consulta indicant si exigeix una resposta recursiva o iterativa. La diferència entre un mode i l’altre és com ha d’actuar el servidor DNS per obtenir la resposta quan no la té en la seva base de dades d’informació.

En el mode iteratiu, el servidor retorna la millor resposta possible basada en la seva informació local, sense preguntar a ningú més. En el mode recursiu, el servidor intenta trobar la resposta preguntant a tants altres servidors com calgui per obtenir-la.

Un servidor pot emetre les respostes següents:

  1. Respon enviant la dada que li han sol·licitat (un nom de host, una adreça IP, la llista de servidors de noms, de servidors d’autenticació…).
  2. Ha localitzat el domini buscat, però no disposa de la dada sol·licitada. Cal tenir en compte que es poden sol·licitar altres dades a part de l’adreça IP, per exemple, els servidors de correu que té el domini.
  3. Finalment, pot ser que el domini sol·licitat no existeixi.

Recursió

Quan un servidor rep una consulta del client, mira la base de dades local de la seva zona. Si existeix la informació sol·licitada, la retorna. Si la dada no forma part de la seva zona, però la té emmagatzemada en la memòria cau (perquè ja ha realitzat amb anterioritat un consulta similar i ha emmagatzemat temporalment la resposta), també la retorna. Si la dada no forma part del seu espai de noms ni es troba en la memòria cau, el mode recursiu mana al servidor anar preguntant recursivament a altres servidors, apropant-se més a cada pas al domini sol·licitat. Si el servidor no coneix cap servidor més proper al domini buscat a qui preguntar, acaba preguntant als servidors de l’arrel.

Exemple de recursió

Si es consulta el domini www.inf.ioc.cat. i el servidor desconeix aquest domini, intentarà contactar amb un servidor de noms del domini inf.ioc.cat. Si tampoc sap com adreçar-se a aquest domini, intentarà contactar amb un servidor de noms de domini ioc.cat. Si també el desconeix, provarà de localitzar un servidor per al domini .cat. Si tampoc és el cas, es posarà en contacte amb un servidor de noms de l’arrel, . Un cop en l’arrel, sempre és possible accedir al domini buscat descendint per l’arbre de dominis.

Si tots els processos recursius acabessin preguntant als nodes arrel, aquests se saturarien. El servidor que ha rebut la consulta del resolver pregunta al node més proper al domini buscat. Si coneix algun servidor de noms més proper, li ho pregunta i evita d’anar a l’arrel.

Una altra manera d’evitar la sobrecàrrega dels nodes arrel és l’ús de la informació emmagatzemada de consultes anteriors, que es desa localment en la memòria cau del servidor.

Consulta d'informació delegada

Si es consulta l’adreça www.inf.ioc.cat. i el servidor que rep la consulta és el servidor de noms del domini ioc.cat., aquest no pregunta cap amunt (a cat. o a l’arrel .), sinó que obté de la seva pròpia base de dades la llista dels servidors de noms autoritaris de la zona delegada inf.ioc.cat., als quals preguntarà per obtenir una resposta.

Imagineu un alumne de Sydney, estudiant de l’IOC, que genera una consulta al servidor de noms del seu ISP australià per identificar el domini www.int.ioc.cat.. Probablement el servidor desconeix aquest domini i els propers, inf.ioc.cat. i ioc.cat. Però segurament en la memòria cau (per consultes prèvies) té la llista de servidors de noms autoritaris del domini cat. Serà a un d’aquests servidors (i no a un node arrel) a qui farà la consulta que li permetrà accedir de manera descendent al domini buscat.

Per tant, en el procés recursiu, el servidor de noms que rep la consulta del resolver ha de tornar una resposta que pot procedir de la seva base de dades de zona, de la memòria cau o de les respostes finals que ha obtingut preguntant recursivament a altres servidors propers al domini a consultar.

Fixeu-vos que un servidor que rep una consulta recursiva del resolver té la feina d’esbrinar per si mateix la resposta. Podria repetir la mateixa consulta al servidor més proper fent-la recursiva en lloc d’iterativa. Això exigiria a l’altre servidor fer tota la feina. Aquest plantejament, tot i que possible, es considera abusiu.

Usualment, el client consulta el seu DNS de manera recursiva i els servidors es consulten entre ells de manera iterativa.

Iteració

En el mode iteratiu, un servidor dóna la millor resposta possible basant-se en la pròpia informació (base de dades de zones locals i memòria cau). En cap cas no consulta cap altre servidor. Si no disposa de la resposta, lliura una llista amb els servidors més propers al domini que es busca. La llista pot ser d’un o més servidors i és tasca del servidor que ha fet la consulta decidir a quin d’ells tornar a preguntar (en el cas recursiu).

Els nodes arrel no accepten consultes recursives per evitar l’abús i la saturació.

Les consultes iteratives són usualment de servidor a servidor, però no del resolver al servidor. Si el resolver fes una consulta iterativa a un servidor, significaria que quan la resposta fos una referència a un altre servidor, el resolver hauria de fer una altra consulta. Generalment els resolver no tenen aquesta capacitat, simplement fan una consulta recursiva al servidor que tenen configurat i és aquest el que ha de fer tota la feina per obtenir la resposta.

El client resolver fa una consulta recursiva al seu servidor DNS local. Si el servidor DNS disposa de la resposta, la torna. Pot ser de la seva zona i serà una resposta autoritativa o pot tenir-la en la memòria cau i serà no autoritativa.

Si no disposa de la resposta, consulta iterativament altres servidors apropant-se al domini buscat. Cada servidor que consulta iterativament li pot proporcionar la resposta (autoritativa o no), si la coneix, o una llista de servidors DNS autoritatius per al domini indicat.

Finalment, s’obtindrà una resposta que pot ser aquella dada que es buscava o un error si el domini buscat no existeix.

Resolució inversa

Un host amb l’adreça IP 192.168.1.24 correspon al domini 24.1.168.192.IN-ADDR.ARPA.

El DNS proporciona un mecanisme per obtenir el nom de domini que correspon a una adreça IP determinada. Aquest mecanisme, anomenat resolució inversa, es basa en un domini especial anomenat IN-ADDR.ARPA. Hi ha protocols de xarxa que requereixen una resolució inversa correcta per funcionar bé i sovint s’utilitza com a mesura de seguretat per verificar l’existència de l’adreça IP en un domini.

La xarxa 172.16.32.0/24 correspon al domini ARPA següent: 32.16.172.IN-ADDR.ARPA.

S’ha ideat un domini anomenat IN-ADDR.ARPA que permet representar en forma de nom de domini totes les adreces IP possibles. El format són etiquetes numèriques del 0 al 255 que representen cada octet d’una adreça IP. Les etiquetes dels octets es concatenen en ordre invers i se’ls afegeix el sufix IN-ADDR.ARPA. Un nom de domini amb quatre etiquetes d’octets correspon a un host, un nom de domini amb menys etiquetes correspon a una xarxa.

En l’exemple següent es mostren els servidors de noms del domini ioc.cat i es fa una consulta de resolució inversa a cada un d’ells:

[user@host ~]$ host -vt NS ioc.cat
[user@host ~]# host 62.97.103.68
[user@host ~]# host  213.151.118.169

Exemple de configuració amb recursió

Tot seguit s’analitzen les opcions que permeten configurar un servidor de noms en mode recursiu o en mode iteratiu. De fet, observat el fitxer de configuració podem veure que és ben senzill:

# Llistat del fitxer named.conf:
// named.conf
// servidor només cau
options {
	listen-on port 53 { 127.0.0.1; 192.168.4.1};
	listen-on-v6 port 53 { ::1; };
	directory 	"/var/named";
	dump-file 	"/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";

        allow-query-cache { any; };
	allow-query       { any; };
	recursion yes;

	/* Path to ISC DLV key */
	bindkeys-file "/etc/named.iscdlv.key";
};

logging {
  channel default_debug {
    file "data/named.run";
    severity dynamic;
  };
};

zone "." IN {
  type hint;
  file "named.ca";
};

include "/etc/named.rfc1912.zones";

Podem observar que es tracta simplement d’establir l’opció apropiada:

  • recursion yes; estableix el mode de funcionamet com a recursiu.
  • recursion no; estableix el mode de funcionament com a iteratiu.

Com es pot saber si el servidor funciona recursivament o iterativament? És ben senzill: un servidor iteratiu simplement pot resoldre consultes de la zeva zona o consultes prèvies que té emmagatzemades en la memòria cau. Però no pot resoldre consultes externes a la seva zona, ja que la recursió s’ha desactivat.

Per tant, podem configurar el servidor iterativament (recursion no;) i comprovar que no es resolen consultes externes com gmail.com.. Tot seguit podem activar la recursió, recursion yes;, i fer la mateixa consulta externa. En aquesta ocasió s’ha d’obtenir el resultat buscat.

Utilitzar un servidor 'forwarder'

Existeix un cas particular de funcionament dels servidors de noms que anomenem forwarders. Són servidors que podem anomenar informalment l’encarregat, o podem dir, encara més informalment, que “li passem el mort a tal” on tal és el forwarder.

Imaginem, per exemple, una xarxa local corresponent al departament d’administració d’una empresa i que forma part d’una xarxa més gran, corresponent a l’empresa. En la xarxa d’administració s’ha instal·lat un servidor de noms només cau que no administra cap domini local. Es vol que aquest servidor tampoc generi consultes externes per motius que els administradors de xarxes creuen oportuns: per exemple, per temes de tallafocs, seguretat… Es vol que el servidor faci totes les consultes al servidor de noms de l’empresa, que serà qui farà la tasca de forwarder.

És a dir, quan es vol que un servidor de noms no realitzi consultes externes via recursió, sinó que totes les consultes les realitzi a un mateix servidor, és diu que es traspassen les consultes a aquest servidor encarregat. Aquest servidor és un forwarder.

Es diu que un servidor fa forward quan passa totes les consultes externes a un altre servidor, que serà l’encarregat de resoldre-les.

El servidor que rep l’encàrrec de fer aquesta feina de resolució s’anomena forwarder.

Per configurar una estructura de resolució de noms amb un forwarder:

  • En el servidor de noms que traspassarà les consultes a l’altre cal indicar quin servidor de noms serà el forwarder.
  • En el que farà la funció de forwarder no cal indicar res. Simplement es trobarà que rep moltes consultes de resolució d’un host determinat, però no s’ha d’indicar res.
         allow-query-cache{ any;};   
         allow-query { any; };
         recursion yes;
         forward only;
         forwarders { 192.168.122.1; 192.168.122.2}; 

En el fragment de codi anterior, extret del fitxer de configuració /etc/named.conf, podem observar les dues directives que indiquen al servidor que ha de traspassar totes les consultes a un servidor “encarregat”. Anem a veure el significat de cada opció:

  • forwarders: indica l’adreça o adreces IP dels servidors als quals es farà forward de la consulta, és a dir, als quals s’encomanarà la tasca de resoldre-la. Com que l’especificació del protocol DNS recomana dos servidors de noms per domini, és usual trobar en aquesta opció almenys dues adreces IP. Aquestes corresponen als dos servidors d’un domini, els típicament anomenats primari i secundari.
  • forward only: si s’activa aquesta opció, el servidor funcionarà exclusivament en mode forward, de manera que qualsevol consulta serà tramesa al forwarder, idependentment de la memòria cau i de les zones pròpies.

Respostes de memòria cau

Es pot configurar un servidor de noms de domini perquè faci la funció de només cau. No gestiona cap zona, simplement atén les peticions dels resolvers client i les passa a altres servidors de noms. La seva funció és emmagatzemar en la memòria cau les respostes que obté abans de passar-les als clients. Això li permetrà que les futures consultes que siguin repetides les pugui contestar directament en lloc de demanar-les a un altre servidor. Evidentment, aquest tipus de servidor no emet respostes amb autoritat.

La funció de memòria cau es pot activar i desactivar segons convingui. A més, es pot combinar amb les altres opcions de resolució per seleccionar el mode de funcionament del servidor. Les combinacions més usuals són:

  • Si únicament es configura la funció de memòria cau es tractarà d’un servidor només /cau.
  • Si es combina la memòria cau i la recursió es farà resolució externa i es disposarà d’un cau local per poder contestar immediatament les consultes fetes amb anterioritat.
  • El mateix passa si es combina la memòria cau amb el forward. El forward traspassarà la responsabilitat de resoldre les consultes externes a un altre servidor de noms. Disposar de la memòria cau activada permetrà respondre immediatament les consultes repetides.
  • Desactivar la memòria cau significa que no s’emmagatzemen localment les respostes que es reben. Per tant, si es tornen a fer consultes que ja s’havien realitzat anteriorment caldrà tornar-les a resoldre pel mètode apropiat.

Si tornem a examinar el bloc d’opcions de configuració del mode de funcionament del servidor, extretes del fitxer /etc/named.conf, s’observa:

       allow-query-cache{ any;};   
       allow-query { any; };
       recursion yes;

L’opció allow-query-cache permet indicar si s’activa o no la memòria cau i per a quines consultes. Les opcions que pot prendre són:

  • any; indica que s’emmagatzemen en la memòria cau totes les respostes rebudes.
  • none; no permet el funcionament de la memòria cau.
  • adreces-ip; indica que les consultes que provinguin d’aquestes adreces-ip s’han d’emmagatzemar en la memòria cau. Les adreces-ip poden ser, de fet, combinacions dels tres conceptes següents: adreces IP, de xarxa o una llista-de-noms. Per exemple, 192.168.4.0/24;.

Autoritari, no autoritari i informació de memòria cau

Cada zona de l’espai dels noms de domini és gestionada per un o més servidors autoritaris per a la zona. Això significa que són els servidors que manen, que tenen l’última paraula respecte de la zona. De fet, significa que són els servidors que administren la zona. Aquests servidors es configurem com a autoritaris de la zona. Les respostes que emeten a consultes referents a la seva zona porten un segell indicant que són autoritàries, que provenen de la base de dades distribuïda de l’espai de noms de domini.

Els servidors de noms guarden en una memòria cau les respostes que reben d’altres servidors. Aquesta informació també és utilitzada per elaborar respostes a consultes de dominis de fora de la zona de la qual són autoritaris. És a dir, quan un servidor rep d’un altre la llista de servidors autoritaris (en una consulta iterativa) per a una zona, aquesta llista s’emmagatzema a la memòria cau. Quan un servidor rep una resposta a una consulta també es guarda. Quan rep una resposta negativa, indicant que el domini de la consulta o el tipus de dada sol·licitat no existeix, també ho guarda. En aquest cas s’anomena negative caching.

Un servidor respon utilitzant la informació disponible en la base de dades de la seva zona (resposta autoritativa) o de la informació emmagatzemada en la seva memòria cau (provinent de consultes a zones externes efectuades anteriorment).

Quan rep una consulta a una zona externa que ja s’havia efectuat abans, s’utilitza la resposta de la memòria cau. També s’agafa de la memòria cau la llista de servidors autoritaris per a una zona més propera al domini que es busca, per tal de no preguntar als servidors arrel. Quan un servidor de noms respon utilitzant la informació de la memòria cau, la resposta és no autoritativa. No prové del servidor autoritari de la zona, sinó que s’utilitza una informació prèviament obtinguda (i que pot estar desfasada).

Per exemple, s’ha fet una consulta per al domini adm.ioc.cat i en el procés de resolució recursiu el servidor ha obtingut la llista de servidors autoritaris per als dominis cat. i ioc.cat. Si ara es demana al mateix servidor pel domini inf.ioc.cat. primerament provarà de resoldre aquest domini, però com que és desconegut, el següent domini més pròxim és ioc.cat. Aquest sí que el coneix, perquè el té emmagatzemat a la memòria cau de la resposta anterior. S’utilitzarà la llista de servidors autoritaris del domini ioc.cat. per obtenir una resposta o per continuar descendint per l’arbre de l’espai de noms.

Emmagatzemar informació de les respostes d’altres servidors en la memòria cau ofereix dos grans avantatges:

  1. Incrementa la velocitat de resposta. Ja no cal anar a trobar la resposta a la font de dades de la zona, sinó que s’utilitza la informació d’una resposta anterior.
  2. Evita la sobrecàrrega dels servidors arrel.

No cal anar al node arrel per cada consulta un cop que es disposa en la memòria cau d’informació més propera al domini a cercar. La utilització de la memòria cau té, però, un inconvenient que cal considerar: les dades no necessàriament són actualitzades. El DNS es fonamenta en una base de dades jeràrquica i distribuïda en la qual la informació es troba en els fitxers gestionats per cada servidor de zona. Una dada emmagatzemada en la memòria cau pot no reflectir la dada real, que ha estat modificada en el servidor autoritari de zona però que encara no s’ha propagat perquè es manté en la memòria cau fins que caduca el seu TTL (temps de vida).

Són servidors autoritaris els que administren una zona (tant el servidor primari o mestre com els secundaris o esclaus). Tenen accés a la informació original de la base de dades de zona.

Són respostes no autoritàries les que provenen de la informació desada en la memòria cau.

Fixeu-vos que si la informació de la memòria cau es desés indefinidament, els canvis que es fessin en els servidors autoritaris no es propagarien als altres servidors (perquè segurament ja disposarien d’una resposta en la seva memòria cau). Cal un mecanisme perquè la informació de la memòria cau caduqui transcorregut un cert interval de temps. Anomenem TTL, Time To Live o temps de vida, l’interval de temps que les dades han de perdurar en la memòria cau. Un cop transcorregut aquest temps, les dades s’eliminen. Si fa falta una dada, per obtenir-la caldrà fer una nova consulta.

Servidor només cau

La configuració completa d’un servidor DNS no és difícil, però és entretinguda. Cal crear cada fitxer de zona amb les entrades pertinents de cada host de la zona. Hi ha organitzacions petites que no necessiten configurar el servei DNS completament, en tindrien prou a tenir un servidor DNS local que permetés accelerar les consultes DNS que es fan a l’exterior.

Sabem que tota resolució de nom de domini comporta una consulta a un servidor DNS, usualment el del proveïdor de servei d’Internet (ISP). Es pot posar en marxa un servidor només cau en una xarxa local per proporcionar més eficiència a les consultes. El servidor només cau no administra cap zona, no té registres de recurs, simplement rep les consultes dels clients, les tramet al servidor DNS extern, rep les seves respostes, les desa en la memòria cau i les retorna al client.

El benefici d’aquest esquema és que el servidor només cau acumula en la memòria les respostes que va obtenint. En les consultes següents, si es demana pels mateixos dominis, ja no li cal passar la consulta a l’exterior, sinó simplement respondre des de la memòria cau. Evidentment, les seves respostes són sempre no autoritàries.

Un servidor només cau només emmagatzema les respostes d’altres servidors externs en la memòria, però no gestiona cap zona. No és autoritari, simplement augmenta l’eficiència quan rep consultes de les quals ja en sap la resposta (la té a la memòria cau).

Tot seguit es mostra un exemple de configuració d’un servidor només cau:

options {
	listen-on port 53 { 127.0.0.1; };
	listen-on-v6 port 53 { ::1; };
	directory 	"/var/named";
	dump-file 	"/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";
        allow-query-cache { any; };  
	allow-query       { any; };    
	recursion yes;
	/* Path to ISC DLV key */
	bindkeys-file "/etc/named.iscdlv.key";
};

logging {
  channel default_debug {
    file "data/named.run";
    severity dynamic;
  };
};

zone "." IN {
  type hint;
  file "named.ca";
};

En l’exemple anterior es pot observar que no es defineix cap fitxer de zona per ser administrada, excepte el fitxer de resolució directa dels servidors de noms de la zona arrel. Per tant, aquest servidor únicament atén peticions DNS com a intermediari i les desa a la memòria cau. El directori on emmagatzema temporalment la informació és /var/named/data.

Creació de zones

El propòsit principal d’un servei DNS és administrar una zona com per exemple una xarxa local amb tots els equips d’una organització, o un conjunt de zones d’una organització més complexa. Per fer això caldrà definir els fitxers de configuració del servei DNS i definir cada una de les zones de què es compongui la xarxa. També caldrà crear els fitxers corresponents a la resolució inversa de cada xarxa i del loopback.

Per crear una zona pròpia caldrà:

  • Definir les zones en el fitxer de configuració del servei.
  • Crear el fitxer de zona en què es defineix la resolució directa per a cada host de la zona i les característiques de la zona.
  • Crear el fitxer de resolució inversa de la zona.

S’ha vist que les zones descriuen els equips que en formen part. És a dir, cada fitxer de zona és una base de dades que descriu els hosts que hi ha en la zona i la mateixa zona. Vegem dos exemples de fitxers de zona abans d’explicar com descriure cadascun dels elements que hi pertanyen:

  • Zona edt.org., corresponent a la resolució directa.
  • Zona 1.17.172.in-addr.arpa., corresponent a la resolució inversa de la zona. Aquesta zona correspon a la xarxa 172.17.1.0/24.
; Fitxer de configuració dels hosts de la zona:
; edt.org  (172.17.1.0/24)
$TTL 3D
@ IN SOA ns.edt.org. netadmin.edt.org. 1 3H 15M 1W 1D
    NS ns
    MX 10 mailhost
ns		A	172.17.1.1
mailhost	A	172.17.1.2
server		A 	172.17.1.10
hp-7200c	A	172.17.1.5
hp-l6p		A	172.17.1.6
router 		CNAME	server
www		CNAME	server
ftp		CNAME	server
printer         CNAME   hp-l6p
; zona 1.17.172.in-addr.arpa.
; edt.org  (reverse)  172.17.1.0/24
$TTL 3D
1.17.172.in-addr.arpa.  IN SOA ns.edt.org. netadmin.edt.org. 1 3M 1M 1W 1D
    NS ns.edt.org.
1	PTR 	ns.edt.org.
2	PTR	mailhost.edt.org.
5	PTR	hp-7200c.edt.org.
6	PTR	hp-l6p.edt.org.
10      PTR     server.edt.org.

Tipus de registres

Aprofitar fitxers de zona

Els fitxers de zona de descripció del loopback i dels nodes arrel són pràcticament iguals per a totes les zones, de manera que usualment es copien d’una zona ja existent en lloc d’escriure’ls de nou.

El sistema de noms de domini és una base de dades jeràrquica i distribuïda en què cada servidor de noms gestiona la informació corresponent a la zona de la qual és autoritari. Cada zona conté informació dels hosts que la formen. La informació de zona s’emmagatzema en forma de registre de recurs o resource record (RR).

Aquest registre conté la informació que permet identificar cada nom de domini amb l’adreça IP corresponent, anomenat forward mapping o resolució directa. També conté la informació per identificar cada adreça IP amb el nom de domini corresponent, anomenat reverse mapping o resolució inversa. La informació de zones conté altres dades que permeten identificar els servidors DNS autoritaris per la zona, els servidors de correu…

La configuració d’una zona s’emmagatzema en un conjunt de fitxers anomenat fitxers de zona. L’especificació del DNS diu com han de ser aquests fitxers de zona i com s’hi han de descriure els registres de recurs (descripció de cada element que pertany a la zona).

El conjunt dels registres de recurs de totes les zones de l’espai de noms formen la base de dades distribuïda jeràrquica del sistema DNS.

Aplicacions DNS

Hi ha diverses aplicacions que proporcionen el servei de servidor de noms. La més famosa i utilitzada és el BIND (Berkeley Internet Name Domain). En la versió BIND 9 s’utilitza un fitxer de configuració anomenat /etc/named.conf per configurar el servidor i indicar-li quins són i on es troben els fitxers de zona.

En qualsevol zona hi haurà almenys els fitxers de zona següents:

  • Un fitxer amb les associacions dels noms de domini a adreces IP. Aquest fitxer defineix la resolució directa.
  • Un fitxer per a cada subxarxa amb l’associació de cada adreça IP al seu nom de domini canònic. Defineix la resolució inversa.
  • Un fitxer amb la definició de la resolució inversa del loopback.
  • Un fitxer amb la descripció dels nodes arrel d’Internet.

Un cop que els fitxers de zona contenen tots els registres de recurs necessaris, cal configurar el servidor de noms perquè utilitzi aquests fitxers. Si bé la configuració dels fitxers de zona és estàndard (definida per l’especificació DNS), la configuració del servidor depèn del programa que s’utilitzi.

Registres de recurs

Cada fitxer de zona conté un conjunt d’entrades cadascuna de les quals defineix un registre de recurs (RR). Els registres més usuals són SOA, NS, A, CNAME, PTR i MX. L’ordre en què apareixen és indiferent, però usualment és el mateix dels exemples. Cada línia té el format:

domini classe [ttl] tipus rdata:
  • domini és el nom de domini que s’està definint.
  • classe només pren actualment el valor “IN”, per Internet.
  • ttl és un camp opcional que descriu el temps de vida durant el qual cal emmagatzemar aquest registre en la memòria cau.
  • tipus és el tipus d’RR que s’està definint.
  • rdata és el valor que s’associa al nom de domini que es defineix.

Tot i que es pot definir un TTL en cada registre de recurs, el més usual és definir un TTL genèric per a totes les entrades del fitxer de zona. El servidor BIND 9 utilitza la directiva $ttl (per exemple: $ttl1 1h) per indicar el temps que els altres servidors de noms han de guardar en la seva memòria cau les respostes d’aquest servidor (una hora en l’exemple).

En la secció “Annexos” del web d’aquest mòdul trobareu altres tipus d’RR. També es poden trobar en l’especificació DNS.

Registre SOA

El registre de recurs SOA (start of authority o inici de definició de zona amb autoritat) diu que el fitxer de zona on es troba és la millor font de dades per a la zona, que el servidor de noms és autoritari per a la zona. Acostuma a ser el primer RR que hi ha en el fitxer de zona, tot i que no és obligatori. Per cada fitxer de zona hi ha d’haver només un registre SOA.

Un registre SOA té el format:

nomDomini. IN SOA nsPrimari. admin.nsPrimari. (opcions-slaves)

Un exemple seria el següent:

inf.ioc.cat. IN SOA ns1.inf.ioc.cat. admin.ns1.inf.ioc.cat. ( 1h 3h 1h 1w 1h )

La descripció de cada camp és la següent:

  • nomDomini. indica el nom del domini que s’està definint i pel qual el servidor de noms és autoritari. Fixeu-vos en el punt final: és important posar-lo.
  • IN indica que la classe és Internet.
  • SOA informa que és un registre de recurs tipus SOA.
  • nsPrimari. és el nom del host servidor de noms primari per a aquesta zona. Un altre cop pareu atenció al punt final.
  • admin.nsPrimari. és l’adreça de correu electrònic de l’administrador del servidor de noms de domini, amb el format usuari.servidor. El primer punt que separa el nom d’usuari i el nom del servidor cal interpretar-lo com una arrova (usuari@servidor).
  • opcions-slaves són paràmetres que s’indiquen entre parèntesis i que serveixen per definir com ha de ser la comunicació entre el servidor primari (o master) i els servidors secundaris (o slaves). A grans trets s’indiquen els conceptes següents:

Punt final en el nom de domini

Posar o no el punt al final d’un nom de domini és important. Si acaba amb punt és un nom de domini absolut. Si no du punt és un nom relatiu i s’hi afegirà el domini per defecte al final.

  • Serial: el número de sèrie de la versió de les dades. A cada canvi de les dades de la zona, el número s’incrementa.
  • Refresh: temps a transcórrer entre cada refresc de dades del servidor secundari.
  • Retry: temps d’espera per tornar a intentar un refresc quan el servidor secundari ha fallat en l’intent d’actualitzar les seves dades des del servidor primari.
  • Expire: temps a partir del qual les dades del servidor secundari es consideren sense autoritat si no s’han refrescat abans.
  • Minimum: valor del TTL dels camps per defecte. Recordeu que a cada camp s’hi pot assignar un TTL específic. Segons la versió del servidor indicarà el TTL de les respostes negatives (negative caching), ja que el temps TTL es defineix per la directiva $ttl.

Registre NS

El registre de recurs NS (name server o servidor de nom) defineix un servidor de noms autoritatiu per a la zona. Hi haurà tantes entrades NS com servidors de noms autoritatius hi hagi en la zona. L’estàndard DNS en recomana almenys dos (un de primari o master i un de seguretat, secundari o slave).

Un registre NS consta dels camps:

nomDomini. IN NS nameServer.

Un exemple seria aquest:

inf.ioc.cat. IN NS ns1.inf.ioc.cat.

La descripció de cada camp és la següent:

  • nomDomini. indica el nom del domini que s’està definint.
  • IN indica que la classe és Internet.
  • NS descriu que es tracta d’un tipus de registre de recurs en què es defineix un servidor de noms.
  • nameServer. és el nom del servidor de noms. Fixeu-vos un altre cop que tant nomDomini. com nameServer. acaben en punt per indicar que són noms de domini absolut o FQDN.

En la llista següent es pot veure part d’una resposta a una consulta nslookup per observar quins són els servidors de noms de Yahoo:

Authoritative answers can be found from: 
yahoo.com       nameserver = ns2.yahoo.com. 
...
ns8.yahoo.com   internet address = 202.165.104.22

Registre A

Un registre de recurs A (address o adreça) associa un nom de host a una adreça IP (resolució directa). Per cada nom de host de la xarxa caldrà disposar d’una entrada que associï el nom del host a la seva adreça IP.

Un registre A consta dels camps:

nomHost. IN A IP

Un exemple seria aquest:

mahatma.inf.ioc.cat. IN A 192.168.0.2
siddhartha           IN A 192.168.0.3

La descripció de cada camp és la següent:

  • nomHost. indica el nom del host que s’està definint. Pot ser relatiu (sense punt final) o absolut (afegint el domini complert al final).
  • IN indica que la classe és Internet.
  • A informa que es tracta d’un tipus de registre de recurs de definició d’adreça IP.
  • IP és l’adreça IP assignada al host.

Fixem-nos un altre cop que nomHost. acaba en punt per indicar que és un FQDN. Si no acabés en punt s’interpretaria com un nom relatiu al SOA que s’està definint actualment. Un host pot tenir més d’una IP assignada al mateix nom de host. Quan això passa s’anomena multi-homed. Simplement caldrà que hi hagi un registre A per a cada adreça IP. Constarà del mateix nom de host a l’esquerra de la definició i de la corresponent adreça IP a la dreta. Per exemple:

superserver.dom.com. IN A 10.0.0.1 
superserver.dom.com. IN A 10.0.0.2
multihomed.edt.org.  IN A 172.12.0.1
                     IN A 172.12.0.2

A i CNAME

Compte! No s’han de confondre els registres de recurs A i CNAME: el registre A defineix hosts, mentre que el registre CNAME defineix àlies.

Els noms definits en els registres de tipus A són noms canònics. Un host es pot identificar per més d’un nom, però només un és el nom canònic (original), la resta són àlies. Els noms canònics es defineixen amb el tipus de registre A. Els àlies es defineixen amb el tipus de registre CNAME.

Registre CNAME

Els registres de recurs CNAME (canonical name o nom canònic) associen un àlies a un nom canònic.

Un registre CNAME consta dels camps:

nomHost. IN CNAME hostCanonicalName. | IP

Un exemple seria aquest:

ftp.inf.ioc.cat. IN CNAME mahatma.inf.ioc.cat.
tftp.inf.ioc.cat IN CNAME 192.168.0.2

Exemple de host multi-homed

Es vol posar l’àlies super1 i super2 a cada una de les IP del host superserver.com (un host que té dues adreces IP assignades a aquest nom). Les entrades CNAME serien les següents:

  • super1.dom.com. IN CNAME 10.0.0.1.
  • super2.dom.com. IN CNAME 10.0.0..2.

La descripció de cada camp és la següent:

  • nomHost. indica el nom de l’àlies que s’està definint.
  • IN indica que la classe és Internet.
  • CNAME informa que es tracta d’un registre de recurs de definició d’un àlies.
  • hostCanonicalName | IP és el nom de host canònic al qual s’assigna l’àlies. Fixeu-vos un altre cop que és un FQDN i que acaba en punt. Generalment, els registres CNAME tenen a la part dreta de la definició un nom canònic, però de vegades caldrà indicar-hi una adreça IP. Penseu en un host multi-homed amb múltiples adreces IP que a més té àlies. Si la definició fos pel nom canònic del host, no se sabria quina de les adreces IP correspon a l’àlies. En aquests casos, el CNAME apunta a una adreça IP.

La resolució dels àlies s’obté buscant l’entrada de l’àlies en el fitxer de zona. Amb l’entrada CNAME s’obté el nom canònic corresponent a l’àlies. Un altre cop es torna a buscar en el fitxer de zona, ara el nom canònic. Una entrada de tipus A proporcionarà l’adreça IP corresponent (àlies –> CNAME –> nom canònic –> A –> adreça IP). Un àlies mai pot aparèixer a la part dreta d’una definició de registre de recurs.

Registre PTR

Un registre de recurs PTR (pointer o punter) associa una adreça IP al nom de host corresponent (resolució inversa). Cal una entrada PTR per a cada interfície de xarxa de la zona, per a cada adreça IP.

Un registre PTR consta dels camps:

ipInversa.in-addr.arpa. PTR hostCanonicalName.

Un exemple seria aquest:

2.20.168.192.in-addr.arpa. IN PTR mahatma.inf.ioc.cat.

La descripció de cada camp és la següent:

  • ipInversa.in-addr.arpa. indica l’adreça IP escrita en forma de domini in-addr.arpa per poder fer la resolució inversa. Les adreces IP s’escriuen al revés quan formen part del domini in-addr.arpa. Així, una IP 192.168.20.2 s’escriu 2.20.168.192.in-addr.arpa.
  • IN indica que la classe és Internet.
  • PTR informa que es tracta d’un registre de recurs de definició de la resolució inversa d’una adreça IP.
  • hostCanonicalName. és el nom de host FQDN assignat a l’adreça IP. El nom del host ha de ser per força el nom canònic. No hi pot haver dues definicions de la mateixa IP amb noms diferents (àlies), només de la IP al nom canònic.

Registre MX

Un registre MX (mail exchanger o servidor de correu electrònic) defineix un servidor de correu. Es pot posar una entrada MX per a cada servidor de correu, però no és obligatori que n’hi hagi cap.

Un registre MX consta dels camps:

nomDomini. IN MX num mailServer.

Un exemple seria aquest:

inf.ioc.cat. IN MX 10 mailhost.inf.ioc.cat.

La descripció de cada camp és la següent:

  • nomDomini. indica el nom del domini que s’està definint.
  • IN indica que la classe és Internet.
  • MX informa que es tracta d’un registre de recurs que defineix un servidor de correu per a aquest domini.
  • num és un valor numèric que expressa el grau de preferència d’aquest servidor de correu respecte a altres servidors de correu del domini. El valor més baix és el que es prefereix. Són valors arbitraris que defineix l’administrador de xarxes.
  • mailServer. correspon al nom FQDN del servidor de correu que s’està definint.

Podem observar la llista de servidors de correu de Google fent:

[user@host ~]$ host  google.com

Exemples de registres de recurs (RR)

Les dues llistes següents mostren exemples dels fitxers de configuració per a la resolució directa i la resolució inversa de la zona ioc.cat. En el primer es defineixen dos servidors de nom, un encaminador, una impressora i dos hosts. El primer dels servidors de noms també fa les funcions de servidor de correu, web i FTP.

;Exemple de fitxer de zona ioc.cat
$TTL 3D
ioc.cat. IN SOA ns1.ioc.cat. admin.ioc.cat. { 23; 8H; 2H; 4W; 1D; };
      NS ns1.ioc.cat.
      NS ns2.ioc.cat.
      MX 10 correu.ioc.cat.
ns1.ioc.cat. A     192.168.0.5; servidor amb 2 ip
             A     172.16.20.5
ns2.ioc.cat. A     192.168.0.7; servidor dns slave
router       A     192.168.0.1; router. Nom relatiu
correu       CNAME ns1 ; alias correu
www          CNAME ns1 ; alias web
ftp          CNAME ns1 ; alias ftp
hp-7200c     A     192.168.0.2; impressora
pc01         A     192.168.0.50
pc02         A     192.168.0.51

En la llista següent es pot veure com es defineix una entrada PTR per a cada nom canònic definit en la resolució directa per a una subxarxa concreta. La subxarxa 192.168.0.0/24 utilitza el fitxer 0.168.192.in-addr.arpa per a la resolució inversa:

; Zona 0.168.192.in-addr.arpa.
; Exemple de fitxer de zona inversa ioc.cat
; correspon a la xarxa 192.168.0.0/24
$TTL 3D
ioc.cat. IN SOA ns1.ioc.cat. admin.ioc.cat. { 23; 8H; 2H; 4W; 1D;};
   NS ns1.ioc.cat.

5  PTR ns1.ioc.cat.
7  PTR ns2.ioc.cat.
1  PTR router.ioc.cat. 
2  PTR hp-7200c.ioc.cat. 
50 PTR pc01.ioc.cat. 
52 PTR pc02.ioc.cat.

Configuració dels fitxers de zona

Exemple de configuració del servidor de noms

Si tenim una zona que es compon d’una única xarxa 192.168.20.0/24 amb el nom de domini inf.ioc.cat caldran els següents fitxers de zona:

  • El fitxer de resolució directa inf.ioc.cat.zona.db.
  • El fitxer de resolució inversa 192.168.20.zona.db o inf.ioc.cat.rev.zona.db.
  • El fitxer de resolució inversa del loopback.
  • El fitxer amb la informació dels nodes arrel del DNS, named.ca.

Els fitxers de zona contenen els registres de recurs que formen la base de dades de la zona. Cal configurar el servidor de noms per indicar-li quins són i on són aquests fitxers. Cada administrador anomena els fitxers com li plau o seguint l’estil marcat per l’aplicació servidor DNS que utilitza. Un exemple és anomenar els fitxers de zona amb el format db.nomDomini per al fitxer de resolució directa i db.ipSubXarxa per a la resolució inversa per a cada xarxa de la zona. En els exemples d’aquesta documentació s’utilitza la sintaxis nomDomini.zona.db per a la resolució directa, nomDomini.rev.zone.db per als de la resolució inversa i ip.rev.zone.db quan cal definir la resolució inversa d’altres xarxes.

Independentment de l’aplicació que s’utilitzi com a servidor de noms, caldrà configurar-la per dir-li on són aquests fitxers, com es diuen, si fan la funció de servidor autoritari per a la zona o no, si fan la funció de primari o secundari i altres opcions possibles.

L’aplicació actualment més usada és BIND, que es configura mitjançant un fitxer anomenat /etc/named.conf. La manera d’indicar a BIND 9 quin és el directori per defecte on es troben els fitxers de configuració és usant la directiva options { directory ”/var/named”; }.

Per cada fitxer de zona caldrà definir una entrada al fitxer de configuració global de BIND indicant el nom de la zona, el tipus i el nom del fitxer.

La sintaxi és:

zone nom_zona in { type master|slave|hint; file "nom_fitxer_zona"; };

Un exemple de configuració de zona podria ser aquest:

zone inf.ioc.cat in { type master; file "inf.ioc.cat.zone.db;" }.

La descripció de cada camp és la següent:

  • zone nom_zona: com es pot veure en l’exemple es defineix una zona corresponent al domini inf.ioc.cat.
  • type master | slave | hint: el servidor serà primari (master) per a aquesta zona. Serà el que tindrà els fitxers amb les dades de la zona. El camp tipus pot prendre els valors master, slave i hint, que signifiquen el següent:
  • master: el servidor té autoritat per a aquesta zona i gestiona els fitxers de zona.
  • slave: el servidor és autoritari per a la zona, però obté les dades de la zona del servidor primari o master.
  • hint: indica que es tracta de la informació corresponent als servidors de noms de la zona arrel. Aquesta informació té un tractament especial diferent del de les altres zones.
  • file nom_fitxer_zona: indica el fitxer amb els registres de recurs de la zona. En l’exemple és el fitxer inf.ioc.cat.zone.db.

Cal parar especial atenció en la definició dels fitxers de zona per a la resolució inversa, utilitzant per exemple la xarxa 192.168.20.0/24. La zona s’anomena 20.168.192.in-addr.arpa, i el fitxer de zona, per exemple, db.192.168.20. El nom del fitxer conté l’adreça de xarxa en l’ordre natural, però el domini té els octets invertits perquè forma part del domini in-addr.arpa.

Tot seguit es mostra l’exemple del fitxer de configuració del servei que inclou la definició de la zona directa edt.org. i la definició de la corresponent resolució inversa 1.17.172.in-addr.arpa. El contingut dels fitxers que descriuen els registres de recurs de cada una d’aquestes dues zones s’ha llistat a l’inici de l’apartat.

// server domini: "edt.org."
// xarxa 172.17.1.0/24
options {
	listen-on port 53 { 127.0.0.1; 192.168.122.109; };
	listen-on-v6 port 53 { ::1; };
	directory 	"/var/named";
	dump-file 	"/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";

        allow-query-cache{ any; };  
        allow-query  { any; };
        recursion yes;

	/* Path to ISC DLV key */
	bindkeys-file "/etc/named.iscdlv.key";
};

logging {
  channel default_debug {
    file "data/named.run";
    severity dynamic;
    };
};

zone "." IN {
  type hint;
  file "named.ca";
};

include "/etc/named.rfc1912.zones";

zone "edt.org" {
  notify no;
  type master;
  file "edt.org.zone.db";
};

zone "1.17.172.in-addr.arpa" {
  notify no;
  type master;
  file "edt.org.rev.zone.db";
};

Delegació de zona

El sistema de noms de domini DNS és una estructura jeràrquica i distribuïda. Hem vist com crear dominis i administrar-los en una zona que pot contenir altres subdominis que no s’hagin delegat. Per fer que l’estructura jeràrquica funcioni apropiadament cal poder delegar subdominis a altres entitats.

Delegar un subdomini implica transferir tota l’administració del domini delegat a una altra entitat. Un cop delegat, aquesta entitat és la responsable total de la seva gestió. Caldrà establir el lligam entre el domini pare i el domini fill. Segurament caldrà realitzar els passos següents:

En el servidor de noms del domini fill:

  • Generar els fitxers de zona directa i inversa i configurar apropiadament el servei.
  • Verificar-ne el funcionament.

En el servidor de noms del domini pare:

  • Realitzar la delegació.
  • Verificar la delegació consultant registres del domini fill.

Optimitzar la consulta de la zona pare en el domini fill:

  • Observar que des del servidor de noms fills no es disposa d’accés a la informació del domini pare. No hi ha lligam. Bé, sí, de fet, hi ha el mateix lligam que amb qualsevol altre domini. S’hi podrà accedir o no igual que a qualsevol altre domini.
  • Fer del servidor de noms fill un servidor esclau de la zona pare.

Com a exemple pràctic creem una zona delegada inf.edt.org. corresponent a la xarxa 172.19.0.0/16. Aquests són els fitxers de zona:

; Fitxer de configuració dels hosts de la zona:
; inf.edt.org  (172.19.0.0/16)
$TTL 3D
@ IN SOA ns.inf.edt.org. netadmin.inf.edt.org. 1 3H 15M 1W 1D
    NS ns
    MX 10 mailhost
ns		A	172.19.1.1
mailhost	A	179.19.1.2
printer 	A	179.19.2.5
server		A 	179.19.2.10
router 		CNAME	server
; zona 19.172.in-addr.arpa.
; inf.edt.org  (reverse)  172.19.0.0/16
$TTL 3D
19.172.in-addr.arpa.  IN SOA ns.inf.edt.org. netadmin.inf.edt.org. 1 3M 1M 1W 1D
     NS ns.inf.edt.org.
1.1  PTR ns.inf.edt.org.
1.2  PTR mailhost.inf.edt.org.
2.5  PTR printer.inf.edt.org.
2.10 PTR server.inf.edt.org.

El servidor de noms del domini inf.edt.org. es configura de manera anàloga a com s’han configurat els servidors en els exemples anteriors. Evidentment cal indicar quines són les zones que administra:

zone "inf.edt.org" {
  notify no;
  type master;
  file "inf.edt.org.zone.db";
};
zone "19.172.in-addr.arpa" {
  notify no;
  type master;
  file "inf.edt.org.rev.zone.db";
};

De fet, en el procés de delegació de zona no cal fer res d’especial en el servidor de la zona delegada. Només cal fer la configuració apropiada, posar-lo en funcionament i verificar-lo igual que es fa per a qualsevol altre servidor. On és, doncs, la màgia de la delegació? En el lligam que es fa del domini pare a la zona delegada.

Delegar una zona consisteix a indicar al fitxer de la zona pare quin és el servidor de la zona delegada.

  • Això es fa amb un registre de recurs NS, indicant l’FQDN del servidor de noms de la zona delegada.
  • Usualment caldrà a més un registre de recurs de tipus A, que indiqui quina és l’adreça IP del servidor de noms descrit en el punt anterior. Aquest és el registre de recurs que fa el lligam (glue record) que possibilita la “màgia” de la delegació.

Finalment, cal veure com es fa en la zona edt.org. per delegar. Caldrà afegir al fitxer de zona els dos registres de recurs que possibiliten la delegació:

; Fitxer de configuració dels hosts de la zona:
; edt.org  (172.17.1.0/24)
$TTL 3D
@ IN SOA ns.edt.org. netadmin.edt.org. 1 3H 15M 1W 1D
    NS ns
    MX 10 mailhost
ns		A	172.17.1.1
mailhost	A	172.17.1.2
server		A 	172.17.1.10

... output suprimit ...
; delegació de zona inf.edt.org.
inf.edt.org.    NS ns.inf.edt.org.
ns.inf.edt.org  A  172.19.1.1

Si s’analitza la primera de les línies de delegació, s’observa que es defineix que el domini inf.edt.org. està gestionat per un servidor de noms anomenat ns.inf.edt.org. En la segona línia es fa el lligam físic que possibilita saber on és aquest servidor de noms del domini delegat. Aquesta segona línia indica que el servidor de noms és el corresponent a l’adreça IP 172.19.1.1.

¿Què passa quan es pregunta al servidor de noms de la zona edt.org. pel host printer.inf.edt.org.? El servidor busca en el seu fitxer de zona i detecta que les consultes que acaben en inf.edt.org. han de ser gestionades per un host anomenat ns.inf.host.org. A continuació, intenta resoldre aquest nom consultant un altre cop el fitxer de zona. Ara trobarà que el servidor de noms anomenat ns.inf.edt.org. correspon a l’adreça IP 172.19.1.1. Ara que ja sap on localitzar-lo, continuarà la resolució (està fent una consulta recursiva) apropant-se al domini de destinació. Ara preguntarà per printer al servidor ns.infedt.org. i d’aquest n’obtindrà la resposta autoritativa.

Comprovar la delegació

Per comprovar la delegació de zona cal tenir present que primer cal verificar la zona delegada per si mateixa per tal que tot sigui correcte. Un cop és segur que funciona bé, cal verificar el lligam de la zona pare amb la zona fill. Això es pot realitzar fent consultes locals des del servidor pare de registres de la zona delegada.

Servidor delegat actuant com a esclau de la zona pare

Tal com s’ha vist, des del punt de vista de la zona delegada no hi ha cap lligam a la zona pare. És a dir, des del punt de vista d’un client de dins del domini inf.edt.org., demanar pel host smtp.gmail.com. o demanar pel host server.edt.org. implica el mateix procediment de resolució. Implica fer una consulta externa aplicant els mecanismes generals de resolució que s’han explicat en apartats anteriors. Sembla mentida, però el subdomini inf té tant (des)coneixement del seu domini pare com de qualsevol altre domini d’Internet.

Ara bé, ¿no és lògic pensar que si tots formen part d’una mateixa estructura organitzativa hi haurà sovint consultes des del subdomini inf referents a hosts del domini edt.org? Segur que els empleats de l’organització d’inf contacten sovint amb altres hosts de l’empresa. Per tant, seria bo poder proporcionar coneixement del domini edt.org. al servidor de noms delegat. D’aquesta manera totes les consultes relacionades amb edt.org. serien respostes també directament pel propi servidor delegat.

En l’apartat Transferències de zona es mostra com fer que el servidor de noms de la zona inf sigui esclau de la zona edt.org.

El mecanisme per implementar aquest traspàs de coneixement entre la zona pare i la zona delegada consisteix a fer del servidor de noms delegat un servidor secundari de la zona pare.

Quan es tracta de subdominis dins d’una mateixa estructura organitzativa (una mateixa empresa o institució), és usual que els servidors de noms dels dominis delegats facin també de servidors esclaus del domini pare.

D’aquesta manera poden respondre per si mateixos les consultes referents a tot el domini.

Servei amb adreces IP dinàmiques

El servei de noms permet associar a una adreça IP un nom de domini. Així, per exemple, a l’adreça IP del servidor de l’usuari pere se li assigna el nom de host pere.ioc.cat en el domini de l’IOC. Ara bé, què passa si el host rep una IP dinàmica (de manera que la seva adreça IP pot variar)? Evidentment, en els fitxers de zona que lliguen les adreces IP amb els noms de domini cal saber prèviament l’adreça a usar i això no permetria assignar noms a adreces IP dinàmiques. Però també existeix un mecanisme anomenat DDNS o DNS dinàmic que permet fer actualitzacions dinàmiques en la base de dades de les zones.

El procotocol o extensió DDNS (Dynamic DNS) permet realitzar actualitzacions en una base de dades DNS de manera dinàmica. De fet, es permeten afegir i eliminar registres de recurs dels fitxers de zona.

Aquest protocol està descrit a l’RFC 2136 de l’IETF.

Utilitzant DDNS es poden afegir i eliminar registres a la base de dades d’una zona de manera que a mesura que assigna adreces dinàmiques als seus clients un servidor DHCP també pot anar realitzant peticions d’actualitzacions al servidor DNS per tal de que aquests clients disposin també de noms de domini.

Transferències de zona

Els dominis d’Internet s’administren en zones, cada una gestionada per dos o més servidors de noms. Segons l’estàndard, cada zona té un servidor primari i almenys un servidor secundari. Ambdós són autoritaris per a la zona que administren. Caldrà, doncs, que aquests servidors disposin d’informació tan coherent com sigui possible, que comparteixin la mateixa informació. Això es fa mitjançant les transferències de zona.

Sovint, els servidors de noms actuen també com a memòria cau, emmagatzemant les respostes d’altres servidors per tal d’incrementar la seva eficiència. Quan emeten aquestes respostes actuen de forma no autoritària.

Sovint es confonen els conceptes relatius a la transferència de zones (servidor primaris i secundaris) amb els conceptes relacionats amb l’autoritat o no de les respostes. El següent destacat intenta aclarir cada un d’aquests termes.

Primari/secundari(s), també anomenats master/slave(s): una zona és gestionada per un servidor primari (master) i un o més servidors secundaris (slave) o de seguretat.

Autoritari/no autoritari: els servidors d’una zona (el primari i els secundaris) són autoritat per a aquella zona que administren. Les respostes que emeten basant-se en la informació emmagatzemada en la memòria cau (informació procedent d’altres servidors de noms en lloc de procedir de la pròpia base de dades de zona) són no autoritàries.

Transferència de zona: la informació de la base de dades de la zona ha de ser coherent entre els servidors primari i secundaris. La transferència de zona és el mecanisme que s’estableix per fer que comparteixin la mateixa informació.

El servidor primari manté la base de dades de la zona i l’actualitza. Aquesta informació es copia als servidors secundaris utilitzant un procés de transferència.

Establir com i quan s’ha de fer aquesta transferència és important per proporcionar un bon servei DNS. Cal buscar un compromís entre actualitzar constantment la informació però consumir recursos excessius i no fer-ho però disposar d’informació caducada.

De fet, un servidor pot ser secundari per a una zona (o més d’una) i primari per a altres zones. Imaginem que el servidor ioc.cat. és primari per a la seva zona i ha delegat el domini alumnes.ioc.cat. a l’associació d’alumnes. El servidor de noms dels alumnes és primari per a la seva zona. Per agilitar les consultes al domini ioc.cat., l’IOC i els alumnes han acordat permetre que el servidor de noms de la zona alumnes.ioc.cat. faci també de secundari de la zona ioc.cat.

L’actualització de la informació entre el servidor primari i els secundaris és molt important. Establir correctament aquests paràmetres és un art. Un servidor amb informació antiga causa un mal funcionament a la xarxa, mentre que un servidor actualitzat constantment consumeix recursos excessius.

Anar a la pàgina anterior:
Més informació
Anar a la pàgina següent:
Activitats