Return to dnsmasq.8 CVS log

Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / dnsmasq / man / es

dnsmasq 2.84

.TH DNSMASQ 8
.SH NOMBRE
dnsmasq \- Un ligero servidor DHCP y DNS con caché.
.SH SINOPSIS
.B dnsmasq
.I [OPCION]...
.SH "DESCRIPCIÓN"
.BR dnsmasq
es un ligero servidor DNS, TFTP y DHCP. Su propósito es proveer servicios DNS
y DHCP a una red de área local.
.PP
Dnsmasq acepta búsquedas DNS y las responde desde un pequeño
caché local, o las reenvía hacia un servidor DNS real recursivo.
Carga el contenido de /etc/hosts, de tal forma que nombres de
hosts locales los cuales no aparecen en el DNS mundial puedan ser
resueltos. También responde a búsquedas DNS para hosts configurados
vía DHCP.
.PP
El servidor DHCP dnsmasq incluye soporte para asignación de direcciones
estáticas y redes múltiples. Automáticamente envía un predeterminado sensible de
opciones DHCP, y puede ser configurado para enviar cualquier opciones DHCP deseadas,
incluyendo opciones encapsuladas por vendedores. Incluye un servidor seguro
TFTP solo-lectura para permitir el inicio vía red/PXE de hosts DHCP. Tambíen
incluye soporte para BOOTP.
.PP
Dnsmasq
incluye soporte IPv6 para DNS, pero no para DHCP.
.SH OPCIONES
Nótese que en general parámetros ausentes son permitidos y deshabilitan
funciones, por ejemplo "--pid-file=" deshabilita la escritura de un
archivo PID. En BSD, a menos que la librería GNU getopt esté enlazada,
la forma larga de las opciones no funciona en la línea de comandos,
pero todavía es reconocida en el archivo de configuración.
.TP
.B --test
Leer archivo(s) de configuración y revisar su sintaxis. Salir con código
0 si todo está bien, o un código no-cero en cualquier otro caso. No
iniciar dnsmasq.
.TP
.B \-h, --no-hosts
No leer los nombres de hosts en /etc/hosts.
.TP
.B \-H, --addn-hosts=<archivo>
Archivo de hosts adicional. Leer el archivo especificado adicionalmente
a /etc/hosts. Si se brinda -h, leer solo el archivo especificado. Esta
opción puede ser repetida para más de un archivo de hosts adicional. Si
un directorio es brindado, entonces leer todos los archivos contenidos en
ese directorio.
.TP
.B \-E, --expand-hosts
Agregar el dominio a nombres sencillos (sin punto) en /etc/hosts de la
misma manera que con nombres derivados de DHCP. Nótese que esto no
aplica a nombres de dominio en cnames, expedientes PTR, TXT, etc.
.TP
.B \-T, --local-ttl=<tiempo>
Al responder con información desde /etc/hosts o desde el archivo
de arriendos DHCP, dnsmasq fija el tiempo de vida (TTL) a cero por
predeterminado, significando que el remitente no debrá cachear
la información por sí mismo. Esto es lo correcto a hacer en casi
todas las situaciones. Esta opción permite que se especifique
cierto tiempo de vida (en segundos) para estas respuestas. Esto
reduce la carga sobre el servidor al costo de que los clientes
usaran datos añejos bajo algunas circunstancias.
.TP
.B --neg-ttl=<tiempo>
Respuestas negativas desde servidores upstream normalmente contienen
información time-to-live (tiempo de vida) en expedientes SOA que
dnsmasq usa para hacer caché. Si las respuestas de servidores upstream
omiten esta información, dnsmasq no mete la respuesta en el caché.
Esta opción brinda un valor predeterminado para el time-to-live que
dnsmasq usa para meter respuestas negativas en el caché aún en la
ausencia de un expediente SOA.
.TP
.B --max-ttl=<tiempo>
Fijar un valor TTL (tiempo de vida) máximo que será entregado a
clientes. El TTL máximo especificado será otorgado a clientes en vez
del TTL verdadero si es menor. El valor TTL real es mantenido en el caché
para prevenir la inundación de los servidores DNS upstream.
.TP
.B \-k, --keep-in-foreground
No ir hacia el fondo al iniciar, pero aparte de eso ejecutar como
normal. La intención de esto es para cuando dnsmasq es ejecutado
bajo daemontools o launchd.
.TP
.B \-d, --no-daemon
Modo debug: no hacer un fork hacia el fondo, no crear un archivo PID,
no cambiar el ID del usuario, generar un cache dump completo al
recibir un SIGUSR1, bitacorear a stderr al igual que a syslog, no
forkear procesos nuevos para manejar búsquedas TCP.
.TP
.B \-q, --log-queries
Bitacorear los resultados de búsquedas DNS manejadas por dnsmasq.
Habilitar un dump de caché completo al recibir un SIGUSR1.
.TP
.B \-8, --log-facility=<facilidad>
Fijar la facilidad a la cual dnsmasq deberá enviar mensajes syslog,
esto es DAEMON por predeterminado, y LOCAL0 cuando el modo debug está
en operación. Si la facilidad brindada contiene por lo menos un carácter
"/", se trata como un nombre de archivo, y dnsmasq bitacoreará a dicho
archivo, en vez de syslog. Si la facilidad es '-' entonces dnsmasq
bitacorea a stderr. (Errores durante la lectura de la configuración
irán a syslog todavía, pero todo output desde un inicio exitoso, y todo
output mientras en ejecución, irá a este archivo exclusivamente.)
Al bitacorear a un archivo, dnsmasq cerrará y reabrirá el archivo al
recibir un SIGUSR2. Esto permite que el archivo de bitácora sea rotado
sin detener a dnsmasq.
.TP
.B --log-async[=<líneas>]
Habilitar bitacoréo asincrónico y opcionalmente fijar el límite de número
de líneas que serán enviadas a la coleta por dnsmasq cuando syslog está
lento. Dnsmasq puede bitacorear asincrónicamente: esto le permite continuar
funcionando sin ser bloqueado por syslog, y permite a syslog usar dnsmasq
para búsquedas DNS sin riesgo de tranque. Si la coleta de líneas de bitácora
se llena, dnsmasq bitacoreará el desbordamiento, y el número de mensajes
perdidos. El tamaño predeterminado de coleta es 5, un valor sano sería 5-25,
y un límite de 100 es impuesto.
.TP
.B \-x, --pid-file=<path>
Especificar un path alterno donde dnsmasq debe guardar su PID.
Normalmente es /var/run/dnsmasq.pid.
.TP
.B \-u, --user=<usuario>
Especificar el userid al cual dnsmasq debe cambiarse despues de iniciar.
Dnsmasq normalmente debe ser iniciado como root, pero soltará los
privilegios root despues del inicio, cambiando a otro usuario.
Normalmente este usuario es "nobody", pero eso se puede cambiar
con esta opción.
.TP
.B \-g, --group=<grupo> 
Especificar el grupo como el cual dnsmasq correrá. El predeterminado
es "dip", si está disponible, para facilitar el acceso a
/etc/ppp/resolv.conf el cuál normálmente no es globalmente leíble.
.TP
.B \-v, --version
Mostrar el número de versión.
.TP
.B \-p, --port=<puerto>
Escuchar en el puerto <puerto> en vez del puerto estándar DNS (53).
Fijar esto a cero deshabilita completamente la función DNS, dejando
solo DHCP y/o TFTP.
.TP
.B \-P, --edns-packet-max=<tamaño>
Especificar el paquete UDP EDNS.0 más grande que es soportado por
el reenviador DNS. Por predeterminado es 4096, lo cual es el
tamaño recomendado en RFC5625.
.TP
.B \-Q, --query-port=<puerto>
Enviar búsquedas outbound desde, y escuchar por respuestas en,
el puerto UDP <puerto> en vez de usar puertos aleatorios. Nótese
que usar esta opción hace que dnsmasq sea menos seguro contra
ataques de spoofing DNS, pero puede ser más rápido y usar menos
recursos.
Fijar esta opción a zero hace que dnsmasq use un solo puerto,
asignado por el sistema operativo (esto era el comportamiento
predeterminado en versiones anteriores a 2.43).
.TP
.B --min-port=<puerto>
No usar puertos menores a <puerto> como remitentes para búsquedas
DNS outbound. Dnsmasq escoje puertos aleatorios como remitentes
para búsquedas DNS outbound. Cuando esta opción es brindada, los
puertos usados siempre serán mayores que el especificado. Esto es
útil para sistemas detras de firewalls.
.TP
.B \-i, --interface=<nombre de interface>
Escuchar solo en las interfaces especificadas. Dnsmasq automáticamente
agrega la interface loopback a la lista de interfaces para usar cuando
la opción
.B \--interface
es usada. Si ninguna opción
.B \--interface
o
.B \--listen-address
es brindada, dnsmasq escucha en todas las interfaces disponibles excepto
cualquiera fijada con opciones
.B \--except-interface
Interfaces IP alias (por ejemplo, "eth1:0") no pueden ser utilizadas con
.B --interface
o
.B --except-interface
, usar --listen-address en vez.
.TP
.B \-I, --except-interface=<nombre de interface>
No escuchar en la interface especificada. Nótese que el orden de
las opciones
.B \--listen-address
.B --interface
y
.B --except-interface
no importa y las opciones
.B --except-interface
siempre invalidan a las otras.
.TP 
.B \-2, --no-dhcp-interface=<nombre de interface>
No proveer DHCP ni TFTP en la interface especificada, pero sí
proveer servicio DNS.
.TP
.B \-a, --listen-address=<dirección IP>
Escuchar en la(s) dirección(es) IP especificada(s). Las opciones
.B \--interface
y
.B \--listen-address
ambas pueden ser brindadas, y en tal caso el juego de ambas
direcciones IP y interfaces es usada. Nótese que si ninguna opción
.B \--interface
es brindada, pero sí se brinda la opción
.B \--listen-address
, entonces dnsmasq no escuchará automáticamente en la interface
loopback. Para obtener esto, su dirección IP, 127.0.0.1, debe ser
explícitamente brindada como una opción
.B \--listen-address
.TP
.B \-z, --bind-interfaces
En sistemas que inluyen el soporte, dnsmasq acopla la dirección
de comodín, aún cuando está escuchando solamente en algunas
interfaces. Entonces descarta búsquedas a las cuales no debe
responder. Esto tiene la ventaja de funcionar aún cuando
interfaces van y vienen y cambian direcciones. Esta opción forza
a dnsmasq a acoplarse realmente solo a las interfaces en
las cuales está escuchando. Casi la única vez que esto es útil
es cuando se está corriendo otro servidor DNS (o otra instancia
de dnsmasq) en la misma máquina. Fijar esta opción tambien
habilita multiples instancias de dnsmasq, las cuales proveen
servicio DHCP en la misma máquina.
.TP
.B \-y, --localise-queries
Retornar respuestas a búsquedas DNS desde /etc/hosts las cuales dependen
de la interface donde entró la búsqueda. Si un nombre en /etc/hosts tiene
mas de una dirección asociada con el, y por lo menos una de esas direcciones
está en la misma subred de la interface donde fue enviada, entónces
retornar solo las direcciones en esa subred. Esto permite a un servidor
tener direcciones múltiples en /etc/hosts correspondientes a cada una de
sus interfaces y cada host recibirá la respuesta adecuada
dependiendo de cual red tengan adjunta. Por el momento, esta facilidad
está limitada a IPv4.
.TP
.B \-b, --bogus-priv
Búsquedas privadas reversas raras. Toda búsqueda reversa para rangos de IP
privados (192.168.x.x, etc.) los cuales no se encuentren en
/etc/hosts o en el archivo de arriendos DHCP es respondida con
"dominio no existente" en vez de ser reenviada upstream.
.TP
.B \-V, --alias=[<IP viejo>]|[<IP inicio>-<IP final>],<IP nuevo>[,<máscara>]
Modificar direcciones IPv4 retornadas desde servidores DNS upstream;
<IP viejo> es remplazado con <IP nuevo>. Si la máscara opcional
es brindada, entonces cualquier dirección que coincida con el
<IP viejo> enmascarado será re-escrita. Así que, por ejemplo,
.B --alias=1.2.3.0,6.7.8.0,255.255.255.0 trazará 1.2.3.56 a 6.7.8.56
y 1.2.3.67 a 6.7.8.67. Esto es lo que
ruteadores Cisco PIX llaman "DNS doctoring". Si la dirección vieja es
brindada como un rango, entonces solo direcciones en ese rango, y no
la subred entera, son re-escritas. De tal manera que
.B --alias=192.168.0.10-192.168.0.40,10.0.0.0,255.255.255.0
relaciona 192.168.0.10->192.168.0.40 a 10.0.0.10->10.0.0.40
.TP
.B \-B, --bogus-nxdomain=<dirección IP>
Transformar respuestas que contienen la dirección IP brindada a
respuestas tipo "Dominio no existe". La intención de esto es actuar
en contra de una movida desviada hecha por Verisign en septiembre
del 2003, cuando comenzaron a retornar la dirección de un servidor
de publicidad en respuesta a búsquedas por nombres no registrados,
en vez de la correcta respuesta NXDOMAIN. Esta opción le dice a dnsmasq
que debe forjear la respuesta correcta cuando ve este comportamiento.
Para septiembre 2003 la dirección IP siendo retornada por Verisign
es 64.94.110.11
.TP
.B \-f, --filterwin2k
Algunas versiones de Windows hacen búsquedas DNS periódicas las cuales no
reciben respuestas sensibles desde el DNS público y pueden causar problemas
activando enlaces marcación-en-demanda. Esta opción filtra dichas búsquedas.
Las búsquedas filtradas son para registros tipo SOA y SRV, al igual que
tipo ANY donde el nombre pedido contiene _, para atrapar búsquedas LDAP.
.TP
.B \-r, --resolv-file=<archivo>
Leer las direcciones IP de servidores DNS upstream desde <archivo>,
en vez de /etc/resolv.conf. Para el formato de este archivo, ver
.BR resolv.conf (5)
Las únicas líneas relevantes a dnsmasq son las de servidores DNS. A
dnsmasq se le puede decir que revise más de un archivo resolv.conf,
el primer archivo especificado remplaza al predeterminado, y los
subsiguientes son agregados a la lista. Esto es solo
permitido al hacer polling; el archivo con la actual fecha
de modificación más nueva es el que será usado.
.TP
.B \-R, --no-resolv
No leer /etc/resolv.conf. Obtener los servidores DNS upstream solo
desde la línea de comandos o desde el archivo de configuración de
dnsmasq.
.TP
.B \-1, --enable-dbus
Permitir que la configuración de dnsmasq sea actualizada vía llamadas
de método DBus. La configuración que puede ser cambiada es servidores
DNS upstream (y dominios correspondientes) y limpieza de caché. Esta
opción requiere que dnsmasq haya sido compilado con soporte para DBus.
.TP 
.B \-o, --strict-order
Por predeterminado, dnsmasq enviará búsquedas a cualquiera de los
servidores upstream que conoce, y trata de favorecer servidores los
cuales sabe que están activos. Fijar esta opción forza a dnsmasq a
probar cada búsqueda con cada servidor estrictamente en el orden
que aparecen en /etc/resolv.conf
.TP
.B --all-servers
Por predeterminado, cuando dnsmasq tiene más de un servidor upstream
disponible, enviará búsquedas a solo un servidor. Fijar esta opción
forza a dnsmasq a enviar todas las búsquedas a todos los servidores
disponibles. La respuesta del servidor que responda primero será
devuelta al solicitante original.
.TP
.B --stop-dns-rebind
Denegar (y bitacorear) direcciones de servidores upstream que están
dentro de rangos IP privados. Esto bloquea un ataque donde un navegador
detrás de un firewall es usado para analizar máquinas en la red local.
.TP
.B --rebind-localhost-ok
Eximir a 127.0.0.0/8 de verificaciones de rebinding. Este rango de
direcciones es retornado por servidores de tiempo real tipo hoyo
negro, así que bloquearlo puede deshabilitar estos servicios.
.TP
.B  --rebind-domain-ok=[<domain>]|[[/<domain>/[<domain>/]
No detectar y bloquear dns-rebind en búsquedas a estos dominios. El
argumento puede ser o un dominio sencillo, o múltiples dominios
rodeados por '/', como el syntax de --server, por ejemplo
.B  --rebind-domain-ok=/dominio1/dominio2/dominio3/
.TP
.B \-n, --no-poll
No revisar periodicamente a /etc/resolv.conf en busca de cambios.
.TP
.B --clear-on-reload
Cuando sea que /etc/resolv.conf es re-leida, liberar el caché DNS.
Esto es útil cuando servidores DNS nuevos puedan tener datos diferentes
a los contenidos en el caché.
.TP
.B \-D, --domain-needed
Le dice a dnsmasq que no debe reenviar búsquedas para nombres sencillos,
sin puntos o partes de dominios, a servidores upstream. Si el nombre
no se conoce desde /etc/hosts o desde DHCP entonces una respuesta
"no encontrado" es devuelta.
.TP
.B \-S, --local, --server=[/[<dominio>]/[dominio/]][<dirección IP>[#<puerto>][@<IP de remitente>|<interface>[#<puerto>]]
Especificar la dirección IP de servidores upstream directamente. Fijar
esta opción no suprime la lectura de /etc/resolv.conf, use -R para
hacer eso. Si uno a más dominios opcionales son brindados, ese servidor
es usado solo para esos dominios y las búsquedas son hechas usando
el servidor especificado solamente. La intención de esto es para el
uso con servidores DNS privados: si usted tiene un servidor DNS en su
red el cual lidea con nombres de la forma
xxx.internal.thekelleys.org.uk en 192.168.1.1 entonces brindar la
opción
.B -S /internal.thekelleys.org.uk/192.168.1.1
enviará todas las búsquedas de máquinas internas a ese servidor DNS,
todas las demás búsquedas serán enviadas a los servidores en
/etc/resolv.conf. Una especificación de dominio en blanco,
.B //
tiene el significado especial de "solo nombres no calificados", o
sea nombres sin ningún punto en ellos. Un puerto no-estándar puede
ser especificado como parte de la dirección IP usando el caracter
#. Más de una opción -S es permitida, con partes de dominio o
dirección IP repetidas como sea necesario.

Dominios más específicos toman precedencia sobre los menos específicos,
así que:
.B --server=/google.com/1.2.3.4
.B --server=/www.google.com/2.3.4.5
enviará búsquedas por *.google.com hacia 1.2.3.4, excepto
*www.google.com, el cual irá a 2.3.4.5.

La dirección especial de servidor '#' significa "usar los servidores
estándares", así que
.B --server=/google.com/1.2.3.4
.B --server=/www.google.com/#
enviará búsquedas por *.google.com hacia 1.2.3.4, excepto
*www.google.com, el cual será reenviado de manera usual.

También se permite una opción -S la cual brinda un dominio pero
ninguna dirección IP; esto le dice a dnsmasq que un dominio es local
y puede responder a búsquedas desde /etc/hosts o DHCP pero nunca
deberá reenviar búsquedas en ese dominio a ningún servidor upstream.
.B local
es un sinónimo de
.B server
para hacer los archivos de configuración mas claros en este caso.

El string opcional despues del carácter @ le dice a dnsmasq como fijar
el remitente de las búsquedas hacia este servidor DNS. Debe ser una
dirección IP, la cual debe ser perteneciente a la máquina en la cual
corre dnsmasq, de forma contraria esta línea de servidor será bitacoreada
y después ignorada, o un nombre de interface. Si un nombre de interface
es brindado, entonces búsquedas hacia el servidor serán forzadas vía esa
interface; si una dirección IP es brindada, entonces la dirección de
remitente de las búsquedas será fijada a esa dirección.
La etiqueta query-port es ignorada para cualquier servidores que tengan
una dirección remitente especificada, pero el puerto puede ser
especificado directamente como parte de la dirección remitente. Forzar
búsquedas a una interface no está implementado en todas las plataformas
soportadas por dnsmasq.
.TP
.B \-A, --address=/<dominio>/[dominio/]<dirección IP>
Especificar una dirección IP para retornar por cualquier host en
los dominios brindados. Búsquedas en estos dominios nunca son
reenviadas, y siempre son respondidas con la dirección IP
especificada, la cual puede ser IPv4 o IPv6. Para brindar ambas
direcciones IPv4 y IPv6 para un dominio, usar opciones -A repetidas.
Nótese que /etc/hosts y arriendos DHCP invalidan esto para nombres
individuales. Un uso común para esto es redireccionar el dominio
doubleclick.net entero a algún servidor web local amigable para
evitar banners de publicidad. La especificación funciona de la misma
forma que con --server, con la facilidad adicional que /#/ coincide
con cualquier dominio. De tal forma, --address=/#/1.2.3.4 siempre
retornará 1.2.3.4 para cualquier búsqueda no respondida desde
/etc/hosts o DHCP y que no haya sido enviada a un servidor DNS
upstream por una directiva --server mas especifica.
.TP
.B \-m, --mx-host=<nombre mx>[[,<nombre de host>],<preferencia>]
Retornar un record llamado <mx name> apuntando hacia el nombre de
host brindado (opcionalmente), o el host especificado en la opción
--mx-target, o si esa opción no es brindada, el host en el cual
dnsmasq está corriendo. El predeterminado es útil para redireccionar
correo de sistemas en la red local hacia un servidor central. La
opción de preferencia es opcional, y su predeterminado es 1 si no
es brindada. Más de un record MX puede ser brindado para un host.
.TP 
.B \-t, --mx-target=<nombre de host>
Especificar el target predeterminado para el record MX devuelto
por dnsmasq. Ver --mx-host. Si --mx-target es brindado, pero no
--mx-host, entonces dnsmasq devuelve un record MX conteniendo
el target MX para búsquedas MX en el nombre de host de la máquina donde
dnsmasq está corriendo.
.TP
.B \-e, --selfmx
Retornar un record MX apuntándose a sí mismo para cada máquina local.
Máquinas locales son aquellas en /etc/hosts o con arriendos DHCP.
.TP 
.B \-L, --localmx
Retornar un record MX apuntando al host brindado por mx-target (o
la máquina donde dnsmasq está corriendo) para cada máquina local.
Máquinas locales son aquellas en /etc/hosts o con arriendos DHCP.
.TP
.B \-W, --srv-host=<_servicio>.<_prot>.[<dominio>],[<target>[,<puerto>[,<prioridad>[,<peso>]]]]
Retornar un record DNS SRV. Ver RFC2782 para detalles. Si no es
brindada, el dominio se predetermina a el brindado por
.B --domain.
El predeterminado para el dominio target está vacío, el predeterminado
para puerto es uno, y los predeterminados para peso y prioridad son cero.
Tener cuidado al transponer data desde archivos de zona BIND: los
números de puerto, peso, y prioridad están en un orden diferente. Más
de un record SRV para un servicio/dominio es permitido, todos los que
coincidan son retornados.
.TP
.B \-Y, --txt-record=<nombre>[[,<texto>],<texto>]
Retornar un récord DNS TXT. El valor del récord TXT es una serie de
strings, así que cualquier número puede ser incluido, dividido por
comas.
.TP
.B --ptr-record=<nombre>[,<target>]
Retornar un récord DNS PTR.
.TP
.B --naptr-record=<nombre>,<orden>,<preferencia>,<opciones>,<servicio>,<regexp>[,<remplazo>]
Retornar un récord DNS NAPTR, como especificado en RFC3403.
.TP
.B --cname=<cname>,<target>
Retornar un expediente CNAME que indica que <cname> es realmente <target>. Hay
limitaciones significativas en el target. Debe ser un nombre DNS que le es conocido
a dnsmasq desde /etc/hosts (o archivos hosts adicionales) o de DHCP. Si el target
no satisface este criterio, el cname entero es ignorado. El cname debe ser único,
pero es permisible tener más de un cname indicando el mismo target.
.TP
.B --interface-name=<nombre>,<interface>
Retornar un expediente DNS, asociando el nombre con la dirección primaria
en la interface brindada. Esta opción especifica un expediente tipo A
para el nombre brindado de la misma forma que una línea de /etc/hosts,
excepto que la dirección no es constante y es en vez tomada de la
interface brindada. Si la interface está deshabilitada, nó configurada,
o nó existente, un récord vacío es devuelto. El récord PTR relevante
tambien es creado, trazando la dirección de la interface a el nombre.
Más de un nombre puede ser asociado con una dirección de interface,
repitiendo la opción. En tal caso, la primera instancia es usada para
la traza reversa dirección-a-nombre.
.TP
.B \-c, --cache-size=<tamaño de caché>
Fijar el tamaño del caché de dnsmasq. El predeterminado es 150 nombres.
Fijar el tamaño a cero deshabilita el caché. Nota: el gran tamaño de
caché afecta el rendimiento.
.TP
.B \-N, --no-negcache
Deshabilitar caché negativo. El caché negativo le permite a dnsmasq
recordar resultados tipo "dominio no existe" desde servidores DNS
upstream y responder búsquedas idénticas sin reenviarlas nuevamente.
.TP
.B \-0, --dns-forward-max=<búsquedas>
Fijar el número máximo de búsquedas DNS simultáneas. El valor
predeterminado es 150, lo cuál debería estar bien para la mayoría
de casos. La única situación conocida donde esto debe ser incrementado
es al usar resolvedores de bitácoras de servidores web, los cuales pueden
generar un número inmenso de búsquedas simultáneas.
.TP
.B \-F, --dhcp-range=[interface:<interface>,][tag:<tag>[,tag:<tag>],][set:<tag],]<dirección-inicio>,<dirección-final>[,<netmask>[,<broadcast>]][,<tiempo de arriendo>]
Habilitar el servidor DHCP. Direcciones serán distribuidas desde el
rango <dirección-inicio> hasta <dirección-final> y desde direcciones definidas
estáticamente en opciones
.B dhcp-host
Si el tiempo de arriendo es especificado, entonces arriendos serán
otorgados por esa cantidad de tiempo. El tiempo de arriendo es en
segundos, o minutos (por ejemplo, 45m), u horas (por ejemplo, 1h), o
"infinite". Si no es brindada, el tiempo de arriendo predeterminado
es de una hora. El tiempo de arriendo mínimo es de dos minutos.
Esta opción puede ser repetida, con diferentes
direcciones, para habilitar servicio DHCP en más de una red. Para
redes conectadas diréctamente (en otras palabras, redes en las
cuales la máquina corriendo dnsmasq tiene una interface) la
máscara de subred es opcional. Pero, es requerida para redes que
reciben servicio DHCP vía un agente de relay. La dirección de
broadcast siempre es opcional. Siempre se permite tener más de
un rango dhcp (dhcp-range) en una subred.

El parámetro opcional
.B set:<tag>
fija una etiqueta alfanumérica la cual marca esta red de
tal forma que opciones dhcp puedan ser especificadas en base a cada red.
Cuando es prefijada con 'tag:' en vez, entonces el significado cambia
de "fijar etiqueta" a "coincidir con etiqueta". Solo una etiqueta puede
ser fijada, pero más de una puede ser revisada por coincidencias. La
dirección final puede ser remplazada por la palabra clave
.B static
la cual le dice a dnsmasq que debe habilitar DHCP para la red
especificada, pero no alocar dinámicamente direcciones IP:
Solo hosts que tienen direcciones estáticas brindadas vía
.B dhcp-host
o desde /etc/ethers serán servidas. La dirección final puede ser
remplazada por la palabra clave
.B proxy
caso en el cual dnsmasq proveerá proxy-DHCP en la subred especificada. (Ver
.B pxe-prompt
y
.B pxe-service
para detalles.)

La sección interface:<interface name> no es normalmente usada. Ver la
sección NOTAS para detalles sobre esto.
.TP
.B \-G, --dhcp-host=[<hwaddr>][,id:<client_id>|*][,set:<tag>][,<ipaddr>][,<hostname>][,<tiempo_de_arriendo>][,ignorar]
Especificar parámetros por host para el servidor DHCP. Esto permite
que una máquina con una dirección de hardware particular sea siempre
alocada el mismo nombre de host, dirección IP, y tiempo de arriendo.
Un nombre de host especificado de esta manera toma presedencia
sobre cualquiera suministrado por el cliente DHCP en la máquina.
También se permite omitir la direccion de hardware y incluir el
nombre de host; en tal caso la dirección IP y los tiempos de arriendo
serán aplicables a cualquier máquina que reclame ese nombre.
Por ejemplo:
.B --dhcp-host=00:20:e0:3b:13:af,wap,infinite
le dice a dnsmasq que debe darle a la máquina con dirección
ethernet 00:20:e0:3b:13:af el nombre wap, y un arriendo DHCP infinito.
.B --dhcp-host=lap,192.168.0.199
le dice a dnsmasq que siempre debe alocarle a la maquina lap
la dirección IP 192.168.0.199.

Direcciones alocadas de esta manera no tienen que estar dentro
del rango dado con la opción --dhcp-range, pero deben estar en la subred
de un rango DHCP (dhcp-range) válido. Para subredes que no necesitan
una collección de direcciones dinamicamente alocadas, usar la palabra
clave "static" in la declaración dhcp-range.

Es permitido usar identificadores de cliente en vez de direcciones de
hardware para identificar hosts prefijando 'id:'. O sea que:
.B --dhcp-host=id:01:02:03:04,.....
se refiere al host con identificador de cliente 01:02:03:04.
También se permite especificar el ID de cliente como texto, así:
.B --dhcp-host=id:iddeclientecomotexto,.....

La opción especial id:* significa "ignorar cualquier ID de cliente
y usar solamente direcciones MAC." Esto es útil cuando un cliente
presenta un ID de cliente algunas veces pero otras no.

Si un nombre aparece en /etc/hosts, la dirección asociada puede
ser alocada a un arriendo DHCP, pero solo si existe una opción
.B --dhcp-host
la cual especifica el nombre también. Solo un hostname puede ser
brindado en una opción
.B dhcp-host
pero aliases son posibles por medio del uso de CNAMEs. (Ver
.B --cname
).

La palabra clave "ignore"
le dice a dnsmasq que no debe ofrecer jamás un arriendo DHCP a
una máquina. La máquina puede ser especificada por dirección de
hardware, ID de cliente, o nombre de host, por ejemplo:
.B --dhcp-host=00:20:e0:3b:13:af,ignore
Esto es útil cuando hay otro servidor DHCP en la red que debe ser
usado por algúnas máquinas.

El set:<tag> fija la etiqueta cuando sea que
esta directiva dhcp-host está en uso. Esto puede ser usado para
enviar selectivamente opciones DHCP a este host. Más de una etiqueta
puede ser fijada en una directiva dhcp-host (pero no en otros lugares
donde "set:<tag>" es permitido). Cuando un host coincide con 
cualquier directiva dhcp-host (o una implicada por
/etc/ethers) entonces la etiqueta especial "known" es
fijada. Esto permite que dnsmasq sea configurado para ignorar
pedidos desde máquinas desconocidas usando
.B --dhcp-ignore=tag:!known
Direcciones ethernet (pero no client-ids) pueden tener bytes
comodínes, así que por ejemplo
.B --dhcp-host=00:20:e0:3b:13:*,ignore
causará que dnsmasq ignore un rango de direcciones ethernet. Nótese
que el "*" necesitará ser escapado o escrito entre comillas en la
línea de comandos, pero no en el archivo de configuración.

Direcciones de hardware normalmente coinciden con cualquier
tipo de red (ARP), pero es posible restringirlas a un tipo ARP
singular precediendolo con el tipo ARP (en HEX) y "-". Así que
.B --dhcp-host=06-00:20:e0:3b:13:af,1.2.3.4
solo coincidiría con una dirección de hardware Token-Ring, dado que
el tipo ARP para Token-Ring es 6.

Como caso especial, es posible incluir más de una dirección de
hardware. Ejemplo:
.B --dhcp-host=11:22:33:44:55:66,12:34:56:78:90:12,192.168.0.2
Esto permite que una dirección IP sea asociada con
direcciones de hardware múltiples, y le brinda a dnsmasq permiso
para abandonar un arriendo DHCP a una de las direcciones de hardware
cuando otra pide un arriendo. Nótese que esto es algo peligroso,
sólo funcionará dependiblemente si una de las direcciones de hardware
está activa en cualquier momento y dnsmasq no tiene forma de enforzar
esto. Pero es útil, por ejemplo, para alocar una dirección IP estable
a una laptop que tiene interface alámbrica e inalámbrica.
.TP
.B --dhcp-hostsfile=<archivo>
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.
.TP
.B --dhcp-optsfile=<archivo>
Leer información sobre opciones DHCP desde el archivo especificado. La
ventaja de usar esta opción es la misma que con --dhcp-hostsfile: el
archivo dhcp-optsfile será re-leído cuando dnsmasq recibe un SIGHUP.
Nótese que es posible colocar la información mediante
.B --dhcp-boot
como opciones DHCP, usando los nombres de opción bootfile-name,
server-ip-address, y tftp-server. Esto permite que sean incluidas en
un archivo dhcp-optsfile.
.TP
.B \-Z, --read-ethers
Leer /etc/ethers en busca de información sobre hosts para el servidor
DHCP. El formato de /etc/ethers es una dirección de hardware, seguida
por ya sea un nombre de host o una dirección IP. Al ser leidas por
dnsmasq, estas líneas tienen exáctamente el mismo efecto que opciones
.B --dhcp-host
que contienen la misma información. /etc/ethers es re-leída cuando
dnsmasq recibe un SIGHUP.
.TP
.B \-O, --dhcp-option=[tag:<tag>,[tag:<tag>,]][encap:<opt>,][vi-encap:<enterprise>,][vendor:[<vendor-class>],][<opt>|option:<opt-name>],[<value>[,<value>]]
Especificar opciones diferentes o extra a clientes DHCP. Por
predeterminado, dnsmasq envía algunas opciones estándar a clientes
DHCP. La máscara de subred y dirección broadcast son fijadas igual
a las del host que corre dnsmasq, y el servidor DNS y ruteador
a la dirección de la máquina que corre dnsmasq. Si la opción de
nombre de dominio ha sido fijada, es enviada. Esta opción permite
que esos predeterminados sean sobrescritos, o que sean especificadas
otras opciones. La opción a ser enviada puede ser brindada como un
número decimal o como "option:<option-name>". Los números de opción
están especificados en RFC2132 y RFCs subsiguientes. El juego de
option-names conocido por dnsmasq puede ser descubierto ejecutando
"dnsmasq --help dhcp". Por ejemplo, para fijar la ruta predeterminada a
192.168.4.4, hágase un
.B --dhcp-option=3,192.168.4.4
o
.B --dhcp-option=option:router, 192.168.4.4
y para fijar la dirección de servidor de tiempo a 192.168.0.4,
hágase un
.B --dhcp-option=42,192.168.0.4
o
.B --dhcp-option=option:ntp-server, 192.168.0.4
La dirección especial 0.0.0.0 es entendida que significa "la
dirección de la máquina que corre dnsmasq". Tipos de data permitidos
son direcciones IP de cuatro segmentos, un número decimal, dígitos hex
separados por colones, y un string de texto. Si las etiquetas
opcionales son brindadas, entonces esta opción es solo enviada cuando
todas las etiquetas coinciden.

Procesamiento especial es llevado a cabo en un argumento de texto para
la opción 119, en conforme con RFC3397. Direcciones IP textuales o de
cuatro segmentos como argumentos a la opción 120 son manejados mediante
RFC3361. Direcciones IP de cuatro segmentos que son seguidas por un diagonal
(slash) y después una máscara son codificados mediante RFC3442.

Tener cuidado: niguna verificación es hecha sobre si el número de tipo
correcto es enviado, y es muy posible persuadir a dnsmasq para que
genere paquetes DHCP ilegales mediante uso inadecuado de esta opción.
Cuando el valor es un número decimal, dnsmasq debe determinar qué tan
grande es el objeto de data. Esto es hecho mediante una examinación del
número de opción, y/o el valor, pero puede ser invalidado agregándole
una opción de una sola letra de esta forma: b = un byte, s = dos bytes,
i = cuatro bytes. Esto es principalmente útil con opciones encapsuladas
tipo vendedor (ver abajo) donde dnsmasq no puede determinar el tamaño
de data usando el número de opción. Data de opción la cual consiste
solo de puntos y dígitos será interpretada por dnsmasq como una
dirección IP, y será insertada dentro de una opción de esa manera.
Para forzar un string literal, usar comillas. Por ejemplo, cuando se
usa la opción 66 para enviar una IP literal como un nombre de servidor
TFTP, es necesario hacer:
.B --dhcp-option=66,"1.2.3.4"

Opciones encapsuladas vendor-class también pueden ser especificadas usando
--dhcp-option: por ejemplo
.B --dhcp-option=vendor:PXEClient,1,0.0.0.0
envía la opción específica de clase de vendedor "mftp-address=0.0.0.0" a
cualquier cliente cuyo vendor-class
coincida con "PXEClient". El revisado de coincidencias vendor-class está
basado en substrings (ver --dhcp-vendorclass para detalles). Si una opción
vendor-class (número 60) es enviada por dnsmasq, entonces es usada para
seleccionar opciones encapsuladas en preferencia sobre cualquiera enviada
por el cliente. Es posible omitir el vendorclass completamente;
.B --dhcp-option=vendor:,1,0.0.0.0
caso en el cuál la opción encapsulada siempre es enviada.
Opciones pueden ser encapsuladas dentro de otras opciones, por ejemplo:
.B --dhcp-option=encap:175, 190, "iscsi-client0"
enviará opción 175, dentro de la cual está opción 190. Si múltiples
opciones son brindadas que están encapsuladas con el mismo número de
opción entonces serán correctamente combinadas en una opción encapsulada.
encap: y vendor: no pueden ser fijadas ambas dentro de la misma opción dhcp-option.

La variante final en opciones encapsuladas es "Vendor-Identifying Vendor Options"
como especificado en RFC3925. Estos son denotados así:
.B --dhcp-option=rfc3925-encap:2, 10, "text"
El número en la sección rfc3925-encap: es el número enterprise usado
para identificar esta opción.

La dirección 0.0.0.0 no es tratada de forma especial en opciones encapsuladas.
.TP
.B --dhcp-option-force=[tag:<tag>,[tag:<tag>,]][encap:<opt>,][vi-encap:<enterprise>,][vendor:[<vendor-class>],]<opt>,[<value>[,<value>]]
Esto funciona exáctamente de la misma forma que
.B --dhcp-option
excepto que la opción siempre será enviada, aún si el cliente no la pide en
la lista de pedido de parámetros. Esto se necesita aveces, por ejemplo cuando
enviando opciones a PXELinux.
.TP
.B --dhcp-no-override
Deshabilitar la reutilización de los campos DHCP de nombre de servidor y
archivo como espacio para opciones extra. Si puede, dnsmasq mueve la información
del servidor boot y del nombre de archivo (de dhcp-boot) de sus campos dedicados
hacia opciones DHCP. Esto crea espacio extra en el paquete DHCP para opciones,
pero puede raramente confundir clientes viejos o defectuosos. Esta opción forza
comportamiento "simple y sencillo" para prevenir problemas en tales casos.
.TP
.B \-U, --dhcp-vendorclass=set:<tag>,<vendor-class>
Trazar desde un string vendor-class a una etiqueta. La mayoría de los
clientes DHCP proveen una "vendor class" la cual representa, en cierto
sentido, el tipo de host. Esta opción traza clases de vendedor a network
ids, de tal forma que opciones DHCP pueden ser selectivamente entregadas
a diferentes clases de hosts. Por ejemplo
.B dhcp-vendorclass=set:printers,Hewlett-Packard JetDirect
peritiría que opciones sean fijadas solo para impresoras HP así:
.B --dhcp-option=tag:printers,3,192.168.4.4
El string vendor-class es coordinado con el vendor-class proveido por
el cliente, para permitir coincidencias borrosas. El prefijo set: es
opcional, pero permitido por razones de consistencia.
.TP
.B \-j, --dhcp-userclass=set:<tag>,<user-class>
Trazar desde un string user-class a una etiqueta (con coordinación
substring, como con vendor-class). La mayoría de los clientes DHCP
proveen un "user class" el cual es configurable. Esta opción traza
clases user a network ids, de tal manera que opciones DHCP puedan
ser selectivamente enviadas a diferentes tipos de hosts. Es posible,
por ejemplo, usar esto para especificar una impresora diferente para
hosts en la clase "cuentas" que para los de la clase "ingenieria".
.TP
.B \-4, --dhcp-mac=set:<tag>,<MAC address>
Trazar desde una dirección MAC a una etiqueta. La dirección MAC
puede incluir comodínes. Por ejemplo:
.B --dhcp-mac=set:3com,01:34:23:*:*:*
fijaría el tag "3com" a cualquier host el cual su MAC coincida con
el patrón.
.TP
.B --dhcp-circuitid=<network-id>,<circuit-id>, --dhcp-remoteid=<network-id>,<remote-id>
Trazar de opciones agente de relay RFC3046 a etiquetas. Estos
datos pueden ser proveídos por agentes de relay DHCP. El circuit-id o
remote-id es normlamente brindado como hex separado por doblepuntos, pero
también se permite un string simple. Si se obtiene una coincidencia exacta
entre el circuit o agent ID y uno proveído por un agente de relay,
la etiqueta es fijada.
.TP
.B --dhcp-subscrid=set:<tag>,<subscriber-id>
Trazar de opciones relay subscriber-id RFC3993 a etiquetas.
.TP
.B --dhcp-proxy[=<ip addr>]......
Un agente de relay normal es usado solamente para reenviar las partes
iniciales de una interacción DHCP con el servidor DHCP. Una vez que
un cliente es configurado, se comunica diectamente con el servidor. Esto
es indeseable si el agente de relay está agregando información extra a
los paquetes DHCP, tal como usado por
.B dhcp-circuitid
y
.B dhcp-remoteid.
Una implementación relay completa puede usar la opción serverid-override
RFC 5107 para obligar al servidor DHCP a usar el relay como un proxy
completo, con todos los paquetes pasando a travez de el. Esta opción
provee una manera alternativa de hacer la misma cosa, para relays que
no tienen soporte RFC 5107. Brindada por si sola, manipula el server-id
para todas las interacciones via relays. Si una lista de IPs es brindada,
solo interacciones via relays en esas direcciones son afectadas.
.TP
.B --dhcp-match=set:<tag>,<option number>|option:<option name>|vi-encap:<enterprise>[,<value>]
Sin un valor, fijar la etiqueta si el cliente envía una opción
DHCP del número o valor brindado. Cuando un valor es brindado, fijar la
etiqueta solo si la opción es enviada y coincide con el valor. El valor puede
ser de la forma "01:ff:*:02", caso en el cual el valor debe coincidir (aparte
de los comodines) pero la opción enviada puede tener data que no coincide despues
del final del valor. El valor también puede ser de la misma forma que
.B dhcp-option
caso en el cual la opción enviada es tratada como un array, y un elemento debe
coincidir, así que

--dhcp-match=set:efi-ia32,option:client-arch,6

fijará la etiqueta a "efi-ia32" si el número 6 aparece en la lista de
architecturas enviada por los clientes en opción 93. (Ver RFC 4578 para
detalles.) Si el valor es un string, coincidencia substring es usada.

La forma especial con vi-encap:<enterpise number> busca coincidencia con
clases de vendedor identificadoras para el enterprise especificado. Por
favor ver RFC 3925 para mas detalles sobre estas bestias raras e interesantes.
.TP
.B --tag-if=set:<tag>[,set:<tag>[,tag:<tag>[,tag:<tag>]]]
Llevar a cabo operaciones boolean en etiquetas. Cualquier etiqueta
que aparece como set:<tag> es fijada si todas las etiquetas que aparecen
como tag:<tag> estan fijadas, (o desfijadas cuando tag:!<tag> es
usado). Si ningún tag:<tag> aparece, etiquetas set:<tag> son fijadas
incondicionalmente. Cualquier cantidad de formas set: y tag:
pueden aparecer, en cualquier orden. Líneas tag-if son ejecutadas
en orden, así que si la etiqueta en tag:<tag> es una etiqueta fijada
por otra
.B tag-if,
la línea que fija la etiqueta debe preceder a la que comprueba.
.TP
.B \-J, --dhcp-ignore=tag:<tag>[,tag:<tag>]
Cuando todoas las etiquetas brindadas aparecen en el juego de etiquetas
ignorar el host y no brindarle un arriendo DHCP.
.TP
.B --dhcp-ignore-names[=tag:<tag>[,tag:<tag>]]
Cuando todos las etiquetas brindadas aparecen en el juego de etiquetas, ignorar cualquier nombre de host proveido por el host. Nótese que,
a diferencia de dhcp-ignore, es permisible no brindar ninguna etiqueta,
y en tal caso nombres de host proveidos por clientes DHCP siempre son
ignorados, y hosts DHCP son agregados al DNS usando solo la configuración
dhcp-host en dnsmasq y el contenido de /etc/hosts y /etc/ethers.
.TP
.B --dhcp-generate-names=tag:<tag>[,tag:<tag>]
Generar un nombre para clientes DHCP que de otra forma no tienen uno,
usando la dirección MAC expresada en hex, separada por guiones. Nótese
que si un host provee un nombre, será usado preferiblemente sobre este,
a menos que
.B --dhcp-ignore-names
esté fijado.
.TP
.B --dhcp-broadcast[=tag:<tag>[,tag:<tag>]]
Cuando todas las etiquetas aparecen en el juego de etiquetas, siempre
usar broadcast para comunicar con el host cuando no está configurado.
Es permisible omitir las etiquetas, caso en el cual esto es
incondicional. La mayoría de clientes DHCP que necesitan
respuestas broadcast fijan una opción en sus pedidos para que esto pase automaticamente, algunos clientes BOOTP viejos no lo hacen.
.TP
.B \-M, --dhcp-boot=[tag:<tag>,]<filename>,[<servername>[,<server address>]]
Fijar opciones BOOTP que han de ser devueltas por el servidor DHCP. Nombre
y dirección de servidor son opcionales: si no son brindadas, el nombre es
dejado en blanco, y la dirección es fijada a la de la máquina que corre
dnsmasq. Si dnsmasq está brindando servicio TFTP (ver
.B --enable-tftp
) entonces solo el nombre de archivo es requirido aquí para habilitar
el inicio atravéz de una red. Si las opcionales etiquetas son brindadas,
ellas deberán coincidir para que esta configuración sea enviada. Nótese
que network-ids están prefijadas con "net:" para distinguirlas.
.TP
.B --pxe-service=[tag:<tag>,]<CSA>,<menu text>[,<basename>|<bootservicetype>][,<server address>]
La mayoría de usos para boot-ROMS PXE simplemente permiten al sistema PXE
obtener una dirección IP y entonces bajar el archivo especificado por
.B dhcp-boot
y ejecutarlo. Sin embargo, el sistema PXE es capaz de llevar
a cabo funciones más complejas cuando están soportadas por un
servidor DHCP adecuado.

Esto especifica una opción boot que puede aparecer en un menú de boot
PXE. <CSA> es tipo de sistema de cliente, solo servicios del tipo correcto
aparecerán en un menú. Los tipos conocidos son x86PC, PC98, IA64_EFI,
Alpha, Arc_x86, Intel_Lean_Client, IA32_EFI, BC_EFI, Xscale_EFI y X86-64_EFI;
un número entero puede ser utilizado para otros tipos. El parámetro después
del texto de menú puede ser un nombre de archivo, caso en el cuál dnsmasq
actúa como un servidor boot y le ordena al cliente PXE bajar el archivo
vía TFTP, ya sea de sí mismo (
.B enable-tftp
debe estar fijado para que esto funcione) o desde otro servidor TFTP si la
dirección IP final es brindada.
Nótese que el sufijo "layer" (normalmente ".0") es brindado por PXE, y
no debe ser agregado al nombre base. Si un número entero es brindado en vez
de un nombre base, entonces el cliente PXE buscará un servicio boot adecuado
para ese tipo de red. Esta búsqueda puede ser hecha mediante broadcast,
o directamente a un servidor si la dirección IP es brindada. Si ningún tipo
de servicio boot o nombre de archivo es brindado (o un tipo de servicio boot
de 0 es especificado), entonces la opción de menú abortará el proceso net boot
y continuará desde el medio local.
.TP
.B --pxe-prompt=[tag:<tag>,]<prompt>[,<timeout>]
Fijar esto hace que un aviso sea expuesto despues del boot PXE. Si el timeout
es brindado, entonces despues que el timeout se haya vencido sin input del
teclado, la primera opción del menú sera automaticamente ejecutada. Si el
timeout es cero entonces la primera opción del menú sera automaticamente
ejecutada. Si
.B pxe-prompt
es omitido, el sistema esperará para el input del usuario si hay múltiples
artículos en el menú, pero hará boot imediatamente si hay solo uno. Ver
.B pxe-service
para detalles sobre artículos de menu.

Dnsmasq tiene soporte para "proxy-DHCP" PXE, en este caso otro servidor
DHCP en la red es responsable por asignar direcciones IP, y dnsmasq
simplemente provee la dirección brindada en
.B pxe-prompt
y
.B pxe-service
para permitir boot a travez de la red. Este modo es habilitado usando
la palabra clave
.B proxy
en
.B dhcp-range.
.TP
.B \-X, --dhcp-lease-max=<número>
Limita a dnsmasq a el número especificado de arriendos DHCP. El
predeterminado es 1000. El limite es para prevenir ataques DoS desde
hosts que crean cientos de arriendos y usan mucha de la memoria del
proceso dnsmasq.
.TP
.B \-K, --dhcp-authoritative
Esta opción debe ser fijada cuando dnsmasq es definitivamente el único
servidor DHCP en la red. Cambia el comportamiento de RFC de tal manera
que pedidos desde hosts no conocidos no serán ignorados. Esto permite que
hosts nuevos puedan conseguir un arriendo sin sin un timeout bajo toda
circunstancia. También permite que dnsmasq reconstruya su base de datos
de arriendos sin que cada cliente necesite readquirir un arriendo
si la base de datos es perdida.
.TP
.B --dhcp-alternate-port[=<puerto de servidor>[,<puerto de cliente>]]
Cambiar del predeterminado los puertos usados para DHCP. Si esta opción
es brindada sola, sin argumentos, cambia los puertos usados para DHCP
de 67 y 68 a 1067 y 1068. Si un solo argumento es brindado, ese puerto
es usado para el servidor y el número de puerto mas uno es usado
para el cliente. Finalmente, dos números permiten que se especifiquen
ambos los puertos de servidor y cliente para DHCP.
.TP
.B \-3, --bootp-dynamic[=<network-id>[,<network-id>]]
Habilitar alocación dinámica de direcciones IP a clientes BOOTP. Usar
esto con cuidado, ya que cada dirección alocada a un cliente BOOTP
es arrendada para siempre, y consecuentemente queda no-disponible
para re-uso por otros hosts. Si esto es brindado sin etiquetas,
entonces incondicionalmente habilita alocación dinámica. Con
etiquetas, solo cuando todas las etiquetas están fijadas. Puede
ser repetido con diferentes juegos de etiquetas.
.TP
.B \-5, --no-ping
Por predetermindado, el servidor DHCP tratará de asegurarse que una
dirección no esté en uso antes de alocarsela a un host. Hace esto
enviando un echo ICMP (ping) a la dirección referente. Si recibe una
respuesta, entonces la dirección debe estar siendo usada, y se repite
la prueba con otra. Esta opción deshabilita esta prueba. Usar con
cuidado.
.TP
.B --log-dhcp
Bitacoréo extra para DHCP: Bitacorear todas las opciones enviadas a
clientes DHCP y las etiquetas usadas para determinarlos.
.TP
.B \-l, --dhcp-leasefile=<path>
Usar el archivo especificado para almacenar información de arriendos
DHCP.
.TP
.B \-6 --dhcp-script=<path>
Cuando un arriendo DHCP nuevo es creado, o uno viejo es
destruido, el ejecutable especificado por esta opción es ejecutado.
<path> debe ser un pathname absoluto, ninguna búsqueda PATH ocurre.
Los argumentos para el binario son "add", "old", o "del", la dirección
MAC del host, la dirección IP, y el hostname, si es
conocido. "add" significa que un arriendo ha sido creado, "del" que
ha sido destruido, y "old" es una notificación de un arriendo existente
cuando dnsmasq inicia o un cambio a una MAC o nombre host de un arriendo
existente (también, tiempo de arriendo o vencimiento y client-id, si
leasefile-ro está fijado). Si la dirección MAC es de un tipo de red
que no es ethernet, tendrá el tipo de red precolocado, por ejemplo
"06-01:23:45:67:89:ab" para token ring. El proceso es ejecutado como root
(asumiendo que dnsmasq fue originalmente ejecutado como root) aún si dnsmasq
está configurado para cambiar su UID a un usuario sin privilegios.


El ambiente es heredado del usuario que ha invocado a dnsmasq, con algunas
o todas de las siguientes variables agregadas.

DNSMASQ_CLIENT_ID si el host brindo un client-id.

DNSMASQ_DOMAIN si el nombre de dominio completamente calificado del host
es conocido, esto es fijado a la parte del dominio.

Si el cliente brinda vendor-class, hostname o user-class, estos son
brindados en las variables
DNSMASQ_VENDOR_CLASS, DNSMASQ_SUPPLIED_HOSTNAME, y
DNSMASQ_USER_CLASS0..DNSMASQ_USER_CLASSn, pero solo para acciones "add"
y "old" cuando un host reanuda un arriendo existente, dado a que estos
datos no son almacenados en la base de datos de arriendos de dnsmasq.

Si dnsmasq fue compilado con HAVE_BROKEN_RTC, entonces la duración del
arriendo (en segundos) es almacenada en DNSMASQ_LEASE_LENGTH, de otra
manera el tiempo de vencimiento es almacenado en DNSMASQ_LEASE_EXPIRES.
El número de segundos faltante para el vencimiento del arriendo siempre
es almacenado en DNSMASQ_TIME_REMAINING.

Si un arriendo solía tener un nombre de host, el cual es removido, un
evento "old" es generado con el nuevo estado del arriendo, (por ejemplo, sin
nombre), y el nombre anterior es brindado en la variable de ambiente
DNSMASQ_OLD_HOSTNAME.

DNSMASQ_INTERFACE almacena el nombre de la interface
en la cual llegó el pedido; esto no es fijado para acciones "viejas"
cuando dnsmasq re-inicia.

DNSMASQ_RELAY_ADDRESS es fijado si el cliente
usó un relay DHCP para contactar a dnsmasq y la dirección IP del relay
es conocida.

DNSMASQ_TAGS contiene todas las etiquetas network-id fijadas
durante la transacción DHCP, separadas por espacios.

Todos los descriptores de archivo están cerrados
excepto stdin, stdout, y stderr los cuales están abiertos a /dev/null
(excepto en modo debug).

Este guión no es invocado concurrentemente: máximo una instamcia del
guión está corriendo a la vez (dnsmasq espera a que una instancia de
guión haga exit antes de correr la siguiente). Cambios a la base de
datos de arriendos que requieren que el guión sea invocado son puestos
en cola esperando el exit de una instancia corriente. Si esta cola permite
que cambios multiples de estado le ocurran a un arriendo individual antes
de que el guión pueda ser ejecutado entonces estados anteriores son descartados
y el estado actual del arriendo es reflejado cuando el guión finalmente corre.

Al inicio de dnsmasq, el guión
será invocado para todos los arriendos existentes mientras van siendo
leídos desde el archivo de arriendos. Arriendos vencidos serán llamados
con "del" y otros con "old". <path> debe ser un path absoluto, ninguna
búsqueda PATH ocurre cuando arriendos dnsmasq serán llamados con "del"
y otros con "old". Cuando dnsmasq recibe una señal HUP, el guión será
invocado para arriendos existentes con un evento "old".
.TP
.B --dhcp-scriptuser
Especificar el usuario como el cual se debe correr el archivo
guión de cambio de arriendos. Este es root por predeterminado,
pero puede ser cambiado a otro usuario mediante esta opción.
.TP
.B \-9, --leasefile-ro
Suprimir completamente el uso del archivo de arriendos. El archivo no será
creado, leído, ni escrito. Cambiar la manera en la cuál el archivo guión de
cambio de arriendo (si es brindado) es llamado, de tal forma que la base de
datos de arriendospueda ser mantenida en almacenaje externo por el archivo
guión. Adicionálmente a las invocaciones brindadas en
.B --dhcp-script
el archivo de cambio de arriendos es llamado una vez, al inicio de dnsmasq,
con el único argumento "init". Cuando invocado de esta forma, el guión debería
escribir el estado guardado de la base de datos de arriendos, en formato de
archivo de arriendos dnsmasq, a stdout y hacer exit con código exit cero. Fijar
esta opción también forza que el archivo de cambio de arriendos sea llamado
cuando hay cambios hechos a el client-id y tiempos de arriendo y vencimiento.
.TP
.B --bridge-interface=<nombre de interface>,<alias>[,<alias>]
Tratar paquetes de pedidos DHCP (v4 y v6) y de IPv6 Router Solicit que
llegan a cualquiera de las interfaces <alias> como si hubieran llegado
a la interface <nombre de interface>.  Esta opción permite que dnsmasq
puede proporcionar los servicios DHCP y RA a través de interfaces
ethernet sin dirección y sin puente; por ejemplo en un nodo de cálculo
de OpenStack, donde cada una de esas interfaces es una interfaz TAP
para una máquina virtual, o al usar bridging estilo viejo en
plataformas BSD.
.TP
.B \-s, --domain=<dominio>[,<rango de IPs>]
Especifica los dominios DNS para el servidor DHCP. Dominios pueden ser
brindados incondicionalmente (sin el rango de IPs) o para rangos limitados. Esto
tiene dos efectos: Primeramente, causa que el servidor DHCP le devuelva el
dominio a cualquier host que lo pida. Segundamente, fija el dominio para el
cual es legal para hosts configurados mediante DHCP reclamar. La intención es
restringir nombres de host para que un host no-confiado en la LAN no
pueda proclamar su nombre vía DHCP, como por ejemplo "microsoft.com" y
capturar tráfico no destinado a ella. Si ningún sufijo de dominio es
especificado, entonces cualquier nombre de host con una parte de dominio
(o sea con un punto) será negada y bitacorada. Si un sufijo es especificado,
entonces nombres de host con una parte de dominio son permitidos, con tal
que la parte de dominio coincida con el sufijo. Adicionalmente, cuando
un sufijo es fijado, entonces nombres de host sin parte de dominio tienen
el sufijo agregado como una parte de dominio opcional. Por ejemplo, en
mi red puedo fijar
.B --domain=thekelleys.org.uk
y tener una maquina cuyo nombre host DHCP es "laptop". La dirección IP
de esa máquina es disponible desde
.B dnsmasq
como "laptop" y "laptop.thekelleys.org.uk". Si el dominio es brindado
como "#" entonces el dominio es leido desde la primera directiva search
en /etc/resolv.conf (o equivalente). El rango de direcciones puede ser
<dirección IP>,<dirección IP> or <dirección IP>/<máscara de subred>. Ver
.B --dhcp-fqdn el cual puede cambiar el comportamiento de dnsmasq con
dominios.
.TP
.B --dhcp-fqdn
En el modo predeterminado, dnsmasq pone los nombres no-calificados
de clientes DHCP en el DNS. Por esta razón, los nombres deben ser únicos,
aún si dos clientes que tienen el mismo nombre están en dominios
diferentes. Si un segundo cliente DHCP aparece el cual tiene el mismo
nombre que un cliente existente, el nombre es transferido al cliente nuevo. Si
.B --dhcp-fqdn
está fijado, este comportamiento cambia: El nombre no-calificado
no es puesto en el DNS, solo el nombre calificado. Dos clientes DHCP con
el mismo nombre pueden ambos quedarse con el nombre, con tal que la parte
de dominio sea diferente (o sea que los nombres completamente calificados
difieran). Para asegurar que todos los nombres tengan una parte de dominio,
debe haber al menos
.B --domain
sin una dirección especificada cuando
.B --dhcp-fqdn
está fijado.
.TP
.B --enable-tftp[=<interface>]
Habilitar la función de servidor TFTP. Esto está deliberadamente limitado
a lo necesario para hacerle a un cliente un inicio vía red. Solo lectura es
permitida; las extensiones tsize y blksize son soportadas (tsize solo es
soportada en modo octeto). Ver sección de NOTAS para el uso de el argumento
de interface.
.TP
.B --tftp-root=<directory>[,<interface>]
Buscar, relativo al directorio brindado, archivos para transferir mediante el
uso de TFTP. Cuando esta opción está fijada, paths TFTP que incluyen ".." son
rechazados, para prevenir que clientes salgan de la raíz especificada. Paths
absolutos (los que comienzan con "/") están permitidos, pero deben estar
dentro del tftp-root. Si el argumento opcional de interface es brindado, el
directorio es solo usado para pedidos TFTP vía esa interface.
.TP
.B --tftp-unique-root
Agregar la dirección IP del cliente TFTP como un componente path del lado del
TFTP-root (en formato estándar de cuatro puntos). Solo válido si un tftp-root
está fijado y el directorio existe. Por ejemplo, si tftp-root es "/tftp" y el
cliente 1.2.3.4 pide el archivo "miarchivo" entonces el path efectivo será
"/tftp/1.2.3.4/miarchivo" si /tftp/1.2.3.4 existe o /tftp/miarchivo si no.
.TP
.B --tftp-secure
Habilitar modo TFTP seguro: sin esto, cualquier archivo que es leíble por el
proceso dnsmasq bajo reglas normales de control de acceso UNIX, está disponible
vía TFTP. Cuando la opción --tftp-secure es fijada, solo archivos
pertenecientes al usuario que corre el proceso dnsmasq están accesibles. Si
dnsmasq está corriendo como root, reglas diferentes aplican: --tftp-secure no
tiene ningún efecto, pero solo archivos que tienen el bit de lectura global
fijados están accesibles. No se recomienda correr dnsmasq como root con TFTP
habilitado, y mucho menos sin especificar --tftp-root, ya que se puede exponer
cualquier archivo de lectura global en el servidor a cualquier host de la red.
.TP
.B --tftp-max=<conecciones>
Fijar el número máximo permitido de conecciones TFTP simultáneas. Esto es 50
por predeterminado. Al servir un número grande de conecciones TFTP, límites
de descriptor de archivo por proceso pueden ser encontrados. Dnsmasq necesita
un descriptor de archivo por cada coneccion TFTP concurrente, y por archivo
único (mas algunos otros). De tal manera que servirle el mismo archivo
simultáneo a n clientes requerirá el uso de n + 10 descriptores de archivo,
y servirles archivos diferentes simultáneamente requerirá (2*n) + 10
descriptores. Si
.B --tftp-port-range
es brindado, eso puede afectar el número de conexiones simultáneas.
.TP
.B --tftp-no-blocksize
No permitir que el servidor negocie la opción "blocksize" con un cliente.
Algunos clientes con errores piden esta opción pero se portán mal cuando se
les brinda.
.TP
.B --tftp-port-range=<inicio>,<final>
Un servidor TFTP escucha por inicios de conexión en un puerto bien conocido
(69), pero tambien usa un puerto dinamicamente seleccionado para cada
conexión. Normalmente estos son seleccionados por el sistema operativo,
pero esta opción especifica un rango de puertos para ser usado por transferencias
TFTP. Esto puede ser útil cuando TFTP tiene que pasar atraves de un firewall.
El comienzo del rango no puede ser menor a 1025 a menos que dnsmasq esté corriendo
como root. El número de conexiones simultáneas está limitado por el tamaño del
rango de puertos.
.TP
.B \-C, --conf-file=<archivo>
Especificar un archivo de configuración diferente. La opción conf-file
también es permitida en archivos de configuración, para incluir múltiples
archivos de configuración.
.TP
.B \-7, --conf-dir=<directorio>[,<file-extension>......]
Leer todos los archivos dentro del directorio brindado como archivos
de configuración. Si extensiones son brindadas, cualquier archivo que
termine en esas extensiones son ignorados. Cualquier archivos cuyos nombres
terminen con ~ o comienzen con . o comienzen y terminen con # siempre son
ignorados. Esta opción puede ser brindada en la línea de comandos o en un
archivo de configuración.
.SH ARCHIVO DE CONFIGURACION
Al inicio, dnsmasq lee
.I /etc/dnsmasq.conf,
si existe. (En FreeBSD, el archivo es
.I /usr/local/etc/dnsmasq.conf
) (pero ver las opciónes
.B \-C
y
.B \-7
porfavor.) El formato de este archivo consiste de una opción por línea,
exáctamente como las opciones largas detalladas en la sección OPCIONES
pero sin el "--" al frente. Líneas que comienzan con # son comentarios
y son ignoradas. Para opciones que solo pueden ser especificadas una
sola vez, el archivo de configuración invalida la línea de comandos.
Las comillas son permitidas en el archivo de configuración: entre comillas
tipo " los significados especiales de ,:. y # son eliminados y los
siguientes escapes son permitidos: \\\\ \\" \\t \\e \\b \\r y \\n.
Corresponden a tab, escape, backspace, return y newline.
.SH NOTAS
Al recibir un SIGHUP
.B dnsmasq 
libera su cache y entonces recarga
.I /etc/hosts
y
.I /etc/ethers
al igual que cualquier archivo brindado con --dhcp-hostsfile, --dhcp-optsfile,
o --addn-hosts.
El archivo guión de cambio de arriendos es llamado para todos los arriendos
DHCP existentes. Si
.B
--no-poll
está fijado entonces SIGHUP también re-lee
.I /etc/resolv.conf.
SIGHUP
NO re-lee el archivo de configuración.
.PP
Al recibir un SIGUSR1,
.B dnsmasq 
escribe estadísticas a la bitácora del sistema. Escribe el tamaño
del caché, el numero de nombres que han tenido que ser removidos del
caché antes de que vencieran para hacer espacio para nombres nuevos, y el
número total de nombres que han sido insertados en el caché. Para cada
servidor upstream brinda el número de búsquedas enviadas, y el
número que resultaron en error. En modo
.B --no-daemon
o cuando bitacoréo completo está habilitado (-q), una descarga completa de
el contenido del caché es hecha.
.PP
Cuando recibe un SIGUSR2 y está bitacoreando diréctamente a un archivo (ver
.B --log-facility
)
.B dnsmasq
cerrará y reabrirá el archivo de bitácora. Nótese que durante esta
operación, dnsmasq no estará corriendo como root. Al crear el archivo de
bitácora, dnsmasq cambia el dueño del archivo a el usuario normal como
el que correrá. Logrotate debe ser configurado para crear un archivo de
bitácora nuevo con permisos iguales al existente, antes de enviar
SIGUSR2. Si búsquedas DNS TCP están en progreso, el archivo de bitácora
viejo se mantendrá abierto en procesos hijos que están manejando
búsquedas TCP, y puede continuarse a escribirle. Hay un límite de 150
segundos, después de lo cual todos los procesos TCP existentes se habrán
vencido: por esta razón, no es sabio configurar compresión de archivos
de bitácora para archivos que acaban de ser rotados. Con logrotate, las
opciones requeridas son
.B create
y
.B delaycompress.
.PP
Dnsmasq es un reenviador de búsquedas DNS: no puede responder búsquedas
arbitrarias comenzando desde los servidores root pero reenvía dichas
búsquedas a un servidor DNS recursivo, el cual es típicamente proveído
por el proveedor de Internet. Por predeterminado, dnsmasq lee
.I /etc/resolv.conf
para descubir las direcciones IP de los servidores DNS upstream que
debe usar, dado a que esta información es normalmente almacenada allí.
Amenos que
.B --no-poll
sea usado,
.B dnsmasq
revisa el tiempo de modificación de
.I /etc/resolv.conf
(o equivalente si
.B \--resolv-file 
es usado) y lo re-lee si ha cambiado. Esto permite que servidores DNS séan
fijados dinámicamente vía PPP o DHCP ya que ambos protocolos brindan esta
información.
La ausencia de
.I /etc/resolv.conf
no es un error ya que pudo haber sido creada antes de que una conexión PPP
haya existido. Dnsmasq simplemente sigue revisando en caso de que
.I /etc/resolv.conf 
sea creado en algún momento. A dnsmasq se le puede decir que revise más
de un archivo resolv.conf. Esto es útil en una laptop, donde ambos PPP y
DHCP podrían estar siendo usados: dnsmasq puede ser fijado para revisar ambos
.I /etc/ppp/resolv.conf 
y
.I /etc/dhcpc/resolv.conf 
y usará el contenido del que haya cambiado mas recientemente,
brindando así la habilidad de cambio automático entre servidores DNS.
.PP
Servidores upstream también pueden ser especificados en la línea de
comandos o en el archivo de configuración. Estas especificaciones de
servidor opcionalmente llevan un nombre de dominio el cual le dice a
dnsmasq que debe usar ese servidor solo para encontrar nombres en ese
dominio en particular.
.PP
Para configurar dnsmasq como caché para el host donde está
corriendo, poner un "nameserver 127.0.0.1" en
.I /etc/resolv.conf
para así forzar procesos locales a enviar búsquedas a dnsmasq. Entonces,
o especificar los servidores upstream diréctamente a dnsmasq usando opciones
.B \--server
o poniendo sus direcciones reales en otro archivo, digamos
.I /etc/resolv.dnsmasq
y correr dnsmasq con la opcion
.B \-r /etc/resolv.dnsmasq
Esta segunda técnica permite la actualización dinámica de las direcciones
de servidor mediante PPP o DHCP.
.PP
Direcciones en /etc/hosts "harán sombra" a diferentes direcciones para
los mismos nombres en servidores DNS upstream, así que
"miempresa.com 1.2.3.4" en /etc/hosts se asegurará que las búsquedas
por "miempresa.com" siempre retornarán 1.2.3.4 aún si búsquedas en el
servidor DNS upstream devolverían una dirección diferente. Hay una
excepción a esto: si el servidor DNS upstream contiene un CNAME que
apunta a un nombre sombreado, entonces buscando el CNAME a travéz de
dnsmasq resultará en que la dirección no-sombreada será asociada con
el destino del CNAME. Para circumventar esto, agregar el CNAME a
/etc/hosts de tal manera que el CNAME es sombreado también.

.PP
El sistema de etiquetas funciona de la siguiente manera: Para cada pedido
DHCP, dnsmasq colecciona un juego de etiquetas válidas de líneas de
configuración activas que incluyen set:<tag>, incluyendo una del
.B dhcp-range
usado para alocar la dirección, una de cualquier
.B dhcp-host
que coincida (y "known" si un dhcp-host coincide).
La etiqueta "bootp" es fijada para pedidos BOOTP, y una etiqueta cuyo
nombre es el nombre de la interface donde llegó el pedido tambien es
fijada.

Cualquier linea de configuración que incluya uno o mas
construcciones tag:<tag> solo será válida si todas las etiquetas
coinciden en el juego derivado arriba. Típicamente esto es dhcp-option.
.B dhcp-option 
que tenga etiquetas será usada en preferencia de una opción
.B dhcp-option,
sin etiqueta, con tal que _todas_ las etiquetas coincidan en alguna
parte del juego coleccionado describido arriba. El prefijo '!' en una
etiqueta significa "no" así que --dhcp=option=tag:!purple,3,1.2.3.4 envía
la opción cuando la etiqueta "purple" no está en el juego
de etiquetas válidas. (Si se está usando esto en una línea de comandos
en vez de un archivo de configuración, asegurese de escapar !, el cual
es un metacaracter de shell.)
.PP
Nótese que para
.B dhcp-range
ambos tag:<tag> y set:<tag> son permitidos, para seleccionar el rango
en uso basado en (por ejemplo) dhcp-host, y para afectar las opciones
enviadas, basadas en el rango seleccionado.

Este sistema evolucionó de uno anterior mas limitado y para compatibildad
reversa "net:" puede ser usada en vez de "tag:" y "set:" puede ser
omitida. (Excepto en
.B dhcp-host,
donde "net:" puede ser usado en vez de "set:".) Por la misma razón, '#'
puede ser usado en vez de '!' para indicar NO.
.PP
El servidor DHCP de dnsmasq funcionará como servidor BOOTP tambien,
con tal que las direcciones MAC y IP de los clientes sean brindadas,
ya sea usando configuraciones
.B dhcp-host 
o en
.I /etc/ethers
, y una configuración
.B dhcp-range 
esté presente para activar el servidor DHCP en una red particular.
(Fijar --bootp-dynamic elimina la necesidad de trazados estáticos.) El
parámetro de nombre de archivos en un pedido BOOTP es usado como
una etiqueta, al igual que la etiqueta "bootp", permitiendo así algún
control sobre las opciones devueltas a diferentes clases de hosts.

.B dhcp-range
puede tener un nombre de interface brindado como
"interface:<interface-name>". La semántica de esto es así:
Para DHCP, si cualquier otro dhcp-range existe _sin_ un nombre de
interface, entonces el nombre de interface es ignorado y dnsmasq
se comporta como si las partes de interface no existieran, de otra forma
DHCP solo se provee a interfaces mencionadas en declaraciones
dhcp-range. Para DNS, si no hay opciones
.B --interface
o
.B --listen-address
el comportamiento no se modifica por la parte de interface. Si cualquiera
de estas opciones está presente, las interfaces mencionadas en dhcp-ranges
son agregadas all juego que obtienen servicio DNS.

Similarmente,
.B enable-tftp
puede tomar un nombre de interface, el cual habilita TFTP solo para una
interface en particular, ignorando opciones
.B --interface
o
.B --listen-address.
Adicionalmente, 
.B --tftp-secure
y
.B --tftp-unique-root
y
.B --tftp-no-blocksize
son ignorados por pedidos desde dichas interfaces. (Una directiva
.B --tftp-root
brindando un path raíz y una interface debe ser brindada tambien.)

Estas reglas pueden parecer raras a primera vista, pero permiten que
una simple linea de la forma
"dhcp-range=interface:virt0,192.168.0.4,192.168.0.200" sea agregada a
configuración dnsmasq, lo cual brinda servicios DHCP y DNS a esa interface,
sin afectar los servicios en otras interfaces y irrespectivamente de
la existencia o no de lineas "interface=<interface>" en alguna otra parte
de la configuración dnsmasq.
"enable-tftp=virt0" y "tftp-root=<root>,virt0" hacen el mismo trabajo
para TFTP.
La idea es que una linea así pueda ser agregada automaticamente
por libvirt o sistemas equivalentes, sin estorbar alguna
configuración manual.

.SH CÓDIGOS EXIT
.PP
0 - Dnsmasq hizo fork hacia el fondo exitosamente, o terminó de manera
normal si ir al fondo no está habilitado.
.PP
1 - Un problema con la configuración ha sido detectado.
.PP
2 - Un problema con acceso a redes ocurrió (dirección en uso, intento
de usar puertos privilegiados sin permiso).
.PP
3 - Un problema con una operación de sistema de archivos ocurrió (archivo
o directorio ausente, permisos).
.PP
4 - Falla de alocación de memoria.
.PP
5 - Otro problema misceláneo.
.PP
11 o mayor - un codigo de retorno no cero fué recibido del llamado "init"
del proceso de archivo guión de arriendos. El código exit de dnsmasq es
el código exit del archivo guión con 10 sumado.

.SH LIMITES
Los valores predeterminados para limites de recursos son generálmente
conservadores, y apropiados para uso en dispositivos tipo enrutador
encrustrado con procesadores lentos y poca memoria. En hardware más
capáz, es posible incrementar los límites, y soportar muchos mas
clientes. Lo siguiente se aplica a dnsmasq-2.37: versiones previas
no escalaban tan bien.

.PP
Dnsmasq es capaz de soportar con DNS y DHCP a por lo menos mil (1,000)
clientes. Los tiempos de arriendo no deben ser muy cortos (menos
de una hora). El valor de
.B --dns-forward-max
puede ser aumentado: comienze con el equivalente a el número de clientes y
auméntelo si parece lento el DNS. Nótese que el rendimiento DNS depende
también de los servidores DNS upstream. El tamaño del caché DNS puede ser
incrementado: el límite obligatorio es 10,000 nombres y el predeterminado
(150) es muy bajo. El enviarle un SIGUSR1 a dnsmasq hace que bitacorée
información que es útil para afinar el tamaño de caché. Ver la sección
.B NOTAS
para detalles.

.PP
El servidor TFTP incorporado es capáz de soportar varias transferencias
simultáneas de archivos: el límite absoluto está relacionado con el número
de file-handles permitidos a un proceso y la habilidad del system call
select() a soportar números grandes de file-handles. Si el límite es fijado
demasiado alto con
.B --tftp-max
será de-escalado y el límite real será bitacoreado al inicio. Nótese que más
transferencias son posibles cuando el mismo archivo es enviado qué cuando
cada transferencia envía un archivo diferente.

.PP
Es posible usar dnsmasq para negar publicidad Web usando una lista de
servidores de banners bien conocidos, todos resolviendose a 127.0.0.1 o
0.0.0.0 en
.B /etc/hosts 
o en un archivo hosts adicional. La lista puede ser muy larga. Dnsmasq ha sido
probado exitósamente con un millón de nombres. Ese tamaño de archivo necesita
un CPU de 1GHz y aproximadamente 60MB de RAM.

.SH INTERNACIONALIZACION

Dnsmasq puede ser compilado con soporte para internacionalización. Para hacer esto,
los targets make "all-i18n" y "install-i18n" deberán ser usados en vez de
los targets estándares "all" y "install". Cuando internacionalización es
compilada, dnsmasq producirá mensajes de bitácora en el lenguaje local y soportará
dominios internacionalizados (IDN). Nombres de dominio en /etc/hosts, /etc/ethers,
y /etc/dnsmasq.conf que contienen carácteres no-ASCII serán traducidos a
representación interna DNS punycode. Nótese que dnsmasq determina ambos el
lenguaje para mensajes y el juego de carácteres asumido para archivos de configuración
de la variable ambiental LANG. Esto debe estar fijado al valor predeterminado del sistema
por el guión responsable de iniciar dnsmasq. Al editar archivos de configuración,
tener cuidado de hacerlo usando solo el locale predeterminado del sistema y no
uno especifico del usuario, dado a que dnsmasq no tiene ninguna manera directa de
determinar el juego de caracteres en uso, y debe asumir que es el predeterminado
del sistema.

.SH ARCHIVOS
.IR /etc/dnsmasq.conf 

.IR /usr/local/etc/dnsmasq.conf

.IR /etc/resolv.conf

.IR /etc/hosts

.IR /etc/ethers

.IR /var/lib/misc/dnsmasq.leases 

.IR /var/db/dnsmasq.leases

.IR /var/run/dnsmasq.pid
.SH VER TAMBIEN
.BR hosts (5), 
.BR resolver (5)
.SH AUTOR
Este manual fue escrito por Simon Kelley <simon@thekelleys.org.uk>.

Traducido a español por Christopher Chatham <chrislinux@gmail.com>.