• Dnsmasq y Active Directory – Redes PYME

    por  • 27 Febrero, 2017 • Desde Linux • 1 Comentario

    ¡Hola amigos!. Para comprender y seguir correctamente éste artículo es imprescindible la lectura de sus antecesores:

    En ellos se explican conceptos teóricos y prácticos a los que no haremos referencia en éste. Cambiaremos de distribución en el ejercicio actual hacia Debian 8.6 “Jessie” y continuaremos con los mismos parámetros que usamos en BIND y Active Directory®.

    • El procedimiento descrito en éste post, también es válido para CentOS 7. El archivo de configuración /etc/dnsmasq es el mismo. Lo declaro porque considero innecesario confeccionar un artículo aparte para Dnsmasq y Active Directory® basado en CentOS. Por suerte, los directorios relativos a la documentación y configuración, son los mismos. 😉
    • El Dnsmaq es una creación de Simon Kelley <simon@thekelleys.org.uk>

    Límites sobre el uso del Dnsmasq

    Por su importancia repetimos los LÍMITES que soporta el Dnsmasq -ejecuten man dnsmasq– el cual refleja exactamente lo siguiente:

    LÍMITES

    • Los valores predeterminados para limites de recursos  son  generalmente 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.
    • 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 –dns-forward-max puede ser aumentado: comience 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  bitacore  información  que  es útil  para  afinar  el  tamaño  de  caché.  Ver  la  sección NOTAS para detalles.
    • 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  sys‐tem  call  select()  a  soportar números grandes de file-handles. Si el límite es fijado demasiado alto con –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. 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  /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.
    • Dnsmasq  es capaz de soportar con DNS y DHCP a por lo menos mil (1,000) clientes.

    Instalemos y configuremos a Jessie y al Dnsmasq

    Partiremos de una instalación nueva y limpia de un servidor basado en Debian 8 “Jessie”. O sea, el sistema operativo sin interfaz gráfica ninguna u otro paquete instalado. Los parámetros de la red serán los mismos que utilizamos en el artículo BIND y Active Directory®:

    Nombre de dominio  mordor.fan
    Red LAN         10.10.10.0/24
    
    ===============================================================================
    Servidores      Dirección IP    Propósito (Servidores con SO Windows)
    ===============================================================================
    sauron.mordor.fan.   10.10.10.3  Active Directory® 2008 SR2
    mamba.mordor.fan.   10.10.10.4  Servidor de archivos Windows
    dns.mordor.fan       10.10.10.5  Servidor DnsMasq sobre Jessie
    darklord.mordor.fan.    10.10.10.6  Proxy, gateway y firewall sobre Kerios  
    troll.mordor.fan.   10.10.10.7  Blog basado en... no recuerdo
    shadowftp.mordor.fan.   10.10.10.8  Servidor FTP
    blackelf.mordor.fan.    10.10.10.9  Servicio e-mail completo
    blackspider.mordor.fan. 10.10.10.10 Servicio WWW
    palantir.mordor.fan.    10.10.10.11 Chat en Openfire para Windows
    
    Real        CNAME
    ==============================
    sauron      ad-dc
    mamba       fileserver
    darklord    proxyweb
    troll       blog
    shadowftp   ftpserver
    blackelf    mail
    blackspider www
    palantir    openfire

    Configuraciones iniciales del servidor dns.mordor.fan

    root@dns:~# nano /etc/hostname
    dns
    
    root@dns:~# nano /etc/hosts
    127.0.0.1       localhost
    10.10.10.5      dns.mordor.fan  dns
    
    # The following lines are desirable for IPv6 capable hosts
    ::1     localhost ip6-localhost ip6-loopback
    ff02::1 ip6-allnodes
    ff02::2 ip6-allrouters
    
    root@dns:~# nano /etc/network/interfaces
    # This file describes the network interfaces available on your system
    # and how to activate them. For more information, see interfaces(5).
    source /etc/network/interfaces.d/*
    # The loopback network interface
    auto lo
    iface lo inet loopback
    # The primary network interface
    allow-hotplug eth0
    iface eth0 inet static
            address 10.10.10.5
            netmask 255.255.255.0
            network 10.10.10.0
            broadcast 10.10.10.255
            gateway 10.10.10.1
            # dns-* options are implemented by the resolvconf package, if installed
            dns-nameservers 127.0.0.1
            dns-search mordor.fan

    Instalemos el Dnsmasq y htop

    root@dns:~# aptitude install dnsmasq htop

    Después de instalar el paquete htop podemos comprobar los consumos de CPU y memoria del equipo. Solo estaba consumiendo unos 71 megas de RAM. Si queremos bajar aun mas el consumo, podemos instalar el paquete SSMTP -sencillo MTA– que a su vez purga el paquete Exim4 que Debian siempre instala por defecto y que realmente no necesitamos acorde al uso que daremos a éste servidor:

    root@dns:~# aptitude install ssmtp
    root@dns:~# aptitude purge ~c
    root@dns:~# aptitude clean
    root@dns:~# aptitude autoclean
    root@dns:~# systemctl reboot

    Después de reiniciar el equipo, el consumo es el siguiente: Dnsmasq y Active Directory

     

    Bajo, ¿no?. Continuemos adelante.

    Indiquemos que el Dnsmasq consulte -además- al Microsft® DNS

    Para probar las posibles configuraciones del Dnsmasq en el equipo dns.mordor.fan, debemos incluir una declaración que indique que se consulte al Microsoft DNS del servidor sauron.mordor.fan. Lo podemos hacer incluyendo la directiva server=/mordor.fan/10.10.10.3 en el archivo dnsmasq.conf -como veremos mas adelante- o adicionando la línea nameserver 10.10.10.3 en el archivo /etc/resolv.conf. Como aun no hemos configurado al Dnsmasq acorde a nuestras necesidades, elegimos la segunda forma:

    root@dns:~# nano /etc/resolv.conf
    domain mordor.fan
    nameserver 127.0.0.1
    nameserver 10.10.10.3

    Ya podemos resolver consultas DNS

    Con la configuración por defecto del Dnsmasq que aporta su archivo principal /etc/dnasmq.conf, y con lo declarado en el archivo /etc/resolv.conf del propio servidor “dns“, cualquier cliente conectado a la LAN -y que tenga declarado como servidor DNS a dns.mordor.fan– podrá resolver consultas DNS a expensas del Microsoft® DNS por ahora…

    • Muy importante es comprobar la velocidad de respuesta del Dnsmasq al hacer gala de su condición de Forwarder por la sola inclusión de la IP 10.10.10.3 en su archivo /etc/resolv.conf.

    Desde mi estación de trabajo administrativa y soporte de toda la parafernalia mediante la cual escribo, ejecuto:

    buzz@sysadmin:~$ cat /etc/resolv.conf 
    # Generated by NetworkManager
    domain mordor.fan
    nameserver 10.10.10.5
    
    buzz@sysadmin:~$ nslookup
    > dns
    Server:     10.10.10.5
    Address:    10.10.10.5#53
    
    Name:   dns.mordor.fan
    Address: 10.10.10.5
    
    > sauron
    Server:     10.10.10.5
    Address:    10.10.10.5#53
    
    Non-authoritative answer:
    Name:   sauron.mordor.fan
    Address: 10.10.10.3
    
    > 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan
    Server:     10.10.10.5
    Address:    10.10.10.5#53
    
    03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan  canonical name = sauron.mordor.fan.
    Name:   sauron.mordor.fan
    Address: 10.10.10.3
    
    > 10.10.10.3
    Server:     127.0.0.1
    Address:    127.0.0.1#53
    3.10.10.10.in-addr.arpa name = sauron.mordor.fan.
    
    > 10.10.10.9
    Server:     127.0.0.1
    Address:    127.0.0.1#53
    9.10.10.10.in-addr.arpa name = blackelf.mordor.fan.
    
    > 10.10.10.5
    Server:     127.0.0.1
    Address:    127.0.0.1#53
    5.10.10.10.in-addr.arpa name = dns.mordor.fan.
    
    > mail
    Server:     10.10.10.5
    Address:    10.10.10.5#53
    
    Non-authoritative answer:
    mail.mordor.fan canonical name = blackelf.mordor.fan.
    Name:   blackelf.mordor.fan
    Address: 10.10.10.9
    
    > exit
    
    buzz@sysadmin:~$

    Observemos en detalle los siguientes aspectos:

    • dns.mordor.fan responde directamente las consultas DNS que pueda resolver de acuerdo con la configuración actual de su Dnsmasq. Sino las puede resolver funciona como Forwarder y le pregunta a la IP 10.10.10.3 si puede responder a la consulta. Cuando se le pregunta por la IP del equipo “dns“, responde él directamente. Cuando se le pregunta al Dnsmasq ¿quién es “sauron“,?, hace forwarding a la 10.10.10.3 -no puede responder directamente pues aun no lo tiene registrado- quien le devuelve una Respuesta No Autoritaria correcta.
    • Cuando se le pregunta ¿quién es “03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan“?, hace forwarding nuevamente y en ésta ocasión recibe una Respuesta Autoritaria del Microsoft® DNS.
    • La alta velocidad de respuesta del Dnsmasq para cualquier tipo de consulta.

    Son pequeños detalles que hacen grande un amor ;-).

    Diferencias fundamentales entre Dnsmasq y BIND integrados con un Active Directory®

    Efectuemos un par de consultas DNS sobre los registro SOA y NS del dominio mordor.fan, a cada uno de los servidores de nombre involucrados:

    buzz@sysadmin:~$ host -t SOA mordor.fan 10.10.10.3
    Using domain server:
    Name: 10.10.10.3
    Address: 10.10.10.3#53
    Aliases: 
    mordor.fan has SOA record sauron.mordor.fan. hostmaster.mordor.fan. 56 900 600 86400 3600
    
    buzz@sysadmin:~$ host -t SOA mordor.fan 10.10.10.5
    Using domain server:
    Name: 10.10.10.5
    Address: 10.10.10.5#53
    Aliases: 
    mordor.fan has SOA record sauron.mordor.fan. hostmaster.mordor.fan. 56 900 600 86400 3600
    
    buzz@sysadmin:~$ host -t NS mordor.fan 10.10.10.5
    Using domain server:
    Name: 10.10.10.5
    Address: 10.10.10.5#53
    Aliases: 
    mordor.fan name server sauron.mordor.fan.
    
    buzz@sysadmin:~$ host -t NS mordor.fan 10.10.10.3
    Using domain server:
    Name: 10.10.10.3
    Address: 10.10.10.3#53
    Aliases: 
    mordor.fan name server sauron.mordor.fan.

    Las respuestas son idénticas -lo que es lógico- pues siempre responde sauron.mordor.fan. ante una consulta DNS sobre registros SOA o NS, aunque parezca que responde el dns.mordor.fan. Sin embargo difiere de lo visto en el artículo BIND y Active Directory® donde habíamos suprimido por completo la funcionalidad del Microsoft® DNS. En ese artículo TODAS las consultas DNS sobre el Espacio de Nombres del Domino mordor.fan las respondía el BIND, porque así lo configuramos, y porque el BIND si responde consultas SOA y NS además de que permite el esquema Master – Slave, transferencia de Zonas, etcétera, y por tanto es un servidor DNS mas completo – complejo.

    Acaso esas sean las diferencias principales entre el DNS del Dnsmasq y el BIND… pero el BIND -siempre puede haber uno o mas peros- no tiene un servidor DHCP que se integra perfectamente con un servidor DNS en un solo daemond, y sin necesidad de claves TSIG, archivos de configuraciones, bases de datos de Zonas, etcétera, como hemos vistos en artículos anteriores.

    • Creo que a ésta altura, los Estimados Lectores se habrán dado cuenta de que no odio al BIND ni prefiero al Dnsmasq antes que el BIND. Futuras discusiones al respecto son una total pérdida de tiempo, pues tiene que ver mucho con necesidades, exigencias, gustos, preferencias y ... cada solución tiene su encanto ;-).
    • En escenarios similares, que cada cual instale y configure el software de su preferencia y que mas conozca y que todo le funcione como espera.

    Ventajas de la combinación Dnsmasq + Active Directory®

    Con ésta combinación tenemos el abanico completo de respuestas a consultas DNS y un eficaz medio de arrendamiento de direcciones IP para nuestra LAN PYME. Como veremos mas adelante, funciona correctamente para cualquier situación con respecto a si el equipo está unido o no al Controlador de Dominio del Microsoft® Active Directory®. Además, disponemos de un servidor DNS y DNS Forwarder por excelencia, más un servidor DHCP muy rápido. Y todo con poca demanda de recursos. ¿Desea más?.

    ¿Es posible Dnsmasq + BIND?

    Definitivamente SI. Aunque recomiendo se instalen en equipos diferentes para que no existan choques por el tan querido puerto 53 del servicio DNS. Tal vez y veamos algo al respecto cuando lleguemos al AD-DC basado en Samba 4. ¿Quién sabe?.

    Tips sobre el Dnamasq

    • Los archivos imprescindibles de trabajo para que el Dnsmasq brinde los servicios DHCP y DNS en una LAN son: /etc/dnsmasq.conf, /etc/hosts, /var/lib/misc/dnsmasq.leases, y /etc/resolv.conf. El archivo dnsmasq.leases se crea cuando arrienda su primera dirección IP.
    • Otro archivo de trabajo que puede utilizar es /etc/ethers. De existir ese archivo, la directiva read-ethers declarada en el archivo de configuración, le indica al Dnsmasq que lo lea. Es muy útil cuando relacionamos direcciones MAC/nombres de hosts para determinados propósitos.
    • El servicio DNS se puede deshabilitar completamente mediante la directiva port=0 en el dnsmasq.conf.
    • El servicio DHCP para una o más interfaces de red se puede deshabilitar mediante directivas -una por cada línea- no-dhcp-interface=eth0, no-dhcp-interface=eth1, y así sucesivamente. Muy útil cuando estemos frente a un equipo con 2 -o más- interfaces de red y queremos se brinde el servicio DHCP solo por una de ellas o por ninguna. Por supuesto que, si deshabilitamos el servicio DHCP por todas las interfaces, dejaremos solamente en funcionamiento al servicio DNS. Si deshabilitamos ambos servicios, entonces ¿para qué necesitamos al Dnsmasq?. 😉
    • Para declarar a otros Servidores de Nombre de Dominio DNS que no sean públicos o externos a la LAN -como el caso del Microsoft DNS- lo hacemos mediante la directiva server=/nombre del dominio/IP del servidor DNS en el archivo /etc/dnsmasq.conf. Ejemplo: server=/mordor.fan/10.10.10.3.
    • Para indicar al Dnsmasq que las consultas sobre los dominios locales sean respondidas solamente desde el archivo /etc/hosts o mediante su DHCP, debemos agregar la directiva local=/localnet/ en el archivo principal de su configuración. Ejemplo: local=/mordor.fan/.
    • Para configurar correctamente el archivo /etc/resolv.confresolver sugerimos la lectura de su manual mediante el comando man resolv.conf. Si instalan el Debian 8.6 “Jessie” encontrarán que está bien redactado en lengua hispana.
    • El Dnsmasq no utiliza archivos de Zonas para responder a consultas directas o inversas.
    • Para conocer el significado de cada campo “especial” que se utiliza en la declaración de un Registro de Recurso SRV, debe consultar BIND y Active Directory®. La sintaxis de los registros SRV en el archivo /etc/dnsmasq.conf es la siguiente:
      srv-host=<Service-Name>,<Target>,<Port>,<Priority>,<Wight>

    Los Lectores que deseen conocer más, por favor lean con detenimiento el archivo original /etc/dnsmasq.conf o los documentos existentes en el directorio /usr/share/doc/dnsmasq-base.

    root@dns:~# ls -l /usr/share/doc/dnsmasq-base/
    total 128
    -rw-r--r-- 1 root root   883 may  5  2015 copyright
    -rw-r--r-- 1 root root 36261 may  5  2015 changelog.archive.gz
    -rw-r--r-- 1 root root 11297 may  5  2015 changelog.Debian.gz
    -rw-r--r-- 1 root root 26014 may  5  2015 changelog.gz
    -rw-r--r-- 1 root root  2084 may  5  2015 DBus-interface.gz
    -rw-r--r-- 1 root root  4297 may  5  2015 doc.html
    drwxr-xr-x 2 root root  4096 feb 19 17:52 examples
    -rw-r--r-- 1 root root  9721 may  5  2015 FAQ.gz
    -rw-r--r-- 1 root root  4180 may  5  2015 README.Debian
    -rw-r--r-- 1 root root 12019 may  5  2015 setup.html

    Configuremos al Dnsmasq y al Resolver

    Tomaremos como guía inicial -cambiando los nombres y demás, por supuesto- el archivo de configuración empleado en el artículo “Dnsmasq en CentOS 7.3“.

    No olvidemos el siguiente paso:

    [root@dns ~]# mv /etc/dnsmasq.conf /etc/dnsmasq.conf.original
    

    Direcciones IP fijas

    Las direcciones de los servidores o equipos que requieran de una IP fija -tanto IPv4 como IPv6– se declaran en el archivo /etc/hosts:

    [root@dns ~]# nano /etc/hosts
    127.0.0.1       localhost
    # The following lines are desirable for IPv6 capable hosts
    ::1     localhost ip6-localhost ip6-loopback
    ff02::1 ip6-allnodes
    ff02::2 ip6-allrouters
    
    # Servidores y equipos con IP fijas.
    10.10.10.1  sysadmin.mordor.fan
    10.10.10.3  sauron.mordor.fan
    10.10.10.4  mamba.mordor.fan
    10.10.10.5  dns.mordor.fan
    10.10.10.6  darklord.mordor.fan
    10.10.10.7  troll.mordor.fan
    10.10.10.8  shadowftp.mordor.fan
    10.10.10.9  blackelf.mordor.fan
    10.10.10.10 blackspider.mordor.fan
    10.10.10.11 palantir.mordor.fan

    Creemos el archivo /etc/dnsmasq.conf

    [root@dns ~]# nano /etc/dnsmasq.conf
    # -------------------------------------------------------------------
    # O P C I O N E S   G E N E R A L E S
    # -------------------------------------------------------------------
    domain-needed   # No pasar nombres sin la parte del dominio
    bogus-priv  # No pasar direcciones en el espacio no enrutado
    expand-hosts    # Adiciona automaticamente el dominio al host
    interface=eth0  # Interface. OJO con la Interface
    # except-interface=eth1 # NO escuchar por esta NIC
    strict-order    # Orden en que consulta el archivo /etc/resolv.conf
    
    # Incluya muchas mas opciones de configuración
    # mediante un archivo o ubicando los archivos
    # de configuración adicionales en un directorio
    # conf-file=/etc/dnsmasq.more.conf
    conf-dir=/etc/dnsmasq.d
    
    # Relativos al Nombre del Dominio
    domain=mordor.fan   # Nombre del dominio
    
    # El Servidor de Tiempo es 10.10.10.1
    address=/time.windows.com/10.10.10.1
    
    # Envía una opción vacía del valor WPAD. Se requiere para que 
    # se comporten bien los clientes Windos 7 y posteriores. ;-)
    dhcp-option=252,"\n"
    
    # Archivo donde declararemos los HOSTS que serán "baneados"
    addn-hosts=/etc/banner_add_hosts
    
    # Consultar al servidor Microsoft® DNS "sauron" si es que
    # lo dejamos en funcionamiento
    server=/mordor.fan/10.10.10.3
    
    # Las consultas sobre los dominios locales serán respondidas
    # desde /etc/hosts o mediante DHCP
    local=/mordor.fan/
    
    # Las consultas sobre registros PTR o Inversas, serán respondidas
    # por los servidores "dns" y "sauron" en ese orden
    server=/10.10.10.in-addr.arpa/10.10.10.5
    server=/10.10.10.in-addr.arpa/10.10.10.3
    
    # -------------------------------------------------------------------
    # R E G I S T R O S   C N A M E    M X    T X T
    # -------------------------------------------------------------------
    # Este tipo de registro requiere de una entrada
    # en el archivo /etc/hosts
    # ej: 10.10.0.7 troll.mordor.fan troll
    # cname=ALIAS,REAL_NAME
    cname=ad-dc.mordor.fan,sauron.mordor.fan
    cname=fileserver.mordor.fan,mamba.mordor.fan
    cname=proxyweb.mordor.fan,darklord.mordor.fan
    cname=blog.mordor.fan,troll.mordor.fan
    cname=ftpserver.mordor.fan,shadowftp.mordor.fan
    cname=mail.mordor.fan,blackelf.mordor.fan
    cname=www.mordor.fan,blackspider.mordor.fan
    cname=opendire.mordor.fan,palantir.mordor.fan
    
    # REGISTROS MX
    # Devuelve un registro MX con el nombre "mordor.fan" con destino
    # al equipo blackelf.mordor.fan y prioridad de 10
    mx-host=mordor.fan,mail.mordor.fan,10
    
    # El destino por defecto para los registros MX que se creen
    # utilizando la opción localmx será:
    mx-target=mail.mordor.fan
    
    # Devuelve un registro MX apuntando al mx-target para TODAS
    # las máquinas locales
    localmx
    
    # Registros TXT. Podemos declarar también un registro SPF
    txt-record=mordor.fan,"v=spf1 a -all"
    txt-record=mordor.fan,"Wellcome to The Dark Lan of Mordor"
    
    # -------------------------------------------------------------------
    
    # -------------------------------------------------------------------
    # R A N G O   Y   S U S   O P C I O N E S
    # -------------------------------------------------------------------
    # Rango IPv4 y tiempo de arrendamiento
    # De la 1 a la 29 son para los Servidores y otras necesidades
    dhcp-range=10.10.10.30,10.10.10.250,8h
    
    dhcp-lease-max=222      # Cantidad máxima de direcciones a arrendar
                            # por defecto son 150
    # Rango IPV6
    # dhcp-range=1234::, ra-only
    
    # Opciones para el RANGO
    # O P C I O N E S
    dhcp-option=1,255.255.255.0 # NETMASK
    dhcp-option=3,10.10.10.253  # ROUTER GATEWAY
    dhcp-option=6,10.10.10.5    # DNS Servers
    dhcp-option=15,mordor.fan   # DNS Domain Name
    dhcp-option=19,1        # option ip-forwarding ON
    dhcp-option=28,10.10.10.255 # BROADCAST
    dhcp-option=42,10.10.10.1   # NTP
    
    # dhcp-option=40,MORDOR     # NIS Domain Name
    # dhcp-option=41,10.10.10.3 # NIS Server
    # dhcp-option=44,10.10.10.3 # WINS
    # dhcp-option=45,10.10.10.3 # Datagramas NetBIOS
    # dhcp-option=73,10.10.10.3 # Finger Server
    # dhcp-option=46,8      # Nodo NetBIOS
    
    dhcp-authoritative      # DHCP Autoritario en la subnet
    # -------------------------------------------------------------------
    
    # -------------------------------------------------------------------
    # L O G G I N G   tail -f /var/log/syslog o journalctl -f
    # -------------------------------------------------------------------
    log-queries
    
    # -------------------------------------------------------------------
    # Registros A y SRV correspondientes al Active Directory
    # -------------------------------------------------------------------
    # Registros A
    address=/gc._msdcs.mordor.fan/10.10.10.3
    address=/DomainDnsZones.mordor.fan/10.10.10.3
    address=/ForestDnsZones.mordor.fan/10.10.10.3
    
    # Registro CNAME de la Zona del Microsoft DNS _msdcs.mordor.fan
    cname=03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan,sauron.mordor.fan
    
    # Registros SRV
    # srv-host=<Service-Name>,<Target>,<Port>,<Priority>,<Wight>
    
    # Global Catalog
    # Zona _msdcs.mordor.fan del Microsoft DNS
    srv-host=_ldap._tcp.gc._msdcs.mordor.fan,sauron.mordor.fan,3268,0,0
    srv-host=_ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.mordor.fan,sauron.mordor.fan,3268,0,0
    # Zona mordor.fan del Microsoft DNS
    srv-host=_gc._tcp.mordor.fan,sauron.mordor.fan,3268,0,0
    srv-host=_gc._tcp.Default-First-Site-Name._sites.mordor.fan,sauron.mordor.fan,3268,0,0
    
    # LDAP modificado y privado de un Active Directory
    # Zona _msdcs.mordor.fan del Microsoft DNS
    srv-host=_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan,sauron.mordor.fan,389,0,0
    srv-host=_ldap._tcp.dc._msdcs.mordor.fan,sauron.mordor.fan,389,0,0
    srv-host=_ldap._tcp.18d3360d-8fdb-40cf-a678-d7c420b6d775.domains._msdcs.mordor.fan,sauron.mordor.fan,389,0,0
    srv-host=_ldap._tcp.pdc._msdcs.mordor.fan,sauron.mordor.fan,389,0,0
    # Zona mordor.fan del Microsoft DNS
    srv-host=_ldap._tcp.mordor.fan,sauron.mordor.fan,389,0,0
    srv-host=_ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones.mordor.fan,sauron.mordor.fan,389,0,0
    srv-host=_ldap._tcp.DomainDnsZones.mordor.fan,sauron.mordor.fan,389,0,0
    srv-host=_ldap._tcp.Default-First-Site-Name._sites.mordor.fan,sauron.mordor.fan,389,0,0
    srv-host=_ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.mordor.fan,sauron.mordor.fan,389,0,0
    srv-host=_ldap._tcp.ForestDnsZones.mordor.fan,sauron.mordor.fan,389,0,0
    
    #
    # KERBEROS modificado y privado de un Active Directory
    srv-host=_kerberos._tcp.Default-First-Site-Name._sites.mordor.fan,sauron.mordor.fan,88,0,0
    srv-host=_kerberos._tcp.mordor.fan,sauron.mordor.fan,88,0,0
    srv-host=_kpasswd._tcp.mordor.fan,sauron.mordor.fan,464,0,0
    srv-host=_kerberos._udp.mordor.fan,sauron.mordor.fan,88,0,0
    srv-host=_kpasswd._udp.mordor.fan,sauron.mordor.fan,464,0,0
    
    # F I N   del archivo /etc/dnsmasq.conf
    # -------------------------------------------------------------------

    Creemos el archivo /etc/banner_add_host

    [root@dns ~]# nano /etc/banner_add_hosts
    127.0.0.1   windowsupdate.com
    127.0.0.1   ctldl.windowsupdate.com
    127.0.0.1   ocsp.verisign.com
    127.0.0.1   csc3-2010-crl.verisign.com
    127.0.0.1   www.msftncsi.com
    127.0.0.1   ipv6.msftncsi.com
    127.0.0.1   teredo.ipv6.microsoft.com
    127.0.0.1   ds.download.windowsupdate.com
    127.0.0.1   download.microsoft.com
    127.0.0.1   fe2.update.microsoft.com
    127.0.0.1   crl.microsoft.com
    127.0.0.1   www.download.windowsupdate.com
    127.0.0.1   win8.ipv6.microsoft.com
    127.0.0.1   spynet.microsoft.com
    127.0.0.1   spynet1.microsoft.com
    127.0.0.1   spynet2.microsoft.com
    127.0.0.1   spynet3.microsoft.com
    127.0.0.1   spynet4.microsoft.com
    127.0.0.1   spynet5.microsoft.com
    127.0.0.1   office15client.microsoft.com
    127.0.0.1   addons.mozilla.org
    127.0.0.1   crl.verisign.com
    
    [root@dns ~]# dnsmasq --test
    dnsmasq: syntax check OK.
    
    [root@dns ~]# systemctl restart dnsmasq.service 
    [root@dns ~]# systemctl status dnsmasq.service
    

    Modifiquemos el archivo /etc/resolv.conf – Resolver

    root@dns:~# nano /etc/resolv.conf 
    domain mordor.fan
    search mordor.fan
    

    ¿Por qué no tenemos declaradas las habituales líneas en el archivo resolv.conf?. Porque declaramos en el dnsmasq.conf las siguientes directivas:

    # Consultar al servidor Microsoft® DNS "sauron" si es que
    # lo dejamos en funcionamiento
    server=/mordor.fan/10.10.10.3
    
    # Las consultas sobre los dominios locales serán respondidas
    # desde /etc/hosts o mediante DHCP
    local=/mordor.fan/
    
    # Las consultas sobre registros PTR o Inversas, serán respondidas
    # por los servidores "dns" y "sauron" en ese orden
    server=/10.10.10.in-addr.arpa/10.10.10.5
    server=/10.10.10.in-addr.arpa/10.10.10.3
    

    Consultas desde sysadmin.mordor.fan

    El archivo /etc/resolv.conf de éste equipo es:

    buzz@sysadmin:~$ cat /etc/resolv.conf
    # Generated by NetworkManager
    search mordor.fan
    nameserver 10.10.10.5
    buzz@sysadmin:~$ host -t A spynet4.microsoft.com
    spynet4.microsoft.com has address 127.0.0.1
    
    buzz@sysadmin:~$ host -t A www.download.windowsupdate.com
    www.download.windowsupdate.com has address 127.0.0.1
    
    buzz@sysadmin:~$ dig dns
    buzz@sysadmin:~$ dig dns.mordor.fan
    ;; QUESTION SECTION:
    ;dns.mordor.fan.            IN  A
    
    ;; ANSWER SECTION:
    dns.mordor.fan.     0   IN  A   10.10.10.5
    
    buzz@sysadmin:~$ host -t SRV _ldap._tcp.gc._msdcs
    buzz@sysadmin:~$ host -t SRV _ldap._tcp.gc._msdcs.mordor.fan
    _ldap._tcp.gc._msdcs.mordor.fan has SRV record 0 0 3268 sauron.mordor.fan.
    
    buzz@sysadmin:~$ dig _ldap._tcp.gc._msdcs.mordor.fan
    ;; QUESTION SECTION:
    ;_ldap._tcp.gc._msdcs.mordor.fan. IN    A
    
    ;; ANSWER SECTION:
    _ldap._tcp.gc._msdcs.mordor.fan. 0 IN   A   10.10.10.3
    
    buzz@sysadmin:~$ dig mordor.fan axfr
    buzz@sysadmin:~$ dig 10.10.10.in-addr.arpa axfr
    

    Y de esa forma, cuantas consultas necesitemos

    Dnsmasq + Active Directory® + Clientes Microsoft® Windows

    Cambio de nombre de un cliente Microsoft® Windows

    seven.mordor.fan arrendó la dirección IP:

    root@dns:~# cat /var/lib/misc/dnsmasq.leases 
    1488006009 00:0c:29:d6:14:36 10.10.10.115 seven 01:00:0c:29:d6:14:36

    Cambiemos el nombre del “seven” -que no está unido al Dominio del Active Directory- por “eucaliptus“. Después del cambio y el reinicio comprobamos:

    root@dns:~# cat /var/lib/misc/dnsmasq.leases 
    1488006633 00:0c:29:d6:14:36 10.10.10.115 eucaliptus 01:00:0c:29:d6:14:36

    La historia de los cambios las podemos ver desde “sysadmin”:

    buzz@sysadmin:~$ host -t A seven
    seven.mordor.fan has address 10.10.10.115

    Después del cambio de nombre

    buzz@sysadmin:~$ host -t A seven
    seven has no A record
    
    buzz@sysadmin:~$ host -t A eucaliptus
    eucaliptus.mordor.fan has address 10.10.10.115

    Consultas desde el cliente eucaliptus.mordor.fan

    Microsoft Windows [Version 6.1.7601]
    Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
    
    C:\Users\buzz>nslookup
    Default Server:  dns.mordor.fan
    Address:  10.10.10.5
    
    > sauron
    Server:  dns.mordor.fan
    Address:  10.10.10.5
    
    Name:    sauron.mordor.fan
    Address:  10.10.10.3
    
    > mordor.fan
    Server:  dns.mordor.fan
    Address:  10.10.10.5
    
    Name:    mordor.fan
    Address:  10.10.10.3
    
    > eucaliptus
    Server:  dns.mordor.fan
    Address:  10.10.10.5
    
    Name:    eucaliptus.mordor.fan
    Address:  10.10.10.115
    
    > 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan
    Server:  dns.mordor.fan
    Address:  10.10.10.5
    
    Name:    sauron.mordor.fan
    Address:  10.10.10.3
    Aliases:  03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan
    
    > set type=SRV
    > _kerberos._udp.mordor.fan
    Server:  dns.mordor.fan
    Address:  10.10.10.5
    
    _kerberos._udp.mordor.fan       SRV service location:
              priority       = 0
              weight         = 0
              port           = 88
              svr hostname   = sauron.mordor.fan
    sauron.mordor.fan       internet address = 10.10.10.3
    
    > _ldap._tcp.18d3360d-8fdb-40cf-a678-d7c420b6d775.domains._msdcs.mordor.fan
    Server:  dns.mordor.fan
    Address:  10.10.10.5
    
    _ldap._tcp.18d3360d-8fdb-40cf-a678-d7c420b6d775.domains._msdcs.mordor.fan
    SRV service location:
              priority       = 0
              weight         = 0
              port           = 389
              svr hostname   = sauron.mordor.fan
    sauron.mordor.fan       internet address = 10.10.10.3
    
    > exit
    
    C:\Users\buzz>

    Registro de los clientes Windows en el Microsoft® DNS

    Clientes Windows no unidos al Dominio del Active Directory®

    Debemos comprobar si se registran correctamente en el Microsoft® DNS, las direcciones IP arrendadas por los diferentes clientes Windows desde el Dnsmasq. Puede influir la forma en que activemos las Actualizaciones dinámicas – Dynamic updates en las Zonas del Microsoft® DNS del Active Directory®. Partimos de la configuración por defecto del Microsoft DNS el cual permite solamente las Actualizaciones Dinámicas Seguras – Dynamic updates –> Secure only, en cada una de sus Zonas.

    Observemos que el cliente con el actual FQDN eucaliptus.mordor.fan no está unido al Dominio del Active Directory (o a un Samba4 AD-DC), y constituye una excepción a la regla de Microsoft de que “sólo los clientes registrados en Mi Dominio tendrán permiso a través de Mi Mecanismo de Actualización -que Yo solo conozco- para registrarse en Mi DNS“. Menos mal que el Samba4 AD-DC nos enseña algo al respecto.

    eucaliptus.mordor.fan arrendó la IP 10.10.10.115:

    buzz@sysadmin:~$ host -t A eucaliptus
    eucaliptus.mordor.fan has address 10.10.10.115

    Cambiemos su nombre por el de “caoba“, reiniciemos el Windows 7, y veamos que sucede cuando preguntamos por los nombres “eucaliptus” y “caoba” a cada uno de los DNS, primero al Microsoft DNS y después al Dnsmasq:

    buzz@sysadmin:~$ host -t A eucaliptus.mordor.fan 10.10.10.3
    Using domain server:
    Name: 10.10.10.3
    Address: 10.10.10.3#53
    Aliases: 
    
    Host eucaliptus.mordor.fan not found: 3(NXDOMAIN)
    
    buzz@sysadmin:~$ host -t A caoba.mordor.fan 10.10.10.3
    Using domain server:
    Name: 10.10.10.3
    Address: 10.10.10.3#53
    Aliases: 
    
    Host caoba.mordor.fan not found: 3(NXDOMAIN)
    
    buzz@sysadmin:~$ host -t A eucaliptus.mordor.fan 10.10.10.5
    Using domain server:
    Name: 10.10.10.5
    Address: 10.10.10.5#53
    Aliases: 
    
    Host eucaliptus.mordor.fan not found: 3(NXDOMAIN)
    
    buzz@sysadmin:~$ host -t A caoba.mordor.fan 10.10.10.5
    Using domain server:
    Name: 10.10.10.5
    Address: 10.10.10.5#53
    Aliases: 
    
    caoba.mordor.fan has address 10.10.10.115

    Podemos cambiar el nombre del cliente Windows 7 que no está unido al Dominio mordor.fan del Active Directory® cuantas veces queramos, que el Microsoft® DNS no se entera de esos cambios ni de que existe tal cliente. ¿Es posible que se deba solamente a que tenemos seleccionada la opción  Dynamic updates –> Secure only en cada Zona del Micorosft DNS?.

    Para que el Señor Microsoft® DNS se entere de los cambios, debemos seleccionar Dynamic updates –> Nonsecure and secure. Esa opción, Estimados Lectores, implica una significativa vulnerabilidad de la seguridad de cualquier Servidor de Nombres de Dominio que se respete, sea de Microsft® o UNIX®/Linux. El Microsoft® DNS advierte sobre la vulnerabilidad porque al final no es mas que un BIND modificado y privatizado para ofrecernos “Seguridad a cambio de Obscuridad“. Sino, ¿por qué recomienda guardar en su famoso Registro todas las configuraciones y registros DNS de su Microsoft® DNS cuando estamos implementando un Active Directory®?. Además de admitir las actualizaciones no seguras en el Microsoft® DNS, es necesaria la modificación siguiente en la configuración de la tarjeta de red del cliente Windows 7:

     

    Comprobemos:

    buzz@sysadmin:~$ host -t A caoba.mordor.fan 10.10.10.3
    Using domain server:
    Name: 10.10.10.3
    Address: 10.10.10.3#53
    Aliases: 
    caoba.mordor.fan has address 10.10.10.115
    
    buzz@sysadmin:~$ host 10.10.10.115 10.10.10.3
    Using domain server:
    Name: 10.10.10.3
    Address: 10.10.10.3#53
    Aliases: 
    115.10.10.10.in-addr.arpa domain name pointer caoba.mordor.fan.
    
    buzz@sysadmin:~$ host -t A caoba 10.10.10.5
    Using domain server:
    Name: 10.10.10.5
    Address: 10.10.10.5#53
    Aliases: 
    caoba.mordor.fan has address 10.10.10.115
    
    buzz@sysadmin:~$ host 10.10.10.115 10.10.10.5
    Using domain server:
    Name: 10.10.10.5
    Address: 10.10.10.5#53
    Aliases: 
    115.10.10.10.in-addr.arpa domain name pointer caoba.mordor.fan.

    ¡Ahora sí. Que bonito sincronismo para dos servidores DNS no sincronizados por ningun medio!, no?.

    Clientes Windows unidos al Dominio del Active Directory®

    Unamos el cliente caoba.mordor.fan al Dominio, no sin antes eliminar la modificación que hicimos en la configuración de su tarjeta de red, si es que en algún momento la hicimos para comprobar nada más el punto del capítulo anterior. También borremos la entrada de “caoba” en el Microsoft® DNS, y retornemos las Actualizaciones Dinámicas a su punto de origen de “Secure only“. De paso, es válido reiniciar el servicio del Microsoft® DNS.

    Después de unido al Dominio, y a pesar de todos nuestros esfuerzos, el cliente “caoba” no aparece registrado en el Microsoft® DNS. Hasta declaramos en el dnsmasq.conf -de forma temporal- que el primer servidor DNS es 10.10.10.3.

    Microsoft Windows [Version 6.1.7601]
    Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
    
    C:\Users\saruman>ipconfig /all
    
    Windows IP Configuration
    
       Host Name . . . . . . . . . . . . : CAOBA
       Primary Dns Suffix  . . . . . . . : mordor.fan
       Node Type . . . . . . . . . . . . : Hybrid
       IP Routing Enabled. . . . . . . . : No
       WINS Proxy Enabled. . . . . . . . : No
       DNS Suffix Search List. . . . . . : mordor.fan
    
    Ethernet adapter Local Area Connection:
    
       Connection-specific DNS Suffix  . : mordor.fan
       Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Network Connection
       Physical Address. . . . . . . . . : 00-0C-29-D6-14-36
       DHCP Enabled. . . . . . . . . . . : Yes
       Autoconfiguration Enabled . . . . : Yes
       Link-local IPv6 Address . . . . . : fe80::352a:b954:7eba:963e%12(Preferred)
       IPv4 Address. . . . . . . . . . . : 10.10.10.115(Preferred)
       Subnet Mask . . . . . . . . . . . : 255.255.255.0
       Lease Obtained. . . . . . . . . . : Saturday, February 25, 2017 8:19:05 AM
       Lease Expires . . . . . . . . . . : Saturday, February 25, 2017 4:20:36 PM
       Default Gateway . . . . . . . . . : 10.10.10.253
       DHCP Server . . . . . . . . . . . : 10.10.10.5
       DHCPv6 IAID . . . . . . . . . . . : 251661353
       DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-20-3B-69-81-00-0C-29-D6-14-36
    
       DNS Servers . . . . . . . . . . . : 10.10.10.3
                                           10.10.10.5
       NetBIOS over Tcpip. . . . . . . . : Enabled
    
    Tunnel adapter isatap.mordor.fan:
    
       Media State . . . . . . . . . . . : Media disconnected
       Connection-specific DNS Suffix  . : mordor.fan
       Description . . . . . . . . . . . : Microsoft ISATAP Adapter
       Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes
    
    Tunnel adapter Local Area Connection* 9:
    
       Media State . . . . . . . . . . . : Media disconnected
       Connection-specific DNS Suffix  . :
       Description . . . . . . . . . . . : Microsoft Teredo Tunneling Adapter
       Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes
    
    C:\Users\saruman>
    
    buzz@sysadmin:~$ host -t A caoba.mordor.fan 10.10.10.3
    Using domain server:
    Name: 10.10.10.3
    Address: 10.10.10.3#53
    Aliases: 
    Host caoba.mordor.fan not found: 3(NXDOMAIN)
    
    buzz@sysadmin:~$ host -t A caoba.mordor.fan
    caoba.mordor.fan has address 10.10.10.115
    
    • De la única forma que se registra el cliente “caoba” en el Microsft® DNS es modificando su tarjeta de red como se indicó en la imagen anterior, o sea, declarando explícitamente que: el sufijo DNS para la conexión es mordor.fan, que registre la dirección de la conexión en el DNS, y que utilice el sufijo DNS declarado al registrar la conexión.
    buzz@sysadmin:~$ host -t A caoba.mordor.fan 10.10.10.3
    Using domain server:
    Name: 10.10.10.3
    Address: 10.10.10.3#53
    Aliases: 
    caoba.mordor.fan has address 10.10.10.115
    
    buzz@sysadmin:~$ host -t A caoba.mordor.fan
    caoba.mordor.fan has address 10.10.10.115
    Cambiemos el nombre de “caoba” a “cedro”
    buzz@sysadmin:~$ host -t A caoba.mordor.fan 10.10.10.3
    Using domain server:
    Name: 10.10.10.3
    Address: 10.10.10.3#53
    Aliases: 
    Host caoba.mordor.fan not found: 3(NXDOMAIN)
    
    buzz@sysadmin:~$ host -t A cedro.mordor.fan 10.10.10.3
    Using domain server:
    Name: 10.10.10.3
    Address: 10.10.10.3#53
    Aliases: 
    cedro.mordor.fan has address 10.10.10.115
    
    buzz@sysadmin:~$ host -t A caoba.mordor.fan 10.10.10.5
    Using domain server:
    Name: 10.10.10.5
    Address: 10.10.10.5#53
    Aliases: 
    Host caoba.mordor.fan not found: 3(NXDOMAIN)
    
    buzz@sysadmin:~$ host -t A cedro.mordor.fan 10.10.10.5
    Using domain server:
    Name: 10.10.10.5
    Address: 10.10.10.5#53
    Aliases: 
    cedro.mordor.fan has address 10.10.10.115

    Y todo normal, como le agrada a los clientes Microsoft® y al Microsoft® DNS que sean las cosas.

    Trabajemos con el Microsoft® DHCP y el Microsoft® DNS

    Estimados Lectores, éste capítulo está fuera del contexto de un blog dedicado al Software Libre. Consulten la ayuda de Microsoft®. ¿No creen?. 😉

    Conclusiones

    Existen varias formas de trabajar el Microsoft® DNS cuando hacemos que conviva en una Red PYME con el Dnsmasq. Entre ellas mencionaremos solo las siguientes:

    • Detener totalmente el servicio Microsoft® DNS en el equipo donde se esté ejecutando, indicando después que el inicio del servicio está inhabilitado. Desmarcar en la configuración de la tarjeta de red de cada cliente Microsoft® la opción de que Registre la dirección de la conexión en el DNS. Eliminar del archivo /etc/dnsmasq.conf la directiva server=/mordor.fan/10.10.10.3. Notas:
      • Aunque no se responda a las consultas sobre los registros SOA y NS, la red funcionará correctamente, así como la unión de los diferentes clientes -Microsoft® y Linux- al Dominio del Active Directory®.
      • Tiene la ventaja de que en la LAN PYME solo existirá un Servidor de Nombres de Dominio -macho machote- y será el Dnsmasq. ;-). Por otra parte, se elimina la posibilidad de que ocurran inconsistencias entre los registros DNS almacenados en el Microsoft® DNS y los disponibles mediante el Dnsmasq.
    • Dejar en funcionamiento el Microsoft® DNS para que responda solamente las consultas DNS sobre los registros SOA y NS. Notas:
      • Modificar la configuración de la tarjeta de red de cada cliente Windows, desmarcando la opción de que Registre la dirección de la conexión en el DNS.
      • Pensamos que esta solución es un derroche de recursos.
    • Configurar los servicios como hemos visto a lo largo de todo el artículo, el cual muestra una solución más del agrado de la filosofía Microsoft® -que no FreeBSD/Linux- Ok?.

    Resumen

    • La propuesta del Microsoft® DNS es muy cerrada. No deja espacio alguno para otras soluciones que no estén acorde a su hermética filosofía.
    • La Madre Naturaleza nos enseña que existimos en un universo diverso. Lo normal es tener una LAN mixta, en movimiento hacia el Software Libre, y rica en vida y variedad.
    • Tal parece que para Microsoft®, los clientes que no se Unan a Su Filosofía son unos Marginados, y por tanto, no debe molestarse en tenerlos en consideración.
    • ¡Que difícil es trabajar con Software Privado!. Prefiero pasar un poco de trabajo configurando Software Libre y ser verdaderamente Libre, ¡carajo!.

    “El Mejor Criterio de la Verdad es la Práctica”.

    El artículo Dnsmasq y Active Directory – Redes PYME aparece primero en Dnsmasq y Active Directory – Redes PYME.

    Artículo original: Dnsmasq y Active Directory – Redes PYME

    One Response to Dnsmasq y Active Directory – Redes PYME

    1. 19 Marzo, 2017 at 12:15

      Lástima que no reflejen la cantidad de visitas que ha tenido éste artículo. Lástima que recién me entero de que todos mis artículos se repitan -junto a otros de muy buena calidad- en éste sitio, aunque reconozca que lo hacen de una forma muy respetuosa. Gracias por ello. Lástima que lo han hecho sin mi permiso personal, pues me gustaría mas que siempre me leyeran en el sitio original.

    Deja un comentario

    Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *