1: .TH DNSMASQ 8
2: .SH NOMBRE
3: dnsmasq \- Un ligero servidor DHCP y DNS con caché.
4: .SH SINOPSIS
5: .B dnsmasq
6: .I [OPCION]...
7: .SH "DESCRIPCIÓN"
8: .BR dnsmasq
9: es un ligero servidor DNS, TFTP y DHCP. Su propósito es proveer servicios DNS
10: y DHCP a una red de área local.
11: .PP
12: Dnsmasq acepta búsquedas DNS y las responde desde un pequeño
13: caché local, o las reenvía hacia un servidor DNS real recursivo.
14: Carga el contenido de /etc/hosts, de tal forma que nombres de
15: hosts locales los cuales no aparecen en el DNS mundial puedan ser
16: resueltos. También responde a búsquedas DNS para hosts configurados
17: vía DHCP.
18: .PP
19: El servidor DHCP dnsmasq incluye soporte para asignación de direcciones
20: estáticas y redes múltiples. Automáticamente envía un predeterminado sensible de
21: opciones DHCP, y puede ser configurado para enviar cualquier opciones DHCP deseadas,
22: incluyendo opciones encapsuladas por vendedores. Incluye un servidor seguro
23: TFTP solo-lectura para permitir el inicio vía red/PXE de hosts DHCP. Tambíen
24: incluye soporte para BOOTP.
25: .PP
26: Dnsmasq
27: incluye soporte IPv6 para DNS, pero no para DHCP.
28: .SH OPCIONES
29: Nótese que en general parámetros ausentes son permitidos y deshabilitan
30: funciones, por ejemplo "--pid-file=" deshabilita la escritura de un
31: archivo PID. En BSD, a menos que la librería GNU getopt esté enlazada,
32: la forma larga de las opciones no funciona en la línea de comandos,
33: pero todavía es reconocida en el archivo de configuración.
34: .TP
35: .B --test
36: Leer archivo(s) de configuración y revisar su sintaxis. Salir con código
37: 0 si todo está bien, o un código no-cero en cualquier otro caso. No
38: iniciar dnsmasq.
39: .TP
40: .B \-h, --no-hosts
41: No leer los nombres de hosts en /etc/hosts.
42: .TP
43: .B \-H, --addn-hosts=<archivo>
44: Archivo de hosts adicional. Leer el archivo especificado adicionalmente
45: a /etc/hosts. Si se brinda -h, leer solo el archivo especificado. Esta
46: opción puede ser repetida para más de un archivo de hosts adicional. Si
47: un directorio es brindado, entonces leer todos los archivos contenidos en
48: ese directorio.
49: .TP
50: .B \-E, --expand-hosts
51: Agregar el dominio a nombres sencillos (sin punto) en /etc/hosts de la
52: misma manera que con nombres derivados de DHCP. Nótese que esto no
53: aplica a nombres de dominio en cnames, expedientes PTR, TXT, etc.
54: .TP
55: .B \-T, --local-ttl=<tiempo>
56: Al responder con información desde /etc/hosts o desde el archivo
57: de arriendos DHCP, dnsmasq fija el tiempo de vida (TTL) a cero por
58: predeterminado, significando que el remitente no debrá cachear
59: la información por sí mismo. Esto es lo correcto a hacer en casi
60: todas las situaciones. Esta opción permite que se especifique
61: cierto tiempo de vida (en segundos) para estas respuestas. Esto
62: reduce la carga sobre el servidor al costo de que los clientes
63: usaran datos añejos bajo algunas circunstancias.
64: .TP
65: .B --neg-ttl=<tiempo>
66: Respuestas negativas desde servidores upstream normalmente contienen
67: información time-to-live (tiempo de vida) en expedientes SOA que
68: dnsmasq usa para hacer caché. Si las respuestas de servidores upstream
69: omiten esta información, dnsmasq no mete la respuesta en el caché.
70: Esta opción brinda un valor predeterminado para el time-to-live que
71: dnsmasq usa para meter respuestas negativas en el caché aún en la
72: ausencia de un expediente SOA.
73: .TP
74: .B --max-ttl=<tiempo>
75: Fijar un valor TTL (tiempo de vida) máximo que será entregado a
76: clientes. El TTL máximo especificado será otorgado a clientes en vez
77: del TTL verdadero si es menor. El valor TTL real es mantenido en el caché
78: para prevenir la inundación de los servidores DNS upstream.
79: .TP
80: .B \-k, --keep-in-foreground
81: No ir hacia el fondo al iniciar, pero aparte de eso ejecutar como
82: normal. La intención de esto es para cuando dnsmasq es ejecutado
83: bajo daemontools o launchd.
84: .TP
85: .B \-d, --no-daemon
86: Modo debug: no hacer un fork hacia el fondo, no crear un archivo PID,
87: no cambiar el ID del usuario, generar un cache dump completo al
88: recibir un SIGUSR1, bitacorear a stderr al igual que a syslog, no
89: forkear procesos nuevos para manejar búsquedas TCP.
90: .TP
91: .B \-q, --log-queries
92: Bitacorear los resultados de búsquedas DNS manejadas por dnsmasq.
93: Habilitar un dump de caché completo al recibir un SIGUSR1.
94: .TP
95: .B \-8, --log-facility=<facilidad>
96: Fijar la facilidad a la cual dnsmasq deberá enviar mensajes syslog,
97: esto es DAEMON por predeterminado, y LOCAL0 cuando el modo debug está
98: en operación. Si la facilidad brindada contiene por lo menos un carácter
99: "/", se trata como un nombre de archivo, y dnsmasq bitacoreará a dicho
100: archivo, en vez de syslog. Si la facilidad es '-' entonces dnsmasq
101: bitacorea a stderr. (Errores durante la lectura de la configuración
102: irán a syslog todavía, pero todo output desde un inicio exitoso, y todo
103: output mientras en ejecución, irá a este archivo exclusivamente.)
104: Al bitacorear a un archivo, dnsmasq cerrará y reabrirá el archivo al
105: recibir un SIGUSR2. Esto permite que el archivo de bitácora sea rotado
106: sin detener a dnsmasq.
107: .TP
108: .B --log-async[=<líneas>]
109: Habilitar bitacoréo asincrónico y opcionalmente fijar el límite de número
110: de líneas que serán enviadas a la coleta por dnsmasq cuando syslog está
111: lento. Dnsmasq puede bitacorear asincrónicamente: esto le permite continuar
112: funcionando sin ser bloqueado por syslog, y permite a syslog usar dnsmasq
113: para búsquedas DNS sin riesgo de tranque. Si la coleta de líneas de bitácora
114: se llena, dnsmasq bitacoreará el desbordamiento, y el número de mensajes
115: perdidos. El tamaño predeterminado de coleta es 5, un valor sano sería 5-25,
116: y un límite de 100 es impuesto.
117: .TP
118: .B \-x, --pid-file=<path>
119: Especificar un path alterno donde dnsmasq debe guardar su PID.
120: Normalmente es /var/run/dnsmasq.pid.
121: .TP
122: .B \-u, --user=<usuario>
123: Especificar el userid al cual dnsmasq debe cambiarse despues de iniciar.
124: Dnsmasq normalmente debe ser iniciado como root, pero soltará los
125: privilegios root despues del inicio, cambiando a otro usuario.
126: Normalmente este usuario es "nobody", pero eso se puede cambiar
127: con esta opción.
128: .TP
129: .B \-g, --group=<grupo>
130: Especificar el grupo como el cual dnsmasq correrá. El predeterminado
131: es "dip", si está disponible, para facilitar el acceso a
132: /etc/ppp/resolv.conf el cuál normálmente no es globalmente leíble.
133: .TP
134: .B \-v, --version
135: Mostrar el número de versión.
136: .TP
137: .B \-p, --port=<puerto>
138: Escuchar en el puerto <puerto> en vez del puerto estándar DNS (53).
139: Fijar esto a cero deshabilita completamente la función DNS, dejando
140: solo DHCP y/o TFTP.
141: .TP
142: .B \-P, --edns-packet-max=<tamaño>
143: Especificar el paquete UDP EDNS.0 más grande que es soportado por
144: el reenviador DNS. Por predeterminado es 4096, lo cual es el
145: tamaño recomendado en RFC5625.
146: .TP
147: .B \-Q, --query-port=<puerto>
148: Enviar búsquedas outbound desde, y escuchar por respuestas en,
149: el puerto UDP <puerto> en vez de usar puertos aleatorios. Nótese
150: que usar esta opción hace que dnsmasq sea menos seguro contra
151: ataques de spoofing DNS, pero puede ser más rápido y usar menos
152: recursos.
153: Fijar esta opción a zero hace que dnsmasq use un solo puerto,
154: asignado por el sistema operativo (esto era el comportamiento
155: predeterminado en versiones anteriores a 2.43).
156: .TP
157: .B --min-port=<puerto>
158: No usar puertos menores a <puerto> como remitentes para búsquedas
159: DNS outbound. Dnsmasq escoje puertos aleatorios como remitentes
160: para búsquedas DNS outbound. Cuando esta opción es brindada, los
161: puertos usados siempre serán mayores que el especificado. Esto es
162: útil para sistemas detras de firewalls.
163: .TP
164: .B \-i, --interface=<nombre de interface>
165: Escuchar solo en las interfaces especificadas. Dnsmasq automáticamente
166: agrega la interface loopback a la lista de interfaces para usar cuando
167: la opción
168: .B \--interface
169: es usada. Si ninguna opción
170: .B \--interface
171: o
172: .B \--listen-address
173: es brindada, dnsmasq escucha en todas las interfaces disponibles excepto
174: cualquiera fijada con opciones
175: .B \--except-interface
176: Interfaces IP alias (por ejemplo, "eth1:0") no pueden ser utilizadas con
177: .B --interface
178: o
179: .B --except-interface
180: , usar --listen-address en vez.
181: .TP
182: .B \-I, --except-interface=<nombre de interface>
183: No escuchar en la interface especificada. Nótese que el orden de
184: las opciones
185: .B \--listen-address
186: .B --interface
187: y
188: .B --except-interface
189: no importa y las opciones
190: .B --except-interface
191: siempre invalidan a las otras.
192: .TP
193: .B \-2, --no-dhcp-interface=<nombre de interface>
194: No proveer DHCP ni TFTP en la interface especificada, pero sí
195: proveer servicio DNS.
196: .TP
197: .B \-a, --listen-address=<dirección IP>
198: Escuchar en la(s) dirección(es) IP especificada(s). Las opciones
199: .B \--interface
200: y
201: .B \--listen-address
202: ambas pueden ser brindadas, y en tal caso el juego de ambas
203: direcciones IP y interfaces es usada. Nótese que si ninguna opción
204: .B \--interface
205: es brindada, pero sí se brinda la opción
206: .B \--listen-address
207: , entonces dnsmasq no escuchará automáticamente en la interface
208: loopback. Para obtener esto, su dirección IP, 127.0.0.1, debe ser
209: explícitamente brindada como una opción
210: .B \--listen-address
211: .TP
212: .B \-z, --bind-interfaces
213: En sistemas que inluyen el soporte, dnsmasq acopla la dirección
214: de comodín, aún cuando está escuchando solamente en algunas
215: interfaces. Entonces descarta búsquedas a las cuales no debe
216: responder. Esto tiene la ventaja de funcionar aún cuando
217: interfaces van y vienen y cambian direcciones. Esta opción forza
218: a dnsmasq a acoplarse realmente solo a las interfaces en
219: las cuales está escuchando. Casi la única vez que esto es útil
220: es cuando se está corriendo otro servidor DNS (o otra instancia
221: de dnsmasq) en la misma máquina. Fijar esta opción tambien
222: habilita multiples instancias de dnsmasq, las cuales proveen
223: servicio DHCP en la misma máquina.
224: .TP
225: .B \-y, --localise-queries
226: Retornar respuestas a búsquedas DNS desde /etc/hosts las cuales dependen
227: de la interface donde entró la búsqueda. Si un nombre en /etc/hosts tiene
228: mas de una dirección asociada con el, y por lo menos una de esas direcciones
229: está en la misma subred de la interface donde fue enviada, entónces
230: retornar solo las direcciones en esa subred. Esto permite a un servidor
231: tener direcciones múltiples en /etc/hosts correspondientes a cada una de
232: sus interfaces y cada host recibirá la respuesta adecuada
233: dependiendo de cual red tengan adjunta. Por el momento, esta facilidad
234: está limitada a IPv4.
235: .TP
236: .B \-b, --bogus-priv
237: Búsquedas privadas reversas raras. Toda búsqueda reversa para rangos de IP
238: privados (192.168.x.x, etc.) los cuales no se encuentren en
239: /etc/hosts o en el archivo de arriendos DHCP es respondida con
240: "dominio no existente" en vez de ser reenviada upstream.
241: .TP
242: .B \-V, --alias=[<IP viejo>]|[<IP inicio>-<IP final>],<IP nuevo>[,<máscara>]
243: Modificar direcciones IPv4 retornadas desde servidores DNS upstream;
244: <IP viejo> es remplazado con <IP nuevo>. Si la máscara opcional
245: es brindada, entonces cualquier dirección que coincida con el
246: <IP viejo> enmascarado será re-escrita. Así que, por ejemplo,
247: .B --alias=1.2.3.0,6.7.8.0,255.255.255.0 trazará 1.2.3.56 a 6.7.8.56
248: y 1.2.3.67 a 6.7.8.67. Esto es lo que
249: ruteadores Cisco PIX llaman "DNS doctoring". Si la dirección vieja es
250: brindada como un rango, entonces solo direcciones en ese rango, y no
251: la subred entera, son re-escritas. De tal manera que
252: .B --alias=192.168.0.10-192.168.0.40,10.0.0.0,255.255.255.0
253: relaciona 192.168.0.10->192.168.0.40 a 10.0.0.10->10.0.0.40
254: .TP
255: .B \-B, --bogus-nxdomain=<dirección IP>
256: Transformar respuestas que contienen la dirección IP brindada a
257: respuestas tipo "Dominio no existe". La intención de esto es actuar
258: en contra de una movida desviada hecha por Verisign en septiembre
259: del 2003, cuando comenzaron a retornar la dirección de un servidor
260: de publicidad en respuesta a búsquedas por nombres no registrados,
261: en vez de la correcta respuesta NXDOMAIN. Esta opción le dice a dnsmasq
262: que debe forjear la respuesta correcta cuando ve este comportamiento.
263: Para septiembre 2003 la dirección IP siendo retornada por Verisign
264: es 64.94.110.11
265: .TP
266: .B \-f, --filterwin2k
267: Algunas versiones de Windows hacen búsquedas DNS periódicas las cuales no
268: reciben respuestas sensibles desde el DNS público y pueden causar problemas
269: activando enlaces marcación-en-demanda. Esta opción filtra dichas búsquedas.
270: Las búsquedas filtradas son para registros tipo SOA y SRV, al igual que
271: tipo ANY donde el nombre pedido contiene _, para atrapar búsquedas LDAP.
272: .TP
273: .B \-r, --resolv-file=<archivo>
274: Leer las direcciones IP de servidores DNS upstream desde <archivo>,
275: en vez de /etc/resolv.conf. Para el formato de este archivo, ver
276: .BR resolv.conf (5)
277: Las únicas líneas relevantes a dnsmasq son las de servidores DNS. A
278: dnsmasq se le puede decir que revise más de un archivo resolv.conf,
279: el primer archivo especificado remplaza al predeterminado, y los
280: subsiguientes son agregados a la lista. Esto es solo
281: permitido al hacer polling; el archivo con la actual fecha
282: de modificación más nueva es el que será usado.
283: .TP
284: .B \-R, --no-resolv
285: No leer /etc/resolv.conf. Obtener los servidores DNS upstream solo
286: desde la línea de comandos o desde el archivo de configuración de
287: dnsmasq.
288: .TP
289: .B \-1, --enable-dbus
290: Permitir que la configuración de dnsmasq sea actualizada vía llamadas
291: de método DBus. La configuración que puede ser cambiada es servidores
292: DNS upstream (y dominios correspondientes) y limpieza de caché. Esta
293: opción requiere que dnsmasq haya sido compilado con soporte para DBus.
294: .TP
295: .B \-o, --strict-order
296: Por predeterminado, dnsmasq enviará búsquedas a cualquiera de los
297: servidores upstream que conoce, y trata de favorecer servidores los
298: cuales sabe que están activos. Fijar esta opción forza a dnsmasq a
299: probar cada búsqueda con cada servidor estrictamente en el orden
300: que aparecen en /etc/resolv.conf
301: .TP
302: .B --all-servers
303: Por predeterminado, cuando dnsmasq tiene más de un servidor upstream
304: disponible, enviará búsquedas a solo un servidor. Fijar esta opción
305: forza a dnsmasq a enviar todas las búsquedas a todos los servidores
306: disponibles. La respuesta del servidor que responda primero será
307: devuelta al solicitante original.
308: .TP
309: .B --stop-dns-rebind
310: Denegar (y bitacorear) direcciones de servidores upstream que están
311: dentro de rangos IP privados. Esto bloquea un ataque donde un navegador
312: detrás de un firewall es usado para analizar máquinas en la red local.
313: .TP
314: .B --rebind-localhost-ok
315: Eximir a 127.0.0.0/8 de verificaciones de rebinding. Este rango de
316: direcciones es retornado por servidores de tiempo real tipo hoyo
317: negro, así que bloquearlo puede deshabilitar estos servicios.
318: .TP
319: .B --rebind-domain-ok=[<domain>]|[[/<domain>/[<domain>/]
320: No detectar y bloquear dns-rebind en búsquedas a estos dominios. El
321: argumento puede ser o un dominio sencillo, o múltiples dominios
322: rodeados por '/', como el syntax de --server, por ejemplo
323: .B --rebind-domain-ok=/dominio1/dominio2/dominio3/
324: .TP
325: .B \-n, --no-poll
326: No revisar periodicamente a /etc/resolv.conf en busca de cambios.
327: .TP
328: .B --clear-on-reload
329: Cuando sea que /etc/resolv.conf es re-leida, liberar el caché DNS.
330: Esto es útil cuando servidores DNS nuevos puedan tener datos diferentes
331: a los contenidos en el caché.
332: .TP
333: .B \-D, --domain-needed
334: Le dice a dnsmasq que no debe reenviar búsquedas para nombres sencillos,
335: sin puntos o partes de dominios, a servidores upstream. Si el nombre
336: no se conoce desde /etc/hosts o desde DHCP entonces una respuesta
337: "no encontrado" es devuelta.
338: .TP
339: .B \-S, --local, --server=[/[<dominio>]/[dominio/]][<dirección IP>[#<puerto>][@<IP de remitente>|<interface>[#<puerto>]]
340: Especificar la dirección IP de servidores upstream directamente. Fijar
341: esta opción no suprime la lectura de /etc/resolv.conf, use -R para
342: hacer eso. Si uno a más dominios opcionales son brindados, ese servidor
343: es usado solo para esos dominios y las búsquedas son hechas usando
344: el servidor especificado solamente. La intención de esto es para el
345: uso con servidores DNS privados: si usted tiene un servidor DNS en su
346: red el cual lidea con nombres de la forma
347: xxx.internal.thekelleys.org.uk en 192.168.1.1 entonces brindar la
348: opción
349: .B -S /internal.thekelleys.org.uk/192.168.1.1
350: enviará todas las búsquedas de máquinas internas a ese servidor DNS,
351: todas las demás búsquedas serán enviadas a los servidores en
352: /etc/resolv.conf. Una especificación de dominio en blanco,
353: .B //
354: tiene el significado especial de "solo nombres no calificados", o
355: sea nombres sin ningún punto en ellos. Un puerto no-estándar puede
356: ser especificado como parte de la dirección IP usando el caracter
357: #. Más de una opción -S es permitida, con partes de dominio o
358: dirección IP repetidas como sea necesario.
359:
360: Dominios más específicos toman precedencia sobre los menos específicos,
361: así que:
362: .B --server=/google.com/1.2.3.4
363: .B --server=/www.google.com/2.3.4.5
364: enviará búsquedas por *.google.com hacia 1.2.3.4, excepto
365: *www.google.com, el cual irá a 2.3.4.5.
366:
367: La dirección especial de servidor '#' significa "usar los servidores
368: estándares", así que
369: .B --server=/google.com/1.2.3.4
370: .B --server=/www.google.com/#
371: enviará búsquedas por *.google.com hacia 1.2.3.4, excepto
372: *www.google.com, el cual será reenviado de manera usual.
373:
374: También se permite una opción -S la cual brinda un dominio pero
375: ninguna dirección IP; esto le dice a dnsmasq que un dominio es local
376: y puede responder a búsquedas desde /etc/hosts o DHCP pero nunca
377: deberá reenviar búsquedas en ese dominio a ningún servidor upstream.
378: .B local
379: es un sinónimo de
380: .B server
381: para hacer los archivos de configuración mas claros en este caso.
382:
383: El string opcional despues del carácter @ le dice a dnsmasq como fijar
384: el remitente de las búsquedas hacia este servidor DNS. Debe ser una
385: dirección IP, la cual debe ser perteneciente a la máquina en la cual
386: corre dnsmasq, de forma contraria esta línea de servidor será bitacoreada
387: y después ignorada, o un nombre de interface. Si un nombre de interface
388: es brindado, entonces búsquedas hacia el servidor serán forzadas vía esa
389: interface; si una dirección IP es brindada, entonces la dirección de
390: remitente de las búsquedas será fijada a esa dirección.
391: La etiqueta query-port es ignorada para cualquier servidores que tengan
392: una dirección remitente especificada, pero el puerto puede ser
393: especificado directamente como parte de la dirección remitente. Forzar
394: búsquedas a una interface no está implementado en todas las plataformas
395: soportadas por dnsmasq.
396: .TP
397: .B \-A, --address=/<dominio>/[dominio/]<dirección IP>
398: Especificar una dirección IP para retornar por cualquier host en
399: los dominios brindados. Búsquedas en estos dominios nunca son
400: reenviadas, y siempre son respondidas con la dirección IP
401: especificada, la cual puede ser IPv4 o IPv6. Para brindar ambas
402: direcciones IPv4 y IPv6 para un dominio, usar opciones -A repetidas.
403: Nótese que /etc/hosts y arriendos DHCP invalidan esto para nombres
404: individuales. Un uso común para esto es redireccionar el dominio
405: doubleclick.net entero a algún servidor web local amigable para
406: evitar banners de publicidad. La especificación funciona de la misma
407: forma que con --server, con la facilidad adicional que /#/ coincide
408: con cualquier dominio. De tal forma, --address=/#/1.2.3.4 siempre
409: retornará 1.2.3.4 para cualquier búsqueda no respondida desde
410: /etc/hosts o DHCP y que no haya sido enviada a un servidor DNS
411: upstream por una directiva --server mas especifica.
412: .TP
413: .B \-m, --mx-host=<nombre mx>[[,<nombre de host>],<preferencia>]
414: Retornar un record llamado <mx name> apuntando hacia el nombre de
415: host brindado (opcionalmente), o el host especificado en la opción
416: --mx-target, o si esa opción no es brindada, el host en el cual
417: dnsmasq está corriendo. El predeterminado es útil para redireccionar
418: correo de sistemas en la red local hacia un servidor central. La
419: opción de preferencia es opcional, y su predeterminado es 1 si no
420: es brindada. Más de un record MX puede ser brindado para un host.
421: .TP
422: .B \-t, --mx-target=<nombre de host>
423: Especificar el target predeterminado para el record MX devuelto
424: por dnsmasq. Ver --mx-host. Si --mx-target es brindado, pero no
425: --mx-host, entonces dnsmasq devuelve un record MX conteniendo
426: el target MX para búsquedas MX en el nombre de host de la máquina donde
427: dnsmasq está corriendo.
428: .TP
429: .B \-e, --selfmx
430: Retornar un record MX apuntándose a sí mismo para cada máquina local.
431: Máquinas locales son aquellas en /etc/hosts o con arriendos DHCP.
432: .TP
433: .B \-L, --localmx
434: Retornar un record MX apuntando al host brindado por mx-target (o
435: la máquina donde dnsmasq está corriendo) para cada máquina local.
436: Máquinas locales son aquellas en /etc/hosts o con arriendos DHCP.
437: .TP
438: .B \-W, --srv-host=<_servicio>.<_prot>.[<dominio>],[<target>[,<puerto>[,<prioridad>[,<peso>]]]]
439: Retornar un record DNS SRV. Ver RFC2782 para detalles. Si no es
440: brindada, el dominio se predetermina a el brindado por
441: .B --domain.
442: El predeterminado para el dominio target está vacío, el predeterminado
443: para puerto es uno, y los predeterminados para peso y prioridad son cero.
444: Tener cuidado al transponer data desde archivos de zona BIND: los
445: números de puerto, peso, y prioridad están en un orden diferente. Más
446: de un record SRV para un servicio/dominio es permitido, todos los que
447: coincidan son retornados.
448: .TP
449: .B \-Y, --txt-record=<nombre>[[,<texto>],<texto>]
450: Retornar un récord DNS TXT. El valor del récord TXT es una serie de
451: strings, así que cualquier número puede ser incluido, dividido por
452: comas.
453: .TP
454: .B --ptr-record=<nombre>[,<target>]
455: Retornar un récord DNS PTR.
456: .TP
457: .B --naptr-record=<nombre>,<orden>,<preferencia>,<opciones>,<servicio>,<regexp>[,<remplazo>]
458: Retornar un récord DNS NAPTR, como especificado en RFC3403.
459: .TP
460: .B --cname=<cname>,<target>
461: Retornar un expediente CNAME que indica que <cname> es realmente <target>. Hay
462: limitaciones significativas en el target. Debe ser un nombre DNS que le es conocido
463: a dnsmasq desde /etc/hosts (o archivos hosts adicionales) o de DHCP. Si el target
464: no satisface este criterio, el cname entero es ignorado. El cname debe ser único,
465: pero es permisible tener más de un cname indicando el mismo target.
466: .TP
467: .B --interface-name=<nombre>,<interface>
468: Retornar un expediente DNS, asociando el nombre con la dirección primaria
469: en la interface brindada. Esta opción especifica un expediente tipo A
470: para el nombre brindado de la misma forma que una línea de /etc/hosts,
471: excepto que la dirección no es constante y es en vez tomada de la
472: interface brindada. Si la interface está deshabilitada, nó configurada,
473: o nó existente, un récord vacío es devuelto. El récord PTR relevante
474: tambien es creado, trazando la dirección de la interface a el nombre.
475: Más de un nombre puede ser asociado con una dirección de interface,
476: repitiendo la opción. En tal caso, la primera instancia es usada para
477: la traza reversa dirección-a-nombre.
478: .TP
479: .B \-c, --cache-size=<tamaño de caché>
480: Fijar el tamaño del caché de dnsmasq. El predeterminado es 150 nombres.
481: Fijar el tamaño a cero deshabilita el caché.
482: .TP
483: .B \-N, --no-negcache
484: Deshabilitar caché negativo. El caché negativo le permite a dnsmasq
485: recordar resultados tipo "dominio no existe" desde servidores DNS
486: upstream y responder búsquedas idénticas sin reenviarlas nuevamente.
487: .TP
488: .B \-0, --dns-forward-max=<búsquedas>
489: Fijar el número máximo de búsquedas DNS simultáneas. El valor
490: predeterminado es 150, lo cuál debería estar bien para la mayoría
491: de casos. La única situación conocida donde esto debe ser incrementado
492: es al usar resolvedores de bitácoras de servidores web, los cuales pueden
493: generar un número inmenso de búsquedas simultáneas.
494: .TP
495: .B \-F, --dhcp-range=[interface:<interface>,][tag:<tag>[,tag:<tag>],][set:<tag],]<dirección-inicio>,<dirección-final>[,<netmask>[,<broadcast>]][,<tiempo de arriendo>]
496: Habilitar el servidor DHCP. Direcciones serán distribuidas desde el
497: rango <dirección-inicio> hasta <dirección-final> y desde direcciones definidas
498: estáticamente en opciones
499: .B dhcp-host
500: Si el tiempo de arriendo es especificado, entonces arriendos serán
501: otorgados por esa cantidad de tiempo. El tiempo de arriendo es en
502: segundos, o minutos (por ejemplo, 45m), u horas (por ejemplo, 1h), o
503: "infinite". Si no es brindada, el tiempo de arriendo predeterminado
504: es de una hora. El tiempo de arriendo mínimo es de dos minutos.
505: Esta opción puede ser repetida, con diferentes
506: direcciones, para habilitar servicio DHCP en más de una red. Para
507: redes conectadas diréctamente (en otras palabras, redes en las
508: cuales la máquina corriendo dnsmasq tiene una interface) la
509: máscara de subred es opcional. Pero, es requerida para redes que
510: reciben servicio DHCP vía un agente de relay. La dirección de
511: broadcast siempre es opcional. Siempre se permite tener más de
512: un rango dhcp (dhcp-range) en una subred.
513:
514: El parámetro opcional
515: .B set:<tag>
516: fija una etiqueta alfanumérica la cual marca esta red de
517: tal forma que opciones dhcp puedan ser especificadas en base a cada red.
518: Cuando es prefijada con 'tag:' en vez, entonces el significado cambia
519: de "fijar etiqueta" a "coincidir con etiqueta". Solo una etiqueta puede
520: ser fijada, pero más de una puede ser revisada por coincidencias. La
521: dirección final puede ser remplazada por la palabra clave
522: .B static
523: la cual le dice a dnsmasq que debe habilitar DHCP para la red
524: especificada, pero no alocar dinámicamente direcciones IP:
525: Solo hosts que tienen direcciones estáticas brindadas vía
526: .B dhcp-host
527: o desde /etc/ethers serán servidas. La dirección final puede ser
528: remplazada por la palabra clave
529: .B proxy
530: caso en el cual dnsmasq proveerá proxy-DHCP en la subred especificada. (Ver
531: .B pxe-prompt
532: y
533: .B pxe-service
534: para detalles.)
535:
536: La sección interface:<interface name> no es normalmente usada. Ver la
537: sección NOTAS para detalles sobre esto.
538: .TP
539: .B \-G, --dhcp-host=[<hwaddr>][,id:<client_id>|*][,set:<tag>][,<ipaddr>][,<hostname>][,<tiempo_de_arriendo>][,ignorar]
540: Especificar parámetros por host para el servidor DHCP. Esto permite
541: que una máquina con una dirección de hardware particular sea siempre
542: alocada el mismo nombre de host, dirección IP, y tiempo de arriendo.
543: Un nombre de host especificado de esta manera toma presedencia
544: sobre cualquiera suministrado por el cliente DHCP en la máquina.
545: También se permite omitir la direccion de hardware y incluir el
546: nombre de host; en tal caso la dirección IP y los tiempos de arriendo
547: serán aplicables a cualquier máquina que reclame ese nombre.
548: Por ejemplo:
549: .B --dhcp-host=00:20:e0:3b:13:af,wap,infinite
550: le dice a dnsmasq que debe darle a la máquina con dirección
551: ethernet 00:20:e0:3b:13:af el nombre wap, y un arriendo DHCP infinito.
552: .B --dhcp-host=lap,192.168.0.199
553: le dice a dnsmasq que siempre debe alocarle a la maquina lap
554: la dirección IP 192.168.0.199.
555:
556: Direcciones alocadas de esta manera no tienen que estar dentro
557: del rango dado con la opción --dhcp-range, pero deben estar en la subred
558: de un rango DHCP (dhcp-range) válido. Para subredes que no necesitan
559: una collección de direcciones dinamicamente alocadas, usar la palabra
560: clave "static" in la declaración dhcp-range.
561:
562: Es permitido usar identificadores de cliente en vez de direcciones de
563: hardware para identificar hosts prefijando 'id:'. O sea que:
564: .B --dhcp-host=id:01:02:03:04,.....
565: se refiere al host con identificador de cliente 01:02:03:04.
566: También se permite especificar el ID de cliente como texto, así:
567: .B --dhcp-host=id:iddeclientecomotexto,.....
568:
569: La opción especial id:* significa "ignorar cualquier ID de cliente
570: y usar solamente direcciones MAC." Esto es útil cuando un cliente
571: presenta un ID de cliente algunas veces pero otras no.
572:
573: Si un nombre aparece en /etc/hosts, la dirección asociada puede
574: ser alocada a un arriendo DHCP, pero solo si existe una opción
575: .B --dhcp-host
576: la cual especifica el nombre también. Solo un hostname puede ser
577: brindado en una opción
578: .B dhcp-host
579: pero aliases son posibles por medio del uso de CNAMEs. (Ver
580: .B --cname
581: ).
582:
583: La palabra clave "ignore"
584: le dice a dnsmasq que no debe ofrecer jamás un arriendo DHCP a
585: una máquina. La máquina puede ser especificada por dirección de
586: hardware, ID de cliente, o nombre de host, por ejemplo:
587: .B --dhcp-host=00:20:e0:3b:13:af,ignore
588: Esto es útil cuando hay otro servidor DHCP en la red que debe ser
589: usado por algúnas máquinas.
590:
591: El set:<tag> fija la etiqueta cuando sea que
592: esta directiva dhcp-host está en uso. Esto puede ser usado para
593: enviar selectivamente opciones DHCP a este host. Más de una etiqueta
594: puede ser fijada en una directiva dhcp-host (pero no en otros lugares
595: donde "set:<tag>" es permitido). Cuando un host coincide con
596: cualquier directiva dhcp-host (o una implicada por
597: /etc/ethers) entonces la etiqueta especial "known" es
598: fijada. Esto permite que dnsmasq sea configurado para ignorar
599: pedidos desde máquinas desconocidas usando
600: .B --dhcp-ignore=tag:!known
601: Direcciones ethernet (pero no client-ids) pueden tener bytes
602: comodínes, así que por ejemplo
603: .B --dhcp-host=00:20:e0:3b:13:*,ignore
604: causará que dnsmasq ignore un rango de direcciones ethernet. Nótese
605: que el "*" necesitará ser escapado o escrito entre comillas en la
606: línea de comandos, pero no en el archivo de configuración.
607:
608: Direcciones de hardware normalmente coinciden con cualquier
609: tipo de red (ARP), pero es posible restringirlas a un tipo ARP
610: singular precediendolo con el tipo ARP (en HEX) y "-". Así que
611: .B --dhcp-host=06-00:20:e0:3b:13:af,1.2.3.4
612: solo coincidiría con una dirección de hardware Token-Ring, dado que
613: el tipo ARP para Token-Ring es 6.
614:
615: Como caso especial, es posible incluir más de una dirección de
616: hardware. Ejemplo:
617: .B --dhcp-host=11:22:33:44:55:66,12:34:56:78:90:12,192.168.0.2
618: Esto permite que una dirección IP sea asociada con
619: direcciones de hardware múltiples, y le brinda a dnsmasq permiso
620: para abandonar un arriendo DHCP a una de las direcciones de hardware
621: cuando otra pide un arriendo. Nótese que esto es algo peligroso,
622: sólo funcionará dependiblemente si una de las direcciones de hardware
623: está activa en cualquier momento y dnsmasq no tiene forma de enforzar
624: esto. Pero es útil, por ejemplo, para alocar una dirección IP estable
625: a una laptop que tiene interface alámbrica e inalámbrica.
626: .TP
627: .B --dhcp-hostsfile=<archivo>
628: Leer información host DHCP desde el archivo especificado. El archivo contiene información de un host por línea. El formato de una línea es igual que texto hacia la derecha de '=' en --dhcp-host. La ventaja de almacenar información host DHCP en este archivo es que puede ser cambiada sin tener que reiniciar dnsmasq. El archivo será re-leído cuando dnsmasq recibe un SIGHUP.
629: .TP
630: .B --dhcp-optsfile=<archivo>
631: Leer información sobre opciones DHCP desde el archivo especificado. La
632: ventaja de usar esta opción es la misma que con --dhcp-hostsfile: el
633: archivo dhcp-optsfile será re-leído cuando dnsmasq recibe un SIGHUP.
634: Nótese que es posible colocar la información mediante
635: .B --dhcp-boot
636: como opciones DHCP, usando los nombres de opción bootfile-name,
637: server-ip-address, y tftp-server. Esto permite que sean incluidas en
638: un archivo dhcp-optsfile.
639: .TP
640: .B \-Z, --read-ethers
641: Leer /etc/ethers en busca de información sobre hosts para el servidor
642: DHCP. El formato de /etc/ethers es una dirección de hardware, seguida
643: por ya sea un nombre de host o una dirección IP. Al ser leidas por
644: dnsmasq, estas líneas tienen exáctamente el mismo efecto que opciones
645: .B --dhcp-host
646: que contienen la misma información. /etc/ethers es re-leída cuando
647: dnsmasq recibe un SIGHUP.
648: .TP
649: .B \-O, --dhcp-option=[tag:<tag>,[tag:<tag>,]][encap:<opt>,][vi-encap:<enterprise>,][vendor:[<vendor-class>],][<opt>|option:<opt-name>],[<value>[,<value>]]
650: Especificar opciones diferentes o extra a clientes DHCP. Por
651: predeterminado, dnsmasq envía algunas opciones estándar a clientes
652: DHCP. La máscara de subred y dirección broadcast son fijadas igual
653: a las del host que corre dnsmasq, y el servidor DNS y ruteador
654: a la dirección de la máquina que corre dnsmasq. Si la opción de
655: nombre de dominio ha sido fijada, es enviada. Esta opción permite
656: que esos predeterminados sean sobrescritos, o que sean especificadas
657: otras opciones. La opción a ser enviada puede ser brindada como un
658: número decimal o como "option:<option-name>". Los números de opción
659: están especificados en RFC2132 y RFCs subsiguientes. El juego de
660: option-names conocido por dnsmasq puede ser descubierto ejecutando
661: "dnsmasq --help dhcp". Por ejemplo, para fijar la ruta predeterminada a
662: 192.168.4.4, hágase un
663: .B --dhcp-option=3,192.168.4.4
664: o
665: .B --dhcp-option=option:router, 192.168.4.4
666: y para fijar la dirección de servidor de tiempo a 192.168.0.4,
667: hágase un
668: .B --dhcp-option=42,192.168.0.4
669: o
670: .B --dhcp-option=option:ntp-server, 192.168.0.4
671: La dirección especial 0.0.0.0 es entendida que significa "la
672: dirección de la máquina que corre dnsmasq". Tipos de data permitidos
673: son direcciones IP de cuatro segmentos, un número decimal, dígitos hex
674: separados por colones, y un string de texto. Si las etiquetas
675: opcionales son brindadas, entonces esta opción es solo enviada cuando
676: todas las etiquetas coinciden.
677:
678: Procesamiento especial es llevado a cabo en un argumento de texto para
679: la opción 119, en conforme con RFC3397. Direcciones IP textuales o de
680: cuatro segmentos como argumentos a la opción 120 son manejados mediante
681: RFC3361. Direcciones IP de cuatro segmentos que son seguidas por un diagonal
682: (slash) y después una máscara son codificados mediante RFC3442.
683:
684: Tener cuidado: niguna verificación es hecha sobre si el número de tipo
685: correcto es enviado, y es muy posible persuadir a dnsmasq para que
686: genere paquetes DHCP ilegales mediante uso inadecuado de esta opción.
687: Cuando el valor es un número decimal, dnsmasq debe determinar qué tan
688: grande es el objeto de data. Esto es hecho mediante una examinación del
689: número de opción, y/o el valor, pero puede ser invalidado agregándole
690: una opción de una sola letra de esta forma: b = un byte, s = dos bytes,
691: i = cuatro bytes. Esto es principalmente útil con opciones encapsuladas
692: tipo vendedor (ver abajo) donde dnsmasq no puede determinar el tamaño
693: de data usando el número de opción. Data de opción la cual consiste
694: solo de puntos y dígitos será interpretada por dnsmasq como una
695: dirección IP, y será insertada dentro de una opción de esa manera.
696: Para forzar un string literal, usar comillas. Por ejemplo, cuando se
697: usa la opción 66 para enviar una IP literal como un nombre de servidor
698: TFTP, es necesario hacer:
699: .B --dhcp-option=66,"1.2.3.4"
700:
701: Opciones encapsuladas vendor-class también pueden ser especificadas usando
702: --dhcp-option: por ejemplo
703: .B --dhcp-option=vendor:PXEClient,1,0.0.0.0
704: envía la opción específica de clase de vendedor "mftp-address=0.0.0.0" a
705: cualquier cliente cuyo vendor-class
706: coincida con "PXEClient". El revisado de coincidencias vendor-class está
707: basado en substrings (ver --dhcp-vendorclass para detalles). Si una opción
708: vendor-class (número 60) es enviada por dnsmasq, entonces es usada para
709: seleccionar opciones encapsuladas en preferencia sobre cualquiera enviada
710: por el cliente. Es posible omitir el vendorclass completamente;
711: .B --dhcp-option=vendor:,1,0.0.0.0
712: caso en el cuál la opción encapsulada siempre es enviada.
713: Opciones pueden ser encapsuladas dentro de otras opciones, por ejemplo:
714: .B --dhcp-option=encap:175, 190, "iscsi-client0"
715: enviará opción 175, dentro de la cual está opción 190. Si múltiples
716: opciones son brindadas que están encapsuladas con el mismo número de
717: opción entonces serán correctamente combinadas en una opción encapsulada.
718: encap: y vendor: no pueden ser fijadas ambas dentro de la misma opción dhcp-option.
719:
720: La variante final en opciones encapsuladas es "Vendor-Identifying Vendor Options"
721: como especificado en RFC3925. Estos son denotados así:
722: .B --dhcp-option=rfc3925-encap:2, 10, "text"
723: El número en la sección rfc3925-encap: es el número enterprise usado
724: para identificar esta opción.
725:
726: La dirección 0.0.0.0 no es tratada de forma especial en opciones encapsuladas.
727: .TP
728: .B --dhcp-option-force=[tag:<tag>,[tag:<tag>,]][encap:<opt>,][vi-encap:<enterprise>,][vendor:[<vendor-class>],]<opt>,[<value>[,<value>]]
729: Esto funciona exáctamente de la misma forma que
730: .B --dhcp-option
731: excepto que la opción siempre será enviada, aún si el cliente no la pide en
732: la lista de pedido de parámetros. Esto se necesita aveces, por ejemplo cuando
733: enviando opciones a PXELinux.
734: .TP
735: .B --dhcp-no-override
736: Deshabilitar la reutilización de los campos DHCP de nombre de servidor y
737: archivo como espacio para opciones extra. Si puede, dnsmasq mueve la información
738: del servidor boot y del nombre de archivo (de dhcp-boot) de sus campos dedicados
739: hacia opciones DHCP. Esto crea espacio extra en el paquete DHCP para opciones,
740: pero puede raramente confundir clientes viejos o defectuosos. Esta opción forza
741: comportamiento "simple y sencillo" para prevenir problemas en tales casos.
742: .TP
743: .B \-U, --dhcp-vendorclass=set:<tag>,<vendor-class>
744: Trazar desde un string vendor-class a una etiqueta. La mayoría de los
745: clientes DHCP proveen una "vendor class" la cual representa, en cierto
746: sentido, el tipo de host. Esta opción traza clases de vendedor a network
747: ids, de tal forma que opciones DHCP pueden ser selectivamente entregadas
748: a diferentes clases de hosts. Por ejemplo
749: .B dhcp-vendorclass=set:printers,Hewlett-Packard JetDirect
750: peritiría que opciones sean fijadas solo para impresoras HP así:
751: .B --dhcp-option=tag:printers,3,192.168.4.4
752: El string vendor-class es coordinado con el vendor-class proveido por
753: el cliente, para permitir coincidencias borrosas. El prefijo set: es
754: opcional, pero permitido por razones de consistencia.
755: .TP
756: .B \-j, --dhcp-userclass=set:<tag>,<user-class>
757: Trazar desde un string user-class a una etiqueta (con coordinación
758: substring, como con vendor-class). La mayoría de los clientes DHCP
759: proveen un "user class" el cual es configurable. Esta opción traza
760: clases user a network ids, de tal manera que opciones DHCP puedan
761: ser selectivamente enviadas a diferentes tipos de hosts. Es posible,
762: por ejemplo, usar esto para especificar una impresora diferente para
763: hosts en la clase "cuentas" que para los de la clase "ingenieria".
764: .TP
765: .B \-4, --dhcp-mac=set:<tag>,<MAC address>
766: Trazar desde una dirección MAC a una etiqueta. La dirección MAC
767: puede incluir comodínes. Por ejemplo:
768: .B --dhcp-mac=set:3com,01:34:23:*:*:*
769: fijaría el tag "3com" a cualquier host el cual su MAC coincida con
770: el patrón.
771: .TP
772: .B --dhcp-circuitid=<network-id>,<circuit-id>, --dhcp-remoteid=<network-id>,<remote-id>
773: Trazar de opciones agente de relay RFC3046 a etiquetas. Estos
774: datos pueden ser proveídos por agentes de relay DHCP. El circuit-id o
775: remote-id es normlamente brindado como hex separado por doblepuntos, pero
776: también se permite un string simple. Si se obtiene una coincidencia exacta
777: entre el circuit o agent ID y uno proveído por un agente de relay,
778: la etiqueta es fijada.
779: .TP
780: .B --dhcp-subscrid=set:<tag>,<subscriber-id>
781: Trazar de opciones relay subscriber-id RFC3993 a etiquetas.
782: .TP
783: .B --dhcp-proxy[=<ip addr>]......
784: Un agente de relay normal es usado solamente para reenviar las partes
785: iniciales de una interacción DHCP con el servidor DHCP. Una vez que
786: un cliente es configurado, se comunica diectamente con el servidor. Esto
787: es indeseable si el agente de relay está agregando información extra a
788: los paquetes DHCP, tal como usado por
789: .B dhcp-circuitid
790: y
791: .B dhcp-remoteid.
792: Una implementación relay completa puede usar la opción serverid-override
793: RFC 5107 para obligar al servidor DHCP a usar el relay como un proxy
794: completo, con todos los paquetes pasando a travez de el. Esta opción
795: provee una manera alternativa de hacer la misma cosa, para relays que
796: no tienen soporte RFC 5107. Brindada por si sola, manipula el server-id
797: para todas las interacciones via relays. Si una lista de IPs es brindada,
798: solo interacciones via relays en esas direcciones son afectadas.
799: .TP
800: .B --dhcp-match=set:<tag>,<option number>|option:<option name>|vi-encap:<enterprise>[,<value>]
801: Sin un valor, fijar la etiqueta si el cliente envía una opción
802: DHCP del número o valor brindado. Cuando un valor es brindado, fijar la
803: etiqueta solo si la opción es enviada y coincide con el valor. El valor puede
804: ser de la forma "01:ff:*:02", caso en el cual el valor debe coincidir (aparte
805: de los comodines) pero la opción enviada puede tener data que no coincide despues
806: del final del valor. El valor también puede ser de la misma forma que
807: .B dhcp-option
808: caso en el cual la opción enviada es tratada como un array, y un elemento debe
809: coincidir, así que
810:
811: --dhcp-match=set:efi-ia32,option:client-arch,6
812:
813: fijará la etiqueta a "efi-ia32" si el número 6 aparece en la lista de
814: architecturas enviada por los clientes en opción 93. (Ver RFC 4578 para
815: detalles.) Si el valor es un string, coincidencia substring es usada.
816:
817: La forma especial con vi-encap:<enterpise number> busca coincidencia con
818: clases de vendedor identificadoras para el enterprise especificado. Por
819: favor ver RFC 3925 para mas detalles sobre estas bestias raras e interesantes.
820: .TP
821: .B --tag-if=set:<tag>[,set:<tag>[,tag:<tag>[,tag:<tag>]]]
822: Llevar a cabo operaciones boolean en etiquetas. Cualquier etiqueta
823: que aparece como set:<tag> es fijada si todas las etiquetas que aparecen
824: como tag:<tag> estan fijadas, (o desfijadas cuando tag:!<tag> es
825: usado). Si ningún tag:<tag> aparece, etiquetas set:<tag> son fijadas
826: incondicionalmente. Cualquier cantidad de formas set: y tag:
827: pueden aparecer, en cualquier orden. Líneas tag-if son ejecutadas
828: en orden, así que si la etiqueta en tag:<tag> es una etiqueta fijada
829: por otra
830: .B tag-if,
831: la línea que fija la etiqueta debe preceder a la que comprueba.
832: .TP
833: .B \-J, --dhcp-ignore=tag:<tag>[,tag:<tag>]
834: Cuando todoas las etiquetas brindadas aparecen en el juego de etiquetas
835: ignorar el host y no brindarle un arriendo DHCP.
836: .TP
837: .B --dhcp-ignore-names[=tag:<tag>[,tag:<tag>]]
838: Cuando todos las etiquetas brindadas aparecen en el juego de etiquetas, ignorar cualquier nombre de host proveido por el host. Nótese que,
839: a diferencia de dhcp-ignore, es permisible no brindar ninguna etiqueta,
840: y en tal caso nombres de host proveidos por clientes DHCP siempre son
841: ignorados, y hosts DHCP son agregados al DNS usando solo la configuración
842: dhcp-host en dnsmasq y el contenido de /etc/hosts y /etc/ethers.
843: .TP
844: .B --dhcp-generate-names=tag:<tag>[,tag:<tag>]
845: Generar un nombre para clientes DHCP que de otra forma no tienen uno,
846: usando la dirección MAC expresada en hex, separada por guiones. Nótese
847: que si un host provee un nombre, será usado preferiblemente sobre este,
848: a menos que
849: .B --dhcp-ignore-names
850: esté fijado.
851: .TP
852: .B --dhcp-broadcast[=tag:<tag>[,tag:<tag>]]
853: Cuando todas las etiquetas aparecen en el juego de etiquetas, siempre
854: usar broadcast para comunicar con el host cuando no está configurado.
855: Es permisible omitir las etiquetas, caso en el cual esto es
856: incondicional. La mayoría de clientes DHCP que necesitan
857: respuestas broadcast fijan una opción en sus pedidos para que esto pase automaticamente, algunos clientes BOOTP viejos no lo hacen.
858: .TP
859: .B \-M, --dhcp-boot=[tag:<tag>,]<filename>,[<servername>[,<server address>]]
860: Fijar opciones BOOTP que han de ser devueltas por el servidor DHCP. Nombre
861: y dirección de servidor son opcionales: si no son brindadas, el nombre es
862: dejado en blanco, y la dirección es fijada a la de la máquina que corre
863: dnsmasq. Si dnsmasq está brindando servicio TFTP (ver
864: .B --enable-tftp
865: ) entonces solo el nombre de archivo es requirido aquí para habilitar
866: el inicio atravéz de una red. Si las opcionales etiquetas son brindadas,
867: ellas deberán coincidir para que esta configuración sea enviada. Nótese
868: que network-ids están prefijadas con "net:" para distinguirlas.
869: .TP
870: .B --pxe-service=[tag:<tag>,]<CSA>,<menu text>[,<basename>|<bootservicetype>][,<server address>]
871: La mayoría de usos para boot-ROMS PXE simplemente permiten al sistema PXE
872: obtener una dirección IP y entonces bajar el archivo especificado por
873: .B dhcp-boot
874: y ejecutarlo. Sin embargo, el sistema PXE es capaz de llevar
875: a cabo funciones más complejas cuando están soportadas por un
876: servidor DHCP adecuado.
877:
878: Esto especifica una opción boot que puede aparecer en un menú de boot
879: PXE. <CSA> es tipo de sistema de cliente, solo servicios del tipo correcto
880: aparecerán en un menú. Los tipos conocidos son x86PC, PC98, IA64_EFI,
881: Alpha, Arc_x86, Intel_Lean_Client, IA32_EFI, BC_EFI, Xscale_EFI y X86-64_EFI;
882: un número entero puede ser utilizado para otros tipos. El parámetro después
883: del texto de menú puede ser un nombre de archivo, caso en el cuál dnsmasq
884: actúa como un servidor boot y le ordena al cliente PXE bajar el archivo
885: vía TFTP, ya sea de sí mismo (
886: .B enable-tftp
887: debe estar fijado para que esto funcione) o desde otro servidor TFTP si la
888: dirección IP final es brindada.
889: Nótese que el sufijo "layer" (normalmente ".0") es brindado por PXE, y
890: no debe ser agregado al nombre base. Si un número entero es brindado en vez
891: de un nombre base, entonces el cliente PXE buscará un servicio boot adecuado
892: para ese tipo de red. Esta búsqueda puede ser hecha mediante broadcast,
893: o directamente a un servidor si la dirección IP es brindada. Si ningún tipo
894: de servicio boot o nombre de archivo es brindado (o un tipo de servicio boot
895: de 0 es especificado), entonces la opción de menú abortará el proceso net boot
896: y continuará desde el medio local.
897: .TP
898: .B --pxe-prompt=[tag:<tag>,]<prompt>[,<timeout>]
899: Fijar esto hace que un aviso sea expuesto despues del boot PXE. Si el timeout
900: es brindado, entonces despues que el timeout se haya vencido sin input del
901: teclado, la primera opción del menú sera automaticamente ejecutada. Si el
902: timeout es cero entonces la primera opción del menú sera automaticamente
903: ejecutada. Si
904: .B pxe-prompt
905: es omitido, el sistema esperará para el input del usuario si hay múltiples
906: artículos en el menú, pero hará boot imediatamente si hay solo uno. Ver
907: .B pxe-service
908: para detalles sobre artículos de menu.
909:
910: Dnsmasq tiene soporte para "proxy-DHCP" PXE, en este caso otro servidor
911: DHCP en la red es responsable por asignar direcciones IP, y dnsmasq
912: simplemente provee la dirección brindada en
913: .B pxe-prompt
914: y
915: .B pxe-service
916: para permitir boot a travez de la red. Este modo es habilitado usando
917: la palabra clave
918: .B proxy
919: en
920: .B dhcp-range.
921: .TP
922: .B \-X, --dhcp-lease-max=<número>
923: Limita a dnsmasq a el número especificado de arriendos DHCP. El
924: predeterminado es 1000. El limite es para prevenir ataques DoS desde
925: hosts que crean cientos de arriendos y usan mucha de la memoria del
926: proceso dnsmasq.
927: .TP
928: .B \-K, --dhcp-authoritative
929: Esta opción debe ser fijada cuando dnsmasq es definitivamente el único
930: servidor DHCP en la red. Cambia el comportamiento de RFC de tal manera
931: que pedidos desde hosts no conocidos no serán ignorados. Esto permite que
932: hosts nuevos puedan conseguir un arriendo sin sin un timeout bajo toda
933: circunstancia. También permite que dnsmasq reconstruya su base de datos
934: de arriendos sin que cada cliente necesite readquirir un arriendo
935: si la base de datos es perdida.
936: .TP
937: .B --dhcp-alternate-port[=<puerto de servidor>[,<puerto de cliente>]]
938: Cambiar del predeterminado los puertos usados para DHCP. Si esta opción
939: es brindada sola, sin argumentos, cambia los puertos usados para DHCP
940: de 67 y 68 a 1067 y 1068. Si un solo argumento es brindado, ese puerto
941: es usado para el servidor y el número de puerto mas uno es usado
942: para el cliente. Finalmente, dos números permiten que se especifiquen
943: ambos los puertos de servidor y cliente para DHCP.
944: .TP
945: .B \-3, --bootp-dynamic[=<network-id>[,<network-id>]]
946: Habilitar alocación dinámica de direcciones IP a clientes BOOTP. Usar
947: esto con cuidado, ya que cada dirección alocada a un cliente BOOTP
948: es arrendada para siempre, y consecuentemente queda no-disponible
949: para re-uso por otros hosts. Si esto es brindado sin etiquetas,
950: entonces incondicionalmente habilita alocación dinámica. Con
951: etiquetas, solo cuando todas las etiquetas están fijadas. Puede
952: ser repetido con diferentes juegos de etiquetas.
953: .TP
954: .B \-5, --no-ping
955: Por predetermindado, el servidor DHCP tratará de asegurarse que una
956: dirección no esté en uso antes de alocarsela a un host. Hace esto
957: enviando un echo ICMP (ping) a la dirección referente. Si recibe una
958: respuesta, entonces la dirección debe estar siendo usada, y se repite
959: la prueba con otra. Esta opción deshabilita esta prueba. Usar con
960: cuidado.
961: .TP
962: .B --log-dhcp
963: Bitacoréo extra para DHCP: Bitacorear todas las opciones enviadas a
964: clientes DHCP y las etiquetas usadas para determinarlos.
965: .TP
966: .B \-l, --dhcp-leasefile=<path>
967: Usar el archivo especificado para almacenar información de arriendos
968: DHCP.
969: .TP
970: .B \-6 --dhcp-script=<path>
971: Cuando un arriendo DHCP nuevo es creado, o uno viejo es
972: destruido, el ejecutable especificado por esta opción es ejecutado.
973: <path> debe ser un pathname absoluto, ninguna búsqueda PATH ocurre.
974: Los argumentos para el binario son "add", "old", o "del", la dirección
975: MAC del host, la dirección IP, y el hostname, si es
976: conocido. "add" significa que un arriendo ha sido creado, "del" que
977: ha sido destruido, y "old" es una notificación de un arriendo existente
978: cuando dnsmasq inicia o un cambio a una MAC o nombre host de un arriendo
979: existente (también, tiempo de arriendo o vencimiento y client-id, si
980: leasefile-ro está fijado). Si la dirección MAC es de un tipo de red
981: que no es ethernet, tendrá el tipo de red precolocado, por ejemplo
982: "06-01:23:45:67:89:ab" para token ring. El proceso es ejecutado como root
983: (asumiendo que dnsmasq fue originalmente ejecutado como root) aún si dnsmasq
984: está configurado para cambiar su UID a un usuario sin privilegios.
985:
986:
987: El ambiente es heredado del usuario que ha invocado a dnsmasq, con algunas
988: o todas de las siguientes variables agregadas.
989:
990: DNSMASQ_CLIENT_ID si el host brindo un client-id.
991:
992: DNSMASQ_DOMAIN si el nombre de dominio completamente calificado del host
993: es conocido, esto es fijado a la parte del dominio.
994:
995: Si el cliente brinda vendor-class, hostname o user-class, estos son
996: brindados en las variables
997: DNSMASQ_VENDOR_CLASS, DNSMASQ_SUPPLIED_HOSTNAME, y
998: DNSMASQ_USER_CLASS0..DNSMASQ_USER_CLASSn, pero solo para acciones "add"
999: y "old" cuando un host reanuda un arriendo existente, dado a que estos
1000: datos no son almacenados en la base de datos de arriendos de dnsmasq.
1001:
1002: Si dnsmasq fue compilado con HAVE_BROKEN_RTC, entonces la duración del
1003: arriendo (en segundos) es almacenada en DNSMASQ_LEASE_LENGTH, de otra
1004: manera el tiempo de vencimiento es almacenado en DNSMASQ_LEASE_EXPIRES.
1005: El número de segundos faltante para el vencimiento del arriendo siempre
1006: es almacenado en DNSMASQ_TIME_REMAINING.
1007:
1008: Si un arriendo solía tener un nombre de host, el cual es removido, un
1009: evento "old" es generado con el nuevo estado del arriendo, (por ejemplo, sin
1010: nombre), y el nombre anterior es brindado en la variable de ambiente
1011: DNSMASQ_OLD_HOSTNAME.
1012:
1013: DNSMASQ_INTERFACE almacena el nombre de la interface
1014: en la cual llegó el pedido; esto no es fijado para acciones "viejas"
1015: cuando dnsmasq re-inicia.
1016:
1017: DNSMASQ_RELAY_ADDRESS es fijado si el cliente
1018: usó un relay DHCP para contactar a dnsmasq y la dirección IP del relay
1019: es conocida.
1020:
1021: DNSMASQ_TAGS contiene todas las etiquetas network-id fijadas
1022: durante la transacción DHCP, separadas por espacios.
1023:
1024: Todos los descriptores de archivo están cerrados
1025: excepto stdin, stdout, y stderr los cuales están abiertos a /dev/null
1026: (excepto en modo debug).
1027:
1028: Este guión no es invocado concurrentemente: máximo una instamcia del
1029: guión está corriendo a la vez (dnsmasq espera a que una instancia de
1030: guión haga exit antes de correr la siguiente). Cambios a la base de
1031: datos de arriendos que requieren que el guión sea invocado son puestos
1032: en cola esperando el exit de una instancia corriente. Si esta cola permite
1033: que cambios multiples de estado le ocurran a un arriendo individual antes
1034: de que el guión pueda ser ejecutado entonces estados anteriores son descartados
1035: y el estado actual del arriendo es reflejado cuando el guión finalmente corre.
1036:
1037: Al inicio de dnsmasq, el guión
1038: será invocado para todos los arriendos existentes mientras van siendo
1039: leídos desde el archivo de arriendos. Arriendos vencidos serán llamados
1040: con "del" y otros con "old". <path> debe ser un path absoluto, ninguna
1041: búsqueda PATH ocurre cuando arriendos dnsmasq serán llamados con "del"
1042: y otros con "old". Cuando dnsmasq recibe una señal HUP, el guión será
1043: invocado para arriendos existentes con un evento "old".
1044: .TP
1045: .B --dhcp-scriptuser
1046: Especificar el usuario como el cual se debe correr el archivo
1047: guión de cambio de arriendos. Este es root por predeterminado,
1048: pero puede ser cambiado a otro usuario mediante esta opción.
1049: .TP
1050: .B \-9, --leasefile-ro
1051: Suprimir completamente el uso del archivo de arriendos. El archivo no será
1052: creado, leído, ni escrito. Cambiar la manera en la cuál el archivo guión de
1053: cambio de arriendo (si es brindado) es llamado, de tal forma que la base de
1054: datos de arriendospueda ser mantenida en almacenaje externo por el archivo
1055: guión. Adicionálmente a las invocaciones brindadas en
1056: .B --dhcp-script
1057: el archivo de cambio de arriendos es llamado una vez, al inicio de dnsmasq,
1058: con el único argumento "init". Cuando invocado de esta forma, el guión debería
1059: escribir el estado guardado de la base de datos de arriendos, en formato de
1060: archivo de arriendos dnsmasq, a stdout y hacer exit con código exit cero. Fijar
1061: esta opción también forza que el archivo de cambio de arriendos sea llamado
1062: cuando hay cambios hechos a el client-id y tiempos de arriendo y vencimiento.
1063: .TP
1064: .B --bridge-interface=<nombre de interface>,<alias>[,<alias>]
1065: Tratar paquetes de pedidos DHCP (v4 y v6) y de IPv6 Router Solicit que
1066: llegan a cualquiera de las interfaces <alias> como si hubieran llegado
1067: a la interface <nombre de interface>. Esta opción permite que dnsmasq
1068: puede proporcionar los servicios DHCP y RA a través de interfaces
1069: ethernet sin dirección y sin puente; por ejemplo en un nodo de cálculo
1070: de OpenStack, donde cada una de esas interfaces es una interfaz TAP
1071: para una máquina virtual, o al usar bridging estilo viejo en
1072: plataformas BSD.
1073: .TP
1074: .B \-s, --domain=<dominio>[,<rango de IPs>]
1075: Especifica los dominios DNS para el servidor DHCP. Dominios pueden ser
1076: brindados incondicionalmente (sin el rango de IPs) o para rangos limitados. Esto
1077: tiene dos efectos: Primeramente, causa que el servidor DHCP le devuelva el
1078: dominio a cualquier host que lo pida. Segundamente, fija el dominio para el
1079: cual es legal para hosts configurados mediante DHCP reclamar. La intención es
1080: restringir nombres de host para que un host no-confiado en la LAN no
1081: pueda proclamar su nombre vía DHCP, como por ejemplo "microsoft.com" y
1082: capturar tráfico no destinado a ella. Si ningún sufijo de dominio es
1083: especificado, entonces cualquier nombre de host con una parte de dominio
1084: (o sea con un punto) será negada y bitacorada. Si un sufijo es especificado,
1085: entonces nombres de host con una parte de dominio son permitidos, con tal
1086: que la parte de dominio coincida con el sufijo. Adicionalmente, cuando
1087: un sufijo es fijado, entonces nombres de host sin parte de dominio tienen
1088: el sufijo agregado como una parte de dominio opcional. Por ejemplo, en
1089: mi red puedo fijar
1090: .B --domain=thekelleys.org.uk
1091: y tener una maquina cuyo nombre host DHCP es "laptop". La dirección IP
1092: de esa máquina es disponible desde
1093: .B dnsmasq
1094: como "laptop" y "laptop.thekelleys.org.uk". Si el dominio es brindado
1095: como "#" entonces el dominio es leido desde la primera directiva search
1096: en /etc/resolv.conf (o equivalente). El rango de direcciones puede ser
1097: <dirección IP>,<dirección IP> or <dirección IP>/<máscara de subred>. Ver
1098: .B --dhcp-fqdn el cual puede cambiar el comportamiento de dnsmasq con
1099: dominios.
1100: .TP
1101: .B --dhcp-fqdn
1102: En el modo predeterminado, dnsmasq pone los nombres no-calificados
1103: de clientes DHCP en el DNS. Por esta razón, los nombres deben ser únicos,
1104: aún si dos clientes que tienen el mismo nombre están en dominios
1105: diferentes. Si un segundo cliente DHCP aparece el cual tiene el mismo
1106: nombre que un cliente existente, el nombre es transferido al cliente nuevo. Si
1107: .B --dhcp-fqdn
1108: está fijado, este comportamiento cambia: El nombre no-calificado
1109: no es puesto en el DNS, solo el nombre calificado. Dos clientes DHCP con
1110: el mismo nombre pueden ambos quedarse con el nombre, con tal que la parte
1111: de dominio sea diferente (o sea que los nombres completamente calificados
1112: difieran). Para asegurar que todos los nombres tengan una parte de dominio,
1113: debe haber al menos
1114: .B --domain
1115: sin una dirección especificada cuando
1116: .B --dhcp-fqdn
1117: está fijado.
1118: .TP
1119: .B --enable-tftp[=<interface>]
1120: Habilitar la función de servidor TFTP. Esto está deliberadamente limitado
1121: a lo necesario para hacerle a un cliente un inicio vía red. Solo lectura es
1122: permitida; las extensiones tsize y blksize son soportadas (tsize solo es
1123: soportada en modo octeto). Ver sección de NOTAS para el uso de el argumento
1124: de interface.
1125: .TP
1126: .B --tftp-root=<directory>[,<interface>]
1127: Buscar, relativo al directorio brindado, archivos para transferir mediante el
1128: uso de TFTP. Cuando esta opción está fijada, paths TFTP que incluyen ".." son
1129: rechazados, para prevenir que clientes salgan de la raíz especificada. Paths
1130: absolutos (los que comienzan con "/") están permitidos, pero deben estar
1131: dentro del tftp-root. Si el argumento opcional de interface es brindado, el
1132: directorio es solo usado para pedidos TFTP vía esa interface.
1133: .TP
1134: .B --tftp-unique-root
1135: Agregar la dirección IP del cliente TFTP como un componente path del lado del
1136: TFTP-root (en formato estándar de cuatro puntos). Solo válido si un tftp-root
1137: está fijado y el directorio existe. Por ejemplo, si tftp-root es "/tftp" y el
1138: cliente 1.2.3.4 pide el archivo "miarchivo" entonces el path efectivo será
1139: "/tftp/1.2.3.4/miarchivo" si /tftp/1.2.3.4 existe o /tftp/miarchivo si no.
1140: .TP
1141: .B --tftp-secure
1142: Habilitar modo TFTP seguro: sin esto, cualquier archivo que es leíble por el
1143: proceso dnsmasq bajo reglas normales de control de acceso UNIX, está disponible
1144: vía TFTP. Cuando la opción --tftp-secure es fijada, solo archivos
1145: pertenecientes al usuario que corre el proceso dnsmasq están accesibles. Si
1146: dnsmasq está corriendo como root, reglas diferentes aplican: --tftp-secure no
1147: tiene ningún efecto, pero solo archivos que tienen el bit de lectura global
1148: fijados están accesibles. No se recomienda correr dnsmasq como root con TFTP
1149: habilitado, y mucho menos sin especificar --tftp-root, ya que se puede exponer
1150: cualquier archivo de lectura global en el servidor a cualquier host de la red.
1151: .TP
1152: .B --tftp-max=<conecciones>
1153: Fijar el número máximo permitido de conecciones TFTP simultáneas. Esto es 50
1154: por predeterminado. Al servir un número grande de conecciones TFTP, límites
1155: de descriptor de archivo por proceso pueden ser encontrados. Dnsmasq necesita
1156: un descriptor de archivo por cada coneccion TFTP concurrente, y por archivo
1157: único (mas algunos otros). De tal manera que servirle el mismo archivo
1158: simultáneo a n clientes requerirá el uso de n + 10 descriptores de archivo,
1159: y servirles archivos diferentes simultáneamente requerirá (2*n) + 10
1160: descriptores. Si
1161: .B --tftp-port-range
1162: es brindado, eso puede afectar el número de conexiones simultáneas.
1163: .TP
1164: .B --tftp-no-blocksize
1165: No permitir que el servidor negocie la opción "blocksize" con un cliente.
1166: Algunos clientes con errores piden esta opción pero se portán mal cuando se
1167: les brinda.
1168: .TP
1169: .B --tftp-port-range=<inicio>,<final>
1170: Un servidor TFTP escucha por inicios de conexión en un puerto bien conocido
1171: (69), pero tambien usa un puerto dinamicamente seleccionado para cada
1172: conexión. Normalmente estos son seleccionados por el sistema operativo,
1173: pero esta opción especifica un rango de puertos para ser usado por transferencias
1174: TFTP. Esto puede ser útil cuando TFTP tiene que pasar atraves de un firewall.
1175: El comienzo del rango no puede ser menor a 1025 a menos que dnsmasq esté corriendo
1176: como root. El número de conexiones simultáneas está limitado por el tamaño del
1177: rango de puertos.
1178: .TP
1179: .B \-C, --conf-file=<archivo>
1180: Especificar un archivo de configuración diferente. La opción conf-file
1181: también es permitida en archivos de configuración, para incluir múltiples
1182: archivos de configuración.
1183: .TP
1184: .B \-7, --conf-dir=<directorio>[,<file-extension>......]
1185: Leer todos los archivos dentro del directorio brindado como archivos
1186: de configuración. Si extensiones son brindadas, cualquier archivo que
1187: termine en esas extensiones son ignorados. Cualquier archivos cuyos nombres
1188: terminen con ~ o comienzen con . o comienzen y terminen con # siempre son
1189: ignorados. Esta opción puede ser brindada en la línea de comandos o en un
1190: archivo de configuración.
1191: .SH ARCHIVO DE CONFIGURACION
1192: Al inicio, dnsmasq lee
1193: .I /etc/dnsmasq.conf,
1194: si existe. (En FreeBSD, el archivo es
1195: .I /usr/local/etc/dnsmasq.conf
1196: ) (pero ver las opciónes
1197: .B \-C
1198: y
1199: .B \-7
1200: porfavor.) El formato de este archivo consiste de una opción por línea,
1201: exáctamente como las opciones largas detalladas en la sección OPCIONES
1202: pero sin el "--" al frente. Líneas que comienzan con # son comentarios
1203: y son ignoradas. Para opciones que solo pueden ser especificadas una
1204: sola vez, el archivo de configuración invalida la línea de comandos.
1205: Las comillas son permitidas en el archivo de configuración: entre comillas
1206: tipo " los significados especiales de ,:. y # son eliminados y los
1207: siguientes escapes son permitidos: \\\\ \\" \\t \\e \\b \\r y \\n.
1208: Corresponden a tab, escape, backspace, return y newline.
1209: .SH NOTAS
1210: Al recibir un SIGHUP
1211: .B dnsmasq
1212: libera su cache y entonces recarga
1213: .I /etc/hosts
1214: y
1215: .I /etc/ethers
1216: al igual que cualquier archivo brindado con --dhcp-hostsfile, --dhcp-optsfile,
1217: o --addn-hosts.
1218: El archivo guión de cambio de arriendos es llamado para todos los arriendos
1219: DHCP existentes. Si
1220: .B
1221: --no-poll
1222: está fijado entonces SIGHUP también re-lee
1223: .I /etc/resolv.conf.
1224: SIGHUP
1225: NO re-lee el archivo de configuración.
1226: .PP
1227: Al recibir un SIGUSR1,
1228: .B dnsmasq
1229: escribe estadísticas a la bitácora del sistema. Escribe el tamaño
1230: del caché, el numero de nombres que han tenido que ser removidos del
1231: caché antes de que vencieran para hacer espacio para nombres nuevos, y el
1232: número total de nombres que han sido insertados en el caché. Para cada
1233: servidor upstream brinda el número de búsquedas enviadas, y el
1234: número que resultaron en error. En modo
1235: .B --no-daemon
1236: o cuando bitacoréo completo está habilitado (-q), una descarga completa de
1237: el contenido del caché es hecha.
1238: .PP
1239: Cuando recibe un SIGUSR2 y está bitacoreando diréctamente a un archivo (ver
1240: .B --log-facility
1241: )
1242: .B dnsmasq
1243: cerrará y reabrirá el archivo de bitácora. Nótese que durante esta
1244: operación, dnsmasq no estará corriendo como root. Al crear el archivo de
1245: bitácora, dnsmasq cambia el dueño del archivo a el usuario normal como
1246: el que correrá. Logrotate debe ser configurado para crear un archivo de
1247: bitácora nuevo con permisos iguales al existente, antes de enviar
1248: SIGUSR2. Si búsquedas DNS TCP están en progreso, el archivo de bitácora
1249: viejo se mantendrá abierto en procesos hijos que están manejando
1250: búsquedas TCP, y puede continuarse a escribirle. Hay un límite de 150
1251: segundos, después de lo cual todos los procesos TCP existentes se habrán
1252: vencido: por esta razón, no es sabio configurar compresión de archivos
1253: de bitácora para archivos que acaban de ser rotados. Con logrotate, las
1254: opciones requeridas son
1255: .B create
1256: y
1257: .B delaycompress.
1258: .PP
1259: Dnsmasq es un reenviador de búsquedas DNS: no puede responder búsquedas
1260: arbitrarias comenzando desde los servidores root pero reenvía dichas
1261: búsquedas a un servidor DNS recursivo, el cual es típicamente proveído
1262: por el proveedor de Internet. Por predeterminado, dnsmasq lee
1263: .I /etc/resolv.conf
1264: para descubir las direcciones IP de los servidores DNS upstream que
1265: debe usar, dado a que esta información es normalmente almacenada allí.
1266: Amenos que
1267: .B --no-poll
1268: sea usado,
1269: .B dnsmasq
1270: revisa el tiempo de modificación de
1271: .I /etc/resolv.conf
1272: (o equivalente si
1273: .B \--resolv-file
1274: es usado) y lo re-lee si ha cambiado. Esto permite que servidores DNS séan
1275: fijados dinámicamente vía PPP o DHCP ya que ambos protocolos brindan esta
1276: información.
1277: La ausencia de
1278: .I /etc/resolv.conf
1279: no es un error ya que pudo haber sido creada antes de que una conexión PPP
1280: haya existido. Dnsmasq simplemente sigue revisando en caso de que
1281: .I /etc/resolv.conf
1282: sea creado en algún momento. A dnsmasq se le puede decir que revise más
1283: de un archivo resolv.conf. Esto es útil en una laptop, donde ambos PPP y
1284: DHCP podrían estar siendo usados: dnsmasq puede ser fijado para revisar ambos
1285: .I /etc/ppp/resolv.conf
1286: y
1287: .I /etc/dhcpc/resolv.conf
1288: y usará el contenido del que haya cambiado mas recientemente,
1289: brindando así la habilidad de cambio automático entre servidores DNS.
1290: .PP
1291: Servidores upstream también pueden ser especificados en la línea de
1292: comandos o en el archivo de configuración. Estas especificaciones de
1293: servidor opcionalmente llevan un nombre de dominio el cual le dice a
1294: dnsmasq que debe usar ese servidor solo para encontrar nombres en ese
1295: dominio en particular.
1296: .PP
1297: Para configurar dnsmasq como caché para el host donde está
1298: corriendo, poner un "nameserver 127.0.0.1" en
1299: .I /etc/resolv.conf
1300: para así forzar procesos locales a enviar búsquedas a dnsmasq. Entonces,
1301: o especificar los servidores upstream diréctamente a dnsmasq usando opciones
1302: .B \--server
1303: o poniendo sus direcciones reales en otro archivo, digamos
1304: .I /etc/resolv.dnsmasq
1305: y correr dnsmasq con la opcion
1306: .B \-r /etc/resolv.dnsmasq
1307: Esta segunda técnica permite la actualización dinámica de las direcciones
1308: de servidor mediante PPP o DHCP.
1309: .PP
1310: Direcciones en /etc/hosts "harán sombra" a diferentes direcciones para
1311: los mismos nombres en servidores DNS upstream, así que
1312: "miempresa.com 1.2.3.4" en /etc/hosts se asegurará que las búsquedas
1313: por "miempresa.com" siempre retornarán 1.2.3.4 aún si búsquedas en el
1314: servidor DNS upstream devolverían una dirección diferente. Hay una
1315: excepción a esto: si el servidor DNS upstream contiene un CNAME que
1316: apunta a un nombre sombreado, entonces buscando el CNAME a travéz de
1317: dnsmasq resultará en que la dirección no-sombreada será asociada con
1318: el destino del CNAME. Para circumventar esto, agregar el CNAME a
1319: /etc/hosts de tal manera que el CNAME es sombreado también.
1320:
1321: .PP
1322: El sistema de etiquetas funciona de la siguiente manera: Para cada pedido
1323: DHCP, dnsmasq colecciona un juego de etiquetas válidas de líneas de
1324: configuración activas que incluyen set:<tag>, incluyendo una del
1325: .B dhcp-range
1326: usado para alocar la dirección, una de cualquier
1327: .B dhcp-host
1328: que coincida (y "known" si un dhcp-host coincide).
1329: La etiqueta "bootp" es fijada para pedidos BOOTP, y una etiqueta cuyo
1330: nombre es el nombre de la interface donde llegó el pedido tambien es
1331: fijada.
1332:
1333: Cualquier linea de configuración que incluya uno o mas
1334: construcciones tag:<tag> solo será válida si todas las etiquetas
1335: coinciden en el juego derivado arriba. Típicamente esto es dhcp-option.
1336: .B dhcp-option
1337: que tenga etiquetas será usada en preferencia de una opción
1338: .B dhcp-option,
1339: sin etiqueta, con tal que _todas_ las etiquetas coincidan en alguna
1340: parte del juego coleccionado describido arriba. El prefijo '!' en una
1341: etiqueta significa "no" así que --dhcp=option=tag:!purple,3,1.2.3.4 envía
1342: la opción cuando la etiqueta "purple" no está en el juego
1343: de etiquetas válidas. (Si se está usando esto en una línea de comandos
1344: en vez de un archivo de configuración, asegurese de escapar !, el cual
1345: es un metacaracter de shell.)
1346: .PP
1347: Nótese que para
1348: .B dhcp-range
1349: ambos tag:<tag> y set:<tag> son permitidos, para seleccionar el rango
1350: en uso basado en (por ejemplo) dhcp-host, y para afectar las opciones
1351: enviadas, basadas en el rango seleccionado.
1352:
1353: Este sistema evolucionó de uno anterior mas limitado y para compatibildad
1354: reversa "net:" puede ser usada en vez de "tag:" y "set:" puede ser
1355: omitida. (Excepto en
1356: .B dhcp-host,
1357: donde "net:" puede ser usado en vez de "set:".) Por la misma razón, '#'
1358: puede ser usado en vez de '!' para indicar NO.
1359: .PP
1360: El servidor DHCP de dnsmasq funcionará como servidor BOOTP tambien,
1361: con tal que las direcciones MAC y IP de los clientes sean brindadas,
1362: ya sea usando configuraciones
1363: .B dhcp-host
1364: o en
1365: .I /etc/ethers
1366: , y una configuración
1367: .B dhcp-range
1368: esté presente para activar el servidor DHCP en una red particular.
1369: (Fijar --bootp-dynamic elimina la necesidad de trazados estáticos.) El
1370: parámetro de nombre de archivos en un pedido BOOTP es usado como
1371: una etiqueta, al igual que la etiqueta "bootp", permitiendo así algún
1372: control sobre las opciones devueltas a diferentes clases de hosts.
1373:
1374: .B dhcp-range
1375: puede tener un nombre de interface brindado como
1376: "interface:<interface-name>". La semántica de esto es así:
1377: Para DHCP, si cualquier otro dhcp-range existe _sin_ un nombre de
1378: interface, entonces el nombre de interface es ignorado y dnsmasq
1379: se comporta como si las partes de interface no existieran, de otra forma
1380: DHCP solo se provee a interfaces mencionadas en declaraciones
1381: dhcp-range. Para DNS, si no hay opciones
1382: .B --interface
1383: o
1384: .B --listen-address
1385: el comportamiento no se modifica por la parte de interface. Si cualquiera
1386: de estas opciones está presente, las interfaces mencionadas en dhcp-ranges
1387: son agregadas all juego que obtienen servicio DNS.
1388:
1389: Similarmente,
1390: .B enable-tftp
1391: puede tomar un nombre de interface, el cual habilita TFTP solo para una
1392: interface en particular, ignorando opciones
1393: .B --interface
1394: o
1395: .B --listen-address.
1396: Adicionalmente,
1397: .B --tftp-secure
1398: y
1399: .B --tftp-unique-root
1400: y
1401: .B --tftp-no-blocksize
1402: son ignorados por pedidos desde dichas interfaces. (Una directiva
1403: .B --tftp-root
1404: brindando un path raíz y una interface debe ser brindada tambien.)
1405:
1406: Estas reglas pueden parecer raras a primera vista, pero permiten que
1407: una simple linea de la forma
1408: "dhcp-range=interface:virt0,192.168.0.4,192.168.0.200" sea agregada a
1409: configuración dnsmasq, lo cual brinda servicios DHCP y DNS a esa interface,
1410: sin afectar los servicios en otras interfaces y irrespectivamente de
1411: la existencia o no de lineas "interface=<interface>" en alguna otra parte
1412: de la configuración dnsmasq.
1413: "enable-tftp=virt0" y "tftp-root=<root>,virt0" hacen el mismo trabajo
1414: para TFTP.
1415: La idea es que una linea así pueda ser agregada automaticamente
1416: por libvirt o sistemas equivalentes, sin estorbar alguna
1417: configuración manual.
1418:
1419: .SH CÓDIGOS EXIT
1420: .PP
1421: 0 - Dnsmasq hizo fork hacia el fondo exitosamente, o terminó de manera
1422: normal si ir al fondo no está habilitado.
1423: .PP
1424: 1 - Un problema con la configuración ha sido detectado.
1425: .PP
1426: 2 - Un problema con acceso a redes ocurrió (dirección en uso, intento
1427: de usar puertos privilegiados sin permiso).
1428: .PP
1429: 3 - Un problema con una operación de sistema de archivos ocurrió (archivo
1430: o directorio ausente, permisos).
1431: .PP
1432: 4 - Falla de alocación de memoria.
1433: .PP
1434: 5 - Otro problema misceláneo.
1435: .PP
1436: 11 o mayor - un codigo de retorno no cero fué recibido del llamado "init"
1437: del proceso de archivo guión de arriendos. El código exit de dnsmasq es
1438: el código exit del archivo guión con 10 sumado.
1439:
1440: .SH LIMITES
1441: Los valores predeterminados para limites de recursos son generálmente
1442: conservadores, y apropiados para uso en dispositivos tipo enrutador
1443: encrustrado con procesadores lentos y poca memoria. En hardware más
1444: capáz, es posible incrementar los límites, y soportar muchos mas
1445: clientes. Lo siguiente se aplica a dnsmasq-2.37: versiones previas
1446: no escalaban tan bien.
1447:
1448: .PP
1449: Dnsmasq es capaz de soportar con DNS y DHCP a por lo menos mil (1,000)
1450: clientes. Los tiempos de arriendo no deben ser muy cortos (menos
1451: de una hora). El valor de
1452: .B --dns-forward-max
1453: puede ser aumentado: comienze con el equivalente a el número de clientes y
1454: auméntelo si parece lento el DNS. Nótese que el rendimiento DNS depende
1455: también de los servidores DNS upstream. El tamaño del caché DNS puede ser
1456: incrementado: el límite obligatorio es 10,000 nombres y el predeterminado
1457: (150) es muy bajo. El enviarle un SIGUSR1 a dnsmasq hace que bitacorée
1458: información que es útil para afinar el tamaño de caché. Ver la sección
1459: .B NOTAS
1460: para detalles.
1461:
1462: .PP
1463: El servidor TFTP incorporado es capáz de soportar varias transferencias
1464: simultáneas de archivos: el límite absoluto está relacionado con el número
1465: de file-handles permitidos a un proceso y la habilidad del system call
1466: select() a soportar números grandes de file-handles. Si el límite es fijado
1467: demasiado alto con
1468: .B --tftp-max
1469: será de-escalado y el límite real será bitacoreado al inicio. Nótese que más
1470: transferencias son posibles cuando el mismo archivo es enviado qué cuando
1471: cada transferencia envía un archivo diferente.
1472:
1473: .PP
1474: Es posible usar dnsmasq para negar publicidad Web usando una lista de
1475: servidores de banners bien conocidos, todos resolviendose a 127.0.0.1 o
1476: 0.0.0.0 en
1477: .B /etc/hosts
1478: o en un archivo hosts adicional. La lista puede ser muy larga. Dnsmasq ha sido
1479: probado exitósamente con un millón de nombres. Ese tamaño de archivo necesita
1480: un CPU de 1GHz y aproximadamente 60MB de RAM.
1481:
1482: .SH INTERNACIONALIZACION
1483:
1484: Dnsmasq puede ser compilado con soporte para internacionalización. Para hacer esto,
1485: los targets make "all-i18n" y "install-i18n" deberán ser usados en vez de
1486: los targets estándares "all" y "install". Cuando internacionalización es
1487: compilada, dnsmasq producirá mensajes de bitácora en el lenguaje local y soportará
1488: dominios internacionalizados (IDN). Nombres de dominio en /etc/hosts, /etc/ethers,
1489: y /etc/dnsmasq.conf que contienen carácteres no-ASCII serán traducidos a
1490: representación interna DNS punycode. Nótese que dnsmasq determina ambos el
1491: lenguaje para mensajes y el juego de carácteres asumido para archivos de configuración
1492: de la variable ambiental LANG. Esto debe estar fijado al valor predeterminado del sistema
1493: por el guión responsable de iniciar dnsmasq. Al editar archivos de configuración,
1494: tener cuidado de hacerlo usando solo el locale predeterminado del sistema y no
1495: uno especifico del usuario, dado a que dnsmasq no tiene ninguna manera directa de
1496: determinar el juego de caracteres en uso, y debe asumir que es el predeterminado
1497: del sistema.
1498:
1499: .SH ARCHIVOS
1500: .IR /etc/dnsmasq.conf
1501:
1502: .IR /usr/local/etc/dnsmasq.conf
1503:
1504: .IR /etc/resolv.conf
1505:
1506: .IR /etc/hosts
1507:
1508: .IR /etc/ethers
1509:
1510: .IR /var/lib/misc/dnsmasq.leases
1511:
1512: .IR /var/db/dnsmasq.leases
1513:
1514: .IR /var/run/dnsmasq.pid
1515: .SH VER TAMBIEN
1516: .BR hosts (5),
1517: .BR resolver (5)
1518: .SH AUTOR
1519: Este manual fue escrito por Simon Kelley <simon@thekelleys.org.uk>.
1520:
1521: Traducido a español por Christopher Chatham <chrislinux@gmail.com>.
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>
![[BACK]](/icons/cvsweb/back.gif){kind=icon}
Return to dnsmasq.8 CVS log ![[TXT]](/icons/cvsweb/text.gif){kind=icon}
![[DIR]](/icons/cvsweb/dir.gif){kind=icon}
Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / dnsmasq / man / es