IMPORTANT: Per accedir als fitxer de subversion: http://acacha.org/svn (sense password). Poc a poc s'aniran migrant els enllaços. Encara però funciona el subversion de la farga però no se sap fins quan... (usuari: prova i la paraula de pas 123456)

Servidor DNS

De SergiTurWiki
Share/Save/Bookmark
(S'ha redirigit des de: Bind9)
Dreceres ràpides: navegació, cerca
Alert.png Aquesta wiki forma part dels materials d'un curs
Curs: DissenyXarxesLinux, LinuxAdministracioAvancada
Fitxers: ServidorsDHCPiDNS.pdf (ServidorsDHCPiDNS.odp), Fitxer:DNSIOC.pdf
Repositori SVN: https://svn.projectes.lafarga.cat/svn/iceupc/LinuxAdministracioAvan%c3%a7ada/moodle/sessio6/
Usuari: anonymous
Paraula de pas: sense paraula de pas
Autors: Sergi Tur Badenas

Vegeu també Client DNS

Contingut

DNS (Domain Name System)

DNS és un conjunt de protocols i serveis, la funció principal dels quals és l'assignació de dominis d'Internet a adreces IP numèriques. El fet d'assignar un nom (p.e. www.upc.edu) a una adreça IP (p.e 147.83.20.2) permet als usuaris utilitzar noms en comptes d'haver de recordar un codi numèric. Un altre dels avantatges de DNS és que permet abstraure el nom de màquina de la seva adreça IP (poden així variar sense tenir que modificar el nom de la màquina).

Sistemes de noms plans i jeràrquics

Hi ha dos tipus de sistemes de resol·lució de noms:

  • Plans: els noms de màquina de la xarxa són plans i no existeix el concepte de zona. Aquest tipus de sistemes no permeten reutilitzar noms de màquina ni definir els conceptes de domini, subdomini, etc.
  • Jeràrquics: Es poden definir dominis, zones i subdominis de forma que els noms de màquina puguin ser reutilitzats. Per exemple, el nom de màquina www, es pot tornar a utilitzar en diferents dominis. Exemples: www.iesebre.com, www.google.com, www.domini.com...

També podem parlar de sistemes:

  • Centralitzats: un sol servidor de DNS (o servidor que comparteix el fitxer /etc/hosts). Aquest sistemes són poc escabal·lables ja que les peticions al servidor centralitzat augmenten molt amb el nombre de clients.
  • Distribuïts: Múltiples servidors de noms es reparteixen la càrrega de proveir de resol·lució de noms als clients d'una xarxa. És el cas del sistema actual de DNS utilitzat a Internet i moltes xarxes LAN. Els servidors es reparteixen la feina, encarregant-se de zones de la xarxa. Aquests tipus de sistemes normalment s'apliquen a sistemes jerarquics.

Antecedents de DNS. Fitxer /etc/hosts

Per saber més sobre el fitxer /etc/hosts, consulteu l'article Client DNS.

Característiques

  • Domain Name System (DNS) és una base de dades distribuïda i jeràrquica que emmagatzema la informació associada als dominis de xarxes com per exemple Internet.
  • L'assignació de noms a adreces IP és la funcionalitat més comuna però no l'única.
  • Inicialment, DNS va néixer de la necessitat de recordar fàcilment els noms de les màquines. S'utilitzava el fitxer /etc/hosts per traduir IPs en noms de domini. El creixement explosiu de la xarxa va demostrar la poca escalabilitat d'aquest sistema i va sorgir el sistema DNS modern, on la càrrega i la informació de DNS es troba distribuïda de forma jeràrquica a diferents màquines d'Internet.

Terminologia

  • Zona: Normalment les zones són igual o més petites que un domini. Un domini privat o petit com iesebre.com pot tenir suficient amb una sola zona, però els dominis grans com els dominis de primer nivell (.com) o dominis de segon nivells grans (p.ex. hp.com) poden delegar la gestió de la resolució de noms en diferents zones. Un servidor de DNS pot gestionar una o més zones i no totes les zones d'un mateix domini han de ser gestionades per un sol servidor de DNS.
  • Query: o petició aka lookup o DNS lookup. És la consulta que fa un client o un servidor de DNS a un altre servidor de DNS. Hi ha dos tipus de consultes:
  • Record caching: les procés de resolució de DNS redueix la carrega individual de cada servidor fent cache de les peticions DNS per a un periode de temps després d'una primera resposta. Aquest temps està relacionat amb el que es coneix com TTL. Consulteu Cache, TTL i propagació
  • Delegació: Les zones grans com per exemple una zona de primer nivell com .edu bàsicament el que farà és delegar el domini als servidors de zona dels subdominis.
  • Circular dependencies: cal tenir en compte que els servidors de DNS al delegar especifiquin les delegacions utilitzant noms de servidor i nos pas adreces IP. Això implica que el servidor de DNS euq esta intentant resoldre la delegació necessita fent una consulta extra per obtenir la IP. Si el nom que dona la delegació és un subdomini del domini aleshores ocurreix una circular dependency o dependència circular. En aquest cas el servidor que proveix la delegació també ha de proveir les adreces IP d'un o més servidors autoritzats de la delegació. Aquesta informació se l'anomena glue
  • Glue records: són els registres comentat a l'anterior definició.
  • Authoritative (autoritzat): Consulteu #Servidor de noms autoritzat
  • lame server o dns lame server: Vegeu la secció Servidor_DNS#lame_servers. Els registres NS d'una zona han de coincidir amb els registres DNS llistats al registre SOA. Els servidors llistats al fitxer de zona però que no apareixen al registre SOA s'anomenen lame servers ([1])
  • Open DNS server: són els servidors de DNS als quals qualsevol màquina d'internet pot realitzar consultes per a dominis dels quals no és un servidor autoritzat. No es recomana que un servidor sigui al mateix temps authoritative d'un domini i recursiu (inclus encara que no sigui open) degut a que aleshores és un servidor que pot rebre atacs cache poisoning ( sense recursion, no hi ha cache, i aleshores és imposible enverinar-la). A més es pot utilitzar els servidor de DNS com a part d'un atac utilitzant la seva IP

Tipus de servidors DNS

Segons la funcionalitat del servidor podem classificar els servidors de DNS en:

  • Caching Server: En aquest tipus de configuració el servidor respondra a peticions recursives de DNS (posiblement només per a certes IPs autoritzades) i buscarà per al client la resposta adequada a la petició i a més l'emmagatzemarà en una cache. Les següents peticions seran més ràpides reduint d'aquesta forma l'ampla de banda consumit en peticions de DNS (no és una gran quantitat però), però també reduirà la latència (aquest valor si és més important). Si el servidor de cache obté les dades del servidors de zona master (és a dir, no l'obté de la seva cache), aleshores la resposta serà una resposta autoritzada, si les dades s'obtenen de la cache la resposta és non-authoritative.
  • Forwarding Server aka Proxy Name Server: és un subtipus de servidor de cache, que podriem dir que només fa de servidor de cache. És el nom que se li posa als servidors de DNS que simplement fan forward de totes les peticions de DNS que reben i les posen a la seva cache. Amb bind s'utilitzen els paràmetres forward (si el paràmetre forward apareix a la zona global amb el valor only aleshores els servidors és un servidor de forwading només) i forwarders tant com a paràmetres globals (vegeu forward only) com a paràmetres de zona (vegeu Forwarding de zones).
  • Master: Amb bind s'indica el type master. Són aquells servidors on els fitxers de zona estan en local, és a dir en fitxers locals
  • Slave: Amb bind s'indica el type slave. Els fitxers de zona s'obtenen mitjançant zone transfers, és a dir, els fitxers de zona s'obtenen de servidors masters.
  • Primary Master Server: BIND9 can be used to serve DNS records (groups of records are referred to as zones) for a registered domain name or an imaginary one (but only if used on a restricted network). També es pot ser un servidor de DNS primari en una xarxa privada o restringida. Cal tenir en compte que un servidor Master primary podria ser de tipus slave (vegeu mé endavant Stealth servers)
  • Secondary Master Server: és un servidor complementari, secundari o de backup que complementa al servidor primari. Normalment és una còpia de la configuració del servidor primari, però també es pot configurar com a servidor esclau de forma que els canvis fets al servidor primari es propaguin automàticament al servidor secundari. Es recomanen per a tenir una major disponibilitat del domini en cas de caiguda del servidor primari.
  • Hibrids: Servidors que fan de cache i de servidors primaris o secundaris de certes zones al mateix temps. Compte amb el Cache Poisoning.
  • Stealth Servers: poden ser Stealth Primary o Stealth Secondary. És un servidor el qual està allà però no s'utilitza per a rebre peticions des de Internet. Imagineu que tenim 3 servidors DNS: A, B i C on A és el primari i B i C els secundaris. Si es configura el registre del domini per utilitzar (delegació de DNS) els servidors A i B com a servidore DNS del domini, aleshores el servidor C és un Stealth Secondary. És un servidor secundari també però no s'utilitzarà per rebre peticions públiques. Si es configura el domini amb els servidors de DNS B i C, aleshores A és un stealth primary. Vegeu l'apartat Servidor_DNS#Stealth_Servers
  • Authoritative Only DNS Server: Vegeu Servidor_DNS#Authoritative_only
  • Split Horizon DNS Server: Vegeu Split Horizon DNS Server

Amb bind cal tenir en compte el paràmetre de zona type que només pot tenir els valors:

master, slave, stub, forward, hint

NOTA: hint es reserva a Bind per a indicar les zones predefinides com per exemple els root servers o les zones de xarxes privades com les d'adreces 192.168.0.0/16

NOTA: Forward s'utilitzar per forwarding de zones. Vegeu Forwarding de zones

NOTA: stub zone: són zones similars a les zones escalves però només es repliquen els NS records i no pas la zona sencera

Recursos

Servidor de noms autoritzat

NOTA: En anglès el terme és authoritative DNS Server

authoritative DNS Server
DNS Servers can be configured to host more than one domain. A server can be primary for one domain, and secondary for another. The term authoritative refers to any DNS servers that has a complete copy of the domain's information, 
whether it was entered by an administrator or transferred from a primary server. Thus, a secondary server can and should be authoritative for any domain for which it performs secondary authoritative resolution.
http://www.inetdaemon.com/tutorials/internet/dns/servers/authoritative.shtml

Un servidor de noms autoritzat (authoritative) és un servidor de noms que dona respostes aconseguides per ell mateix, ja sigui de la seva base de dades (fitxers locals) o de fitxers locals que s'ha obtingut per tècniques de transferència de zona (per exemple un servidor esclau pot ser autoritzat). Els servidors sempre són autoritzats per a una o varies zones d'Internet però no per a totes. Existeix una jerarquia DNS que permet repartir la responsabilitat dels dominis d'Internet entre varies màquines. Quan a un servidor de DNS li fan un pregunta sobre un domini del qual no és el servidor autoritzat, aleshores el servidor de DNS ha de consultar a altres servidors per a obtenir la resposta (en el cas que la pregunta sigui recursiva) o informarà al client de a quin servidor li pot fer la consulta (si la pregunta és iterativa).

És diu que un servidor de DNS és només autoritzat (authoritative-only) quan només respon a preguntes sobre dominis dels quals és un servidor autoritzat.

Tant els servidors esclaus com els servidors masters poden ser servidors autoritzats.

Cada nom de domini ha de tenir assignat un conjunt de servidors dns autoritzats. Aquests servidors es registren al domini pare com a registres NS.

Quan es registra un nom de domini tipus elmeudomini.com cal proveir al top level domain (.com) de la IP de com a mínim un servidor de DNS primari i un de secundari. Això es fa així per garantir que si el servidor de DNS primari falla, al menys tenir l'opció d'un de secundari.

Sovint els servidors primaris són servidors master i els secundaris es configuren com esclaus (encara que pot no ser així ja que no és normatiu).

IMPORTANT: Els servidors que no són autoritzats s'anomenen també caching/recursive, ja que només fan cache de peticions DNS ja conegudes per una petició (query) prèvia o si no coneixen la resposta a una petició fan recursivitat, és a dir envien la petició a un altre servidor.

Authority:

Que és considera una còpia completa d'una zona? La zona que té:

És una pràctica habitual tenir un servidor autoritzat primari ( primary authoritative DNS server ) i un servidors autoritzat secundari ( secondary authoritative DNS server). Al registrar un domini a in registrador acreditat de dominis, el servidor primari autoritzat és el primer servidor indicat a la llista. Tota la resta són servidors secundaris.

NOTA: És recomana que el servidor primari i el secundari estiguin a xarxes IPS diferents i que el hardware estigui en situacions físiques diferents per tal d'evitar que en cas de desastre el domini sencer no es trobi disponible. Es poden tenir múltiples servidors secundaris però només un primari

Resposta autoritzada

Un servidor DNS autoritzat indica que les respostes són autoritzades utilitzant una marca a les respostes DNS. Aquesta marca s'anomena AA (Authoritative Answer). Aquesta marca la podem observar amb ordres com dig.

Vegem un exemple, si feu una consulta sobre el domini upc.edu a un servidor que no sigui l'autoritzat de la UPC us retornara una resposta normal (no autoritzada):

$ dig www.upc.edu @8.8.8.8

; <<>> DiG 9.8.1-P1 <<>> www.upc.edu @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64083
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.upc.edu.			IN	A 

;; ANSWER SECTION:
www.upc.edu.		21092	IN	CNAME	www.upc.es.
www.upc.es.		3092	IN	A	147.83.2.135

;; Query time: 48 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Jan 13 15:44:03 2013
;; MSG SIZE  rcvd: 69

IMPORTANT: Observeu que de les dos respostes cap és autoritzada. Es veu al camp AUTHORITY: 0

IMPORTANT: Totes les respostes que s'obtenen de la cache d'un servidor de DNS són sempre no autoritzades!

En canvi si feu la consulta al servidors DNS de la UPC, que els podeu obtenir amb:

$ dig soa www.upc.edu

Veureu que hi ha una secció anomenada AUTHORITY SECTION:

$ dig www.upc.edu @backus.upc.es

; <<>> DiG 9.8.1-P1 <<>> www.upc.edu @backus.upc.es
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31577
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 2
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;www.upc.edu.			IN	A

;; ANSWER SECTION:
www.upc.edu.		86400	IN	CNAME	www.upc.es.
www.upc.es.		3600	IN	A	147.83.2.135   

;; AUTHORITY SECTION:
upc.es.			86400	IN	NS	sun.rediris.es.
upc.es.			86400	IN	NS	backus.upc.es.
upc.es.			86400	IN	NS	euler.upc.es.
upc.es.			86400	IN	NS	chico.rediris.es. 

;; ADDITIONAL SECTION:
euler.upc.es.		86400	IN	A	147.83.2.10
backus.upc.es.		86400	IN	A	147.83.2.3  

;; Query time: 17 msec
;; SERVER: 147.83.2.3#53(147.83.2.3)
;; WHEN: Sun Jan 13 15:47:38 2013
;; MSG SIZE  rcvd: 188

En aquest cos obteniur 4 respostes autoritzades (4 servidors: sun.rediris.es., backus.upc.es., euler.upc.es., chico.rediris.es. ) Recursos:

Com funcionen els noms de domini

Possiblement la millor manera d'entendre com funcionen els noms de domini és amb un exemple. Si volem resoldre la IP per al nom de domini:

  • atonito.lsi.upc.edu

Si executem la comanda

$ ping atonito.lsi.upc.edu
PING atonito.lsi.upc.edu (147.83.20.2) 56(84) bytes of data.

obtindrem que la IP és 147.83.20.2

Les parts que composen aquest nom de domini són:

  • Root. Els noms de domini tenen una estructura d'arbre similar a la dels sistemes de fitxers en linux. Tot nom de domini parteix d'una arrel (representada per . ). Així l'adreça atonito.lsi.upc.edu és en realitat atonito.lsi.upc.edu. (amb punt). El punt indica que la resolució de nom de domini s'ha d'iniciar al servidor root:
         o A.ROOT-SERVERS.NET.
         o B.ROOT-SERVERS.NET.
         o C.ROOT-SERVERS.NET.
         o ...
         o M.ROOT-SERVERS.NET. 
  • TLD (top-level domain). El primer nivell del domini indica el top-level domain (edu). Altres top-level domains són es, org, edu, com, bizz, etc. Existeixen un nombre limitat de dominis de primer nivell gestionats normalment per la ICAAN.
  • Subdominis. La resta de parts del nom de domini són subdominis del domini precedent (lsi és subdomini de upc.edu).
  • Host. Normalment, encara que no sempre, l'última part del nom de domini (p.e. atonito) correspon al nom d'una màquina dins d'un domini (lsi.upc.edu).

NOTA: Els noms de domini no són sensibles a majúscules i minúscules (case sensitive) i per tant poden escriure's de qualsevol de les dues formes.

Root Servers

Els servidors d'arrel de DNS són els servidors principals de DNS i els que saben on estan els servidors de noms per a cadascuna de les zones de més alt nivell d'Internet ( Top Level Domains).

Hi ha tretze servidors arrel d'Internet (cadascun amb les seves repliques de seguretat) distribuïts per tota la xarxa. Aquests servidors reben milers de consultes per segon. Cadascun d'aquests servidors té una lletra (de la A a la M) i amb el nom de màquina lletra.root-servers.net:

