Diferencia entre revisiones de «DNS»
Línea 3: | Línea 3: | ||
[http://ca.wikipedia.org/wiki/Domain_Name_System DNS] és un conjunt de protocols i serveis, la funció principal dels quals és l'assignació de [http://ca.wikipedia.org/wiki/Domini_d%27Internet dominis d'Internet] a adreces IP numèriques. El fet d'assignar un nom a una adreça IP 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). | [http://ca.wikipedia.org/wiki/Domain_Name_System DNS] és un conjunt de protocols i serveis, la funció principal dels quals és l'assignació de [http://ca.wikipedia.org/wiki/Domini_d%27Internet dominis d'Internet] a adreces IP numèriques. El fet d'assignar un nom a una adreça IP 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: | 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. | :*'''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 | :*'''Jeràrquics''': Es poden definir dominis, zones i subdominis de forma que els noms de màquina puguen ser reutilitzats. Per exemple, el nom de màquina www, es pot tornar a utilitzar en diferents dominis. Exemples: www.google.com, www.domini.com... | ||
També podem parlar de sistemes: | També podem parlar de sistemes: | ||
:*'''Centralitzats''': un sol servidor de DNS (o servidor que comparteix el fitxer | :*'''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. | :*'''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''' | |||
Es tracta de un fitxer de cada màquina on guardem la IP de noms coneguts. Ha quedat pràcticament en desús, però encara es pot utilitzar en xarxes menudes sense DNS. | Es tracta de un fitxer de cada màquina on guardem la IP de noms coneguts. Ha quedat pràcticament en desús, però encara es pot utilitzar en xarxes menudes sense DNS. | ||
:*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. | :*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. |
Revisión del 23:17 14 nov 2017
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 a una adreça IP 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 puguen ser reutilitzats. Per exemple, el nom de màquina www, es pot tornar a utilitzar en diferents dominis. Exemples: 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
Es tracta de un fitxer de cada màquina on guardem la IP de noms coneguts. Ha quedat pràcticament en desús, però encara es pot utilitzar en xarxes menudes sense DNS.
- 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
- nameserver: Servidor de noms DNS, aka NS o Name Server.
- resolver: client DNS. Hi ha diverses implementacions i solen estar integrades al sistema operatiu
- Domini: Vegeu #Com funcionen els noms de domini.
- TLD o Top Level Domains: Son dominis de primer ordre com .com, .org... Consulteu Top Level Domains
- 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 que 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
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
Forward s'utilitzar per forwarding de zones. Vegeu Forwarding de zones
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
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).
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.
Que és considera una còpia completa d'una zona? La zona que té:
- Un registre SOA (Start of Authority) vàlid
- Registres NS vàlids per al domini. La llista de registres NS ha de concordar amb el registre SOA (vegeu lame servers)
É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.
É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
Observeu que de les dos respostes cap és autoritzada. Es veu al camp AUTHORITY: 0
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:
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
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).
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
- 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.
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:
http://www.tcpipguide.com/free/diagrams/dnsgenformat.png
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.
La següent imatge es mostra la capçalera:
http://www.tcpipguide.com/free/t_DNSMessageHeaderandQuestionSectionFormat.htm
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.
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; }; };
zone "informatica.iesebre.com" { type slave; masters { 192.168.0.40; }; file "slave/informatica.iesebre.com.hosts"; };
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
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
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; };
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:
$ sudorndc 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
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.
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.
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).
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 ...
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.
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
Les normes són:
- Caràcters alfanumèrics
- Guions
Fitxer /etc/bind/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
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.
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:
- Com a servidor public o extern d'una configuració Stealth (aka DMZ o Hidden Master) per tal de proveir seguretat perimetral.
- High Performance DNS servers
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
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.
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
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:
- DNSSEC Lookaside Validation (DLV): El servidor de DNS bind té una opció anomenada dnssec-lookaside. Aquesta opció permet activar DLV utilitzant el repositori dlv.isc.org i proporciona una built-in trusted key per a fer-ho. La clau és troba al fitxer /etc/bind/bind.keys:
$ 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.
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”; };
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.
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
$ 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
$ 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
$ 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
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:
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
Exemple. Activar Logging per a la depuració
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
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 ...
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
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.
$ 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
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
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;
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.
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.
- Tema relacionat: IPCOP.No_funcionen_les_peticions_DNS_amb_dnsmasq
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
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
- Click Start, click Run, type regedit, and then click OK.
- Locate and then click the following key in the registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters
- On the Edit menu, point to New, and then click REG_DWORD.
- Type ServerPriorityTimeLimit, and then press ENTER.
- On the Edit menu, click Modify.
- 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
- La base y gran majoría del contingut d'aquest article està tret de [5]
- http://books.google.es/books?id=GZ2UzZ0PEr0C&pg=PA128&lpg=PA128&dq=bind+reverse+0.168.192.in-addr.arpa&source=bl&ots=XeT7UbCMt7&sig=R5qzE_e8FULC4NX_sT-aOy_TZXQ&hl=ca&ei=sZhgS4S8E5yMmwP8h6zHDA&sa=X&oi=book_result&ct=result&resnum=1&ved=0CAcQ6AEwAA#v=onepage&q=bind%20reverse%200.168.192.in-addr.arpa&f=false
- Bind HOW-TO
- http://www.section6.net/wiki/index.php/Using_DNS_with_BIND
- http://www.madboa.com/geek/soho-bind/
- http://www.bind9.net/
- http://www.circleid.com/posts/cricket_liu_dns_and_bind_5th_edition/
- http://www.isc.org/index.pl?/sw/bind/arm93
- Definició de DNS a la wikipedia.
- Domini d'Internet a la wikipedia
- DNS HOW-TO Linux.Documentació tècnica de com configurar BIND en linux.
- (DNS Resources Directory). Recursos para administrar DNS
- Bind oficial site.
- WhoIS. Proporciona dades sobre qui posseïx un determinat domini.
- ICANN
- URDP
- Internic.net, informació pública sobre els dominis d'Internet.
- LLista de dominis d'Internet
- http://www.arda.homeunix.net/dnssetup.html#dnseuropa
- DNS/BIND a la espiral