Letter Old name Operator Location A B C D E F G H I J K L M
ns.internic.net 	VeriSign 	Dulles, Virginia, USA
ns1.isi.edu 	Information Sciences Institute 	Marina Del Rey, California, USA
c.psi.net 	Cogent Communications 	distribuït utilitzant anycast
terp.umd.edu 	University of Maryland 	College Park, Maryland, USA
ns.nasa.gov 	NASA 	Mountain View, California, USA
ns.isc.org 	Internet_Systems_Consortium 	distribuït utilitzant anycast
ns.nic.ddn.mil 	United States Department of Defense 	Columbus, Ohio, USA
aos.arl.army.mil 	U.S. Army Research Lab (https://www.arl.army.mil/) 	Aberdeen Proving Ground, Maryland, USA
nic.nordu.net 	Autonomica (http://www.autonomica.se/) 	distribuït utilitzant anycast 
	VeriSign 	distribuït utilitzant anycast
	RIPE NCC 	distribuït utilitzant anycast
	ICANN 	Los Angeles, California
	WIDE Project 	distribuït utilitzant anycast

(extret de la wikipedia)

Top Level Domains (TLD)

Un domini de primer nivell és l'última part d'un domini d'Internet; és a dir, les lletres que segueixen l'últim punt del domini. Per exemple, al nom de domini ca.wikipedia.org, el domini de primer nivell és org.

La Internet Assigned Numbers Authority - IANA (Autoritat per l'assignació de nombres a Internet) actualment classifica els dominis de primer nivell en tres tipus:

  • Domini de primer nivell territorial (en anglès: country code top-level domain o ccTLD): És el tipus que té cada estat o territori depenent. Té dues lletres, per exemple jp pel Japò.
  • Domini de primer nivell genèric (en anglès: generic top-level domain o gTLD): En teoria els fan servir les organitzacions d'una classe particular (per exemple, com per organitzacions comercials). Té tres o més lletres. La majoria de gTLDs són d'ús internacional, però per raons històriques els dominis mil i gov són restringits pel govern federal i l'exèrcit dels EUA respectivament. Aquests dominis es subclassifiquen en dominis de primer nivell patrocinats sTLD, com .cat, .aero, .coop i .museum, i dominis de primer nivell no patrocinats uTLD, com .biz, .info, .name i .pro.
  • Domini de primer nivell d'infraestructura: L'únic d'aquest tipus confirmat és arpa, encara que se sap que .root ha existit per raons no conegudes.

Una llista completa dels TLDs existents, en preparació i retirats, es pot trobar a http://ca.wikipedia.org/wiki/Domini_de_primer_nivell.

Com es resol una adreça IP amb DNS en la pràctica?

Tal i com podem observar en el següent gràfic:

DNSTorontoExample.png

el procés de resolució DNS es composa d'una sèrie de peticions a servidors DNS per tal de resoldre la pregunta: quina és la IP de la màquina www.utsc.toronto.ca?. Tal i com veurem més endavant, el primer pas per resoldre aquesta pregunta és consultar la cache. Si la cache no disposa de la informació aleshores la petició es redirecciona a algun dels servidors root. Aquest procés es repeteix fins trobar amb el servidor DNS final capaç de contestar a la pregunta.

En el nostre exemple el procés seria:

  • El client demana al root server (A.ROOT-SERVERS.NET) l'adreça de la màquina atonito.lsi.upc.edu. Si executem:
$ dig +norec +noques +nostats +nocmd atonito.lsi.upc.edu @A.ROOT-SERVERS.NET.

obtindrem una llista de les màquines que resolen els dominis .net

    • Repetim el procés. Aquest cop executem:
$ dig +norec +noques +nostats +nocmd atonito.lsi.upc.edu @L3.NSTLD.COM. 

Un altre cop obtindrem una llista de les màquines que resolen el domini upc.edu (backus.upc.es i euler.upc.es).

  • Repetim el procés i executem:
$ dig +norec +noques +nostats +nocmd atonito.lsi.upc.edu @backus.upc.es. 

Finalment aquest servidor DNS és capaç de resoldre la IP.

Peticions iteratives versus peticions recursives

IMPORTANT: A Bind el comportament per defecte és recursion yes

Si us fixeu en l'exemple de l'apartat anterior, no tots els servidors de DNS que hi intervenen realitzen la mateixa tasca. De fet, excepte el servidor local, la resta de servidors no responen a la pregunta si no que delegen la feina a una altre servidor. En canvi el servidor local, realitza de forma recursiva la mateixa pregunta a diferents servidors. Això és així per què la petició del client al servidor local ha estat una petició recursiva.

Hi ha dos tipus de peticions (querys):

  • Recursives: Es demana al servidor que sigui ell qui proveeixi d'una resposta a la petició o en tot cas que mostri un missatge d'error si no pot respondre a la petició.
  • Iteratives (no recursives): El servidor pot delegar la resposta a la petició a un altre servidor. El servidor respon amb la millor resposta possible que coneix (poden intervenir les memòries cau...). Sempre es respon amb tots els servidors de DNS possibles i és que hi ha fet la petició qui decidirà a qui fer la següent petició. Les peticions iteratives només les solen fer els servidors de DNS, per tal de mirar de resoldre peticions recursives dels seus clients per a les quals no tenen resposta a la cache (vegeu també resposta autoritzada i resposta no autoritzada)
Normalment les peticions de clients a servidors de DNS locals són recursives i les peticions entre servidors de DNS són iteratives

Aquestes últimes només succeïxen quan el servidor local no té la resposta a la petició (per no tenir-la en memòria cau i no ser l'encarregat de la zona a la qual pertany la petició).

Consulteu nslookup per veure com fer una consulta no recursiva.

Consulteu Servidor_DNS#Configurar_el_nostre_servidor_per_acceptar_peticions_recursives per veure quines màquines poden fer peticions recursives.

Com s'escull entre els diferents servidors d'una zona?

Com ja hem comentat, pot haver-hi més d'un servidor que siguin els encarregats d'una zona. Quin escollim? Doncs bé DNS utilitza el que s'anomena RoundTrip Time (RTT). Cada cop que un servidor fa una consulta a un altre servidor de DNS, es mesura quan temps tarda en rebre la resposta. Si un servidor de DNS rep una resposta conforme una zona està gestionada per dos servidors del quals encara no coneix el seu RTT, aleshores pregunta a tots dos per obtenir un valor de RTT. El pròxim cop només preguntarà al que té el RTT més baix (el més ràpid).

Cache, ttl i propagació

L'alt volum de peticions que genera un sistema com DNS ha provocat que els dissenyadors busquessin una forma alternativa per tal de reduir la carrega dels servidors DNS. El mecanisme utilitzat és que un cop un client de DNS rep una resposta de resolució de nom de domini d'un servidor DNS emmagatzema aquesta resposta en una cache durant un cert temps anomenat TTL (time to live).

NOTA: tingueu en compte que un servidor no pot memoritzar en memòria cau un valor de forma indefinida. Això provocaria que els canvis no es propaguessin mai

La contrapartida d'aquest sistema de cache és que apareix l'efecte de propagació. La cache i el TTL provoquen que si un nom de domini canvia d'IP aquest canvi tardi un cert temps en propagar-se per tot els servidors DNS del mon (en alguns casos pot arribar a tardar 3 dies).

Consulteu l'apartat cache per saber per que hi ha dos TTL (TTL negatiu i TTL positiu).

Informació addicional:

Cache

En el procés de resolució vist als apartats anteriors hem suposat que no intervenen les memòries cau (cache). Per optimitzar el procés, el servidor local pot referir-se directament al servidor que té l'autoritat de la zona demanada, sempre i quan sàpiga quin és el servidor de DNS encarregat d'aquesta zona. D'aquesta manera les peticions són més ràpides.

A l'exemple anterior:

www.utsc.utoronto.ca

Li pot preguntar directament, si el té en cau, al servidor de DNS de la zona:

utsc.utoronto.ca

Sinó al servidor de la zona:

utoronto.ca

i així fins arribar a l'arrel. Aquí serà lo més lluny que arribarà ja que tot servidor de DNS té una llista dels servidors root de DNS.

Hi ha dos tipus de cache:

  • Cache positiva: On s'emmagatzemen les IP de les màquines que s'han resolt correctament
  • Cache negativa: On s'emmagatzemen les màquines que no han tingut resolució.

Sol haver-hi un TTL diferent (Time To Live) per a cada tipus de cache. Cal tenir en compte que el TTL per a un resposta concreta l'estableix el servidor que dona una resposta autoritzada, és a dir el servidor (o servidors) autoritzats de la zona a la que pertany el registre pel que preguntem

Un dels inconvenients d'aquest sistema distribuit és que els canvis en els registres DNS no es propaguen automàticament per tota la xarxa, ja que requereixen que totes les caches expirin i es refresquin després de superar el TTL. El RFC 1912 dona normes bàsiques per valors apropiats de TTL.

Cal tenir en compte que a més els clients DNS també poden tenir cache (per exemple el de Windows, no així pero el resolv.conf de Linux).

El Negative caching i el positive caching, és a dir el temps en que una cahce guarda la no existència d'un registre es determina pel registre SOA de la zona.

DNS Records

NOTA: També coneguts com a resource records

  • SOA record: Especifica el servidor de DNS que proveïx d'informació de la zona (authoritative server). Controla paràmetres com el correu de l'administrador de la zona, el número de sèrie, i temps per al refresc de la zona. També conegut com start of authority record. Valors recomanats per RIPE NCC: [2]
  • NS record: Assigna un nom de domini a un servidors de DNS o llista de servidors encarregats del domini (authoritative DNS servers). També conegut com name server record.
  • A record: tradueix una adreça de màquina a la seva adreça IP de versió 4 (IPv4) (utilitzat per a les resolucions directes). També anomenat address record.
  • AAAA record: tradueix una adreça de màquina a la seva adreça IP de versió 6 (IPv6). També anomenat IPv6 address record
  • CNAME record: alias d'un nom a un altre, L'alias a d'apuntar a un registre de tipus A. També anomenat canonical name record. El registre al qual apunta pot ser local al servidor de DNS o un extern.
  • MX record: Assigna un nom de domini a un servidor o una llista de servidors de correu d'aquest domini. També anomenat mail exchange record.
  • PTR record: Assigna una adreca IPv4]] a el nom canònic d'una màquina (utilitzat per a les resolucions inverses). Al establir un registre PTR per a una màquina en un xarxa privada (in-addr.arpa) s'activa la resolució inversa per aquesta adreça. Això permet que al cridar l'host des de la xarxa local es cridi la seva IP pública i no pas la privada (P. ex. un servidor web accessible des de la xarxa local i des d'Internet). També conegut com pointer record.
  • TXT record: Permet a l'administrador afegir registres DNS de text. Proporciona suport per a especificacions com "Sender Policy Framework" o "DomainKeys".
  • NAPTR records: Nou tipus igual que suporta expressions regulars. També conegut com Naming Authority Pointer.
  • SFP record: Relacionat amb anti-SPAM

Altres tipus de registres proveïxen informació (LOC record dóna la localització física d'un servidor).

Consulteu les ordres nslookup i dig per veure com fer peticions (querys DNS) concretes de registres.

TCP vs UDP

Els RFC indiquen que el port UDP s'ha d'utilitzar per a les peticions (querys) DNS de clients i el port TCP per a les transferències de zona.

Ara bé, Windows té un algoritme una mica impacient, la primera petició és fa amb UDP, però les següents es fan amb TCP.

NOTA: Cal tenir en compte que si fem transferències de zona o tenim clients Windows val la pena deixar el port 53 de TCP obert en el nostre firewall

Comprovació de dominis

Podeu utilitzar les webs:

http://www.nabber.org/projects/dnscheck

o:

http://dnscheck.ripe.net/

Protocol DNS

DNS és un protocol basat en missatges. Hi ha 3 tipus de missatges DNS:

Queries
Responses
Updates

ELs updates s'utilitzen per a les actualitzacions de zones DNS. Tots els missatges tenen un format comú, vegeu la imatge:

dnsgenformat.png
DNS Message format

Amb els següents apartats o seccions DNS:

  • Header: Conté els camps que descriuen el tipus de missatge i donen informació sobre el missatge. Els detalls els podeu trobar una mica més avall. També conté uns contadors que indiquen el nombre d'entrades que hi ha a cadascuna de les següents seccions DNS:
  • Question: inclou la informació d'una o més preguntes o querys.
  • Answer: porta un o més DNS resource records amb la resposta a la pregunta realitzada
  • Authority: porta un o més resource records que apunten als servidors DNS authoritative name servers que poden ser utilitzats per al procés de resol·lució de DNS.
  • Additional: porta un o més resource records que content informació adicional relacionada amb la pregunta realitzada.

NOTA: Totes les seccions existeixen sempre en un missatge DNS però el que si pot passar és que estiguin buides és a dir sense entrades, o el que és el mateix amb els comptadors a 0

DNS Message Header Format:

La següent imatge es mostra la capçalera:

http://www.tcpipguide.com/free/t_DNSMessageHeaderandQuestionSectionFormat.htm
DNS Header

El format de la capçalera és compartir entre les peticions (query) i les respostes (responses), simplement s'utilitza un flag (flag qr) per indicar si és un cas o l'altre. La capçalera té les següents parts:

  • ID: un identificador de 16 bits generat generat pel dispositiu que crear la query DNS. El servidor copi l'identificador a la resposta per tal de poder cuadrar (match). Aquest ús és similar al que es fa amb els missatges ICMP
  • QR: 1 bit que indica si es tracta d'una query (0) o de una resposta.
  • Opcode: especifica el tipus de missatge DNS que s'està utilitzant. Les opcions són:
  • QUERY: una query estandard (el opcode s'utilitza igual per les queries que per les responses)
  • IQUERY: Inversed Query. OBSOLET
  • STATUS: una petició de l'estat del servidor
  • NOTIFY: missatge enviat d'un master a un esclau per tal de notificar-li que hi han canvis a una zona i que pot solicitar un zone transfer per aplicar-los. RFC1996
  • UPDATE: Permet el que es coneix com servidor DNS dinàmic i permet actualitzar un servidor de DNS. RFC2136.
  • Flags:
  • qr: Query response. Simplement indica que el paquet és una resposta.
  • aa: Authoritative Answer. Indica que la resposta és autoritative, és a dir, que el server que a respost la query DNS és el servidor encarregat de gestionar la zona de DNS. Si el flag no apareix aleshores la resposta no és autoritative
  • ra: Recursion Allowed: Indica quan el servidor suporta recursion.
  • rd: Recursion Desired: Quan forma part d'una query s'indica que es vol fer la petició en mode recursiu (només si el server ho suporta o ho autoritza per aquest client). El valor d'aquest bit no es modifica a la reposta.
  • tc: Truncated Response: Indicar que la resposta a estat truncada per que el protocol de transport (TPC o UDP) no permetia entrar la resposta en un paquet. Passa amb els paquets de tipus UDP i a vegades oblica a fer una petició TCP amb el servidor per obterni el missatge complet.
  • Zero: Tres bits reservats que tenen el valor 0.
  • rCode o return code: Indica l'estatus de la resposta o el codi de retorn:
  • No error: cap error en la resposta
  • Format error: el servidor no pot respondre a la query per que no esta ben formatada.
  • ServerFailure: no s'ha pogut respondre a la query per un error al servidor.
  • Name error o NXDOMAIN: el nom especificat a la consulta no existeix al domini
  • Not implemented: la query demanda no és suportada peel servidor.
  • Refused: el servidor es nega a respondre normalment per raons de polítiques de seguretat (policy) i no pas per qüestion tècniques o errors.
  • YXDOMAIN: TODO
  • YX RR SET: TODO
  • NX RR SET: TODO
  • Notauth: el servidor que rep la query no és l'autoritzat de la zona.
  • Notzone: el nom indicat al missatge no està dins la zona.
  • Comptadors:
  • QDCount: especifica el nombre de preguntes o queries que porta el missatge a la secció Question
  • ANCount: especifica el nombre de preguntes o queries que porta el missatge a la secció Answer
  • NSCount: especifica el nombre de preguntes o queries que porta el missatge a la secció Authority (NS= Name Server)
  • ARCount: especifica el nombre de preguntes o queries que porta el missatge a la secció Additional


Recursos:

LIR

http://www.ripe.net/data-tools/dns/reverse-dns#reverse-dns

BIND (Berkeley Internet Name Domain)

Bind és el servidor DNS utilitzant més freqüentment, sobretot en sistemes operatius tipus Unix. De fet, és l'standard de facto.

Actualment hi ha dues versions de bind. Bind a seques i BIND 9 (release 9 de Bind). BIND 9 va ser reescrit des de zero per millorar bind i per afegir noves funcionalitats i suport per a DNSSEC (DNS Security Extensions). Les versions antigues de bind a l'igual que passa amb altres programes com sendmail són coneguts pel gran nombre de vulnerabilitats conegudes. Bind 9 té un historial de vulnerabilitats més baix.

Zones versus dominis

Una zona és un punt de delegació dins d'un arbre DNS. Una zona esta formada per diferents parts contigües de l'arbre de domini sobre les quals un servidor de DNS té la informació completa i en té l'autoritat. La zona conté tota la informació des de un punt de l'arbre de domini cap avall excepte aquelles zones que estan delegades a altres servidors DNS. Un punt de delegació esta marcat per un o més registres NS a la zona pare.

Tipus de servidors

  • Primary masters: Llegeix el fitxer de zona d'un fitxer del propi servidor.
  • Secondary masters o slave: Llegeix el fitxer de zona del master server que té autoritat a la zona. També son coneguts com a servidors esclaus.

IMPORTANT: Llegiu Servidor_DNS#Tipus_de_servidors_DNS per veure tots els tipus de servidors possibles

El procés de connexió del secundari al principal per tal d'obtenir la informació de la zona s'anomena transferència de zona (zone transfer). Tan el servidor primari com el secundari o secundaris són servidors autoritzats de la zona.

Aquesta relació facilita la gestió de la zona. Només cal mantenir un sol fitxer de zona al servidor primari i tota la resta de servidors secundaris es sincronitzen.

Cal tenir en compte que més aviat parlem de master o de'esclau quan parlem de zones i no pas servidors. Un servidor pot ser esclau d'una zona i master d'un altre. La definició de si una zona és master o esclava es fa al fitxer principal de configuració (o a named.conf.local en cas de Debian/Ubuntu):

Exemple master:

zone "prova.eu" in {
       type master;
       file "db.prova.edu";
};


Exemple esclau:

zone "prova.eu" in {
     type slave;
     file "bk.prova.eu";
     masters { 194.249.232.3; };
};

NOTA: Sovint a l'esclau s'indica a quin fitxer es guardarà la zona transferida:

zone "informatica.iesebre.com" {
       type slave;
       masters { 
               192.168.0.40;
               }; 
       file "slave/informatica.iesebre.com.hosts";
       };

IMPORTANT: El fitxer de zona en cas d'utilitzar apparmor s'ha de guardar a /var/cache/bind/ ja que per defecte és l'única carpeta autoritzada per AppArmor. Vegeu el fitxer /etc/apparmor.d/usr.sbin.named).

El fitxer es pot indicar com una ruta absoluta o relativa a la instal·lació del servidor, en l'exemple:

/var/lib/named/slave/informatica.iesebre.com.hosts

que conté:

# cat /var/lib/named/slave/informatica.iesebre.com.hosts
$ORIGIN .
$TTL 86400	; 1 day
informatica.iesebre.com	IN SOA	ns1.informatica.iesebre.com. informatica.iesebre.com. (
				2007040302 ; serial
				10800      ; refresh (3 hours)
				3600       ; retry (1 hour)
				604800     ; expire (1 week)
				86400      ; minimum (1 day)
				)
			NS	ns1.informatica.iesebre.com.
$ORIGIN informatica.iesebre.com.
INSEbreXen1		CNAME	xen
mediawiki		A	192.168.7.182
negrell			A	192.168.2.2
nemesis			A	192.168.0.40
			A	192.168.2.1
			A	192.168.7.182
ns			A	192.168.7.182
profes			A	192.168.2.11
proxy			A	192.168.7.182
www			A	192.168.7.182
xen			A	192.168.2.10

NOTA: L'usuari que utilitza el bind per a executar-se (el podeu consultar amb $ ps aux

Consulteu:

Servidor_DNS#Configuraci.C3.B3_de_zones_esclaves

Per obtenir més detalls sobre com configurar un servidor DNS esclau i com es fan les transferències de zona entre servidors DNS.

Tipus de zones

  • IN: IN ve d'INternet

Actualment gairebé es pot dir que l'únic tipus de zona que s'utilitza és Internet.

Directives de bind

  • $INCLUDE: Serveix per incloure altres fitxers. Per exemple incloure un fitxer de xona dins d'un altre zona
  • $ORIGIN: Estableix el nom del domini que s'utilitzarà per a tots els noms de màquina abreviats (sense punt final) . Normalment no s'utilitza ja que el nom del domini ja s'ha establert al fitxer named.conf però us podeu trobar sovint exemples amb aquesta directiva ja que mostra de forma explicita quin és el nom de domini.
  • $TTL: Estableix el time to live per defecte. És una variable general ja que cada zona pot sobreescriure aquest valor.


Instal·lació de bind

Per instal·lar bind hem d'executar:

$ sudo apt-get install bind9
Leyendo lista de paquetes... Hecho
Creando árbol de dependencias       
Reading state information... Hecho
Se instalarán los siguientes paquetes NUEVOS:
  bind9
0 actualizados, 1 se instalarán, 0 para eliminar y 0 no actualizados.
Se necesita descargar 0B/300kB de archivos.
Se utilizarán 741kB de espacio de disco adicional después de desempaquetar.
Seleccionando el paquete bind9 previamente no seleccionado.
(Leyendo la base de datos ...  
21767 ficheros y directorios instalados actualmente.)
Desempaquetando bind9 (de .../bind9_1%3a9.3.2-2ubuntu3_i386.deb) ...
Configurando bind9 (9.3.2-2ubuntu3) ...
Adding group `bind' (111)...
Done.
Adding system user `bind' with uid 105...
Adding new user `bind' (105) with group `bind'.
Not creating home directory `/var/cache/bind'.
wrote key file "/etc/bind/rndc.key"
 * Starting domain name service...                                       [ ok ]

Hi ha tres fets a destacar de la instal·lació:

  • Es crea un usuari i un grup anomenat bind per executar el servidor de DNS.
  • La base de dades de DNS no es crea (la instal·lació per defecte és un servidor DNS de cache)
  • S'inicia el dimoni/servei bind.

Tal i com suggereix apt-get, també és recomanable disposar dels paquets bind-doc i dnsutils, amb documentació i eines per a DNS

$ sudo apt-get install bind9-doc dnsutils

Podem consultar els fitxers que instal·la bind amb la comanda:

$ dpkg -L bind9

Tenim les següents comandes/aplicacions/servidors:

$ dpkg -L bind9 | grep bin
/usr/sbin
/usr/sbin/named
/usr/sbin/rndc
/ usr/sbin/rndc-confgen
/usr/sbin/dnssec-keygen
/usr/sbin/dnssec-signzone
/usr/sbin/named-checkconf
/usr/sbin/named-checkzone

I els següents fitxers de configuració:

$ dpkg -L bind9 | grep etc
/.
/etc
/etc/bind
/etc/bind/db.0
/etc/bind/db.255
/etc/bind/db.empty
/etc/bind/zones.rfc1918
/etc/bind/db.127
/etc/bind/db.local
/etc/bind/db.root
/etc/bind/named.conf
/etc/bind/named.conf.local
/etc/bind/named.conf.options
/etc/init.d
/etc/init.d/bind9

La resta de fitxers són manuals i documentació (carpeta /usr/share) i la base de dades /var/cache/bind. De la documentació cal destacar la FAQ amb preguntes i respostes:

$ cd /usr/share/doc/bind9
$ gunzip FAQ.gz
$ nano FAQ

i els fitxers README:

$ cd /usr/share/doc/bind9
$ gunzip README.gz
$ gunzip README.Debian.gz
$ nano README
$ nano README.Debian

Instal·lació a OpenSuse

El podem instal·lar amb zypper:

# zypper install bind

Cal tenir en compte que els fitxers instal·lats són diferents als de Debian:

# rpm -ql bind
/etc/apparmor.d
/etc/apparmor.d/usr.sbin.named
/etc/init.d/named
/etc/named.conf
/etc/named.conf.include
/etc/rndc.key
/etc/slp.reg.d
/etc/slp.reg.d/bind.reg
/etc/sysconfig/SuSEfirewall2.d/services/bind
/usr/sbin/dnssec-keygen
/usr/sbin/dnssec-signzone
/usr/sbin/named
/usr/sbin/named-checkconf
/usr/sbin/named-checkzone
/usr/sbin/named-compilezone
/usr/sbin/rcnamed
/usr/share/bind
/usr/share/bind/createNamedConfInclude
/usr/share/bind/ldapdump
/usr/share/man/man5/named.conf.5.gz
/usr/share/man/man8/dnssec-keygen.8.gz
/usr/share/man/man8/dnssec-signzone.8.gz
/usr/share/man/man8/named-checkconf.8.gz
/usr/share/man/man8/named-checkzone.8.gz
/usr/share/man/man8/named-compilezone.8.gz
/usr/share/man/man8/named.8.gz
/var/adm/fillup-templates/sysconfig.named-named
/var/lib/named/127.0.0.zone
/var/lib/named/dyn
/var/lib/named/etc/localtime
/var/lib/named/etc/named.conf.include
/var/lib/named/localhost.zone
/var/lib/named/master
/var/lib/named/root.hint
/var/lib/named/slave

El fitxer d'inicialització system V té també un altre nom:

# /etc/init.d/named restart
..dead
Shutting down name server BIND - Warning: named not running!                                                                                                          done
Starting name server BIND

Funcions d'un servidor DNS i tipus de configuracions

Hi ha dos possibles configuracions principals d'un servidor DNS per a una xarxa:

  • Cau de resolució de noms: El servidor de DNS només fa de memòria CAU de les resolucions de nom de la nostra xarxa. Cada cop que hi ha una petició de resolució de nom de domini el servidor consulta la seva memòria cau. Si la resolució està a la memòria ell mateix envia la resposta, sinó segueix el procés normal de resolució de noms. També s'anomena FORWARDING.
  • Servidor de noms: El servidor de DNS és responsable de la resolució de noms d'una o més zones. Les zones poden ser xarxes privades o xarxes públiques. Normalment aquest tipus de servidors DNS també fan de memòria cau.

Forwarding

Amb Bind, podem activar el cau modificant el fitxer named.conf o named.conf.options a Debian/Ubuntu:

forward first;
  forwarders {
        10.1.0.2;
        10.1.0.1;
  };

NOTA: Fer de servidor cau no implica que no podem gestionar també un domini. Es poden combinar les dues opcions. Vegeu Servidor_DNS#Tipus_de_servidors_DNS

Es pot indicar que es vol fer forwarding de tots els requests amb:

// options section fragment of named.conf 
// forwarders can have multiple choices
options { 
	directory "/var/named";
	version "not currently available";
	forwarders {10.0.0.1; 10.0.0.2;}; 
	forward only;
};

Vegeu també:

 Tipus de servidors DNS

Recursos:

Control del servei bind. Execució, parada, status i reconfiguració de BIND

Seguint els estàndards de Debian GNU/Linux (basat en el sistema d'scripts d'inicialització SystemV (http://en.wikipedia.org/wiki/System_V)) l'script de control del dimoni bind és:

/etc/init.d/bind9

Les accions que podem fer amb el servei són start|stop|reload|restart|force-reload.

Cada cop que fem un canvi a la configuració de bind haurem de fer un restart o, millor encara, un reload del servei:

$ sudo /etc/init.d/bind9 reload

La comanda reload és equivalent a executar:

$ sudo rndc reload

Veieu la secció Comanda rndc per a més informació sobre aquesta comanda.

En altres sistemes el fitxer és /etc/init.d/named però el comportament és el mateix.

Tal com podem veure executant:

$ sudo updatedb
$ locate bind9 | grep rc
/etc/rc0.d/K85bind9
/etc/rc1.d/K85bind9
/etc/rc2.d/S15bind9
/etc/rc3.d/S15bind9
/etc/rc4.d/S15bind9
/etc/rc5.d/S15bind9
/etc/rc6.d/K85bind9

El serveis DNS s'executa a partir del nivell 2 (cal destacar que no està disponible al nivell SINGLE USER MODE rcS.d).

Podeu trobar més informació a l'article Configuració de serveis en Linux

Ports

Els ports de DNS són:

$ cat /etc/services | grep domain
domain          53/tcp                          # name-domain server
domain          53/udp

El port UDP s'utilitza per resoldre consultes (querys) i el TCP per a les transferències de zona.

Podeu comprovar si una màquina té DNS amb la comanda nmap:

$ sudo nmap localhost
[sudo] password for sergi: 

Starting Nmap 4.20 ( http://insecure.org ) at 2008-01-24 19:28 CET
Interesting ports on localhost (127.0.0.1):
Not shown: 1687 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
53/tcp   open  domain
...

$ sudo nmap -sU localhost -p 53

Starting Nmap 4.20 ( http://insecure.org ) at 2008-01-24 19:29 CET
Interesting ports on localhost (127.0.0.1):
PORT   STATE         SERVICE
53/udp open|filtered domain

Nmap finished: 1 IP address (1 host up) scanned in 2.049 seconds

Configuració de Bind

Els fitxers de configuració del dimoni bind (seguint els estàndards de Debian GNU/Linux) es troben a la carpeta /etc/bind.

El fitxer principal de configuració és el fitxer etc/bind/named.conf. Si consultem el fitxer veurem que està fragmentat en tres parts: ell mateix i els fitxers /etc/bind/named.conf.local i el fitxer /etc/bind/named.conf.options.

NOTA: En altres sistemes Linux el fitxer named.conf el trobem directament a la carpeta /etc. també és comú que no hi hagi la divisió de la configuració en tres fitxers i estigui tot junt en un sol fitxer /etc/named.conf.

Per modificar la configuració de bind o bé canviem les opcions o bé modifiquem o creem noves zones. Les zones especifiquen les parts del nom de domini de les quals s'encarrega un servidor de DNS, normalment les zones es corresponen amb dominis tot i que no necessàriament ha de ser així (un domini sencer pot estar controlat per una o més zones en diferents servidors DNS). Si veiem les zones per defecte del fitxer named.conf:

zone "." {
        type hint;
        file "/etc/bind/db.root";
};

Aquesta zona és la zona arrel. El mínim que ha de tenir un servidor de DNS (que funcioni com a cache i no controli zones pròpies) és aquesta zona per delegar les resolucions de noms encara que no tingui el cache. Consulteu la secció sobre el fitxer /etc/bind/db.root.

La resta de zones són les que el servidor de DNS controla (es diu que el servidor de DNS és authoritative):

La zona de localhost i la seva resolució inversa (127.0.0.0):

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

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

És obligatòria de forma similar el que passa amb els fitxers /etc/hosts i també ens proporciona la resolució del nom de màquina localhost:

$ cat /etc/hosts
127.0.0.1       localhost
127.0.1.1       ubuntu

I també de la resolució inversa del domini de difusió (broadcast) (ips reservades per a xarxa i braodcast):

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

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

Recursos:

Els següents apartats expliquen en més detall els fitxers de configuració de bind.

Exemple de fitxer de configuració de zona

> cat /var/lib/named/master/iesebre.com
$TTL 2D
@	IN	SOA	ns.iesebre.com. informatica.iesebre.com. (
			2007040302
			3H
			1H
			1W
			1D )

iesebre.com.	        IN      NS	ns.iesebre.com.
ns.iesebre.com.        IN      A       192.168.0.9
www.iesebre.com.	IN	A	192.168.0.9
mail.iesebre.com.	IN	A	192.168.0.9
pop.iesebre.com.	IN	A	192.168.0.9

NOTA: IN ve d'Internet i és la classe de dades DNS més utilitzada

La primera línia indica el TTL o TIME TO LIVE.

Després ve el registre SOA que ocupa múltiples línies. Cal assegurar-se que el nom de la zona és troba a la primera columna. És pot utilitzar @ (en aquest exemple equival a iesebre.com.) i s'utilitza el nom de la zona especificat al fitxer principal de configuració named.conf o es pot posar el nom de la zona directament.

Els camps:

ns.iesebre.com. informatica.iesebre.com. 

Són primer el nom del servidor DNS primari de la zona (cal definir més avall la IP de la màquina amb un registre A) i després el correu electrònic de l'administrador de la zona. El correu s'interpreta el primer punt com una arroba:

informatica.iesebre.com. --> informatica AT iesebre.com          (el AT és per evitar SPAM!)

sion.alumnat. root.sion.alumnat.

IMPORTANT: Si es posa el nom de la zona cal no oblidar-se del punt final! Si no hi ha punt aleshores es considera una abreviatura. Per exemple a un fitxer db.iesebre.com:

www.iesebre.com IN A 192.168.0.9

es consideraria com la màquina:

www.iesebre.com.iesebre.com

Es a dir també podríem haver posat:

 www	IN	A	192.168.0

és equivalent a:

www.iesebre.com.	IN	A	192.168.0.9

Després ve el nom del servidor de DNS primari per a la zona (també acabat en punt) i finalment el correu electrònic del responsable de la zona (el primer punt es substitueix per una @). Es poden utilitzar correus Unix (o posar d'inventats, no es comprova que existeixi realment).

El parèntesi s'utilitza per tal de poder expandir el registre SOA en múltiples línies. Els valors entre parèntesi son importants per als servidors esclaus. Consulteu

Servidor_DNS#Registres_SOA_del_servidor_master_i_zones_esclaves

Després ens trobem amb el registre NS o registres. Cal indicar un registre NS er cada servidor de DNS responsable (authoritative) de la zona, siguin primaris o secundaris. En el nostre cas només hi ha un servidor:

iesebre.com.	        IN      NS	sion.iesebre.com.

NOTA: Alternativament, si hem utilitzat una arroba per indicar el nom del domini, ens podem saltar, no posar, el nom del domini:

         	        IN      NS	sion.iesebre.com.

Després hi ha 3 registres A o registres de host:

www.iesebre.com.	IN	A	192.168.0.9
mail.iesebre.com.	IN	A	192.168.0.9
pop.iesebre.com.	IN	A	192.168.0.9

Si utilitzem l'arroba, nomes cal posar:

www	IN	A	192.168.0.9
mail	IN	A	192.168.0.9
pop	IN	A	192.168.0.9

Noms de màquina

Hi ha dos tipus de noms:

  • CNAME: Canonical Names, son el nom principal. Algunes màquines poden tenir múltiples IP (multihomed). S'especifiquen amb registres A
  • Alias: Són altres noms de les màquines, s'especifiquen amb:
alias CNAME CanonicalName

Mai un alias pot sortir a la dreta (només ho poden fer els noms canònics).

NOTA: Els registres PTR que indiquen les resolucions inverses només es poden fer amb canonical names

Multihomed hosts

Una màquina multihomed és una màquina amb més d'una IP vàlida (ja sigui per que tingui múltiples interfícies de xarxa o interfícies virtuals amb ip aliasing). S'indiquen de la següent manera:

www.iesebre.com.	IN	A	192.168.0.9
www.iesebre.com.	IN	A	192.168.0.10
...

NOTA: Amb xarxes segmentades, si et donen la IP d'una màquina d'un segment de xarxa al que no és té accés, aleshores no hi tindrem accés

Round robin i address sorting

  • Roud Robin: Quan s'assignen múltiples IP a un servidor de DNS, la teoria diu que aleshores els clients DNS al obtenir dos (o més) IP com a opcions de resolució de nom d'una màquina concreta, han d'anar alternant les opcions possibles. Això sovint s'utilitza per fer un balanceig de càrrega
  • Address Sorting: es parla d'address sorting quan controlem en quin ordre s'utilitzen les diferents IPs que ens proporciona un servidor de DNS

per a un nom de màquina concret. Cal tenir en compte que l'address sorting pot anular el Round Robin i per tant el balanceig de càrrega.

NOTA: Cal tenir en compte que molts clients, per defecte, utilitzen primer aquelles IP que són del segment de xarxa o segments de xarxa als que està connectada la màquina client.

Comentaris

Als fitxers de configuració:

/* This is a C-style comment */
// This is a C++-style comment
# This is a shell-style comment

Als fitxers de zona:

Comentari

Abreviatures

Als fitxers de zona es consideraren abreviatures tots els noms que no acabin en punt, per exemple:

www    IN A 192.168.0.9

és equivalent a:

www    IN A 192.168.0.9

L'arroba es pot utilitzar com a nom de domini:

@ IN SOA dns.prova.eu. al.prova.eu. (

                         1        ; Serial
                         3h       ; Refresh after 3 hours
                         1h       ; Retry after 1 hour
                         1w       ; Expire after 1 week
                         1h )     ; Negative caching TTL of 1 hour

També es pot repetir nom anterior:

www   IN A     192.249.249.1
      IN A     192.253.253.1

Noms de màquina correcta

Hi ha unes quantes normes a complir amb els noms canònics, segons el RFC 952

NOTA: No s'aplica als CNAMES que poden tenir qualsevol caràcter ASCII imprimible

Les normes són:

  • Caràcters alfanumèrics
  • Guions

NOTA: Els guions baixos no són vàlids

Fitxer /etc/bind/named.conf

NOTA: En algunes distribucions i en versions antigues de BIND el fitxer es troba a /etc/named.conf

Aquest fitxer és el fitxer principal de configuració de bind. En la seva versió per a Debian, aquest fitxer no l'haurem de modificar mai ja que només té /etc/bind/named.conf.options i les zones per defecte (que se suposa que mai s'han de tocar) i delega les opcions i la creació de zones pròpies als fitxers /etc/bind/named.conf.local respectivament.

$ cat /etc/bind/named.conf
................................................

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

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

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

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

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

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

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

....................

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

El millor recurs per conèixer totes les opcions del fitxer named.conf és el manual de Linux.

Fitxer /etc/bind/named.conf.options

$ cat /etc/bind/named.conf.options 
 options {
       directory "/var/cache/bind";
 
       // If there is a firewall between you and nameservers you want
       // to talk to, you might need to uncomment the query-source
       // directive below.  Previous versions of BIND always asked
       // questions using port 53, but BIND 8.1 and later use an unprivileged
       // port by default.
 
       // query-source address * port 53;
 
       // If your ISP provided one or more IP addresses for stable 
       // nameservers, you probably want to use them as forwarders.  
       // Uncomment the following block, and insert the addresses replacing 
       // the all-0's placeholder.
 
       // forwarders {
       //      0.0.0.0;
       // };
 
       auth-nxdomain no;    # conform to RFC1035
 
       // By default, name servers should only perform recursive domain
       // lookups for their direct clients.  If recursion is left open
       // to the entire Internet, your name server could be used to
       // perform distributed denial of service attacks against other
       // innocent computers.  For more information on DDoS recursion:
       // http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0987
 
       allow-recursion { localnets; };
 
       // If you have DNS clients on other subnets outside of your
       // server's "localnets", you can explicitly add their networks
       // without opening up your server to the Internet at large:
       // allow-recursion { localnets; 192.168.0.0/24; };
  
       // If your name server is only listening on 127.0.0.1, consider:
       // allow-recursion { 127.0.0.1; }; 

Normalment el que sempre es modifica d'aquest fitxer és l'apartat forwarders i és on s'especifiquen els servidors DNS del nostre proveïdor de serveis.

Fitxer /etc/bind/named.conf.local

En aquest fitxer hem de configurar les zones de les que volem que el servidor de DNS s'encarregui. Un exemple pot ser (extret de http://www.iesebre.com/~ocastell/Xarxes_i_Linux/):

zone "0.168.192.in-addr.arpa" {
  type master;
  file "/var/lib/named/192.168.0.rev";
  };
zone "1.168.192.in-addr.arpa" {
  type master;
  file "/var/lib/named/192.168.1.rev";
  };
zone "iesdeltebre.net" {
  type master;
  file "/var/lib/named/iesdeltebre.net.hosts";
  };
zone "intracentre" {
  type master;
  file "/var/lib/named/intracentre.hosts";
  };

Aquí es configuren dues xarxes privades de classe C (192.168.0.0/24 i 192.168.1.0/24). Els noms de les zones de resolució inverses en cada cas són iesdeltebre.net i intracentre.

$ttl 38400                                                    
0.168.192.in-addr.arpa. IN   SOA   s-207. ocastell (          
             2003062504                                                     
             10800                                                          
             3600                                                           
             604800                                                         
             38400 )                                                              
2.0.168.192.in-addr.arpa.  IN   PTR    s-207.iesdeltebre.net. 
2.0.168.192.in-addr.arpa.  IN   PTR    iesdeltebre.net.

$ttl 38400
iesdeltebre.net.  IN     SOA   s-207. ocastell (
              2003062502
              10800
              3600  
              604800
              38400 )
iesdeltebre.net.       IN NS     s-207.
0.168.192.in-addr.arpa.    IN   NS    s-207.
s-207.iesdeltebre.net. IN    A      192.168.0.2
iesdeltebre.net.        IN CNAME s-207
www.iesdeltebre.net.    IN CNAME s-20


Fitxer /etc/bind/db.root

Aquest fitxer conté la llista de servidors arrel de DNS:

$ cat /etc/bind/db.root
.................................

;; ADDITIONAL SECTION:
A.ROOT-SERVERS.NET.     3600000 IN      A       198.41.0.4
B.ROOT-SERVERS.NET.     3600000 IN      A       192.228.79.201
C.ROOT-SERVERS.NET.     3600000 IN      A       192.33.4.12
D.ROOT-SERVERS.NET.     3600000 IN      A       128.8.10.90
E.ROOT-SERVERS.NET.     3600000 IN      A       192.203.230.10
F.ROOT-SERVERS.NET.     3600000 IN      A       192.5.5.241
G.ROOT-SERVERS.NET.     3600000 IN      A       192.112.36.4
H.ROOT-SERVERS.NET.     3600000 IN      A       128.63.2.53
I.ROOT-SERVERS.NET.     3600000 IN      A       192.36.148.17
J.ROOT-SERVERS.NET.     3600000 IN      A       192.58.128.30
K.ROOT-SERVERS.NET.     3600000 IN      A       193.0.14.129
L.ROOT-SERVERS.NET.     3600000 IN      A       198.32.64.12
M.ROOT-SERVERS.NET.     3600000 IN      A       202.12.27.33
................................

En aquest cas el servidor delega la resolució de noms arrel (NS).

El primer pas per tal de resoldre un nom de domini és consultar en un servidor arrel de DNS el domini de nivell principal (TLD) corresponent. A Bind la llista de servidors principals es manté al fitxer /etc/bind/db.root (en alguns sistemes/versions també s'anomena root.hints). Aquest fitxer s'obté amb la comanda:dig:

$ dig ns . @a.root-servers.net

A l'apartat maintenance del HOW-TO-DNS hi ha un script per tal de mantenir actualitzat aquest fitxer.

Fitxer /etc/bind/zones.rfc1918

En aquest fitxer s'especifiquen les xarxes privades tal i com es defineix al RFC 1918.

$ cat zones.rfc1918 
zone "10.in-addr.arpa"      { type master; file "/etc/bind/db.empty"; };  //CLASE A

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

//Adreces de classe C
zone "168.192.in-addr.arpa" { type master; file "/etc/bind/db.empty"; };


Configuració de zones

Primer algunes qüestions de sintaxi dels fitxers de zona:

  • Els comentaris es fan amb el caràcter ; i poden estar al principi de línia o al final.
  • El caràcter @ es pot utilitzar per a referir-se a la zona que estem configurant
  • La comanda $GENERATE serveix per crear loops. Exemple:
$GENERATE 0-19 host${0,2}         A       192.168.0.${10,2}

Ens genera les següents 20 línies:

host00         A       192.168.0.10
host01         A       192.168.0.11
host02         A       192.168.0.12
..........
host19        A       192.168.0.29


Per crear una zona de resolució directa es pot utilitzar una plantilla com la següent:

;; Aquí pots posar una descripció de la zona
$TTL 1H 
@                       IN      SOA     servidor_dns.nom_del_domini_amb_punt_final. hostmaster (
                               200703021       ; serial
                               8H              ; refresh for slaves
                               3H              ; retry
                               4W              ; expire time at slaves
                               1H              ; negative TTL
                               )
 
                               IN      NS      servidor_dns.nom_del_domini_amb_punt_final.
;;Descomenteu la següent línia si teniu servei correu
;;                            IN      MX      10 nom_maquina_correu.nom_del_domini_amb_punt_final.
;;;;;;;;;;;;;;;;;;;;;
; Descripció de les traduccions
;;;;;;;;;;;;;;;;;;;;;;   

;;Noms de màquines amb A
;;Descomenteu la següent línia si voleu afegir un Gateway 
;gateway                         IN      A       adreça_ip_del_gateway (192.168.0.1?)  
;;Descomenteu les següents línies si voleu afegir màquines 
;host1                           IN      A       adreça_IP_host1
;host2                           IN      A       adreça_IP_host2
;host3                           IN      A       adreça_IP_host3 

; Alternativament podem utilitzar una iteració  amb GENERATE
;$GENERATE 0-19 hosts${0,2}      A       192.168.0.${0,2}

;Els servidors de noms i de correu electrònic han de ser host A
;correu                          IN      A       ip_del_servidor_de_correu
;domain                          IN      A       ip_del_servidor_de_DNS

;; Defineix dominis de serveis amb CNAMEs. IMPORTANT: es posen noms de màquina que resolgui DNS i no IPs.
;www                             IN      CNAME   nom_host_web
;ldap                            IN      CNAME   nom_host_ldap
;ssh                             IN      CNAME   nom_host_ssh

Les primeres línies indiquen quina és la zona, i qui és el responsable (hostmaster, que és equivalent a hostmaster@domini.com) i altres informacions importants de la zona. És important destacar el número de sèrie que és important actualitzar (augmentar en un nombre) cada cop que s'actualitza el fitxer (important per temes de sevidors DNS secundaris i propagacions).


El nombre serial té el següent: any + mes + dia + ordinal_que_incrementes si modifiques el DNS més d'un cop al dia.

El fitxer el podem anomenar /etc/bind/db.nom_del_nostre_domini i afegir les següents linies al fitxer /etc/bind/named.conf:

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

Per crear una zona de resolució inversa és pràcticament igual (suposem una xarxa privada de classe C 192.168.0.0/24):

;; Aquí pots posar una descripció de la zona
$TTL 1H 
@                       IN      SOA     nom_del_domini_amb_punt_final. hostmaster (
                               2003080101      ; serial
                               8H              ; refresh for slaves
                               3H              ; retry
                               4W              ; expire time at slaves
                               1H              ; negative TTL
                               )
 
                               IN      NS      nom_del_domini_amb_punt_final.
;;;;;;;;;;;;;;;;;;;;;;
; Descripció
;;;;;;;;;;;;;;;;;;;;;; 

;;Noms de màquines amb A
;; Descomenteu aquesta línia si voleu afegir Gateway 
;adreça_IP_gateway             IN      PTR     gateway.nom_del_domini_amb_punt_final.
;Exemple
;1                             IN      PTR     gateway.nom_del_domini_amb_punt_final.
;;Descomenteu aquesta línia si voleu afegir màquines (hosts)
;adreça_IP_host1               IN      PTR     host1.nom_del_domini_amb_punt_final.
;Exemples (només és necessària la part de la ip corresponent a màquina  )
;2                             IN      PTR     host1.nom_del_domini_amb_punt_final.
;3                             IN      PTR     host2.nom_del_domini_amb_punt_final.
;4                             IN      PTR     host3.nom_del_domini_amb_punt_final.
 
; Alternativament podem utilitzar una iteració  amb GENERATE. Exemple per crear 20 hosts
;$GENERATE 0-19 ${2}                  PTR      host${0,2}.nom_del_domini_amb_punt_final.

El fitxer el podem anomenar /etc/bind/db.192.168.0 i afegir les línies següents al fitxer /etc/bind/named.conf:

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

Per comprovar que els fitxers de zona són correctes (no tenen errors sintàctics):

$ sudo named-chekzone nom_domini fitxer_de_zona

El paràmetre -D és útil per debugar si tots els noms de màquina s'han creat correctament (mostra un resum en mode canònic):

$ sudo named-checkzone -D AulaLinux db.aulalinux

També podem comprovar la configuració general de Bind amb:

$ sudo named-chekconf /etc/named.conf

Per aplicar els canvis executem:

$ sudo /etc/init.t/bind9 reload

o

$ sudo rndc reload

Per comprovar que tot va bé podem comprovar la resolució directa de noms amb la comanda ping:

$ ping ip_a_comprovar

I la resolució inversa amb la comanda host:

$ host nom_de_maquina_a_comprovar

Recursos:

Exemple AulaLinux

NOTA: Aquest exemple és compagina amb l'exemple Exemple AulaLinux de l'article sobre DHCP.

En aquest apartat trobeu la solució per a una aula de 15 pcs. El domini l'anomenarem aulalinux i els pcs el volem anomenar ali01, ali02, ali03, ...., ali15, tal i com posa als noms de màquina.

Els rang d'IPs de la xarxa és:

147.83.75.132 a 147.83.75.146

El gateway té l'adreça:

147.83.75.147

I l'ordinador del professor és

147.83.75.130

Fitxer /etc/bind/db.aulalinux.ice.upc.edu:

;; Zona AulaLinux
$TTL 1H
@                       IN      SOA     aulalinux.ice.upc.edu. hostmaster (
                             2004070101      ; serial
                             8H              ; refresh for slaves
                             3H              ; retry
                             4W              ; expire time at slaves
                             1H              ; negative TTL
                             )  

                             IN      NS      domain.aulaLinux.ice.upc.edu.
;;Descomenteu la següent línia si teniu servei correu
;;                            IN      MX      10 mailserver.AulaLinux.ice.upc.edu.
;;;;;;;;;;;;;;;;;;;;;
; Descripció de les traduccions
;;;;;;;;;;;;;;;;;;;;;;  

;;Noms de màquines amb A
;;Descomenteu la següent línia si voleu afegir un Gateway
gateway                         IN      A        147.83.75.129
;;Descomenteu les següents línies si voleu afegir màquines
;;ali01                           IN      A       147.83.75.131
;;ali02                           IN      A       147.83.75.132
;;ali03                           IN      A       147.83.75.133
;;... 

; Alternativament podem utilitzar una iteració  amb GENERATE
;$GENERATE 132-146 ali${0,2}          A       147.83.75.${3}  

;Els servidors de noms i de correu electrònic han de ser host A
;correu                          IN      A       mailserver
;domain                          IN      A       host  

;; Defineix dominis de serveis amb CNAMEs. IMPORTANT: es posen noms de màquina que resolgui DNS i no IPs.
;www                             IN      CNAME   nom_host_web
;ldap                            IN      CNAME   nom_host_ldap 

Si comprovem el fitxer amb la comanda named-checkzone:

$ sudo named-checkzone -D AulaLinux.ice.upc.edu db.aulalinux.ice.upc.edu
db.aulalinux.ice.upc.edu: file does not end with newline
zone AulaLinuxice.upc.edu/IN: loaded serial 2004070101
AulaLinux.ice.upc.edu                                    3600 IN SOA       AulaLinux. hostmaster.AulaLinux. 2004070101 28800 10800 2419200 3600
AulaLinux.ice.upc.edu                                    3600 IN NS        AulaLinux.
gateway.AulaLinux.ice.upc.edu                            3600 IN A         ip_del_gateway
ali01.AulaLinux.ice.upc.edu                               3600 IN A         147.83.75.132
ali02.AulaLinux.ice.upc.edu                               3600 IN A         147.83.75.133
ali03.AulaLinux.ice.upc.edu                               3600 IN A         147.83.75.133
ali04.AulaLinux.ice.upc.edu                               3600 IN A         147.83.75.135
ali05.AulaLinux.ice.upc.edu                               3600 IN A         147.83.75.136
ali06.AulaLinux.ice.upc.edu                               3600 IN A         147.83.75.137
ali07.AulaLinux.ice.upc.edu                               3600 IN A         147.83.75.138
ali08.AulaLinux.ice.upc.edu                               3600 IN A         147.83.75.139
ali09.AulaLinux.ice.upc.edu                               3600 IN A         147.83.75.140
ali10.AulaLinux.ice.upc.edu                               3600 IN A         147.83.75.141
ali11.AulaLinux.ice.upc.edu                               3600 IN A         147.83.75.142
ali12.AulaLinux.ice.upc.edu                               3600 IN A         147.83.75.143
ali13.AulaLinux.ice.upc.edu                               3600 IN A         147.83.75.144
ali14.AulaLinux.ice.upc.edu                               3600 IN A         147.83.75.145
ali15.AulaLinux.ice.upc.edu                               3600 IN A         147.83.75.146

Tot està correcte.

Fitxer /etc/bind/db.147.83.75 (Resolució inversa):

;; resolució inversa AulaLinux.ice.upc.edu
$TTL 1H
@                       IN      SOA     AulaLinux.ice.upc.edu. hostmaster (
                                2006062701      ; serial
                                8H              ; refresh for slaves
                                3H              ; retry
                                4W              ; expire time at slaves
                                1H              ; negative TTL
                                )
 
                              IN      NS      domain.aulaLinux.ice.upc.edu.
;;;;;;;;;;;;;;;;;;;;;;
; Descripció
;;;;;;;;;;;;;;;;;;;;;;   

;;Noms de màquines amb A
;; Descomenteu aquesta línia si voleu afegir Gateway
;;129                    IN      PTR     gateway.AulaLinux.ice.upc.edu.
;Exemple
;1                             IN      PTR     gateway.nom_del_domini_amb_punt_final.
;;Descomenteu aquesta línia si voleu afegir màquines (hosts)
;adreça_IP_host1               IN      PTR     host1.nom_del_domini_amb_punt_final.
;Exemples (només és necessària la part de la ip corresponent a màquina  )
;131                             IN      PTR     ali01.AulaLinux.ice.upc.edu.
;132                             IN      PTR     ali02.AulaLinux.ice.upc.edu.
;133                             IN      PTR     ali03.AulaLinux.ice.upc.edu.

; Alternativament podem utilitzar una iteració  amb GENERATE. Exemple per crear 20 hosts
;$GENERATE 11-25 ${1}                  PTR      ali${0,2}.AulaLinux.ice.upc.edu.

Si comprovem el fitxer amb la comanda named-checkzone:

$ sudo named-checkzone -D AulaLinux.ice.upc.edu db.147.83.75
zone AulaLinux/IN: loaded serial 2006062701
AulaLinux.                                    3600 IN SOA       AulaLinux. hostmaster.AulaLinux. 2003080101 28800 10800 2419200 3600
AulaLinux.                                    3600 IN NS        AulaLinux.
1.AulaLinux.ice.upc.edu                                  3600 IN PTR       gateway.AulaLinux.
11.AulaLinux.ice.upc.edu                                  3600 IN PTR       ali01.AulaLinux.ice.upc.edu.
12.AulaLinux.ice.upc.edu                                  3600 IN PTR       ali02.AulaLinux.ice.upc.edu.
13.AulaLinux.ice.upc.edu                                  3600 IN PTR       ali03.AulaLinux.ice.upc.edu.
14.AulaLinux.ice.upc.edu                                  3600 IN PTR       ali04.AulaLinux.ice.upc.edu.
15.AulaLinux.ice.upc.edu                                  3600 IN PTR       ali05.AulaLinux.ice.upc.edu.
16.AulaLinux.ice.upc.edu                                  3600 IN PTR       ali06.AulaLinux.ice.upc.edu.
17.AulaLinux.ice.upc.edu                                  3600 IN PTR       ali07.AulaLinux.ice.upc.edu.
18.AulaLinux.ice.upc.edu                                  3600 IN PTR       ali08.AulaLinux. ice.upc.edu.
19.AulaLinux.ice.upc.edu                                  3600 IN PTR       ali09.AulaLinux. ice.upc.edu.
20.AulaLinux.ice.upc.edu                                  3600 IN PTR       ali10.AulaLinux. ice.upc.edu.
21.AulaLinux.ice.upc.edu                                  3600 IN PTR       ali11.AulaLinux.ice.upc.edu.
22.AulaLinux.ice.upc.edu                                  3600 IN PTR       ali12.AulaLinux.ice.upc.edu.
23.AulaLinux.ice.upc.edu                                  3600 IN PTR       ali13.AulaLinux.ice.upc.edu.
24.AulaLinux.ice.upc.edu                                  3600 IN PTR       ali14.AulaLinux.ice.upc.edu. 
25.AulaLinux.ice.upc.edu                                  3600 IN PTR       ali15.AulaLinux.ice.upc.edu.

Ara modifiquem el fitxer /etc/bind/named.conf.local:

$ cat /etc/bind/named.conf.local
//
// Do any local configuration here
// 
 
// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";

zone "AulaLinux.ice.upc.edu" {
       type master;
       file "/etc/bind/db.aulalinux.ice.upc.edu";
};

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

Ja podem recarregar bind per tal que tingui en compte els canvis:

$ sudo rndc reload
server reload successful

Ara configurem la màquina client per tal que utilitzi aquest servidor de dns. Editem el fitxer /etc/resolv.conf:

$ sudo joe /etc/bind/resolv.conf
domain AulaLinux.ice.upc.edu
nameserver ip_servidor_dns


Podem deixar les DNS que ja tinguéssim del nostre proveïdor de serveis al final (és el més assenyat per si falla el nostre servidor DNS). De totes maneres recordeu d'activar els forwarders al fitxer d'opcions:

$ sudo joe /etc/named.conf.options
options {
       directory "/var/cache/bind";
 
       ...............................
 
       forwarders {   
               ip_dns_upc_1;
               ip_dns_upc_2;
       };   
 
       auth-nxdomain no;    # conform to RFC1035
 
       ..............................  

El més còmode si utilitzem DHCP és modificar el servidor de DHCP per tal que utilitzi aquest servidor de DNS.

Ara comprovem que tot funciona correctament amb les comandes ping i host:

$ ping pc01
$ host 147.83.75.132

Control d'accés (llistes ACL)

És pot configurar quins clients poden fer ús del servidor de DNS amb llistes de control d'accés (ACL lists). Veiem un exemple extret d'Skolelinux:

Primer és defineix una llista d'accés (grup de ips):

acl skolelinux {
      // Adding the entire 10.0.0.0/8 even if only a small fraction of
      // it is used
      10.0.0.0/8;

      // Ditto for 192.168.0.0/16
      192.168.0.0/16;

      // localhost
      127.0.0.0/8;
};

I a les opcions de bind (fitxer /etc/bind9/named.conf.options) afegim:

// Limiting access to skolelinux hosts
      allow-recursion {
              skolelinux;
      };
      allow-transfer {
              skolelinux;
      };
      allow-query {
              skolelinux;
      };

Configuració de correu electrònic. Registres MX

Permet especificar els servidor de correu electrònic d'un domini o zona. Un exemple:

iesebre.com.    IN    MX    10 ASPMX.L.GOOGLE.com.
iesebre.com.    IN    MX    20 ALT1.ASPMX.L.GOOGLE.com.
iesebre.com.    IN    MX    30 ALT2.ASPMX.L.GOOGLE.com.
iesebre.com.    IN    MX    40 ASPMX2.GOOGLEMAIL.com.
iesebre.com.    IN    MX    50 ASPMX3.GOOGLEMAIL.com.

El primer camp és el nom de domini o zona. El camp de la dreta de tot és el nom del servidor de correu electrònic (normalment prèviament s'ha establer un registre A per a aquest servidor). El penúltim camp indica l'ordre de preferència.

Podem obtenir el registre MX d'un domini amb nslookup:

$ nslookup - 80.58.61.250
> set type=MX
> iesebre.com
Server:		80.58.61.250
Address:	80.58.61.250#53

Non-authoritative answer:
iesebre.com	mail exchanger = 10 ASPMX.L.GOOGLE.com.
iesebre.com	mail exchanger = 20 ALT1.ASPMX.L.GOOGLE.com.
iesebre.com	mail exchanger = 30 ALT2.ASPMX.L.GOOGLE.com.
iesebre.com	mail exchanger = 40 ASPMX2.GOOGLEMAIL.com.
iesebre.com	mail exchanger = 50 ASPMX3.GOOGLEMAIL.com.

Authoritative answers can be found from:
ASPMX.L.GOOGLE.com	internet address = 72.14.221.114
ALT1.ASPMX.L.GOOGLE.com	internet address = 209.85.216.102
ALT2.ASPMX.L.GOOGLE.com	internet address = 209.85.217.41
ASPMX2.GOOGLEMAIL.com	internet address = 209.85.135.27
ASPMX3.GOOGLEMAIL.com	internet address = 209.85.222.5
ASPMX3.GOOGLEMAIL.com	internet address = 209.85.222.6
ASPMX3.GOOGLEMAIL.com	internet address = 209.85.222.4
ASPMX3.GOOGLEMAIL.com	internet address = 209.85.222.8
ASPMX3.GOOGLEMAIL.com	internet address = 209.85.222.7
ASPMX3.GOOGLEMAIL.com	internet address = 209.85.222.3
ASPMX3.GOOGLEMAIL.com	internet address = 209.85.222.1
ASPMX3.GOOGLEMAIL.com	internet address = 209.85.222.2  

O amb dig:

$ dig iesebre.com MX

; <<>> DiG 9.7.1-P2 <<>> iesebre.com MX
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15120
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;iesebre.com.			IN	MX

;; ANSWER SECTION:
iesebre.com.		80981	IN	MX	30 ALT2.ASPMX.L.GOOGLE.com.
iesebre.com.		80981	IN	MX	40 ASPMX2.GOOGLEMAIL.com.
iesebre.com.		80981	IN	MX	50 ASPMX3.GOOGLEMAIL.com.
iesebre.com.		80981	IN	MX	10 ASPMX.L.GOOGLE.com.
iesebre.com.		80981	IN	MX	20 ALT1.ASPMX.L.GOOGLE.com.

;; Query time: 101 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Sep 20 07:55:48 2011
;; MSG SIZE  rcvd: 159

NOTA: Normalment indica les adreces IP públiques dels servidor on s'han d'enviar els correus electrònics per a aquest domini, és a dir els servidors de correu PO3 o IMAP

Un exemple de com configurar un domini per treballar amb Google Apps:

$ cat db.openfpnet.guifi.net
$TTL 500
@		IN	SOA	ns1.openfpnet.guifi.net. info.openfpnet.guifi.net. (
				2011052101 ; Serialnumber
				10800	; Refresh
				3600	; Retry
				604800	; Expire
				86400 )	; Minimum TTL
			NS	ns1.openfpnet.guifi.net.
 		IN 	MX 1 	ASPMX.L.GOOGLE.COM.
 		IN 	MX 5 	ALT1.ASPMX.L.GOOGLE.COM.
 		IN 	MX 5 	ALT2.ASPMX.L.GOOGLE.COM.
 		IN 	MX 10 	ASPMX2.GOOGLEMAIL.COM.
 		IN 	MX 10 	ASPMX3.GOOGLEMAIL.COM.
 		IN 	MX 10 	ASPMX4.GOOGLEMAIL.COM.
 		IN	MX 10 	ASPMX5.GOOGLEMAIL.COM.
 86400 		IN 	A 	88.26.242.77
 86400 		IN 	TXT 	"v=spf1 include:_spf.google.com ~all"
ns1             A       88.26.242.77
webmail 	IN 	CNAME ghs.google.com.


  • file:///usr/share/doc/bind9-doc/arm/Bv9ARM.ch06.html#id2565990

Configuració de zones esclaves

Un exemple és configurar un servidor de DNS a guifi.net. Cal afegir una zona esclava com a (fet amb Webmin):

zone "guifi.net" {
	type slave;
 	masters { 
		80.24.16.164;
		}; 
	file "/var/cache/bind/guifi.net.hosts";
	};

La clau està en definir la zona com esclava i indicar la adreça IP del servidor master.

Aquestes línies s'afegeixen al fitxer (o al que sigui que teniu la configuració de les zones):

/etc/bind/named.conf.local

Al reiniciar bind amb:

$ sudo /etc/init.d/bind9 restart

És genera el fitxer:

$ cat /var/cache/bind/guifi.net.hosts
$ORIGIN .
$TTL 38400	; 10 hours 40 minutes
guifi.net		IN SOA	esperanca.gurb.net. Ramon\.Roca.guifi.net. ( 
				1232134452 ; serial
				10800      ; refresh (3 hours)
				3600       ; retry (1 hour)
				604800     ; expire (1 week)
				38400      ; minimum (10 hours 40 minutes)
				)
			NS	esperanca.gurb.net.
			A	84.88.36.51
$ORIGIN guifi.net.
almogaver		A	10.138.17.4
anoia			CNAME	bandoler
correu.antic		A	10.138.25.68
arguelaguer		A	80.33.93.121
asterisk		CNAME	veuip
ausa			A	10.138.160.98
$ORIGIN ausa.guifi.net.
proxy			CNAME	ausa.guifi.net.
$ORIGIN guifi.net.
avia			CNAME	capolat
$ORIGIN avia.guifi.net.
proxy			CNAME	capolat.guifi.net.
$ORIGIN guifi.net.
bages			A	147.83.101.88
bandoler		A	10.138.25.69
bcn			NS	ns1.bcn
$ORIGIN bcn.guifi.net.
ns1			A	10.138.27.194
$ORIGIN guifi.net.
bdn			NS	ns1.bdn
$ORIGIN bdn.guifi.net.
ns1			A	10.35.228.35
$ORIGIN guifi.net.
bellmunt		A	10.138.52.100
$ORIGIN bellmunt.guifi.net.
proxy			CNAME	bellmunt.guifi.net.
$ORIGIN guifi.net.
grafiques.besalu	CNAME	sibibesalu
bonpreu			A	10.138.41.99
brull			NS	ns1.brull
$ORIGIN brull.guifi.net.
ns1			A	10.138.103.2
...

Recursos:

Registres SOA del servidor master i zones esclaves

Posem com exemple el següent registre SOA:

prova.eu. IN SOA ns.prova.eu. hostmaster.prova.eu. (
                         1        ; Serial
                         3h       ; Refresh after 3 hours
                         1h       ; Retry after 1 hour
                         1w       ; Expire after 1 week
                         1h )     ; Negative caching TTL of 1 hour

El primer número és el número de sèrie. S'utilitza un número i molta gent decideix utilitzar el següent esquema per assignar el número

YYYYMMDDNN

On:

  • YYYY: és l'any
  • MM: és el més
  • DD: és el dia
  • NN: és un comptador que indica que indica quantes vegades s'ha modificat el fitxer de zona en el dia indicat pels camps anteriors.

Per exemple:

2007042001

Aquest ordre és fa així per que l'última modificació sempre serà la que tingui el número de sèrie més gran. Aquest comportament ha de ser així per al correcta funcionament de les zones esclaves, i es imprescindible que el número de sèrie augmenti cada cop que es modifiquen les dades de la zona. Quan un servidor esclau contacta amb un servidor principal, primer pregunta pel número de sèrie de la zona. Si el número de sèrie és major que el número de sèrie de l'esclau aleshores l'esclau fa una actualització de les dades de la zona. Si el fitxer esclau s'inicia i no té cap informació de la zona (no té fitxer de backup o és el primer cop que s'inicia) aleshores sempre carrega la zona.

NOTA: En el cas que s'indiquin múltiples servidors master, aleshores l'esclau escull el que tingui el número de sèrie més alt

Els següents camps estan tots expressats en intervals de temps (si no s'indica res en segons):

  • refresh: Indica als esclaus cada quan han de consultar si hi ha novetats a la zona.
  • retry: Si el servidor esclau falla al intentar connectar amb el servidor master, intentarà tornar a connectar-se cada x temps on x és el temps indicat al camp retry. Normalment aquest calor és menor que el valor de refresh.
  • expireIf: si tarda més del temps indicat en aquest camp en poder connectar amb el master, aleshores la zona expira. Que una zona expira implica que el servidor de DNS ja no donarà més informació sobre aquesta zona als seus clients. Sempre ha de ser més gran que els valors refresh i retry.
  • negative caching TTL: TTL o Time To Live

Camps que es poden utilitzar per especificar dates. Exemples:

  • 3h, 180m, 2h60m, 3d, 6w

El RFC 1537 recomana el següents valors per a servidors de noms top-level:

Refresh        24 hours
Retry           2 hours
Expire         30 days
Default TTL     4 days

Recursos:

Exemple amb servidor Open Suse

Configuració del master (Ubuntu Server 9.10):

$ cat /etc/bind/named.conf.local
...
//Aquest és el servidor master de la zona informatica.iesebre.com
zone "informatica.iesebre.com" {
        allow-transfer { any; };
        type master;
        file "/etc/bind/db.informatica.iesebre.com";
        };

Configuració de l'esclau (Open Suse):

# cat /etc/named.conf
//Obtenir la zona iesebre.com del servidor master
zone "informatica.iesebre.com" {
       type slave;
       masters { 
               192.168.0.40;
               }; 
       file "slave/informatica.iesebre.com.hosts";
       };

On 192.168.0.40 és la IP del master.

Fitxers de log

A Opensuse trobareu la informació de la transferència de zones a:

$ sudo tail -f /var/log/messages | grep named

A debian/Ubuntu:

$ sudo tail -f /var/log/syslog | grep named

Mostrar totes les peticions que arriben al servidor

Cal activar querylog:

$ sudo rndc querylog

Ara podeu consultar els missatges de log a:

$ tail -f /var/log/syslog

Al mateix fitxer de log podreu veure un missatge que diu:

Jul  9 03:56:54 cop named[6738]: received control channel command 'querylog'
Jul  9 03:56:54 cop named[6738]: query logging is now on

Per desactivar el log un altre cop:

$ sudo rndc querylog

Depurar amb l'ordre dig

Podeu fer transferències de zona a mà amb l'ordre dig i el registre axfr. La següent és una transferència de la zona informatica.iesebre.com demanada al servidor master 192.168.0.40:

> dig axfr informatica.iesebre.com @192.168.0.40

; <<>> DiG 9.4.1-P1 <<>> axfr informatica.iesebre.com @192.168.0.40
; (1 server found)
;; global options:  printcmd
informatica.iesebre.com. 86400	IN	SOA	ns1.informatica.iesebre.com. informatica.iesebre.com. 2010012602 10800 3600 604800 86400
informatica.iesebre.com. 86400	IN	NS	ns1.informatica.iesebre.com.
A20-2PC0.informatica.iesebre.com. 86400	IN A	192.168.7.100
A20-2PC1.informatica.iesebre.com. 86400	IN A	192.168.7.101
A20-2PC10.informatica.iesebre.com. 86400 IN A	192.168.7.101
A20-2PC11.informatica.iesebre.com. 86400 IN A	192.168.7.101
A20-2PC12.informatica.iesebre.com. 86400 IN A	192.168.7.101
A20-2PC13.informatica.iesebre.com. 86400 IN A	192.168.7.101
A20-2PC14.informatica.iesebre.com. 86400 IN A	192.168.7.101
A20-2PC15.informatica.iesebre.com. 86400 IN A	192.168.7.101
A20-2PC16.informatica.iesebre.com. 86400 IN A	192.168.7.101
A20-2PC2.informatica.iesebre.com. 86400	IN A	192.168.7.101
A20-2PC3.informatica.iesebre.com. 86400	IN A	192.168.7.101
A20-2PC4.informatica.iesebre.com. 86400	IN A	192.168.7.101
A20-2PC5.informatica.iesebre.com. 86400	IN A	192.168.7.101
A20-2PC6.informatica.iesebre.com. 86400	IN A	192.168.7.101
A20-2PC7.informatica.iesebre.com. 86400	IN A	192.168.7.101
A20-2PC8.informatica.iesebre.com. 86400	IN A	192.168.7.101
A20-2PC9.informatica.iesebre.com. 86400	IN A	192.168.7.101
A20-3PC0.informatica.iesebre.com. 86400	IN A	192.168.7.125
A20-3PC1.informatica.iesebre.com. 86400	IN A	192.168.7.127
A20-3PC10.informatica.iesebre.com. 86400 IN A	192.168.7.136
A20-3PC11.informatica.iesebre.com. 86400 IN A	192.168.7.137
A20-3PC12.informatica.iesebre.com. 86400 IN A	192.168.7.138
A20-3PC13.informatica.iesebre.com. 86400 IN A	192.168.7.139
A20-3PC14.informatica.iesebre.com. 86400 IN A	192.168.7.140
A20-3PC15.informatica.iesebre.com. 86400 IN A	192.168.7.141
A20-3PC16.informatica.iesebre.com. 86400 IN A	192.168.7.142
A20-3PC16.informatica.iesebre.com. 86400 IN A	192.168.7.143
A20-3PC16.informatica.iesebre.com. 86400 IN A	192.168.7.144
A20-3PC2.informatica.iesebre.com. 86400	IN A	192.168.7.128
A20-3PC3.informatica.iesebre.com. 86400	IN A	192.168.7.129
A20-3PC4.informatica.iesebre.com. 86400	IN A	192.168.7.130
A20-3PC5.informatica.iesebre.com. 86400	IN A	192.168.7.131
A20-3PC6.informatica.iesebre.com. 86400	IN A	192.168.7.132
A20-3PC7.informatica.iesebre.com. 86400	IN A	192.168.7.133
A20-3PC8.informatica.iesebre.com. 86400	IN A	192.168.7.134
A20-3PC9.informatica.iesebre.com. 86400	IN A	192.168.7.135
A20-4PC0.informatica.iesebre.com. 86400	IN A	192.168.7.150
A20-4PC1.informatica.iesebre.com. 86400	IN A	192.168.7.151
A20-4PC10.informatica.iesebre.com. 86400 IN A	192.168.7.160
A20-4PC11.informatica.iesebre.com. 86400 IN A	192.168.7.161
A20-4PC12.informatica.iesebre.com. 86400 IN A	192.168.7.162
A20-4PC13.informatica.iesebre.com. 86400 IN A	192.168.7.163
A20-4PC14.informatica.iesebre.com. 86400 IN A	192.168.7.164
A20-4PC15.informatica.iesebre.com. 86400 IN A	192.168.7.165
A20-4PC16.informatica.iesebre.com. 86400 IN A	192.168.7.166
A20-4PC2.informatica.iesebre.com. 86400	IN A	192.168.7.152
A20-4PC3.informatica.iesebre.com. 86400	IN A	192.168.7.153
A20-4PC4.informatica.iesebre.com. 86400	IN A	192.168.7.154
A20-4PC5.informatica.iesebre.com. 86400	IN A	192.168.7.155
A20-4PC6.informatica.iesebre.com. 86400	IN A	192.168.7.156
A20-4PC7.informatica.iesebre.com. 86400	IN A	192.168.7.157
A20-4PC8.informatica.iesebre.com. 86400	IN A	192.168.7.158
A20-4PC9.informatica.iesebre.com. 86400	IN A	192.168.7.159
alumnes.informatica.iesebre.com. 86400 IN A	192.168.2.12
INSEbreXen1.informatica.iesebre.com. 86400 IN CNAME xen.informatica.iesebre.com.
mediawiki.informatica.iesebre.com. 86400 IN A	192.168.7.182
negrell.informatica.iesebre.com. 86400 IN A	192.168.2.2
nemesis.informatica.iesebre.com. 86400 IN A	192.168.0.40
nemesis.informatica.iesebre.com. 86400 IN A	192.168.2.1
nemesis.informatica.iesebre.com. 86400 IN A	192.168.7.182
ns1.informatica.iesebre.com. 86400 IN	A	192.168.7.182
profes.informatica.iesebre.com.	86400 IN A	192.168.2.11
proxy.informatica.iesebre.com. 86400 IN	A	192.168.7.182
www.informatica.iesebre.com. 86400 IN	A	192.168.7.182
xen.informatica.iesebre.com. 86400 IN	A	192.168.2.10
informatica.iesebre.com. 86400	IN	SOA	ns1.informatica.iesebre.com. informatica.iesebre.com. 2010012602 10800 3600 604800 86400
;; Query time: 2 msec
;; SERVER: 192.168.0.40#53(192.168.0.40)
;; WHEN: Tue Jan 26 08:45:03 2010
;; XFR size: 68 records (messages 1, bytes 1716)

DNS notify

In BIND 8, DNS NOTIFY is on by default, but you can turn NOTIFY off globally with the substatement:

    options {
                   notify no;
   };

You can also turn NOTIFY on or off for a particular zone. For example, say you know that all of the slave servers for your acmebw.com zone are running BIND 4, and therefore don't understand NOTIFY requests. The zone statement:

   zone "acmebw.com" {
                   type master;
                   file "db.acmebw";
                   notify no;
   };

La llista per defecte de màquines notificades són les del registre NS de la zona

also-notify { ip_addr [port ip_port] ; [ ip_addr [port ip_port] ; ... ] };

also-notify defines a list of IP address(es) (and optional port numbers) that will be sent a NOTIFY when a zone changes (or the specific zone if the statement is specified in a zone clause). These IP(s)s are in addition to those listed in the NS records for the zone. The also-notify in a zone is not cumulative with any global also-notify statements. If a global notify statement is 'no' this statement may be used to override it for a specific zone and, conversely, if the global options contain a also-notify list, setting notify 'no' in the zone will override the global option. This statement may be used in normal zone, view or a global options clause. While this statement would normally be used in a zone of type 'master' there is nothing to prevent its use in a 'slave' zone - in which case the NOTIFY would be triggered following a zone transfer to the slave.

options {
....
    also-notify {10.1.0.15; 172.28.32.7;}; // all zones
....
};
....
zone "example.com in{
....
    also-notify {10.0.1.2;}; // only this host
....
};
zone "example.net in{
....
    notify no; // no NOTIFY for zone
....
};


zone "acmebw.com" {
                type master;
                file "db.acmebw.com";
                notify yes;
                also-notify 15.255.152.4;
};

Troubleshooting. Resol·lució de problemes

Error al serial del registre SOA. Valor en el futur

Consulteu:

non-authoritative answer from master X

Si als fitxers de log vegeu un missatge similar al següent:

$ sudo tail -f /var/log/messages | grep named
Jan 26 08:26:01 tallafocs-asi named[1296]: zone 0.168.192.in-addr.arpa/IN: refresh: non-authoritative answer from master 192.168.0.9#53 (source 0.0.0.0#0)

Si proveu de fer la consulta manualment:

$ dig 0.168.192.in-addr.arpa @192.168.0.9

; <<>> DiG 9.4.1-P1 <<>> 0.168.192.in-addr.arpa @192.168.0.9
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 40532
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;0.168.192.in-addr.arpa.		IN	A

;; AUTHORITY SECTION:
168.192.in-addr.arpa.	10800	IN	SOA	sirius.xtec.cat. postmaster.xtec.net. 1 3600 1200 604800 10800

;; Query time: 216 msec
;; SERVER: 192.168.0.9#53(192.168.0.9)
;; WHEN: Tue Jan 26 11:26:56 2010
;; MSG SIZE  rcvd: 110

Observeu que la resposta autoritzada no provés del servidor de DNS (en aquest cas prové del servidor de DNS de la xtec). En canvi la zona de resolució directa:

> dig iesebre.com @192.168.0.9

; <<>> DiG 9.4.1-P1 <<>> iesebre.com @192.168.0.9
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13731
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

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

;; AUTHORITY SECTION:
iesebre.com.		86400	IN	SOA	ns.iesebre.com. informatica.iesebre.com. 2010012601 10800 3600 604800 86400

;; Query time: 1 msec
;; SERVER: 192.168.0.9#53(192.168.0.9)
;; WHEN: Tue Jan 26 11:32:57 2010
;; MSG SIZE  rcvd: 80

> ping ns.iesebre.com
PING ns.iesebre.com (192.168.0.9) 56(84) bytes of data.
64 bytes from 192.168.0.9: icmp_seq=1 ttl=64 time=1.21 ms

El servidor de DNS si és l'autoritzat. La configuració de les zones és:

zone "iesebre.com" in {
       allow-transfer { any; };
       file "master/iesebre.com";
       type master;
};
zone "192.168" in {
        allow-transfer { any; };
        file "master/192.168.rev";
        type master;
};

L'error està a

 zone "192.168" in {

Ha de ser:

zone "168.192.in-addr.arpa" {

Seguretat

Open DNS

Tenir un servidor de DNS que suporti recursive queries de qualsevol usuari és una idea molt dolenta idea a nivell de seguretat. Aquests tipus de servidors es poden utilitzar per a realitzar atacs de DDoS (atacs distribuits de Denegació de Servei) i també són molt subsceptibles a atacs de cache poisoning. Amb Bind és posible definir el rang d'adreces IP que tenen permes utilitzar el servidor de DNS com a servidor recursiu (als quals sels anomena closed). POdeu comprovar si el vostre servidor de DNS és Open o no amb:

http://dnscheck.ripe.net/
http://www.cyberciti.biz/faq/dns-cache-poisoning-test/

Una de les normes bàsiques de seguretat és que només s'han d'implementar els serveis mínims per complir els objectius. Es recomana que cada servidor de DNS hauria de proveir només d'un servei, per exemple o:

authoritative only

o

caching only

No els dos casos al mateix temps. A la realitat això no és molt realistic en organitzacions petites i s'executen mixed mode DNS servers. Es poden dur a terme moltes actuacions per mitigar els posibles problemes de seguretat. En configuracions mixtes, es gaunya flexibilitat però s'augmenta el risc.

A bind la clau està en la configuració del paràmetre recursion o similars.

Recursos:

Authoritative only

El terme authoritative only s'utilitza per descriure 2 conceptes:

  • El servidor donarà Authoritative Responses (és un zone master o slave per un o més dominis)
  • El servidor no farà cache

Hi ha dos configuracions on típicament es configura un servidor DNS d'aquest tipus:

No es possible aturar completament el cache a Bind però es pot controlar amb:

// options section fragment of named.conf 
// recursion no = limits caching
options {
	directory "/var/named";
	version "not currently available"; 
	recursion no;
};
// zone file sections
....

Hi ha més paràmetres més per controlar el cache:

  • max-cache-size: no afecta al rendiment en aquest tipus de configuració.
  • max-cache-ttl: no afecta al rendiment en aquest tipus de configuració.
  • allow-recursion, que indica una llista de màquines que tenen permes utilitzar recursion (la resta no)

Es poden utilitzar les vistes DNS per proveir de serveis Authoritative only als usuaris externs només i a la resta (interns) serveis més generals.

The configuration examples shown for authoritative only DNS servers all show the zones as being type master;. Thus if two (or more) DNS servers are being used the master zone files would have to be made available separately to all the servers by an out-of-band process (using, say, SFTP). In general this is the safest configuration. In situations where the zone files are highly dynamic, practical considerations may require that one or all of the zones be slaved from a single source. Zone transfer operations use TCP and are thus vulnerable to a new set of security and DoS threats. Avoid this configuration if possible, if not, as minimum secure the transfers with allow-transfer statements in the master zone clause and it may be worth considering use of TSIG to authenticate zone transfers.

Authoritative Only Name Server Configuration. The BIND DNS configuration provides the following functionality:

   'master' DNS for example.com
   does NOT provide 'caching' services for any other domains
   does NOT provide recursive query services for all resolvers (Iterative only)
   optimised for maximum performance

The BIND 'named.conf' is as follows (click to look at any file):

// AUTHORITATIVE ONLY NAME SERVER for EXAMPLE, INC.
// maintained by: me myself alone
// CHANGELOG:
// 1. 9 july 2003 - did something
// 2. 16 july 2003 - did something else
// 3. 23 july 2003 - did something more
//
options {
  directory "/var/named";
  // version statement - inhibited for security
  // (avoids hacking any known weaknesses)	
  version "not currently available";
  // disable all recursion - authoritative only
	recursion no;
  // disables all zone transfer requests in this case 
  // for performance not security reasons
  allow-transfer{none;};
};
//
// log to /var/log/example.log all events
// from info UP in severity (no debug)
// defaults to use 3 files in rotation
// BIND 8.x logging MUST COME FIRST in this file
// BIND 9.x parses the whole file before using the log
// failure messages up to this point are in (syslog)
// typically /var/log/messages
//
  logging{
  channel example_log{
   file "/var/log/named/example.log" versions 3 size 2m;
   severity info;
   print-severity yes;
   print-time yes;
   print-category yes;
 };
 category default{
  example_log;
 };
};
zone "example.com" in{
  type master;
  file "master/master.example.com";
};
// reverse map for class C 192.168.0.0
zone "0.168.192.IN-ADDR.ARPA" in{
  type master;
  file "192.168.0.rev";
};
// required local host domain
zone "localhost" in{
  type master;
  file "master.localhost";
  allow-update{none;};
};
// localhost reverse map
zone "0.0.127.in-addr.arpa" in{
  type master;
  file "localhost.rev";
  allow-update{none;};
};

Notes:

The reverse mapping zone (zone "0.168.192.IN-ADDR.ARPA" ) was originally omitted from this server - given the use of reverse look-up by anti-spam systems we have restored the reverse look-up zone. It would - in a perfect world without spam - typically not be present on a performance oriented server .

BIND provides three more parameters to control caching ,max-cache-size and max-cache-ttl neither of which will have much effect on performance in the above case and allow-recursion which uses a list of hosts that are permitted to use recursion (all others are not) - a kind of poor man's 'view'.

Recursos:

DNS cache poisoning

DNS Cache Poisoning

El següent vídeo explica molt bé com funciona:

http://www.youtube.com/watch?v=1d1tUefYn4U

Recursos:

Comprovar que no hi ha poisoning

Evitar el cache poisoning amb Bind

El primer i més important és tenir una versió actualitzada de Bind, com a mínim Bind 9.

Cal recordard que hi ha dos tipus de DNS lookups (cerques DNS):

  • iterative: A els consultes iteratives la resposta cap al client pot ser de tipus passar-se la pilota, és a dir, que el servidor pot respondre al client (resolver) amb una resposta que l'indica que un altre servidor d'encarrega o li pot donar la resposta a la seva pregunta i el servidor de DNS no fa res mes
  • recursive: amb el mode recursiu el propi servidor de DNS s'encarregara de buscar la resposta demanada pel clent, i un cop trobada la resposta la retorna al client (resolver). Els clients normals (que no són servidors de DNS) necessiten poder consultar a un servidor recursiu.

El millor mètode per a protegir-se del DNS cache poisoning és no permetre recursive lookups des de fonts desconegudes. Això implica que el servidor no ha de contestar authoritatively respecte a zones que no estan sota el seu control, a no ser que aquestes peticions vinguin de la xarxa interna.

NOTA: Some people will claim this doesn’t help, since the attacker can just spoof an internal IP address; but we have already read my article about border security and know that our ingress filters will stop that, right?

Amb bind 9 això es pot fer amb vistes:

//Put all your “trusted” IPs in here.
acl "inside" {
127/8; 10.0.10/24; 192.168.1/24; };

//zone declarations go here.
view "inside" {
match-clients { "inside"; };
recursion yes;
};

//Same zone declarations go here too.
view "outside" {
match-clients { any; };
recursion no;
};

Recursos:

Stealth Servers

Un servidor stealth de DNS és un servidor DNS que no té registres NS públics per al domini que gestiona. Normalment es necessita per complir dos reguisits:

  • L'organització que gestiona el domini necesita un DNS per als serveis públics: web, mail, ftp etc..
  • La organització no vol que el mon sencer conequi els seus host interns per interrogació del servidor de DNS (query o zone transfer) i a més vols resguardar els servidor de "DNS intern". En certa manera la idea es que si cau el servidor de DNS extern només es veuen afectat els serveis públics però no els serveis privats.

Conceptualment, en certa manera és un expecie de DMZ aplicat als servidors DNS

Split (Stealth) Server configuration

Vegeu imatge a: http://www.zytrax.com/books/dns/ch4/#stealth

Els servidors externs es configuren com Authoritative Only i sense caching (sense acceptar recursive queries). El fitxer de zona d'aquest servidor és únic i conté només els serveis públics (SOA, NS records dels servidors DNS públics (no els stealth), MX record(s), etc. Les transferències de zona poden ser permeses entre servidors públics però no s'han d'acceptar els servidor Stealth.

Es pot obtenir una funcionalitat similar utilitzant vistes DNS però si el servidor DNS es veu compromés les dades estan allà als fitxers de configuració, en canvi al servidor "DMZ" de DNS no.

Un exemple:

; public zone master file
; provides minimal public visibility of external services
example.com.  IN      SOA   ns.example.com. root.example.com. (
                             2003080800 ; se = serial number
                             3h         ; ref = refresh
                             15m        ; ret = update retry
                             3w         ; ex = expiry
                             3h      ; min = minimum
                             )
             IN      NS      ns1.example.com.
             IN      NS      ns2.example.com.
             IN      MX  10  mail.example.com.
ns1           IN      A       192.168.254.1
ns2           IN      A       192.168.254.2
mail          IN      A       192.168.254.3
www           IN      A       192.168.254.4
ftp           IN      A       192.168.254.5

El servidor intern (Stealth Server):


; private zone master file used by stealth server(s)
; provides public and private services and hosts
example.com.  IN      SOA   ns.example.com. root.example.com. (
                              2003080800 ; se = serial number
                              3h         ; ref = refresh
                              15m        ; ret = update retry
                              3w         ; ex = expiry
                              3h         ; min = minimum
                              )
              IN      NS      ns1.example.com.
              IN      NS      ns2.example.com.
              IN      MX  10  mail.example.com.
; public hosts
ns1           IN      A       192.168.254.1
ns2           IN      A       192.168.254.2
mail          IN      A       192.168.254.3
www           IN      A       192.168.254.4
ftp           IN      A       192.168.254.5
; private hosts 
joe           IN      A       192.168.254.6
bill          IN      A       192.168.254.7
fred          IN      A       192.168.254.8
....
accounting    IN      A       192.168.254.28
payroll       IN      A       192.168.254.29

Lame servers

A DNS l'adjetiu s'utilitza per fer referència als servidor de DNS que generen lame delegation o lame response. Quan es realitza el procediment de pregunta/query per recursion o procediment recursiu de DNS per tal de trobar un registre DNS concret, normalment un servidor de noms ha de preguntar a múltiples servidors de noms de forma recursiva, típicament seguint un camí de baixada per la jerarquia DNS. Això és coneix com baixar per la [[cadena d'autoritat (chain of authority) per tal ede trobar una resposta a la pregunta.

Per cada query que es realitza a cada servidor, els servidors de DNS esperen que els altres servidors de DNS siguin autoritzats de la zona. Per exemple, els roots servers s'espera que siguin autoritzats de la root zone. Aquest ens envien a servidor que s'espera que siguin autoritzats de Top Level Domains com el .com. I així recursivament.

Si una pregunta es contestada de forma que indica que el servidor que respon no és autoritzat de la zona, aleshores tenim el que es coneix com a lame response. Com la resposta sol ser una delegació, és a dir una indicació que el servidor que s'encarrega de la zona és una altre, aleshores parlem de lame delegation o lame referral

NOTA: Els servidors Lame normalment es coneixen per que com a simptoma provoquen missatges als fitxers de log del servidor de DNS

Exemples

In our examples, the recursing name server will be called **cache.example.net**. These examples involve trying to look up an A record in the **example.com** zone. We'll suppose that **example.com** is delegated to **ns1.example.com** and **ns2.example.com**.

Example 1

Suppose cache.example.net has nothing in cache except the list of root servers, derived by verifying its hint zone. It receives a recursive query for A records named host1.example.com.

The query that is sent by cache.example.net, every time, is for class IN, type A, name host1.example.com.

 - cache.example.net queries f.root-servers.net
 - a.root-servers.net sends back a referral for com
 - cache.example.net queries c.gtld-servers.net
 - a.gtld-servers.net sends back a referral for example.com
 - cache.example.net queries ns2.example.com
 - ns2.example.com sends back a referral for the root zone **<- lame**
 - cache.example.net logs a lame delegation from ns2.example.com
 - cache.example.net queries ns1.example.com
 - ns1.example.com sends back an authoritative answer

Example 2

Suppose that after the previous example, cache.example.net has cached every answer it received. Further suppose that the authoritative answer at the end contained authority records pointing to ns1.example.com, ns2.example.com, and ns3.example.com.

Now suppose that another recursive query is sent to cache.example.net, this time for host2.example.com.

 - cache.example.net queries ns3.example.com
 - ns3.example.com sends back a referral for the example.com zone **<- lame**
 - cache.example.net queries ns1.example.com
 - ns1.example.com sends back an authoritative answer

Solutions

So what can you do about a lame response message in your server's log? Probably not much - it's probably for a zone you don't control. However, if the lame response is for a zone you control, then you should fix it.

If you want to notify the owner of the zone that one of his servers is lame, you may be able to find the person's email address either through a whois query or by looking at the rname field of the zone's SOA record.

DNSSEC

http://www.robota.net/index.rsws?seccion=6&submenu=1&articulo=1134
http://guifi.net/node/34631

DNSSEC es va disenyar per a protegir Internet de certs tipus d'atacs, com per exemple, DNS cache Poisoning. És una sèrie d'extensions del protocol DNS que proporcionen:

  • Autenticació d'origen de les dades DNS
  • Integritat de les dades
  • Authenticated denial of existence

Aquests mecanismes requereixen de canvis en el protocol DNS. S'afegeixen els següent tipus de registres DNS (record types o DNS Record types):

Aquests nous RRs es descriuen en detall al RFC 4034.

També s'afegeixen dos noves banderes de capçalera (DNS header flags):

Per tal de suportar l'increment en la mida dels missatges DNS resultant d'afegir els DNSSEC RRs. DNSSEC també requereix suport per a EDNS0 (RFC 2671).

Finalment DNSSEC requereix suport per a DNSSEC OK (DO) EDNS header bit (RFC 3225) de forma que un security-aware resolver pugui indicar a les seves queries que desitja rebre els registres de DNSSEC RRs en resposta ala seus missatges. Comprovant la signatura, un DNS resolver és capaç de comprovar si la informació és idèntic (correcte i completa) a la informació del servidor DNS authoritative.

Els serveis DNSSEC protegeixen contra la majoria de les possibles amenaces contra DNS.

Cal tenir en compte que DNSSEC no proporciona confidencialitat de les dades i tampoc no protegeix contra atacs de denegació de servei (DDoS Attacks)

Recursos:

DNSSEC i Bind

Altres conceptes a tenir en compte són:

$ cat /etc/bind/bind.keys
/* $Id: bind.keys,v 1.5.42.1 2010/06/20 07:32:24 marka Exp $ */
managed-keys {
       # NOTE: This key is current as of October 2009.
       # If it fails to initialize correctly, it may have expired;
       # see https://www.isc.org/solutions/dlv for a replacement.
	dlv.isc.org. initial-key 257 3 5 "BEAAAAPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn4MxDCE1+lLy2 brhQv5rN32RKtMzX6Mj70jdzeND4XknW58dnJNPCxn8+jAGl2FZLK8t+ 1uq4W+nnA3qO2+DL+k6BD4mewMLbIYFwe0PG73Te9fZ2kJb56dhgMde5 ymX4BI/oQ+cAK50/xvJv00Frf8kw6ucMTwFlgPe+jnGxPPEmHAte/URk Y62ZfkLoBAADLHQ9IrS2tryAe7mbBZVcOwIeU/Rw/mRx/vwwMCTgNboM QKtUdvNXDrYJDSHZws3xiRXF1Rf+al9UmZfSav/4NWLKjHzpT59k/VSt TDN0YUuWrBNh";
};

Per tal de poder utilitzar DNSSEC tots els dominis pares del domini que voleu validar (jerarquia DNS) també han d'estar signats. Això és el que s'anomena una cadena de confiança ([3]).

Per exemple, el domini:

tortosa.guifi.net

Es una cadena de confiança que es pot dividir en les següents parts, aka trust-anchors (ordenades des de l'arrel (el pare de pares) al fill final):

.
net
guifi
tortosa

Els punts són els separadors de la cadena.

NOTA: Els anchors són les parts de les que es composa una cadena. Vegeu imatges a:

Google Images

El problema és que el domini root (.) i altres dominis principals com com, net o info no estan signats.

Per solucionar aquest problema es va crear DLV (DNSSEC Lookaside Validation) com una forma de poder utilitzar DNSSEC quan les zones pares no estan signades.

Recursos:

Tipus de claus

Les claus d'una zona es guarden als registres DNSKEY. Les claus que s'utilitzen són claus asimètriques i els registres lògicament proporcionen la part pública de la clau (tingueu en compte que són consultables públicament per tal que els clients DNS puguin utilitzar-les)

Hi ha dos tipus de claus per tal de assegurar una zona:

  • Zone Signing Key aka ZSK: s'encarrega de signar els registres d'una zona per tal que puguin ser autenticats/validats.
  • Key Signing Key aka KSK: el propòsit d'aquesta clau és connectar les zones pares amb la vostra zona. El canvi de claus KSK s'ha de coordinar amb la zona pare.

Tot i que els dos tipus de claus es necessiten per tal que funcioni DNSSEC, només la clau KSK es publica externament i la clau ZSK s'utilitza només internament (dins de la zona).

Com que les claus són normalment molt llarges, s'utilitza una forma més compacta per tal de referir-se a elles (els hashes). Els hashes es distribueixen en dos tipus de registres DNS:

Si la zona pare està signada a més de proveir els registres DNS per tal de delegar-vos la zona, també proporcionarà el registre DS. Però com que algunes zones pares no estan signades aleshores s'utilitza el registre DLV

En terminologia DNSSEC, DLV connecta “islands of trust”

Com funciona?

TODO

The original design of the Domain Name System (DNS) did not include security; instead it was designed to be a scalable distributed system. The Domain Name System Security Extensions (DNSSEC) attempts to add security, while maintaining backwards compatibility. RFC 3833 attempts to document some of the known threats to the DNS and how DNSSEC responds to those threats.

DNSSEC was designed to protect Internet resolvers (clients) from forged DNS data, such as that created by DNS cache poisoning. All answers in DNSSEC are digitally signed. By checking the digital signature, a DNS resolver is able to check if the information is identical (correct and complete) to the information on the authoritative DNS server. While protecting IP addresses is the immediate concern for many users, DNSSEC can protect other information such as general-purpose cryptographic certificates stored in CERT records in the DNS. RFC 4398 describes how to distribute these certificates, including those for email, making it possible to use DNSSEC as a worldwide public key infrastructure for email.

DNSSEC does not provide confidentiality of data; in particular, all DNSSEC responses are authenticated but not encrypted. DNSSEC does not protect against DoS attacks directly, though it indirectly provides some benefit (because signature checking allows the use of potentially untrustworthy parties). Other standards (not DNSSEC) are used to secure bulk data (such as a DNS zone transfer) sent between DNS servers. As documented in IETF RFC 4367, some users and developers make false assumptions about DNS names, such as assuming that a company's common name plus ".com" is always its domain name. DNSSEC cannot protect against false assumptions; it can only authenticate that the data is truly from or not available from the domain owner.

The DNSSEC specifications (called DNSSEC-bis) describe the current DNSSEC protocol in great detail. See RFC 4033, RFC 4034, and RFC 4035. With the publication of these new RFCs (March 2005), an earlier RFC, RFC 2535 has become obsolete.

It is widely believed[1] that securing the DNS is critically important for securing the Internet as a whole, but deployment of DNSSEC specifically has been hampered by several difficulties:

   The need to design a backward-compatible standard that can scale to the size of the Internet
   Prevention of "zone enumeration" (see below) where desired
   Deployment of DNSSEC implementations across a wide variety of DNS servers and resolvers (clients)
   Disagreement among implementers over who should own the top-level domain root keys
   Overcoming the perceived complexity of DNSSEC and DNSSEC deployment

Microsoft Windows uses a stub resolver, and Windows Server 2008 R2 and Windows 7 in particular use a non-validating (but DNSSEC-aware) stub resolver.[2][3] For the non-validating stub resolver to place any real reliance on DNSSEC services, the stub resolver must trust both the recursive name servers in question (which is usually controlled by the Internet Service Provider) and the communication channels between itself and those name servers, using methods such as IPsec, SIG(0), or TSIG.[4] The use of IPsec is not widespread.[5]

DNSSEC a Bind 9.8 o superior. Configuració automatitzada de DNSSEC

TODO

The latest version of BIND makes DNSSEC validation very easy to set up. Just put the following lines into the "options" section of your named.conf:

 dnssec-validation auto;
 dnssec-lookaside auto;

When you upgrade from an older version of BIND you need to delete the managed-keys.bind pseudo-zone - BIND will only add its built-in root and DLV trust anchors when it first creates the file.

That's it! Easy! Do it!

Publishing signed zones is getting easier too. If you are an old-skool DNS admin who is a dab hand at editing flat text master files, then the main thing that takes some getting used to is wrangling dynamic DNS instead. Signed zones need to be dynamic so that BIND can refresh the RRSIG records periodically, so you might as well use nsupdate to make changes too, and enjoy the shiny future.

To sign a zone, cd to named's working directory where you will create a set of keys for the zone. (You can tell BIND to look for keys elsewhere using a key-directory statement in each zone block or set it globally in the options section.) Then run these commands:

 dnssec-keygen -f KSK $zone
 dnssec-keygen $zone

This creates two key pairs with the default settings: a key signing key pair and a zone signing key pair. Ensure they are readable by the BIND user.

Then create an initial zone file. It has to have at least a SOA and an NS record. I start off with a copy of my local empty zone and change the SOA and NS later.

 $TTL 1h
 @ SOA localhost. root.localhost. 1 1h 1000 1w 1h
   NS  localhost.

Then add a zone statement to named.conf.

 zone "$zone" {
   type master;
   file "$zone";
   update-policy local;
   auto-dnssec maintain;
 };

The update-policy statement lets you run nsupdate -l on the same machine as the nameserver to make changes to the zone. The auto-dnssec statement tells named to handle re-signing automatically. (It will also handle key rollovers if you pre-generate keys and set their lifetimes.)

Then run rndc reconfig and you are all set!

A couple of other non-default settings are possibly worth noting. There is a new feature which makes adding and deleting zones marginally neater. If you put allow-new-zones yes in your options section then you can use the rndc addzone and delzone commands instead of editing named.conf. When adding a zone you still have to create the keys and zone file first. The other tweak is to set dnssec-dnskey-kskonly yes which reduces the size of the zone apex RRSIG RRset (which should probably be the default).

DNSSEC en servidors Caching/Recursive

TODO: http://ftp.eenet.ee/doc/bind/Bv9ARM.ch04.html

El primer que cal fer es activar DNSSEC al fitxer named.conf (o a sistemes Debian al fitxer named.conf.options):

options {
    ...
    dnssec-enable yes;
    dnssec-validation yes;
    ...
};

La validació es basa en el que s'anomena el model chain-of-trust (cadena de confiança). Una cadena de confiança sempre s'acaba en un authoritative trust-anchor en el qual s'acaba fent la validació.

Per exemple, si es vol validar tot lo que hi ha sota el domini:

*.elmeudomini.com.

es necessita un trust anchor (un anchor és un "eslavon", és a dir la part d'una cadena) tant per al domini elmeudomini.com o per a .com com per .

Com no tots els dominis utilitzen DNSSEC (fins i tot alguns dels Top Level Domains (TLDs) com .com, .net, .us, etc.) la Internet Systems Consortium, Inc. proporciona un registre DLV (DLV registry).

Per a configurar l'ús del registre DLV cal afegir el següent al fitxer de configuració:

trusted-keys {
    dlv.isc.org. 257 3 5 “BEA[...]uDB”;
};

NOTA: La clau està abreviada (observeu els tres punts...)

I al fitxer options cal posar

options {
    dnssec-lookaside . trust-anchor dlv.isc.org.;
};

A partir de la versió 9.7:

http://www.isc.org/software/bind/new-features/9.7

Es pot utilitzar:

options {
    dnssec-lookaside auto;
};

Aleshores s'utilitza Automated trust anchor maintenance for DNSSEC (RFC 5011) que proporciona un nou statement anomenat managed-keys que conté les trusted keys que se mantenen de forma automàtica actualitzades utilitzant RFC 5011. L'statement managed-keys es diferencia de trusted-keys en que té un camp addicional (el segon camp) que conté la paraula clau:

initial-key

Que indica que s'ha d'utilitzar aquesta clau només el primer cop. Bind aleshores guarda les claus en una base de dades (managed keys database).

Si la configuració la heu de fer manual, es poden obtenir les claus que es necessiten a la secció trusted-keys amb dig:

$ dig +dnssec dlv.isc.org. dnskey
;; Truncated, retrying in TCP mode.
; <<>> DiG 9.4.2-P1 <<>> dlv.isc.org. dnskey
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46338
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;dlv.isc.org.                   IN      DNSKEY

;; ANSWER SECTION:
dlv.isc.org.            4319    IN      DNSKEY  257 3 5 BEA[...]uDB
dlv.isc.org.            4319    IN      DNSKEY  256 3 5 BEA[...]Q==
dlv.isc.org.            4319    IN      DNSKEY  256 3 5 BEA[...]w==

Però és més fàcil consultar la web (més endavant explicat en més detall):

https://www.isc.org/solutions/dlv#dlv_key

Ara cal reiniciar el servidor DNS per tal d'aplicar els canvis:

$ sudo service bind reload

Ara el servidor DNS ja té activar DNSSEC, està configurat per a validar i sap on buscar les claus per a les quals no és té un trust-anchor.

Un altre exemple:

options {
 
       dnssec-enable yes;
       dnssec-validation yes;
       dnssec-lookaside auto;

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

On:

/etc/bind/named.iscdlv.key

és on es guarda la clau, però normalment no cal tenir un fitxer separat i ni tan sols cal obtenir la clau de la web del ISC:

https://www.isc.org/solutions/dlv#dlv_key

Al final d'aquesta pàgina està la clau:

This is the key you will need to configure in the trusted-keys clause of your named.conf file.
DLV KSK Public key 	PGP signature 	Published: 2008/09/21
DLV KSK for named.conf 	PGP signature 	Published: 2008/09/21

Hi ha dos fitxers, la clau:

http://ftp.isc.org/www/dlv/dlv.isc.org.key

El contingut és:

dlv.isc.org. IN DNSKEY 257 3 5 BEAAAAPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn4MxDCE1+lLy2 brhQv5rN32RKtMzX6Mj70jdzeND4XknW58dnJNPCxn8+jAGl2FZLK8t+ 1uq4W+nnA3qO2+DL+k6BD4mewMLbIYFwe0PG73Te9fZ2kJb56dhgMde5 ymX4BI/oQ+cAK50/xvJv00Frf8kw6ucMTwFlgPe+jnGxPPEmHAte/URk Y62ZfkLoBAADLHQ9IrS2tryAe7mbBZVcOwIeU/Rw/mRx/vwwMCTgNboM QKtUdvNXDrYJDSHZws3xiRXF1Rf+al9UmZfSav/4NWLKjHzpT59k/VSt TDN0YUuWrBNh

i també:

http://ftp.isc.org/www/dlv/dlv.isc.org.key

Amb un exemple de com incrustar la clau:

trusted-keys {
	dlv.isc.org. 257 3 5 "BEAAAAPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn4MxDCE1+lLy2 brhQv5rN32RKtMzX6Mj70jdzeND4XknW58dnJNPCxn8+jAGl2FZLK8t+ 1uq4W+nnA3qO2+DL+k6BD4mewMLbIYFwe0PG73Te9fZ2kJb56dhgMde5 ymX4BI/oQ+cAK50/xvJv00Frf8kw6ucMTwFlgPe+jnGxPPEmHAte/URk Y62ZfkLoBAADLHQ9IrS2tryAe7mbBZVcOwIeU/Rw/mRx/vwwMCTgNboM QKtUdvNXDrYJDSHZws3xiRXF1Rf+al9UmZfSav/4NWLKjHzpT59k/VSt TDN0YUuWrBNh";
};

En tot cas si la baixeu es bona idea comprovar la signatura PGP.

DNSSEC en servidors autoritzats (Authoritative Nameservers)

El primer que cal fer és activar dnssec al fitxer named.conf (o named.conf.options):

options {
 dnssec-enable yes;
};

Per poder activar DNSSEC cal un bind compilat amb suport per a les llibreries OpenSSL, la majoria de Binds proporcionats pels paquets de la majoria de distribucions ja estan compilats amb aquest suport. A més la versió de Bind ha de ser la 9.4.3-P2 o superior.

Un cop fet això cal seguir els següents subpassos:

  • Generar les claus KSK i ZSK
  • Incloure les claus al fitxer de zona
  • Signar la zona
  • Recarregar la zona (o el servidor Bind)

Els següents apartats expliquen en detall cada una de les parts.

Recursos

Crear les claus d'una zona

Cal crear les claus KSK (Key Signing Key) i ZSK (Zone Signing Key) per a cada zona que es vol fer segura. Les claus no expiren i es poden utilitzar tant de temps com faci falta. Evidentment les parts privades de les claus s'han de mantenir privades i segures.

IMPORTANT: Cal mantenir unes copies de seguretat de les claus a un altre màquina que no sigui el servidor per tal de protegir-se contra errors de disc.

Per crear la clau KSK:

dnssec-keygen -r /dev/random -f KSK -a RSASHA1 -b 2048 -n ZONE example.com

per crear la clau ZSK:

dnssec-keygen -r /dev/random -a RSASHA1 -b 1024 -n ZONE example.com
TODO In the example below, we show the creation of a 2048-bit KSK and a 1024-bit ZSK. You should carefully evaluate if these lengths are adequate for your needs. The KSK is used to sign only a small number of records within your 
zone, while the ZSK is used to sign all records. Making the KSK longer can hurt interoperability with some older servers. Making the ZSK longer will increase the size of every signature, which will make your zone file much larger and 
will make the responses from your server be larger.

Incloure les claus al fitxer de zona

Es pot fer directament o amb $INCLUDES.

TODO. Exemple.

Signar la zona i recarregar la zona

Per cada zona, creeu un fitxer de zona signada, incloent els registres DLV:

dnssec-signzone -l dlv.isc.org -r /dev/random -o example.com -k Kexample.com.+005+aaaaa example.com Kexample.com.+005+bbbbb.key

The argument to -k is the KSK. The ZSK is the last argument. aaaaa and bbbbb will need to be substituted by the corresponding key IDs for your keys.

Per recarregar la zona utilitzeu (recomanat en producció):

$ sudo rndc reload

O reinicieu DNS (no recomanat en producció):

$ sudo service bind restart

Assegurar les transferències de zona

TODO

Amb vistes (una clau per vista?)

$ cat /etc/bind/tsig.key
key "viewguifi" {
         algorithm hmac-md5;
         secret "SECRET_PASSWD";
};
# Slave server IP # 1
server ADREÇA IP DE L'ESCLAU {
        keys {
                viewguifi;
    };
};

On:

viewguifi

és l'identificador que se li dona a la clau.

TSIG Keys

NOTA: Si al generar les claus no us fa res, és que necessiteu més entropia. Executeu en paralel una comanda com:

$ find / -type f | xargs grep KSdgajkgdaksdga

Testejar que funciona correctament

Ensure that resolving of both secured and unsecured zones continues to function.

$ dig +dnssec @127.0.0.1 example.com. soa
$ dig @127.0.0.1 example.com. soa
$ dig @127.0.0.1 your.zone. soa

Depurar

Subdominis

Hi ha dos formes de definir-los:

  • Definir el domini i els subdominis en un sol servidor de DNS.
  • Delegant completament el subdomini a un altre servidors de DNS.

Un sol servidor

Es pot fer especificant els noms de màquina del subdomini de forma explicita o amb la directiva $ORIGIN:

; zone fragment for 'zone name' example.com
; name servers in the same zone
$TTL 2d ; zone default TT = 2 days
$ORIGIN example.com.
@              IN      SOA   ns1.example.com. hostmaster.example.com. (
               2003080800 ; serial number
               2h         ; refresh =  2 hours 
               15M        ; update retry = 15 minutes
               3W12h      ; expiry = 3 weeks + 12 hours
               2h20M      ; minimum = 2 hours + 20 minutes
               )
; main domain name servers
              IN      NS     ns1.example.com.
              IN      NS     ns2.example.com.
; mail servers for main domain
              IN      MX 10  mail.example.com.
; A records for name servers above 
ns1           IN      A      192.168.0.3
ns2           IN      A      192.168.0.4
; A record for mail servers above 
mail          IN      A      192.168.0.5
; other domain level hosts and services
bill          IN      A      192.168.0.6
....
; sub-domain definitions
$ORIGIN us.example.com.
              IN      MX 10  mail
; record above uses blank substituition 
; and could have been written as 
; us.example.com.   IN  MX 10 mail.us.example.com.
; OR (using @ substitution)
; @ IN MX 10 mail
; A record for subdomain mail server
mail          IN      A      10.10.0.28
; the record above could have been written as 
; mail.us.example.com. A 10.10.0.28 if it's less confusing
ftp           IN      A      10.10.0.29 
; the record above could have been written as 
; ftp.us.example.com. A 10.10.0.29 if it's less confusing
....
; other subdomain definitions as required 

H per ordre potser es recomanable utilitzar la directiva INCLUDE:

; snippet from file above showing use of $INCLUDE
....
; other domain level hosts and services
bill          IN      A      192.168.0.5
....
; sub-domain definitions
$INCLUDE us-subdomain.sub
; other subdomain definitions as required 

Delegant el subdomini

La clau d'aquesta configuració està en el que s'anomenen els GLUE RECORDS i les circular dependencies. Els glue records són registres que s'inclouen al servidor DNS del domini pare que contenen les adreces dels servidors DNS del domini fill tot i que els servidors DNS del domini fill no són, estrictament parlant, propis de la zona pare.

Per a més informació vegeu:

Terminologia DNS

Per exemple, si el servidor DNS autoritzat per al domini

example.org

és:

ns1.example.org

un ordinador que miri de resoldre:

www.example.org 

Primer resoldra:

ns1.example.org

Com que ns1 està contingut a example.org, aleshores cal resoldre primer:

example.org

El que representa una dependència circular. Per trecanr aquesta dependència, el servidor de noms del top level domain inclou un glue record conjuntament amb la delegació example.org (en els casos de servidors top level domain, aquestes canvis es fan al registrar un domini en un registrador de dominis autoritzat).

Vegem però ara un exemple dins d'un organització provada que delega en suborganitzacions la gestió de part del seu domini. Per exemple amb:

  • Domini principal: example.com
  • Subdomini: subdomain.example.com

Al fitxer de zona del domini principal:

   subdomain        IN    NS    ns1.subdomain.example.com.
                    IN    NS    ns2.subdomain.example.com.
   ns1.subdomain.example.com.    IN  A  IP_SERVIDOR_DNS1
   ns2.subdomain.example.com.    IN  A  IP_SERVIDOR_DNS2

Això pel que fa a la delegació de resol·lucions directes. Per fer la delegació de les zones inverses cal (un exemple):

;; DOMINI.CAT: 109.69.10.0/28 rzone delegation http://ww.ietf.org/rfc/rfc2317.txt
0/28                    NS      ns1.domini.cat.
1                       CNAME   1.0/28.10.69.109.in-addr.arpa.
2                       CNAME   2.0/28.10.69.109.in-addr.arpa.
3                       CNAME   3.0/28.10.69.109.in-addr.arpa.
4                       CNAME   4.0/28.10.69.109.in-addr.arpa.
5                       CNAME   5.0/28.10.69.109.in-addr.arpa.
6                       CNAME   6.0/28.10.69.109.in-addr.arpa.
7                       CNAME   7.0/28.10.69.109.in-addr.arpa.
8                       CNAME   8.0/28.10.69.109.in-addr.arpa.
9                       CNAME   9.0/28.10.69.109.in-addr.arpa.
10                      CNAME   10.0/28.10.69.109.in-addr.arpa.
11                      CNAME   11.0/28.10.69.109.in-addr.arpa.
12                      CNAME   12.0/28.10.69.109.in-addr.arpa.
13                      CNAME   13.0/28.10.69.109.in-addr.arpa.
14                      CNAME   14.0/28.10.69.109.in-addr.arpa.
;; end of domini.cat rzone subnet elegation

Això es fa seguint el RFC2317:

Classless IN-ADDR.ARPA delegation

Per tal de fer la comprovació de la resol·lució inversa:

$ host 109.69.10.2
2.10.69.109.in-addr.arpa is an alias for 2.0/28.10.69.109.in-addr.arpa.
2.0/28.10.69.109.in-addr.arpa domain name pointer 109-69-10-2-puntcat.ip4.guifi.net.

Recursos:

Vistes (views)

Les vistes de DNS permeten especificar diferent informació segons un criteri especific. Per exemple ex pot definir una vista que només s'aplicarà per als clients que vinguin d'una xarxa concreta. Per exemple una vista que s'apliqui a tots els clients:

view "global" { 
	match-clients { any; };
};


view "internal" {
   match-clients { 127.0.0.1; 10.0.0.0/8; 172.0.0.0/8;
};
   recursion yes;  

   zone "node.cat" IN {
       type master;
       file "node.cat.local";
               allow-transfer { any; };
               allow-update { none; };
   };
etc...

Exemple de petició externa:

view "external" {
   match-clients { any; };
   recursion no;  

   zone "node.cat" IN {
        type master;
       file "node.cat.internet";
       allow-transfer { none; };
               allow-update { none; };
   }; 


Recursos:

Comanda rndc

Aquesta comanda ens permet controlar el servidor de noms bind utilitzant comandes. Podem consultar les comandes disponibles executant rndc sense paràmetres:

$ rndc
Usage: rndc [-c config] [-s server] [-p port]
      [-k key-file ] [-y key] [-V] command

command is one of the following:

reload        Reload configuration file and zones.
reload zone [class [view]]
              Reload a single zone.
refresh zone [class [view]]
              Schedule immediate maintenance for a zone.
retransfer zone [class [view]]
              Retransfer a single zone without checking serial number.
freeze zone [class [view]]
              Suspend updates to a dynamic zone.
thaw zone [class [view]]
              Enable updates to a frozen dynamic zone and reload it.
reconfig      Reload configuration file and new zones only.
stats         Write server statistics to the statistics file.
querylog      Toggle query logging.
dumpdb [-all|-cache|-zones] [view ...]
              Dump cache(s) to the dump file (named_dump.db).
stop          Save pending updates to master files and stop the server.
stop -p       Save pending updates to master files and stop the server
              reporting process id.
halt          Stop the server without saving pending updates.
halt -p       Stop the server without saving pending updates reporting
              process id.
trace         Increment debugging level by one.
trace level   Change the debugging level.
notrace       Set debugging level to 0.
flush         Flushes all of the server's caches.
flush [view]  Flushes the server's cache for a view.
flushname name [view]
              Flush the given name from the server's cache(s)
status        Display status of the server.
recursing     Dump the queries that are currently recursing (named.recursing)
*restart      Restart the server.

El podem utilitzar per fer que bind s'adoni de canvis ens els fitxers de configuració (identic a reload de l'script /etc/init.d/bind9) i fins i tot només executar canvis per zones però també es pot utilitzar per estadístiques i consultes de la memòria cau. Per fer un volcat de totes les resolucions de noms de domini que té bind a la memòria cau:

$ sudo rndc dumpdb

Aquest volcat es guarda en el fitxer named_dump.db:

/var/cache/bind/named_dump.db

que es troba a la carpeta de base de dades de bind (especificada a les opcions de bind) que normalment és /var/cache/bind.

Cal tenir en compte que rndc es pot utilitzar per configurar un servidor DNS bind remotament (cal configurar-ho).

Recursos:

Aplicar els canvis d'una zona

Es pot utilitzar rndc reload:

$ sudo rndc reload fubar.com IN external

IMPORTANT: Observeu com s'indica la vista external! Si no utilitzeu vistes podeu utilitzar simplement:

$ sudo rndc reload fubar.com

Si al fitxer de zona no s'ha fet cap canvi us donarà el missatge:

$ sudo rndc reload fubar.com IN default
zone reload up-to-date
$ sudo rndc reload insalfacs.cat IN default
zone reload queued

Consultar l'estatus d'un servidor DNS

$ sudo rndc status
version: 9.6.1-P2
CPUs found: 2
worker threads: 2
number of zones: 14
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
recursive clients: 0/0/1000 
tcp clients: 0/100
server is up and running

Consultar les estadístiques

NOTA: Per defecte no estan activades

$ sudo rndc stats

S'interpreten de la següent manera:

TODO:
success The number of successful queries made to the server or zone. A successful query is defined as query which returns a NOERROR response with at least one answer RR.
referral 	The number of queries which resulted in referral responses.
nxrrset 	The number of queries which resulted in NOERROR responses with no data.
nxdomain 	The number of queries which resulted in NXDOMAIN responses.
failure 	The number of queries which resulted in a failure response other than those above.
recursion 	The number of queries which caused the server to perform recursion in order to find the final answer.

Es guarden al fitxer d'estadístiques:

/var/cache/bind/named.stats

Aquest fitxer es pot canviar amb l'opció statistics-file

[ statistics-file path_name; ]

Cal posar-lo al fitxer options:

$ sudo joe /etc/named/named.conf.options

options {
       directory "/var/cache/bind";
       statistics-file "/var/cache/bind/named.stats";
...

I es poden activar estadístiques per zones:

zone-statistics

[ zone-statistics yes | no ; ]

A la versió 9.5 hi ha un servidor d'estadístiques que les proporciona en XML per poder-les consultar en remot:

http://www.isc.org/software/bind/new-features/9.5

Volcar les consultes recursives

$ sudo rndc recursing

les trobareu a:

/var/cache/bind/named.recursing

Proves amb la memòria CAU

NOTA: exemples executats en un servidor de DNS en local

La primera consulta:

$ dig xtec.cat
...
;; Query time: 76 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jan 12 07:55:03 2010
;; MSG SIZE  rcvd: 497

Les següents:

$ dig xtec.cat
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jan 12 07:59:15 2010
;; MSG SIZE  rcvd: 106

Si torneu a netejar la cache us tornarà a tardar més temps:

$ sudo rndc flush

Comprovació de DNS

Comprovació de la configuració del servidor

Comanda named-checkconf

Permet comprovar si el fitxer de configuració és correcte:

$ named-checkconf /etc/bind/named.conf

Seguint la filosofia Linux:

No news good news

Si la comanda no torna cap resultat és que no hi ha cap error. En cas contrari ens mostrarà es línies que tenen error:

$ sudo named-checkconf /etc/bind/named.conf
/etc/bind/named.conf:20: unknown option 'one'

Cal tenir en compte que per defecte es consulta el fitxer de configuració named.conf però que poseu especificar altres fitxers. També cal tenir en compte que això només comprova la sintaxi d'aquest fitxers i no pas si la configuració de les zones és correcta (cal fer-ho amb named-checkzone).

També és interessant utilitzar l'opció -z per tal d'obtenir més informació (fins i tot en alguns casos mostra errors):

$ sudo /usr/sbin/named-checkconf -z
zone iesebre.com/IN: loaded serial 2010012602
zone 168.192.in-addr.arpa/IN: loading from master file master/192.168.rev failed: file not found
_default/168.192.in-addr.arpa/in: file not found

Recursos:

Comanda named-checkzone

Permet comprovar si el fitxer de configuració és correcte. Un exemple

$ named-checkzone iescopernic.com /etc/bind/db.iescopernic.com
zone iescopernic.com/IN: loaded serial 2004070102
OK

En cas d'error ens indicarà quina és la línia on hi ha error.

La sintaxi completa és:

$ named-checkzone [-d] [-j] [-q] [-v] [-c class] [-k mode] [-n mode] [-o filename] [-t directory] [-w directory] [-D] {zonename} {filename}

On:

Recursos:

Comprovació de la configuració des dels clients

Ordres dig, nslookup, host i ping

Per comprovar la configuració en una màquina client podeu utilitzar les ordres:

  • ping: Comprovació simple de la resol·lució directa (registres A i CNAME)
  • host: Comprovació simple de la resol·lució inversa (registres PTR)
  • dig: Eina molt completa per a fer consultes DNS a servidors
  • nslookup: Eina molt completa per a fer consultes DNS a servidors

Comanda dig

Consulteu dig.

Comanda h2n

Logging

Es configura amb l'statement logging, sinó s'indica res per defecte:

logging {
     category default { default_syslog; default_debug; };
     category unmatched { null; };
};

Activar el query Log

Vegeu un exemple a:

Munin#Bind_plugin

bindgraph

Exemple. Activar Logging per a la depuració

NOTA: No ho he provat!

logging {
 channel dnssec_log {
 file "log/dnssec" size 20m;
 print-time yes;
 print-category yes;
 print-severity yes;
 severity debug 3;
 };
 category dnssec {
 dnssec_log;
 };
};

Performance. Rendiment. Tunning

Paràmetres a tenir en compte:

  • clients-per-query
  • tcp-clients
  • recursive-clients
clients-per-query, max-clients-per-query:
These set the initial value (minimum) and maximum number of recursive simultanious clients for any given query (<qname,qtype,qclass>) that the server will accept before  
dropping additional clients. named will attempt to self tune this value and changes will be logged. The default values are 10 and 100.

This value should reflect how many queries come in for a given name in the time it takes to resolve that name. If the number of queries exceed this value, named will assume 
that it is dealing with a non-responsive zone and will drop additional queries. If it gets a response after dropping queries, it will raise the estimate. The estimate will 
then be lowered in 20 minutes if it has remained unchanged.

If clients-per-query is set to zero, then there is no limit on the number of clients per query and no queries will be dropped.

If max-clients-per-query is set to zero, then there is no upper bound other than imposed by recursive-clients.
recursive-clients:
The maximum number of simultaneous recursive lookups the server will perform on behalf of clients. The default is 1000. Because each recursing client uses a fair bit of 
memory, on the order of 20 kilobytes, the value of the recursive-clients option may have to be decreased on hosts with limited memory.

tcp-clients:
The maximum number of simultaneous client TCP connections that the server will accept. The default is 100. 

Als fitxers de log podem observar com bind augmenta clients-per-query quan és necessari:

$ sudo cat /var/log/syslog.1 | grep clients-per-query
Apr 20 21:14:05 cop named[856]: clients-per-query increased to 15
Apr 20 21:34:05 cop named[856]: clients-per-query decreased to 14
Apr 20 21:54:05 cop named[856]: clients-per-query decreased to 13
Apr 20 22:14:05 cop named[856]: clients-per-query decreased to 12
Apr 20 22:34:05 cop named[856]: clients-per-query decreased to 11
Apr 20 22:54:05 cop named[856]: clients-per-query decreased to 10

Recursos:

Eines de mesura del rendiments

dnsperf

A Ubuntu:

# cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=9.10
DISTRIB_CODENAME=karmic
DISTRIB_DESCRIPTION="Ubuntu 9.10"
$ sudo apt-get install libbind-dev build-essential libssl-dev
$ sudo apt-get install dnsutils bind9
$ sudo apt-get install libcap-dev tshark
$ cd /usr/lib/
$ sudo ln -s libgssapi_krb5.so.2.2 libgssapi_krb5.so                # Jo ja el tenia
$ sudo ln -s libxml2.so.2.7.5 libxml2.so
$ cd /usr/src
$ sudo wget ftp://ftp.nominum.com/pub/nominum/dnsperf/1.0.1.0/dnsperf-src-1.0.1.0-1.tar.gz
$ sudo tar zxvf dnsperf-src-1.0.1.0-1.tar.gz
$ cd dnsperf-src-1.0.1.0-1
$ sudo ./configure
$ sudo make
$ sudo make install

L'executable el teniu a:

/usr/local/bin/dnsperf

Des de la carpeta:

nsperf-src-1.0.1.0-1
$ dnsperf -s dns.hostingaldescubierto.com < examples/queryfile-example-100thousand

Monitoritzar

Munin

dnstop

$ sudo apt-get install dnstop

S'utilitza amb

$ sudo dnstop eth0

Mostra les peticions de DNS que es reben en temps real i de qui provenen.

Per defecte té 2 taules, dominis primaris i dominis secundaris. Es poden consultar premen les tecles 1 i 2 respectivament durant la execució de dnstop. Es poden posar més subnivells amb -l :

$ sudo dnstop -l 5 eth0

Es poden consultar els tipus de registres amb la tecla t (type):

Query Type     Count      %
---------- --------- ------
A?               224   56.7
AAAA?            142   35.9
A6?               29    7.3

Amb la tecla s es torna a la llista de clients (origens de les peticions). Si teniu múltiples targetes de xarxa podeu veure per on us arriben més peticions amb d (destinacions de les peticions DNS)

Es pot consulta l'ajuda completa amb la tecla ?:

s - Sources list
d - Destinations list
t - Query types
o - Opcodes
r - Rcodes
1 - 1st level Query Names      ! - with Sources
2 - 2nd level Query Names      @ - with Sources
3 - 3rd level Query Names      # - with Sources
4 - 4th level Query Names      $ - with Sources
5 - 5th level Query Names      % - with Sources
6 - 6th level Query Names      ^ - with Sources
7 - 7th level Query Names      & - with Sources
8 - 8th level Query Names      * - with Sources
9 - 9th level Query Names      ( - with Sources
^R - Reset counters
^X - Exit
 ? - this

Client DNS

Consulteu Client DNS

DNS i Ldap

NOTA: Per tal que funcionin els passos d'aquest apartat recordeu que el servidor de DNS ha de tenir registre A a Ldap/Gosa sinó la zona directa us fallarà.

IMPORTANT: Aquest apartat suposa que ja teniu el arbre Ldap ple amb la informació necessària de les zones DNS a gestionar. Això és pot fer utilitzant Gosa i el plugin per a DNS o també es pot fer a mà.

Vegeu també: OpenFPnet/Hacklabs/Serveis de xarxa (DNS i DHCP) amb Ldap i Gosa/Unir DNS a LDAP

No hi ha una configuració de Bind que permeti llegir la seva configuració d'un servidor Ldap. De totes maneres cal tenir en compte que si utilitzéssim aquest tipus de configuració i la volguéssim dinàmica el servidor Ldap tindria un munt de peticions.

Per tant, es molt millor un sistema que tingui certa cache. L'eina ldap2zone pot ser molt útil:

$ sudo apt-get install ldap2zone ldap-utils
...
S'instaŀlaran els següents paquets extres:
 bind9 bind9-host bind9utils dnsutils libbind9-60 libdns69 libisc62 libisccc60 libisccfg62 liblwres60
...

NOTA: El paquet ldap2zone només està disponible a Ubuntu des de la versió Lucid 10.04 http://packages.ubuntu.com/maverick/ldap2zone. Vegeu també ldap2dns

NOTA: Podeu gestionar el servidor Ldap i de fet també les màquines que utilitzarant DNS amb Gosa. Consulteu Gosa#Bind_.28DNS.29 per veure com cal instal·lar configurar el plugin de Gosa. Si no teniu gosa de fet us recomanem que l'instal·leu des de zero seguint les instruccions de Gosa#Instal.C2.B7laci.C3.B3_de_gosa_2.7_pas_a_pas_a_Ubuntu_10.10. Aquesta instal·lació ja inclou el plugin de DNS i també el DHCP. DHCP també es pot gestionar amb Ldap i Gosa, consulteu Gosa#DHCP

La versió a una Ubuntu 10.10 és:

$ dpkg -l ldap2zone
...
+++-=================================-=================================-==================================================================================
ii  ldap2zone                         0.2-1                             Extract DNS zones from LDAP trees

Consulteu http://packages.ubuntu.com/oneiric/ldap2zone

Els fitxers proporcionats són:

$ dpkg -L ldap2zone
/.
/etc
/etc/default
/etc/default/ldap2zone
/etc/cron.d
/etc/cron.d/ldap2zone
/usr
/usr/sbin
/usr/sbin/ldap2zone
/usr/sbin/ldap2bind
/usr/share
/usr/share/doc
/usr/share/doc/ldap2zone
/usr/share/doc/ldap2zone/changelog.gz
/usr/share/doc/ldap2zone/dnszonehowto.html
/usr/share/doc/ldap2zone/copyright
/usr/share/doc/ldap2zone/README.Debian
/usr/share/doc/ldap2zone/changelog.Debian.gz
/usr/share/lintian
/usr/share/lintian/overrides
/usr/share/lintian/overrides/ldap2zone
/usr/share/man
/usr/share/man/man1
/usr/share/man/man1/ldap2zone.1.gz
/usr/share/doc-base
/usr/share/doc-base/ldap2zone

IMPORTANT: A la versió de Ubuntu oneiric apareix el fitxer /etc/default/ldap2zone/default...

L'ordre /usr/sbin/ldap2zone és una aplicació desenvolupada en C que accepta tres paràmetres:

$ ldap2zone domain_name_amb_punt_final. ldap_uri TTL

On:

  • domain_name_amb_punt_final.: Nom del domini o zona que es vol obtenir del servidor Ldap. S'ha de posar el punt final.
  • ldap uri: URI del servidor Ldap al qual ens volem connectar.
  • TTL (time to live):

Un exemple:

$ ldap2zone intranet.gonicus.de. ldap://localhost 500

o

$ ldap2zone iesebre.com. ldap://192.168.0.8/dc=iesebre,dc=com 1200
$TTL 1200
@		IN	SOA	ns1.iesebre.com. maninfo.iesebre.com. ( 
				201011211 ; Serialnumber
				10800	; Refresh
				3600	; Retry
				604800	; Expire
				86400 )	; Minimum TTL
			NS	ns1.iesebre.com.
cop			A	192.168.0.4
...

Podeu també consultar el fitxer README:

$ sudo joe /usr/share/doc/ldap2zone/README.Debian

Podeu obtenir més informació al manual:

$ man ldap2zone

L'altre executable és:

ldap2bind

Es tracta d'un script de shell executable tal i com podeu veure amb l'ordre file:

$ file /usr/sbin/ldap2bind
/usr/sbin/ldap2bind: POSIX shell script text executable

Aquest script utilitza les configuracions indicades a /etc/default/ldap2zone.

IMPORTANT: A la versió 11.10 de Ubuntu el paquet no proporciona el fitxer directament al path /etc/default/ldap2zone. Executeu:

$ sudo mv /etc/default/ldap2zone /etc/default/ldap2zoneold
$ sudo mv /etc/default/ldap2zoneold/default /etc/default/ldap2zone

L'original era:

$ cat /etc/default/ldap2zone
# Configuration file for automatic deployment of ldap2zone generated zones to bind

# Should we run the cronjob
# DEFAULT: "false"
RUN_DEPLOY="false"

# How the LDAP server can be accessed
# DEFAULT: "ldap://localhost"
#LDAP_URI="ldap://localhost"

# Where the zonefiles are located
# DEFAULT: "/etc/bind"
BIND_DIR="/etc/bind"

# Time to live value for a and ptr records
# DEFAULT: 500 Seconds
TTL="500" 

# Prefix for zone definition files
# DEFAULT: "db."
# The zone definition file for 0.168.192.in-addr.arpa is stored as 'db.0.168.192.in-addr.arpa'
PREFIX="db."

# Allow Updates from these networks (semicolon separated and ended)
# DEFAULT: Don't allow updates
#ALLOW_UPDATE="192.168.0.0/24

L'he modificat per:

# Configuration file for automatic deployment of ldap2zone generated zones to bind

# Should we run the cronjob
# DEFAULT: "false"
RUN_DEPLOY="false"

LDAP_HOST_PARAM="192.168.0.8"
LDAP_BASE_DN="dc=iesebre,dc=com"

# How the LDAP server can be accessed
# DEFAULT: "ldap://localhost"
LDAP_URI="ldap://$LDAP_HOST_PARAM/$LDAP_BASE_DN"


# Where the zonefiles are located
# DEFAULT: "/etc/bind"
BIND_DIR="/etc/bind"

# Time to live value for a and ptr records
# DEFAULT: 500 Seconds
TTL="500"

# Prefix for zone definition files
# DEFAULT: "db."
# The zone definition file for 0.168.192.in-addr.arpa is stored as 'db.0.168.192.in-addr.arpa'
PREFIX="db."

# Allow Updates from these networks (semicolon separated and ended)
# DEFAULT: Don't allow updates
#ALLOW_UPDATE="192.168.0.0/24;"
#Afegit per Sergi Tur el 9 de setembre de 2012
#Descomentar si s'utilitza una vista per a les dades Ldap
VIEW=default

El contingut de l'script /usr/sbin/ldap2bind(modificat per mi) és:

$ sudo joe /usr/sbin/ldap2bind
#!/bin/sh

[ -r /etc/default/ldap2zone ] && . /etc/default/ldap2zone 

case "$LDAP_URI" in
ldap://*|ldaps://*) ;;
 *) LDAP_URI="ldap://${LDAP_URI}" ;; 
 esac

LDAPSEARCH=`which ldapsearch`

if [ -z "${LDAPSEARCH}" ]; then
        echo "ldapsearch program not in $PATH. Exiting..."
        exit 1
fi

LDAP_URI_PARAM=${LDAP_URI:+"-H $LDAP_URI"}

if [ "$ALLOW_UPDATE" ]; then
        ALLOW_UPDATE_PARAM="allow-update {$ALLOW_UPDATE}";
else ALLOW_UPDATE_PARAM=;
fi

#echo "ldapsearch -LLL -h $LDAP_HOST_PARAM -x \"(objectClass=dNSZone)\" zoneName -b $LDAP_BASE_DN";
ZONES=`ldapsearch -LLL -h $LDAP_HOST_PARAM -x "(objectClass=dNSZone)" zoneName -b $LDAP_BASE_DN | grep zoneName: | sort | uniq | awk '{print $2}'`
ldap2zone=`which ldap2zone`
rndc=`which rndc`

if [ -z "${ZONES}" ]; then
        echo "No domains configured. Exiting..."
        exit 0
fi

if [ -z "${rndc}" ]; then  
        echo "rndc program not in $PATH. Exiting..."
        exit 1
fi

if [ -z "${ldap2zone}" ]; then
        echo "ldap2zone program not in $PATH. Exiting..."
        exit 1
fi

if [ ! -d $BIND_DIR ]; then
        echo "The directory specified as BIND_DIR does not exist. Exiting..."
        exit 1
fi
   
if [ -w $BIND_DIR/named.conf.ldap2zone ]; then
        >${BIND_DIR}/named.conf.ldap2zone
        for domain in $ZONES; do
                cat << EOF >> ${BIND_DIR}/named.conf.ldap2zone
zone "${domain}" {
        type master;
        file "${BIND_DIR}/${PREFIX}${domain}";
        $ALLOW_UPDATE_PARAM
};
EOF
        done
        $rndc reconfig
fi

for domain in $ZONES; do
#       echo
#        echo
#        echo "Setting $domain..."
#        echo
#        echo "Executing $ldap2zone $domain $LDAP_URI $TTL ..."
        if $ldap2zone $domain $LDAP_URI $TTL > /tmp/$domain; then
                lines=$(cat /tmp/$domain | wc -l)
                [ $lines -gt 1 ] && mv /tmp/$domain $BIND_DIR/${PREFIX}${domain}
        fi

#        echo "Executing $rndc reload $domain ..."
        result=$($rndc reload $domain in $VIEW 2>&1)
        if [ $? -ne 0 ]; then
                printf "Reloading the zone '$domain' failed:\n$result\n" 1>&2
        else
                printf "Reloading the zone '$domain' was successful\n" 1>&2
        fi
done


$ sudo /usr/sbin/ldap2bind
Reloading the zone '0.168.192.in-addr.arpa.' was successful
Reloading the zone 'iesebre.com.' was successful

El original era:

#!/bin/sh

[ -r /etc/default/ldap2zone ] && . /etc/default/ldap2zone

case "$LDAP_URI" in
ldap://*|ldaps://*) ;;
 *) LDAP_URI="ldap://${LDAP_URI}" ;;
 esac

LDAPSEARCH=`which ldapsearch`

if [ -z "${LDAPSEARCH}" ]; then
        echo "ldapsearch program not in $PATH. Exiting..."
        exit 1
fi

LDAP_URI_PARAM=${LDAP_URI:+"-H $LDAP_URI"}

if [ "$ALLOW_UPDATE" ]; then
        ALLOW_UPDATE_PARAM="allow-update {$ALLOW_UPDATE}";
else ALLOW_UPDATE_PARAM=;
fi

ZONES=`ldapsearch -LLL $LDAP_HOST_PARAM -x "(objectClass=dNSZone)" zoneName | grep zoneName: | sort | uniq | awk '{print $2}'`
ldap2zone=`which ldap2zone`
rndc=`which rndc`

if [ -z "${ZONES}" ]; then
        echo "No domains configured. Exiting..."
        exit 0
fi

if [ -z "${rndc}" ]; then
        echo "rndc program not in $PATH. Exiting..."
        exit 1
fi

if [ -z "${ldap2zone}" ]; then
        echo "ldap2zone program not in $PATH. Exiting..."
        exit 1
fi

if [ ! -d $BIND_DIR ]; then
        echo "The directory specified as BIND_DIR does not exist. Exiting..."
        exit 1
fi

if [ -w $BIND_DIR/named.conf.ldap2zone ]; then
        >${BIND_DIR}/named.conf.ldap2zone
        for domain in $ZONES; do
                cat << EOF >> ${BIND_DIR}/named.conf.ldap2zone
zone "${domain}" {
        type master;
        file "${BIND_DIR}/${PREFIX}${domain}";
        $ALLOW_UPDATE_PARAM
};
EOF
        done
        $rndc reconfig
fi

for domain in $ZONES; do
        if $ldap2zone $domain $LDAP_URI $TTL > /tmp/$domain; then
                lines=$(cat /tmp/$domain | wc -l)
                [ $lines -gt 1 ] && mv /tmp/$domain $BIND_DIR/${PREFIX}${domain}
        fi

        result=$($rndc reload $domain 2>&1)
        if [ $? -ne 0 ]; then
                printf "Reloading the zone '$domain' failed:\n$result" 1>&2
        else
                printf "Reloading the zone '$domain' was successful\n" 1>&2
        fi
done

Ara cal configurar bind per tal d'utilitzar els fitxers creats per ldap2zone. Afegiu la línia:

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

Al fitxer /etc/bind/named.conf, quedarà de la següent manera:

...
include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";
include "/etc/bind/named.conf.ldap2zone";

Ara creeu el fitxer /etc/bind/named.conf.ldap2zone, que ha de contenir els fitxers de zona. Per exemple:

zone "0.168.192.in-addr.arpa." {
       type master;
       file "/etc/bind/db.0.168.192.in-addr.arpa.";
       
};
zone "16.172.in-addr.arpa." {
       type master;
       file "/etc/bind/db.16.172.in-addr.arpa.";
       
};
zone "20.168.192.in-addr.arpa." {
       type master;
       file "/etc/bind/db.20.168.192.in-addr.arpa.";
       
};
zone "202.168.192.in-addr.arpa." {
       type master;
       file "/etc/bind/db.202.168.192.in-addr.arpa.";
       
};
zone "203.168.192.in-addr.arpa." {
       type master;
       file "/etc/bind/db.203.168.192.in-addr.arpa.";
       
};
zone "204.168.192.in-addr.arpa." {
       type master;
       file "/etc/bind/db.204.168.192.in-addr.arpa.";
       
};
zone "30.168.192.in-addr.arpa." {
       type master;
       file "/etc/bind/db.30.168.192.in-addr.arpa.";
       
};
zone "6.168.192.in-addr.arpa." {
       type master;
       file "/etc/bind/db.6.168.192.in-addr.arpa.";
       
};
zone "alumnat.iesebre.com." {
       type master;
       file "/etc/bind/db.alumnat.iesebre.com.";
       
};
zone "aula202.iesebre.com." {
       type master;
       file "/etc/bind/db.aula202.iesebre.com.";
       
};
zone "aula203.iesebre.com." {
       type master;
       file "/etc/bind/db.aula203.iesebre.com.";
       
};
zone "aula204.iesebre.com." {
       type master;
       file "/etc/bind/db.aula204.iesebre.com.";
       
};
zone "electrics.iesebre.com." {
       type master;
       file "/etc/bind/db.electrics.iesebre.com.";
       
};
zone "gestio.iesebre.com." {
       type master;
       file "/etc/bind/db.gestio.iesebre.com.";
       
};
zone "iesebre.com." {
       type master;
       file "/etc/bind/db.iesebre.com.";
       
};
zone "professorat.iesebre.com." {
       type master;
       file "/etc/bind/db.professorat.iesebre.com.";
       
};

Per activar el cron cal posar al fitxer /etc/default/ldap2zone:

$ cat /etc/default/ldap2zone
...
RUN_DEPLOY="true"
...

Aleshores s'executarà cron cada hora::

$ cat /etc/cron.d/ldap2zone
PATH=/sbin:/bin:/usr/sbin:/usr/bin

@reboot   bind  /usr/sbin/ldap2bind
@hourly   bind  /usr/sbin/ldap2bind

Hi ha que canviar l'usuari bind per root:

$ sudo joe /etc/cron.d/ldap2zone
PATH=/sbin:/bin:/usr/sbin:/usr/bin

@reboot   root  /usr/sbin/ldap2bind
@hourly   root  /usr/sbin/ldap2bind

Podeu comprovar que funciona consultant el syslog:

$ cat /var/log/syslog | grep ldap2bind
Feb  8 07:00:01 cop CRON[12514]: (bind) CMD ( /usr/sbin/ldap2bind)
Feb  8 08:00:01 cop CRON[12749]: (bind) CMD ( /usr/sbin/ldap2bind)
Feb  8 09:00:01 cop CRON[12983]: (bind) CMD ( /usr/sbin/ldap2bind)
Feb  8 10:00:01 cop CRON[13221]: (bind) CMD ( /usr/sbin/ldap2bind)

Finalment l'últim pas és millorar el rendiment de les consultes Ldap, afegint els índex necessaris, si no ho feu així veureu al fitxer de lo els següents missatges:

$ sudo cat /var/log/syslog | grep slapd
...
Feb 11 06:50:32 caro slapd[9601]: <= bdb_equality_candidates: (relativeDomainName) not indexed
Feb 11 06:50:32 caro slapd[9601]: <= bdb_equality_candidates: (zoneName) not indexed

Per afegir els índexs cal connectar-se al servidor Ldap a la base de dades de configuració (cn=config). Es pot fer amb Apache Directory Studio i a l'objecte:

olcDatabase={1}hdb,cn=config

Afegir:

olcDbIndex zoneName,relativeDomainName eq

Per acabar de crear l'index atureu ldap:

$ sudo /etc/init.d/slapd stop

I utilitzar slapindex:

$ sudo /usr/sbin/slapindex
$ sudo chown openldap:openldap -R /var/lib/ldap

Ara torneu a iniciar ldap:

 $ sudo /etc/init.d/slapd start

Vegeu també:

Recursos:

Codi font

Subversion:

https://oss.gonicus.de/repositories/goto/trunk/ldap2zone/

Debian QA:

http://packages.qa.debian.org/l/ldap2zone.html

Changelog:

http://packages.debian.org/changelogs/pool/main/l/ldap2zone/current/changelog

Altres:

http://packages.debian.org/search?keywords=ldap2zone

Mantenidors:

Cajus Pollmeier
Benoit Mortier  

Ubuntu:

http://packages.ubuntu.com/oneiric/ldap2zone

ldap2bind i vistes

La versió original de la comanda no té en compte les possibles vistes que tingui DNS i per això si treballeu en vistes podeu tenir el problema que no sàpiga diferència a quina vista us referiu al intentar actualitzar la zona:

$ sudo [[rndc]+ reload insalfacs.cat
rndc: 'reload' failed: not found

En canvi especificant la vista:

$ sudo rndc reload insalfacs.cat. in default
zone reload up-to-date

o

$ sudo rndc reload insalfacs.cat. in educat
zone reload up-to-date

Per a tenir en compte les vistes només cal afegir una variable al fitxer /etc/default/ldap2zone:

#Afegit per Sergi Tur el 9 de setembre de 2012
#Descomentar si s'utilitza una vista per a les dades Ldap
VIEW=default

I modificar una línia del fitxer /usr/sbin/ldap2bind. Canvieu:

result=$($rndc reload $domain 2>&1)

per

result=$($rndc reload $domain IN $VIEW 2>&1)

Si la variable VIEW és deixa buida aleshores s'executa:

$ sudo rndc reload ZONENAME IN

Que funciona correctament i executa el reload de la zona indicada a la vista per defecte.





Vegeu també:

ldap2dns

TODO: Paquet similar

Recursos:

Configuracions. Exemples

Servidor DNS només cache

Exemple de servidor només cache:

// Two corporate subnets we wish to allow queries from.

acl corpnets { 192.168.4.0/24; 192.168.7.0/24; };
options {
       directory "/etc/namedb";                        // Working directory
       allow-query { corpnets; };
};
// Provide a reverse mapping for the loopback address 127.0.0.1
zone "0.0.127.in-addr.arpa" {
       type master;
       file "localhost.rev";
       notify no;
};

Recursos:

Load Balancing

Un servidor de DNS es pot utilitzar per fer un repartiment de càrrega rudimentari. Si tenim 3 servidors web replicats (10.0.0.1, 10.0.0.2 i 10.0.0.3):

www              600        IN           A                10.0.0.1
                 600        IN           A                10.0.0.2
                 600        IN           A                10.0.0.3

Wildcard. Redireccionar qualsevol subdomini a una IP concreta

Un exemple:

*.photomatt.net. 14400 IN A 64.246.62.114

Per exemple això és necessari per a utilitzar wordpress-mu

Recursos:


Establir registre A per a la màquina "sense nom" d'un domini

Imagineu que esteu gestionant el domini infocentre.santabarbara.cat i voleu que al fer ping:

infocentre.santabarbara.cat

Contesti una IP concreta. Aleshores cal afegir un registre A global.

$ sudo cat db.infocentre.santabarbara.cat. 
$TTL 500
@		IN	SOA	ns1.infocentre.santabarbara.cat. maninfo.infocentre.santabarbara.cat. (
				2011032701 ; Serialnumber
				10800	; Refresh
				3600	; Retry
				604800	; Expire
				86400 )	; Minimum TTL
			NS	ns1.infocentre.santabarbara.cat.
			A	192.168.1.7
Buffalo			A	192.168.1.59
RB750G			A	192.168.1.2
routerADSL		A	192.168.1.1
ProvaperaDNSiDHCP		A	192.168.1.51
Impressora1TODO		A	192.168.1.6
Impressora2TODO		A	192.168.1.18
Impressora3TODO		A	192.168.1.199
infocentreSBrb		A	192.168.1.7
ns1			A	192.168.1.7
www			A	192.168.1.7
moodle			A	192.168.1.7
mediawiki		A	192.168.1.7


Segrestar algunes dominis. Repositoris Ubuntu

La idea és "segrestar" els següents noms de domini:

  • .archive.ubuntu.com (es.archive.ubuntu.com, ad.archive.ubuntu.com, etc... i el propi archive.ubuntu.com)
  • security.ubuntu.com'

Per què? Doncs bé per tal que a la nostra xarxa local, les màquines Ubuntu al fer actualitzacions no se les descarreguin d'Internet, sinó del nostre propi mirror dels repositoris.

Avantatges:

  • No cal modificar el fitxer /etc/apt/sources.list de cada màquina
  • Qualsevol PC, o disc dur itinerant (que hagi de funcionar a la nostra pròpia xarxa i fora d'ella) funcioni el mirror a la nostra xarxa i fora de forma transparent als usuaris.

Suposem que el mirror el tenim a la màquina:

192.168.0.7

Aquesta és la configuració de DNS que hem utilitzat.

Hem creat dos fitxers:

$ cat /etc/bind/db.archive.ubuntu.com
$TTL 1H
@                       IN      SOA     archive.ubuntu.com. hostmaster (
                                2007041701      ; serial
                                8H              ; refresh for slaves
                                3H              ; retry
                                4W              ; expire time at slaves
                                1H              ; negative TTL
                                )  

                                IN      NS      ns.archive.ubuntu.com
;;;;;;;;;;;;;;;;;;;;;;
; Server with aliases
;;;;;;;;;;;;;;;;;;;;;;
ns                    IN      A     192.168.0.7
archive.ubuntu.com.   IN      A     192.168.0.7
ch.archive.ubuntu.com IN      A     130.59.10.34
*.archive.ubuntu.com. IN      A     192.168.0.7 

NOTA:

En aquest cas el nom de màquina ch.archive.ubuntu.com apunta a un repositori "real". És necessari per tal que apt-mirror pugui fer les còpies

$cat /etc/bind/db.security.ubuntu.com
$TTL 1H
@                       IN      SOA     security.ubuntu.com. hostmaster (
                                2007041701      ; serial
                                8H              ; refresh for slaves
                                3H              ; retry
                                4W              ; expire time at slaves
                                1H              ; negative TTL
                                )

                                IN      NS      ns.security.ubuntu.com
;;;;;;;;;;;;;;;;;;;;;;
; Server with aliases
;;;;;;;;;;;;;;;;;;;;;;
ns                     IN      A            192.168.0.7
security.ubuntu.com.   IN      A     192.168.0.7 

i hem afegit les zones al fitxer /etc/bind/named.conf.local:

$cat /etc/bind/named.conf.local
...........

//Mirrors d'ubuntu
zone "archive.ubuntu.com" {
       type master;
       file "/etc/bind/db.archive.ubuntu.com";
};

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

Això conjuntament amb la configuració d'Apt-mirror, ens estalvia un munt de temps i ample de banda a la xarxa.

Llistes. address_match_list

Les 4 xarxes predefinides són:

   "none" - matches no host IP addresses
   "any" - matches all host IP addresses
   "localhost" - matches all the IP address(es) of the server on which BIND is running but only when accessed from the same host (internal). For example, if the server has a single interface with an IP address of 192.168.2.3 then localhost will match 192.168.2.3 and 127.0.0.1 (the loopback address is always present) when issued from the same host, but if any external request arrives on 192.168.2.3 it will not match.
   "localnets" - matches all the IP address(es) and subnetmasks of the server on which BIND is running. For example, if the server has a single interface with an IP address of 192.168.2.3 and a netmask of 255.255.255.0 (or 192.168.2.2/24) then localnets will match 192.168.2.0 to 192.168.2.255 and 127.0.0.1 (the loopback is always present and has a single address, that is a netmask of 255.255.255.255). Some systems do not provide a way to determine the prefix lengths of local IPv6 addresses. In such a case, localnets only matches the local IP addresses, just like localhost though in this case it will apply to external and internal (same host) requests.

Configurar el nostre servidor per acceptar peticions recursives

http://www.zytrax.com/books/dns/ch7/queries.html

IMPORTANT: Els valors per defecte d'un servidor Bind acabat d'instal·lar a Ubuntu són:

recursion yes;
allow-recursion NOT PRESENT (no s'especificat)
allow-query-cache {localnets; localhost;}

Per tant es permeten consultes recursives des de localhost o des de les xarxes locals privades, és a dir, si el servidor pertany (té una IP) d'una o més xarxes locals, aleshores estan podran utilitzar el servei recursiu ([4]).

Vegem cada paràmetre/statement en detall:

recursion:

Del manual:

recursion yes | no;

IMPORTANT: Aquest paràmetre només es pot definir a una vista o les opcions globals de Bind

Si s'estableix recursion a:

recursion yes;

s'està explicitant el valor per defecte i el servidor sempre proporcionarà recursive query behaviour si el client DNS (resolver) el demana.

Si s'estableix:

recursion no; 

El servidor només proveirà iterative query behaviour. El valor del paràmetre allow-recursion si existeix passa a ser irellevant (globalment si l'opció es global o a nivell de vista si es posa a la vista) i el valor allow-query-cache s'estableix a allow-query-cache {none;};

allow-recursion | allow-recursion-on

El paràmetre:

 allow-recursion

juntament amb les vistes DNS permet controlar de forma més fina o granulada el comportament de la recursivitat. Només es pot especificar en una vista o en els paràmetres globals.

Sintaxi:

allow-recursion { address_match_list };
allow-recursion-on { address_match_list };
allow-recursion { 10.0/16; };
allow-recursion-on { 192.168.2.3; };

Només és relevant si esta present l'entrada:

recursion yes;

O no hi ha entrada recursion. Per defecte recursion yes; està actiu. Dit d'un altre manera si recursion és:

recursion no;

Aleshores no té sentit.

NOTA: Si allow-recursion esta present allow-query-cache passa a tenir els mateixos valors

allow-recusion-on permet definir les interfícies que permetrant recursivitat en un servidor multi-homed. Valor per defecte:

allow-recursion-on {any;};) 

Es a dir en principi s'accepten a qualsevol interfície (si es que s'accepten en general)

allow-query-cache, allow-query-cache-on

Només es poden utilitzar en vistes o en la zona de paràmetres globals.

Sintaxi:

allow-query-cache { address_match_list };
allow-query-cache-on { address_match_list };
allow-query-cache { 10/8; };
allow-query-cache-on { localhost; };

Com funciona:

If recursion no; present, defaults to allow-query-cache {none;};. No local cache access permitted.

If recursion yes; (default) then, if allow-recursion present, defaults to the value of allow-recursion. Local cache access permitted to the same address_match_list as allow-recursion.

If recursion yes; (default) then, if allow-recursion is NOT present, defaults to allow-query-cache {localnets; localhost;};. Local cache access permitted to localnets and localhost only.

Es prefereix l'ús de allow-recursion, tot i que tots dos valors permeten fer el mateix. De fet allow-recursion té preferència.

allow-query-cache-on defines the server interface(s) from which queries that access the local cache are accepted and can be useful where a server is multi-homed, perhaps in conjunction with a view clause. Defaults to allow-query- 
cache-on {any;};) meaning that queries that access the local cache are accepted on any server interface.

Com hem dit, només acceptarem peticions de DNS des de les xarxes a les que esta connectat directament el servidor. Això ho podem consultar al fitxer named.conf.options.

$ cat /etc/bind/named.conf.options
options {
        directory "/var/cache/bind";

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

        // query-source address * port 53;  

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

        forwarders {
                195.235.113.3;
                195.235.96.90;
        }; 

        auth-nxdomain no;    # conform to RFC1035 

        // By default, name servers should only perform recursive domain
        // lookups for their direct clients.  If recursion is left open
        // to the entire Internet, your name server could be used to
        // perform distributed denial of service attacks against other
        // innocent computers.  For more information on DDoS recursion:
        // http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0987 

        allow-recursion { localnets; 192.168.0.0/16; }; 

        // If you have DNS clients on other subnets outside of your
        // server's "localnets", you can explicitly add their networks
        // without opening up your server to the Internet at large:
        // allow-recursion { localnets;}; 

        // If your name server is only listening on 127.0.0.1, consider:
        // allow-recursion { 127.0.0.1; }; 

};

La secció que ens interessa és l'allow-recursion i afegir la xarxa a la que permetem peticions recursives:

// By default, name servers should only perform recursive domain
       // lookups for their direct clients.  If recursion is left open
       // to the entire Internet, your name server could be used to
       // perform distributed denial of service attacks against other
       // innocent computers.  For more information on DDoS recursion:
       // http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0987 

       allow-recursion { localnets; 192.168.0.0/16; };

Tal i com diu l'aplicació del missatge cal anar en compte amb qui deixem fer peticions recursives. Llegiu:

En xarxes amb diverses subxarxes o hem de tenir en compte.

Split Horizon DNS Server

TODO

The term Split Horizon is normally used to describe a DNS server that will give different responses (IP addresses) based on the source address, or some other characteristic, of the query. While it has similar configuration properties to the Stealth Server it can also be used in a varity of unique situations such as:

  • Geographic Mapping: Assume that, for example, a web service is replicated in a number of locations (for either performance or access latency reasons) then a specific IP address may be returned based on the source address of the query to ensure the shortest possible path from the user to the service. For those familiar with anycast you could consider this as a poor man's anycast service.
  • Naming Consistency: Assume that you have, say, a corporate in-house LDAP service and that you want to keep certain highly secure data on one server only accessible to certain individuals or organizational sections, which have unique or identifiable IP addresses or address ranges, but for reasons of consistency (scripts, configuration files etc) you want both the secure and insecure LDAP services to be named, say, ldap.example.com.
  • Load Balancing: Assume that an analysis of incoming service users shows that their source-ip addresses can be separated into contiguous ranges: 50% from a to b, 50% from b to c. In this case rather than simply provide multiple A/AAAA RRs (where load balancing is essentially random) it may be more effective to use a split-horizon strategy.

Other possibilities may strike imaginative readers. The unifying element is that some characteristic of the incoming query will cause the DNS to generate a query-dependent result.

S'utilitzen les vistes DNS de Bind per fer aquest tipus de configuració.

Recursos:

Forwarding de zones

Es poden definir zones forwarding. Aquest tipus de zones no les gestionem nosaltres però sobrescrivim els forwardings indicats al fitxer /etc/bind/name.conf.options i per a una zona concreta utilitzem uns DNS concrets. Per exemple es pot fer amb el domini xtec.cat de la següent forma:

zone "xtec.cat" {
    type forward;
    forwarders { 213.176.161.16; 213.176.161.18;};
};
               antics (1) 	        nous (2)
DNS primari 	193.145.88.16 	fletxa 	213.176.161.16
DNS secundari 	193.145.88.18 	fletxa 	213.176.161.18

Es poden consultar amb:

$ nslookup
> set type=ns
> xtec.cat
Server:		127.0.0.1
Address:	127.0.0.1#53

Non-authoritative answer:
xtec.cat	nameserver = sirius.xtec.net.
xtec.cat	nameserver = vega.xtec.net.

Authoritative answers can be found from:
vega.xtec.net	internet address = 213.176.161.18
sirius.xtec.net	internet address = 213.176.161.16

Resolució de problemes. Troubleshooting/FAQ

DNS format error. Error (FORMERR) resolving 'XXX/A/IN': IP#53

Un exemple:

Feb  2 18:21:49 ns2 named[10979]: DNS format error from 185.13.76.12#53 resolving altfarm.mediaplex.com/A for client 10.139.221.168#42475: non-improving referral
Feb  2 18:21:49 ns2 named[10979]: error (FORMERR) resolving 'altfarm.mediaplex.com/A/IN': 185.13.76.12#53
Feb  2 18:21:49 ns2 named[10979]: DNS format error from 185.13.76.12#53 resolving ./NS: non-improving referral
Feb  2 18:21:49 ns2 named[10979]: error (FORMERR) resolving './NS/IN': 185.13.76.12#53


Size limit exceeded (4) amb ldap2bind

Si us dona l'error.

$ sudo ldap2bind
Size limit exceeded (4)

Consulteu Ldap#Les_consultes_tornen_un_m.C3.A0xim_de_500_registres

bad owner name (check-names)

Pot ser degut a un nom de màquina incorrecte:

$ sudo named-checkconf
sergi@cop:/etc/bind$ sudo named-checkzone -d 0.168.192.in-addr.arpa /etc/bind/db.0.168.192.in-addr.arpa.
loading "0.168.192.in-addr.arpa" from "/etc/bind/db.0.168.192.in-addr.arpa." class "IN"
/etc/bind/db.0.168.192.in-addr.arpa.:17: warning: depttecnologic-.docent.insalfacs.cat: bad name (check-names)
zone 0.168.192.in-addr.arpa/IN: loaded serial 2012090717
OK

Problemes amb DNSSEC i la mida del paquet UDP limitada per firewalls a 512bytes

Unknown option 'ACL'

Cal posar l'ACL fora de la secció option.

rndc: connect failed: 127.0.0.1#953: connection refused

$ sudo nmap localhost -p 953

Starting Nmap 5.00 ( http://nmap.org ) at 2011-02-04 10:43 CET
Warning: Hostname localhost resolves to 2 IPs. Using 127.0.0.1.
Interesting ports on localhost (127.0.0.1):
PORT    STATE  SERVICE
953/tcp closed rndc 

Nmap done: 1 IP address (1 host up) scanned in 0.17 seconds
sergi@cop:~$ sudo nmap 192.168.0.4 -p 953

Starting Nmap 5.00 ( http://nmap.org ) at 2011-02-04 10:43 CET
Interesting ports on 192.168.0.4:
PORT    STATE  SERVICE
953/tcp closed rndc

Nmap done: 1 IP address (1 host up) scanned in 0.22 seconds

Consultes IPv6 afecten al rendiment del servidor DNS

Es pot desactivar a /etc/default/bind9 posant l'opció -4

# startup options for the server
OPTIONS="-4 -u bind"

checkhints: L.ROOT-SERVERS.NET/A (198.32.64.12) extra record in hints

Si als logs us apareix:

checkhints: L.ROOT-SERVERS.NET/A (198.32.64.12) extra record in hints

És que no teniu actualitzada la llista de servidors de root:

La llista es pot trobar a:

ftp://ftp.internic.net/domain/named.root

A Open Suse el fitxer amb els servidors DNS de root és:

/var/lib/named/root.hint

També heu de tenir la zona definida al fitxer de configuració /etc/named.conf:

zone "." {
        type hint;
        file "root.hint";
};  

zone "0.0.127.in-addr.arpa" {
        type master;
        file "127.0.0.zone";
};


unexpected RCODE (REFUSED) resolving X

Jan 26 08:38:37 tallafocs-asi named[1296]: unexpected RCODE (REFUSED) resolving 'tinyurl.com/A/IN': 212.0.97.81#53

TODO

NS has no address records

Si als fitxers de log vegeu un missatge com:

$ sudo tail -f /var/log/messages

zone informatica.iesebre.com/IN: NS 'ns1.informatica.iesebre.com' has no address records

És que heu declarar un servidor de noms per a una zona al registre SOA però no li heu posat el corresponent registre A. Per exemple a:

@       IN      SOA     ns1.informatica.iesebre.com. informatica.iesebre.com. (
                        2010012602
                        3H
                        1H
                        1W
                        1D ) 

           IN      NS   ns1.informatica.iesebre.com.
www        IN      A    192.168.7.182

Falta al final la línia:

ns1        IN      A    192.168.7.182


/etc/bind/rndc.key: permission denied

NOTA: Sovint aquest error en màquines Debian succeïx quan s'instal·len al mateix temps els paquets bind i bind9

Després d'una actualització de DNS al setembre de 2006 va deixar de funcionar DNS. Als logs sortia el següent error:

$ sudo cat /var/log/daemon.log | grep named
............
............
Sep 21 12:18:06 tjener named[6894]: /etc/bind/named.conf:62: open: /etc/bind/rndc.key: permission denied

La solució la vaig trobar aquí: http://bugs.skolelinux.no/long_list.cgi?buglist=1115

Cal canviar els permisos, el propietari del fitxer:

sudo chown root:bind rndc.key

Resolució inversa?

Com es pot fer resolució inversa (obtenir el nom de domini a partir de la ip)?

$ host 147.83.20.2
  2.20.83.147.in-addr.arpa domain name pointer atonito.lsi.upc.edu

Windows XP utilitza el servidor secundari

  1. Click Start, click Run, type regedit, and then click OK.
  2. Locate and then click the following key in the registry:
     HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters
  1. On the Edit menu, point to New, and then click REG_DWORD.
  2. Type ServerPriorityTimeLimit, and then press ENTER.
  3. On the Edit menu, click Modify.
  4. Type 0, and then click OK.

Consulteu:

Error "no more recursive clients: quota reached"

Bind accepta fins a 200 clients concurrents per defecte. Si es necessiten més es pot afegir a named.conf:

options
 { 
	recursive-clients       2500;
}

Cal calcular que cada procés utilitza uns 20K.

Recursos

lame server resolving ...

Si trobeu missatges del tipus:

$ sudo cat /var/log/daemon.log | grep lame
Mar 12 18:02:44 moodle named[1451]: lame server resolving 'www.betandwin.es' (in 'betandwin.es'?): 86.109.96.208#53

En principi són missatges de configuracions incorrectes de servidors DNS. No són perilloses.

Es poden treure aquests logs amb:

logging
{ 
	category lame-servers { null; };
}

Comodins/Jokers

Es pot utilitzar el caràcter * per indicar un conjunt de subdomini qualsevol.Exemple:

*                                IN      A       10.0.3.234

Això permet que qualsevol domini que no s'hagi especificat explícitament vagi a una màquina per defecte.

Com es pot fer resolució directa (obtenir la IP a partir del nom de domini)?

$ ping atonito.lsi.upc.edu
PING atonito.lsi.upc.edu (147.83.20.2) 56(84) bytes of data.

Com obtenir tota la informació d'una zona DNS

Per exemple si volem veure el dns de la zona ubuntu.com:

$ dig @ns.ubuntu.com ubuntu.com axfr  

; <<>> DiG 9.3.2 <<>> @ns.ubuntu.com ubuntu.com axfr
; (1 server found)
;; global options:  printcmd
ubuntu.com.             3600    IN      SOA     ns.ubuntu.com. hostmaster.canonical.com. 2007041303 10800 3600 604800 3600
ubuntu.com.             600     IN      A       82.211.81.212
ubuntu.com.             10800   IN      NS      ns.ubuntu.com.
ubuntu.com.             10800   IN      NS      ns0.blackcatnetworks.co.uk.
ubuntu.com.             10800   IN      NS      ns1.blackcatnetworks.co.uk.
ubuntu.com.             3600    IN      MX      10 fiordland.ubuntu.com.
aboa.ubuntu.com.        1800    IN      A       82.211.81.195
access.ubuntu.com.      600     IN      A       82.211.81.212
adelie.ubuntu.com.      1800    IN      A       82.211.81.139
arch.ubuntu.com.        600     IN      A       82.211.81.161
archive.ubuntu.com.     600     IN      A       91.189.88.31
archive.ubuntu.com.     600     IN      A       91.189.89.6
archive.ubuntu.com.     600     IN      A       91.189.89.8
*.archive.ubuntu.com.   600     IN      A       91.189.88.31
*.archive.ubuntu.com.   600     IN      A       91.189.89.6
*.archive.ubuntu.com.   600     IN      A       91.189.89.8
at.archive.ubuntu.com.  600     IN      CNAME   ubuntu.inode.at.
au.archive.ubuntu.com.  600     IN      CNAME   mirror.optus.net.
ba.archive.ubuntu.com.  600     IN      CNAME   archive.ubuntu.com.ba.
be.archive.ubuntu.com.  600     IN      CNAME   ubuntu.mirrors.skynet.be.
bg.archive.ubuntu.com.  600     IN      CNAME   ubuntu.ipacct.com.
bg2.archive.ubuntu.com. 600     IN      CNAME   ubuntu.linux-bg.org.
br.archive.ubuntu.com.  600     IN      CNAME   ubuntu.c3sl.ufpr.br.
bw.archive.ubuntu.com.  600     IN      CNAME   ubuntu-archive.mirror.ac.za.
ca.archive.ubuntu.com.  600     IN      CNAME   gulus.usherbrooke.ca.
ch.archive.ubuntu.com.  600     IN      CNAME   mirror.switch.ch.
cr.archive.ubuntu.com.  600     IN      CNAME   ftp.ucr.ac.cr.
cs.archive.ubuntu.com.  600     IN      CNAME   ubuntu.etf.bg.ac.yu.
cz.archive.ubuntu.com.  600     IN      CNAME   archive.ubuntu.cz.
de.archive.ubuntu.com.  600     IN      A       141.76.2.3
dk.archive.ubuntu.com.  600     IN      CNAME   mirror.uni-c.dk.
ee.archive.ubuntu.com.  600     IN      CNAME   ftp.estpak.ee.
es.archive.ubuntu.com.  600     IN      CNAME   ubuntu2.cica.es.
fi.archive.ubuntu.com.  600     IN      CNAME   mirrors.nic.funet.fi.
 ........................
arctowski.ubuntu.com.   1800    IN      A       82.211.81.158
argon.ubuntu.com.       600     IN      A       91.189.88.1
arsenic.ubuntu.com.     1800    IN      A       82.211.81.218
art.ubuntu.com.         600     IN      A       69.60.114.112
art-staging.ubuntu.com. 600     IN      A       69.60.114.112
asuka.ubuntu.com.       1800    IN      A       82.211.81.180
auckland.ubuntu.com.    1800    IN      A       82.211.81.138
authserver.ubuntu.com.  600     IN      A       82.211.81.133
balleny.ubuntu.com.     1800    IN      A       82.211.81.162
bazaar.ubuntu.com.      600     IN      A       82.211.81.161
belgrano.ubuntu.com.    1800    IN      A       82.211.81.171
beryllium.ubuntu.com.   1800    IN      A       91.189.88.34
bittorrent.ubuntu.com.  600     IN      A       82.211.81.143
boron.ubuntu.com.       1800    IN      A       82.211.81.196
bugs.ubuntu.com.        600     IN      A       82.211.81.212
bugzilla.ubuntu.com.    600     IN      A       82.211.81.133
bugzilla.ubuntu.com.    3600    IN      MX      10 fiordland.ubuntu.com.
buildd.ubuntu.com.      600     IN      A       82.211.81.132
buildd.ubuntu.com.      3600    IN      MX      10 fiordland.ubuntu.com.
byrd.ubuntu.com.        1800    IN      A       91.189.88.11
calcium.ubuntu.com.     1800    IN      A       82.211.81.208
carbon.ubuntu.com.      1800    IN      A       82.211.81.197
casey.ubuntu.com.       1800    IN      A       82.211.81.149
cdimage.ubuntu.com.     600     IN      A       91.189.88.34
cdimage.ubuntu.com.     600     IN      A       91.189.89.4
*.cdimage.ubuntu.com.   600     IN      A       91.189.88.34
*.cdimage.ubuntu.com.   600     IN      A       91.189.89.4
cdimages.ubuntu.com.    600     IN      CNAME   cdimage.ubuntu.com.
*.cdimages.ubuntu.com.  600     IN      A       91.189.88.34
*.cdimages.ubuntu.com.  600     IN      A       91.189.89.4
changelogs.ubuntu.com.  600     IN      A       82.211.81.132
chinstrap.ubuntu.com.   1800    IN      A       82.211.81.135
chlorine.ubuntu.com.    1800    IN      A       82.211.81.204
chromium.ubuntu.com.    1800    IN      A       91.189.89.4
cobalt.ubuntu.com.      1800    IN      A       82.211.81.213
concordia.ubuntu.com.   1800    IN      A       82.211.81.168
davis.ubuntu.com.       1800    IN      A       82.211.81.169
debpatches.ubuntu.com.  600     IN      A       82.211.81.149
doc.ubuntu.com.         600     IN      A       69.60.114.108
docteam.ubuntu.com.     600     IN      A       82.211.81.159
dogfood.ubuntu.com.     600     IN      A       82.211.81.131
*.dogfood.ubuntu.com.   600     IN      A       82.211.81.131
archive.dogfood.ubuntu.com. 600 IN      A       82.211.81.131
librarian.dogfood.ubuntu.com. 600 IN    A       82.211.81.131
shipit.dogfood.ubuntu.com. 600  IN      A       82.211.81.131
*.shipit.dogfood.ubuntu.com. 600 IN     A       82.211.81.131
drescher.ubuntu.com.    1800    IN      A       82.211.81.167
druzhnaya.ubuntu.com.   1800    IN      A       82.211.81.174
durville.ubuntu.com.    1800    IN      A       82.211.81.152
emperor.ubuntu.com.     1800    IN      A       91.189.89.3
escudero.ubuntu.com.    1800    IN      A       82.211.81.161
esperanza.ubuntu.com.   1800    IN      A       82.211.81.173
faure.ubuntu.com.       1800    IN      A       82.211.81.187
fiordland.ubuntu.com.   1800    IN      A       82.211.81.145
forster.ubuntu.com.     1800    IN      A       91.189.89.6
forum.ubuntu.com.       600     IN      A       82.211.81.133
forums.ubuntu.com.      600     IN      A       82.211.81.133
frei.ubuntu.com.        1800    IN      A       91.189.89.5
fridge.ubuntu.com.      600     IN      A       82.211.81.183
ftp.ubuntu.com.         600     IN      A       91.189.88.31
ftp.ubuntu.com.         600     IN      A       91.189.89.6
ftp.ubuntu.com.         600     IN      A       91.189.89.8
.................
ubuntu.com.             3600    IN      SOA     ns.ubuntu.com. hostmaster.canonical.com. 2007041303 10800 3600 604800 3600
;; Query time: 314 msec
;; SERVER: 82.211.81.173#53(82.211.81.173)
;; WHEN: Tue Apr 17 15:10:28 2007
;;  XFR size: 293 records (messages 1)

Small Text

No s'executa el ldap2bind amb el cron

Per defecte a l'arxiu /etc/cron.d/ldap2zone l'usuari que executa la comanda es bind, es incorrecte, ho te que fer el root.

Podeu veure l'error executant:

$ sudo -u bind /usr/sbin/ldap2bind
mv: voleu sobreescriure «/etc/bind/db.10.168.192.in-addr.arpa.», reemplaçant el mode 0644 (rw-r--r--)? 

Size limit exceeded (4) al executar Ldap2bind

Cal modificar el màxim per defecte de 500 objectes per cerca. Consulteu Ldap#Les_consultes_tornen_un_m.C3.A0xim_de_500_registres

Vegeu també

Enllaços externs

RFCs