One place for hosting & domains

      Cómo configurar BIND como servidor DNS de red privada en Ubuntu 18.04


      Introducción

      Una parte importante de la administración de la configuración e infraestructura de servidores incluye el uso sostenido de un método sencillo para buscar las interfaces de red y direcciones IP por nombre mediante la configuración de un sistema de nombres de dominio (DNS) adecuado. El empleo de nombres de dominio completos (FQDN), en vez de direcciones IP, para especificar las direcciones de red puede facilitar la configuración de servicios y aplicaciones, y aumenta la capacidad de mantenimiento de los archivos de configuración. Configurar su propio DNS para su red privada es una excelente opción para mejorar la administración de sus servidores.

      En este tutorial, veremos la manera de configurar un servidor DNS interno usando el software de servidor de nombres BIND (BIND9) en Ubuntu 18.04, que sus servidores pueden usar para resolver direcciones IP y nombres de hosts privados. Esto ofrece una alternativa centralizada para administrar sus nombres de hosts internos y direcciones IP privadas, lo cual es indispensable cuando su entorno abarca más de unos pocos hosts.

      Puede encontrar la versión de CentOS de este tutorial aquí.

      Requisitos previos

      Para completar este tutorial, necesitará la infraestructura siguiente. Cree cada servidor en el mismo centro de datos con red privada habilitada:

      • Un servidor de Ubuntu 18.04 nuevo que servirá como el servidor DNS primario, ns1.
      • (Recomendado) Un segundo servidor Ubuntu 18.04 que servirá como servidor DNS secundario, ns2.
      • Servidores adicionales en el mismo centro de datos que usarán sus servidores DNS.

      En cada uno de estos servidores, configure un acceso administrativo mediante un usuario sudo y un firewall siguiendo nuestra guía de configuración inicial para servidores de Ubuntu 18.04.

      Si no está familiarizado con los conceptos de DNS, se recomienda que lea al menos las tres primeras partes de nuestra Introducción a la administración de DNS.

      Ejemplo e infraestructura y objetivos

      A efectos de este artículo, supondremos lo siguiente:

      • Tenemos dos servidores que se designarán como nuestros servidores de nombres DNS. En esta guía, nos referiremos a estos como ns1 y ns2.
      • Disponemos de dos servidores clientes adicionales que usarán la infraestructura DNS que creemos. En esta guía, los llamaremos host1 y host2. Puede añadir tantos como desee en su infraestructura.
      • Todos estos servidores existen en el mismo centro de datos. Supondremos que este es el centro de datos nyc3.
      • Todos estos servidores tienen habilitada una red privada y están en la subred 10.128.0.0/16. Probablemente deba ajustar esto para sus servidores.
      • Todos los servidores se conectan a un proyecto que se ejecuta en “example.com”. Ya que nuestro sistema DNS será totalmente interno y privado, no es necesario que compre un nombre de dominio. Sin embargo, el uso de un dominio propio puede evitar conflictos con dominios públicos enrutables.

      Con estas suposiciones, decidimos que tiene sentido usar un esquema de nomenclatura que emplee “nyc3.example.com” para hacer referencia a nuestra subred o zona privada. Por tanto, el nombre de dominio completo (FQDN) privado de host1, será host1.ny3.example.com. Consulte la siguiente tabla que contiene la información pertinente:

      hostRolFQDN privadaDirección IP privada
      ns1Servidor DNS primarions1.nyc3.example.com10.128.10.11
      ns2Servidor DNS secundarions2.nyc3.example.com10.128.20.12
      host1Host genérico 1host1.nyc3.example.com10.128.100.101
      host2Host genérico 2host2.nyc3.example.com10.128.200.102

      Nota: Su configuración existente será diferente, pero los nombres de ejemplo y las direcciones IP se utilizarán para demostrar la forma de configurar un servidor DNS para que proporcione un DNS interno funcional. Debería poder adaptar fácilmente esta configuración para su propio entorno sustituyendo los nombres de hosts y direcciones IP privadas por los suyos. No es necesario usar el nombre de la región del centro de datos en su esquema de nomenclatura, pero lo utilizaremos aquí para denotar que estos hosts pertenecen a la red privada de un centro de datos concreto. Si utiliza varios centros de datos, puede configurar un DNS interno con cada centro de datos respectivo.

      Al final de este tutorial, dispondremos de un servidor DNS primario, ns1, y de forma opcional uno secundario, ns2, que servirá como respaldo.

      Comenzaremos instalando nuestro servidor DNS primario, ns1.

      Instalar BIND en servidores DNS

      Nota: El texto resaltado en rojo es importante. A menudo se usará para indicar algo que debe sustituirse por sus propios ajustes o que debería modificarse o añadirse a un archivo de configuración. Por ejemplo, si ve algo similar a host1.nyc3.example.com, sustitúyalo por el FQDN de su servidor. Asimismo, si ve host1_private_IP, sustitúyalo por la dirección IP privada de su propio servidor.

      En ambos servidores DNS, ns1 y ns2, actualice la caché del paquete apt escribiendo lo siguiente:

      Ahora instale BIND:

      • sudo apt-get install bind9 bind9utils bind9-doc

      Configurar Bind para el modo IPv4

      Antes de continuar, configuraremos BIND para el modo IPv4, ya que nuestra red privada utiliza IPv4 exclusivamente. En ambos servidores, edite la configuración predeterminada de bind9 escribiendo lo siguiente:

      • sudo nano /etc/default/bind9

      Añada “-4” al final del parámetro OPTIONS. Debería tener el siguiente aspecto:

      /etc/default/bind9

      . . .
      OPTIONS="-u bind -4"
      

      Guarde y cierre el archivo cuando haya terminado.

      Reinicie BIND para implementar los cambios:

      • sudo systemctl restart bind9

      Ahora que BIND está instalado, configuraremos el servidor DNS primario.

      Configurar el servidor DNS primario

      La configuración de BIND consta de varios archivos que se incluyen desde el archivo de configuración principal, named.conf. Estos nombres de archivos comienzan con named porque ese es el nombre del proceso que BIND ejecuta (abreviatura de “domain name daemon”). Comenzaremos configurando el archivo de opciones.

      Configurar el archivo de opciones

      En ns1, abra el archivo named.conf.options para editarlo:

      • sudo nano /etc/bind/named.conf.options

      Sobre el bloque options existente, cree un nuevo bloque ACL (lista de control de acceso) llamado “trusted”. Aquí definiremos una lista de clientes desde los que permitiremos consultas de DNS recurrentes (es decir, sus servidores que están en el mismo centro de datos que ns1). Usando nuestras direcciones IP privadas de ejemplo, añadiremos ns1, ns2, host1 y host2 a nuestra lista de clientes de confianza:

      /etc/bind/named.conf.options — 1 of 3

      acl "trusted" {
              10.128.10.11;    # ns1 - can be set to localhost
              10.128.20.12;    # ns2
              10.128.100.101;  # host1
              10.128.200.102;  # host2
      };
      
      options {
      
              . . .
      

      Ahora que tenemos nuestra lista de clientes DNS de confianza, nos convendrá editar el bloque options. En este momento, el inicio del bloque tiene el siguiente aspecto:

      /etc/bind/named.conf.options — 2 of 3

              . . .
      };
      
      options {
              directory "/var/cache/bind";
              . . .
      }
      

      Debajo de la directiva directory, añada las líneas de configuración resaltadas (y realice la sustitución en la dirección IP adecuada de ns1) para que tenga un aspecto similar a este:

      /etc/bind/named.conf.options — 3 of 3

              . . .
      
      };
      
      options {
              directory "/var/cache/bind";
      
              recursion yes;                 # enables resursive queries
              allow-recursion { trusted; };  # allows recursive queries from "trusted" clients
              listen-on { 10.128.10.11; };   # ns1 private IP address - listen on private network only
              allow-transfer { none; };      # disable zone transfers by default
      
              forwarders {
                      8.8.8.8;
                      8.8.4.4;
              };
      
              . . .
      };
      

      Cuando termine, guarde y cierre el archivo named.conf.options. En la configuración anterior se especifica que solo sus propios servidores (los “trusted”) podrán consultar su servidor DNS en busca de dominios externos.

      A continuación, configuraremos el archivo local para especificar nuestras zonas de DNS.

      Configurar el archivo local

      En ns1, abra el archivo named.conf.options para editarlo:

      • sudo nano /etc/bind/named.conf.local

      Aparte de algunos contener algunos comentarios, el archivo debería estar vacío. Aquí especificaremos nuestras zonas de reenvío e inversas. Las zonas DNS designan un alcance específico para administrar y definir registros DNS. Debido a que todos nuestros dominios estarán en el subdominio “nyc3.example.com”, usaremos eso como nuestra zona de reenvío. Debido a que las direcciones IP privadas de nuestros servidores están en el espacio IP 10.128.0.0/16, configuraremos una zona inversa para poder definir búsquedas inversas en ese intervalo.

      Añada la zona de reenvío con las siguientes líneas, sustituyendo el nombre de la zona por el suyo y la dirección IP privada del servidor DNS secundario en la directiva allow-transfer:

      /etc/bind/named.conf.local — 1 of 2

      zone "nyc3.example.com" {
          type master;
          file "/etc/bind/zones/db.nyc3.example.com"; # zone file path
          allow-transfer { 10.128.20.12; };           # ns2 private IP address - secondary
      };
      

      Suponiendo que nuestra subred privada es 10.128.0.0/16, agregue la zona inversa con las siguientes líneas (tenga en cuenta que el nombre de nuestra zona inversa comienza con “128.10”, que es el octeto inverso de “10.128”):

      /etc/bind/named.conf.local — 2 of 2

          . . .
      };
      
      zone "128.10.in-addr.arpa" {
          type master;
          file "/etc/bind/zones/db.10.128";  # 10.128.0.0/16 subnet
          allow-transfer { 10.128.20.12; };  # ns2 private IP address - secondary
      };
      

      Si sus servidores abarcan varias subredes privadas, pero están en el mismo centro de datos, asegúrese de especificar una zona adicional y un archivo de zona para cada subred distinta. Cuando termine de añadir todas las zonas deseadas, guarde el archivo named.conf.local y ciérrelo.

      Ahora que nuestras zonas están especificadas en BIND, debemos crear los archivos correspondientes de la zona de reenvío e inversa.

      Crear el archivo de la zona de reenvío

      El archivo de la zona de reenvío representa el punto en el que definimos los registros DNS para reenviar búsquedas DNS. Es decir, cuando el DNS reciba una consulta de nombre, “host1.nyc3.example.com”, por ejemplo, realizará en el archivo de la zona de reenvío para resolver la dirección IP privada correspondiente de host1.

      Crearemos el directorio en el que se alojarán nuestros archivos de zona. Según nuestra configuración de named.conf.local, esa ubicación debería ser /etc/bind/zones:

      • sudo mkdir /etc/bind/zones

      Basaremos nuestro archivo de la zona de reenvío en el archivo de zona db.local de muestra. Cópielo a la ubicación adecuada con los siguientes comandos:

      • sudo cp /etc/bind/db.local /etc/bind/zones/db.nyc3.example.com

      Ahora, editaremos nuestro archivo de la zona de reenvío:

      • sudo nano /etc/bind/zones/db.nyc3.example.com

      Inicialmente, tendrá un aspecto similar al siguiente:

      /etc/bind/zones/db.nyc3.example.com — original

      $TTL    604800
      @       IN      SOA     localhost. root.localhost. (
                                    2         ; Serial
                               604800         ; Refresh
                                86400         ; Retry
                              2419200         ; Expire
                               604800 )       ; Negative Cache TTL
      ;
      @       IN      NS      localhost.      ; delete this line
      @       IN      A       127.0.0.1       ; delete this line
      @       IN      AAAA    ::1             ; delete this line
      

      Primero, deberá editar el registro SOA. Sustituya el primer “localhost” por el FQDN de ns1 y luego “root.localhost” por “admin.nyc3.example.com”. Cada vez que edite un archivo de zona, deberá incrementar el valor serial antes de reiniciar el proceso named. Lo incrementaremos a “3”. Ahora debería tener un aspecto similar a este:

      /etc/bind/zones/db.nyc3.example.com — updated 1 of 3

      @       IN      SOA     ns1.nyc3.example.com. admin.nyc3.example.com. (
                                    3         ; Serial
      
                                    . . .
      

      A continuación, elimine los tres registros al final del archivo (después del registro SOA). Si no está seguro de las líneas que debe eliminar, estas se marcan con un comentario “delete this line” (eliminar esta línea) encima.

      Al final del archivo, añada los registros de su servidor de nombres con las siguientes líneas (sustituya los nombres por los suyos). Observe que en la segunda columna se especifica que estos son registros “NS”:

      /etc/bind/zones/db.nyc3.example.com — updated 2 of 3

      . . .
      
      ; name servers - NS records
          IN      NS      ns1.nyc3.example.com.
          IN      NS      ns2.nyc3.example.com.
      

      Ahora, añada los registros A para sus hosts que pertenecen a esta zona. Esto incluye cualquier servidor cuyo nombre deseemos que termine con “.nyc3.example.com” (sustituya los nombres y las direcciones IP privadas). Usando nuestros nombres de ejemplo y las direcciones IP privadas, añadiremos registros A para ns1, ns2, host1 y host2:

      /etc/bind/zones/db.nyc3.example.com — updated 3 of 3

      . . .
      
      ; name servers - A records
      ns1.nyc3.example.com.          IN      A       10.128.10.11
      ns2.nyc3.example.com.          IN      A       10.128.20.12
      
      ; 10.128.0.0/16 - A records
      host1.nyc3.example.com.        IN      A      10.128.100.101
      host2.nyc3.example.com.        IN      A      10.128.200.102
      

      Guarde y cierre el archivo db.nyc3.example.com.

      Nuestra zona de reenvío de ejemplo final tendrá el siguiente aspecto:

      /etc/bind/zones/db.nyc3.example.com — updated

      $TTL    604800
      @       IN      SOA     ns1.nyc3.example.com. admin.nyc3.example.com. (
                        3     ; Serial
                   604800     ; Refresh
                    86400     ; Retry
                  2419200     ; Expire
                   604800 )   ; Negative Cache TTL
      ;
      ; name servers - NS records
           IN      NS      ns1.nyc3.example.com.
           IN      NS      ns2.nyc3.example.com.
      
      ; name servers - A records
      ns1.nyc3.example.com.          IN      A       10.128.10.11
      ns2.nyc3.example.com.          IN      A       10.128.20.12
      
      ; 10.128.0.0/16 - A records
      host1.nyc3.example.com.        IN      A      10.128.100.101
      host2.nyc3.example.com.        IN      A      10.128.200.102
      

      Ahora, prosigamos con los archivos de la zona inversa.

      Crear los archivos de la zona inversa

      En los archivos de la zona inversa definimos los registros DNS PTR para las búsquedas de DNS inversas. Es decir, cuando el DNS reciba una consulta por dirección IP, “10.128.100.101”, por ejemplo, buscará el los archivos de la zona inversa para resolver el FQDN corespondiente, “host1.nyc3.example.com” en este caso.

      En ns1, para cada zona inversa especificada en el archivo named.conf.local, cree un archivo de zona inversa. Basaremos nuestros archivos de zona inversa en el archivo de zona db.127 de muestra. Cópielo en la ubicación adecuada con los siguientes comandos (sustituyendo el nombre de archivo de destino para que coincida con la definición de su zona inversa):

      • sudo cp /etc/bind/db.127 /etc/bind/zones/db.10.128

      Edite el archivo de la zona inversa que se corresponda con la zona o las zonas inversas definidas en named.conf.local:

      • sudo nano /etc/bind/zones/db.10.128

      Inicialmente, tendrá un aspecto similar al siguiente:

      /etc/bind/zones/db.10.128 — original

      $TTL    604800
      @       IN      SOA     localhost. root.localhost. (
                                    1         ; Serial
                               604800         ; Refresh
                                86400         ; Retry
                              2419200         ; Expire
                               604800 )       ; Negative Cache TTL
      ;
      @       IN      NS      localhost.      ; delete this line
      1.0.0   IN      PTR     localhost.      ; delete this line
      

      Como en el caso del archivo de la zona de reenvío, deberá editar el registro SOA e incrementar el valor serial. Debería tener un aspecto similar a esto:

      /etc/bind/zones/db.10.128 — updated 1 of 3

      @       IN      SOA     ns1.nyc3.example.com. admin.nyc3.example.com. (
                                    3         ; Serial
      
                                    . . .
      

      A continuación, elimine los dos registros al final del archivo (después del registro SOA). Si no está seguro de las líneas que eliminará, se marcan con un comentario “delete this line” (elimine esta línea) encima.

      Al final del archivo, añada los registros de su servidor de nombres con las siguientes líneas (sustituya los nombres por los suyos). Observe que en la segunda columna se especifica que estos son registros “NS”:

      /etc/bind/zones/db.10.128 — updated 2 of 3

      . . .
      
      ; name servers - NS records
            IN      NS      ns1.nyc3.example.com.
            IN      NS      ns2.nyc3.example.com.
      

      Luego añada registros PTR para todos sus servidores cuyas direcciones IP estén en la subred del archivo de zona que está editando. En nuestro ejemplo, esto incluye todos nuestros hosts, porque todos están en la subred 10.128.0.0/16. Tenga en cuenta que la primera columna consiste en los dos últimos octetos de las direcciones IP privadas de sus servidores en orden inverso. Asegúrese de sustituir los nombres y las direcciones IP privadas para que coincidan con sus servidores:

      /etc/bind/zones/db.10.128 — updated 3 of 3

      . . .
      
      ; PTR Records
      11.10   IN      PTR     ns1.nyc3.example.com.    ; 10.128.10.11
      12.20   IN      PTR     ns2.nyc3.example.com.    ; 10.128.20.12
      101.100 IN      PTR     host1.nyc3.example.com.  ; 10.128.100.101
      102.200 IN      PTR     host2.nyc3.example.com.  ; 10.128.200.102
      

      Guarde y cierre el archivo de la zona inversa (repita los pasos de esta sección si debe añadir más archivos de zona inversa).

      Nuestro archivo de zona inversa de ejemplo tiene el siguiente aspecto:

      /etc/bind/zones/db.10.128 — updated

      $TTL    604800
      @       IN      SOA     nyc3.example.com. admin.nyc3.example.com. (
                                    3         ; Serial
                               604800         ; Refresh
                                86400         ; Retry
                              2419200         ; Expire
                               604800 )       ; Negative Cache TTL
      ; name servers
            IN      NS      ns1.nyc3.example.com.
            IN      NS      ns2.nyc3.example.com.
      
      ; PTR Records
      11.10   IN      PTR     ns1.nyc3.example.com.    ; 10.128.10.11
      12.20   IN      PTR     ns2.nyc3.example.com.    ; 10.128.20.12
      101.100 IN      PTR     host1.nyc3.example.com.  ; 10.128.100.101
      102.200 IN      PTR     host2.nyc3.example.com.  ; 10.128.200.102
      

      Terminamos de editar nuestros archivos. Ahora podemos comprobar si hay errores en nuestros archivos.

      Comprobar la sintaxis de la configuración BIND

      Ejecute el siguiente comando para comprobar la sintaxis de los archivos named.conf*:

      Si sus archivos de configuración named no tienen errores de sintaxis, volverá a su intérprete de comandos de shell y no verá mensajes de error. Si existen problemas en sus archivos de configuración, revise los mensajes de error y la sección “Configurar un servidor DNS primario”, y luego pruebe named-checkconf una vez más.

      El comando named-checkzone se puede utilizar para verificar que sus archivos de zona sean correctos. En el primer argumento de este se especifica el nombre de la zona y en el segundo el archivo de zona correspondiente, que están definidos en named.conf.local.

      Por ejemplo, para comprobar la configuración de la zona de reenvío “nyc3.example.com”, ejecute el siguiente comando (cambie los nombres para que coincidan con su zona y archivo de reenvío).

      • sudo named-checkzone nyc3.example.com db.nyc3.example.com

      Para omprobar la configuración de la zona inversa “128.10.in-addr.arpa”, ejecute el siguiente comando (cambie los números para que coincidan con su zona y archivo inversos):

      • sudo named-checkzone 128.10.in-addr.arpa /etc/bind/zones/db.10.128

      Cuando no haya errores en sus archivos de configuración y zona, debería estar listo para reiniciar el servicio BIND.

      Reiniciar BIND

      Reinicie BIND:

      • sudo systemctl restart bind9

      Si configuró el firewall UFW, abra el acceso a BIND escribiendo lo siguiente:

      Con esto, servidor DNS primario quedará configurado y listo para responder a las consultas DNS. Ahora, crearemos el servidor DNS secundario.

      Configurar el servidor DNS secundario

      En la mayoría de los entornos, se recomienda configurar un servidor DNS secundario que responda a las solicitudes si el primario deja de estar disponible. Afortunadamente, el servidor DNS secundario se puede configurar de una manera mucho más sencilla.

      En ns2, edite el archivo named.conf.options:

      • sudo nano /etc/bind/named.conf.options

      En la parte superior del archivo, añada el ACL con las direcciones IP privadas de todos sus servidores de confianza:

      /etc/bind/named.conf.options — updated 1 of 2 (secondary)

      acl "trusted" {
              10.128.10.11;   # ns1
              10.128.20.12;   # ns2 - can be set to localhost
              10.128.100.101;  # host1
              10.128.200.102;  # host2
      };
      
      options {
      
              . . .
      

      Debajo de la directiva directory, añada las siguientes líneas:

      /etc/bind/named.conf.options — updated 2 of 2 (secondary)

              recursion yes;
              allow-recursion { trusted; };
              listen-on { 10.128.20.12; };      # ns2 private IP address
              allow-transfer { none; };          # disable zone transfers by default
      
              forwarders {
                      8.8.8.8;
                      8.8.4.4;
              };
      

      Guarde y cierre el archivo named.conf.options. El archivo debería ser exactamente igual al archivo named.conf.options de ns1, excepto porque debería estar configurado para escuchar en la dirección IP privada de ns2.

      Ahora, edite el archivo named.conf.local:

      • sudo nano /etc/bind/named.conf.local

      Defina las zonas esclavas que se corresponden con las zonas maestras en el servidor DNS primario. Observe que el tipo es “slave”, el archivo no contiene una ruta y hay una directiva masters que debería fijarse en la dirección IP privada del servidor DNS primario. Si definió varias zonas inversas en el servidor DNS primario, asegúrese de añadirlas en su totalidad aquí:

      /etc/bind/named.conf.local — updated (secondary)

      zone "nyc3.example.com" {
          type slave;
          file "db.nyc3.example.com";
          masters { 10.128.10.11; };  # ns1 private IP
      };
      
      zone "128.10.in-addr.arpa" {
          type slave;
          file "db.10.128";
          masters { 10.128.10.11; };  # ns1 private IP
      };
      

      Ahora, guarde y cierre el archivo named.conf.local.

      Ejecute el siguiente comando para comprobar la validez de sus archivos de configuración:

      Una vez comprobado esto, reinicie BIND:

      • sudo systemctl restart bind9

      Permita conexiones DNS al servidor alterando las reglas del firewall UFW:

      Ahora, tiene servidores DNS primario y secundario para la resolución de nombres y direcciones IP de la red privada. Ahora debe configurar sus servidores clientes para usar sus servidores DNS privados.

      Configurar clientes DNS

      A fin de que todos sus servidores en el ACL “trusted” puedan consultar sus servidores DNS, debe configurar cada uno de ellos para que utilicen ns1 y ns2 como servidores de nombres. Este proceso varía dependiendo de su sistema operativo, pero para la mayoría de distribuciones Linux implica añadir sus servidores de nombres al archivo /etc/resolv.conf.

      Clientes de Ubuntu 18.04

      En Ubuntu 18.04, la red se configura con Netplan, una abstracción que le permite escribir una configuración de red estandarizada y aplicarla a software de redes de backend no compatible. Para configurar el DNS, debemos escribir un archivo de configuración de Netplan.

      Primero, encuentre el dispositivo asociado con su red privada consultando la subred privada con el comando ip address:

      • ip address show to 10.128.0.0/16

      Output

      3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 inet 10.128.100.101/16 brd 10.128.255.255 scope global eth1 valid_lft forever preferred_lft forever

      En este ejemplo, la interfaz privada es eth1.

      A continuación, cree un nuevo archivo en /etc/netplan llamado 00-private-nameservers.yaml:

      • sudo nano /etc/netplan/00-private-nameservers.yaml

      Dentro de este, pegue el contenido siguiente. Deberá modificar la interfaz de la red privada, las direcciones de sus servidores DNS ns1 y ns2, y la zona DNS.

      Nota: Netplan usa el formato de serialización de datos YAML para sus archivos de configuración. Debido a que YAML utiliza sangría y espacios en blanco para definir la estructura de sus datos, asegúrese de que en su definición se utilice una sangría uniforme para evitar errores.

      /etc/netplan 00-private-nameservers.yaml

      network:
          version: 2
          ethernets:
              eth1:                                 # Private network interface
                  nameservers:
                      addresses:
                      - 10.128.10.11                # Private IP for ns1
                      - 10.132.20.12                # Private IP for ns2
                      search: [ nyc3.example.com ]  # DNS zone
      
      

      Guarde y cierre el archivo cuando haya terminado.

      A continuación, indique a Netplan que intente usar el nuevo archivo de configuración con netplan try. Si existen problemas que ocasionen una pérdida de redes, Netplan cancelará los cambios tras un tiempo de espera:

      Output

      Warning: Stopping systemd-networkd.service, but it can still be activated by: systemd-networkd.socket Do you want to keep these settings? Press ENTER before the timeout to accept the new configuration Changes will revert in 120 seconds

      Si la cuenta regresiva se actualiza correctamente en la parte inferior, la nueva configuración es al menos suficientemente funcional como para no interrumpir su conexión SSH. Pulse ENTER para aceptar la nueva configuración.

      Ahora, verifique la resolución DNS del sistema para determinar si se plicó su configuración de DNS:

      • sudo systemd-resolve --status

      Desplácese hasta ver la sección de la interfaz de su red privada. Debería ver las direcciones IP privadas de sus servidores DNS enumeradas primero, seguidas de algunos valores alternativos. Su dominio debería figurar en “DNS Domain”:

      Output

      . . . Link 3 (eth1) Current Scopes: DNS LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no DNS Servers: 10.128.10.11 10.128.20.12 67.207.67.2 67.207.67.3 DNS Domain: nyc3.example.com . . .

      Con esto, su cliente debería quedar configurado para usar sus servidores DNS internos.

      Clientes de Ubuntu 16.04 y Debian

      En servidores de Ubuntu 16.04 y Debian Linux, puede editar el archivo /etc/network/interfaces:

      • sudo nano /etc/network/interfaces

      En su interior, encuentre la línea dns-nameservers y anteponga sus propios servidores de nombres a la lista que se encuentra allí. Debajo de esa línea, añada una opción dns-search orientada al dominio base de su infraestructura. En nuestro caso, esto sería “nyc3.example.com”:

      /etc/network/interfaces

          . . .
      
          dns-nameservers 10.128.10.11 10.128.20.12 8.8.8.8
          dns-search nyc3.example.com
      
          . . .
      

      Guarde y cierre el archivo cuando haya terminado.

      Ahora, reinicie sus servicios de red y aplique los nuevos cambios con los comandos siguientes. Asegúrese de sustituir eth0 por el nombre de su interfaz de red:

      • sudo ifdown --force eth0 && sudo ip addr flush dev eth0 && sudo ifup --force eth0

      Con esto debería reiniciarse su red sin que se desactive su conexión actual. Si funcionó correctamente, debería ver algo como esto:

      Output

      RTNETLINK answers: No such process Waiting for DAD... Done

      Compruebe que sus ajustes se hayan aplicado escribiendo lo siguiente:

      Debería ver sus servidores de nombres en el archivo /etc/resolv.conf, además de su dominio de búsqueda:

      Output

      # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 10.128.10.11 nameserver 10.128.20.12 nameserver 8.8.8.8 search nyc3.example.com

      Con esto, su cliente quedará configurado para usar sus servidores DNS.

      Clientes CentOS

      En CentOS, RedHat y Fedora Linux, edite el archivo /etc/sysconfig/network-scripts/ifcfg-eth0. Es posible que deba sustituir eth0 por el nombre de su interfaz de red primaria:

      • sudo nano /etc/sysconfig/network-scripts/ifcfg-eth0

      Busque las opciones DNS1 y DNS2, y fije para ellas las direcciones IP privadas de sus servidores de nombres primario y secundario. Añada un parámetro DOMAIN que será el dominio básico de su infraestructura. En esta guía, sería “nyc3.example.com”:

      /etc/sysconfig/network-scripts/ifcfg-eth0

      . . .
      DNS1=10.128.10.11
      DNS2=10.128.20.12
      DOMAIN='nyc3.example.com'
      . . .
      

      Guarde y cierre el archivo cuando haya terminado.

      Ahora, reinicie el servicio de red escribiendo lo siguiente:

      • sudo systemctl restart network

      El comando puede demorarse unos segundos, pero debería hacer que regrese a la línea de comandos pronto.

      Compruebe que sus cambios se hayan aplicado escribiendo lo siguiente:

      Debería ver sus servidores de nombres y el dominio de búsqueda en la lista:

      /etc/resolv.conf

      nameserver 10.128.10.11
      nameserver 10.128.20.12
      search nyc3.example.com
      

      Su cliente ahora debería poder conectarse a sus servidores DNS y usarlos.

      Probar clientes

      Utilice nslookup para comprobar si sus clientes pueden enviar consultas a sus servidores de nombres. Debería poder hacer esto en todos los clientes que haya configurado y estén en el ACL “trusted”.

      Para los clientes de CentOS, es posible que deba instalar la utilidad con lo siguiente:

      • sudo yum install bind-utils

      Podemos comenzar realizando una búsqueda directa.

      Búsqueda directa

      Por ejemplo, podemos realizar una búsqueda directa para obtener la dirección IP de host1.nyc3.example.com ejecutando el siguiente comando:

      La consulta de “host1” se expande a “host1.nyc3.example.com” porque la opción search se fijó en su subdominio privado y las consultas de DNS intentarán realizar búsquedas en ese subdominio antes de buscar el host en otra parte. El resultado del comando anterior debería tener este aspecto:

      Output

      Server: 127.0.0.53 Address: 127.0.0.53#53 Non-authoritative answer: Name: host1.nyc3.example.com Address: 10.128.100.101

      A continuación, podemos comprobar búsquedas inversas.

      Búsqueda inversa

      Para probar la búsqueda inversa, consulte el servidor DNS con la dirección IP privada de host1:

      El resultado debería tener el siguiente aspecto:

      Output

      11.10.128.10.in-addr.arpa name = host1.nyc3.example.com. Authoritative answers can be found from:

      Si los nombres y las direcciones IP se resuelven a los valores correctos, eso significa que sus archivos de zona se configuraron correctamente. Si recibe valores inesperados, asegúrese de revisar los archivos de zona en su servidor DNS primario (por ejemplo, db.nyc3.example.com y db.10.128).

      ¡Felicitaciones! Sus servidores DNS internos ahora estarán correctamente configurados. A continuación, abordaremos el mantenimiento de sus registros de zona.

      Mantener registros DNS

      Ahora que dispone de un DNS interno activo, deberá mantener sus registros DNS para que se reflejen de forma precisa en su entorno de servidor.

      Añadir un host a un DNS

      Siempre que añada un host a su entorno (en el mismo centro de datos), le convendrá añadirlo al DNS. A continuación, se ofrece una lista de los pasos que debe seguir:

      Servidor de nombres primario

      • Archivo de zona de reenvío: añada un registro “A” para el nuevo host e incremente el valor de “Serial”.
      • Archivo de zona inversa: añada un registro “PTR” para el nuevo host e incremente el valor de “Serial”.
      • Añada la dirección IP privada del nuevo host al ACL “trusted” (named.conf.options).

      Pruebe sus archivos de configuración:

      • sudo named-checkconf
      • sudo named-checkzone nyc3.example.com db.nyc3.example.com
      • sudo named-checkzone 128.10.in-addr.arpa /etc/bind/zones/db.10.128

      A continuación, vuelva a cargar BIND:

      • sudo systemctl reload bind9

      Con esto, su servidor primario debería estar configurado para el nuevo host.

      Servidor de nombres secundarios

      • Añada la dirección IP privada del nuevo host al ACL “trusted” (named.conf.options).

      Compruebe la sintaxis de la configuración:

      A continuación, vuelva a cargar BIND:

      • sudo systemctl reload bind9

      Su servidor secundario ahora aceptará conexiones del nuevo host.

      Configure el nuevo host para que use su DNS

      • Configure /etc/resolv.conf para que use sus servidores DNS.
      • Realice una prueba usando nslookup.

      Eliminar el host del DNS

      Si elimina un host de su entorno, o quiere quitarlo del DNS, simplemente quite todo lo que se añadió cuando agregó el servidor al DNS (es decir, el procedimiento inverso de los pasos anteriores).

      Conclusión

      Ahora puede consultar las interfaces de red privada de sus servidores por nombre, en lugar de hacerlo por dirección IP. Esto hace que la configuración de los servicios y aplicaciones sea más fácil porque ya no tendrá que recordar las direcciones IP privadas, y será más fácil leer y comprender los archivos. Además, ahora podrá cambiar sus configuraciones para que apunten a un nuevo servidor en un único lugar, su servidor DNS primario, en vez de tener que editar una variedad de archivos de configuración distribuidos, lo cual facilita el mantenimiento.

      Una vez que complete su configuración de DNS interna, y que sus archivos de configuración usen FQDN privados para especificar las conexiones de red, será esencial que se realice un mantenimiento correcto de sus servidores DNS. Si los dos dejan de estar disponibles, aquellos de sus servicios y aplicaciones que dependan de ellos dejarán de funcionar correctamente. Por ello, se recomienda configurar su DNS con al menos un servidor secundario y realizar copias de seguridad funcionales de todos ellos.



      Source link

      How To Configure BIND as a Private Network DNS Server on Ubuntu 18.04


      Introdução

      Uma parte importante do gerenciamento da configuração e infraestrutura de servidores inclui a manutenção de maneira fácil de verificar as interfaces de rede e endereços IP por nome, através da configuração de um Sistema de Nome de Domínio (DNS). Ao usar os nomes de domínio totalmente qualificados (FQDNs), ao invés de endereços IP para especificar os endereços de rede, facilita-se a configuração de serviços e aplicativos e aumenta-se a capacidade de manutenção dos arquivos de configuração. Configurar seu próprio DNS para sua rede privada é uma ótima maneira de melhorar o gerenciamento dos seus servidores.

      Neste tutorial, veremos como configurar um servidor DNS interno usando o software de servidor de nomes BIND (BIND9) no Ubuntu 18.04, que pode ser usado pelos seus servidores para resolver nomes de host e endereços IP privados. Isso fornece uma maneira central de gerenciamento dos seus nomes de host e endereços IP privados internos, o que é indispensável quando seu ambiente se expande para mais de alguns poucos hosts.

      A versão CentOS deste tutorial pode ser encontrada aqui.

      Pré-requisitos

      Para completar este tutorial, você precisará das seguinte infraestrutura. Crie cada servidor no mesmo datacenter com o modo de rede privada habilitado:

      • Um servidor Ubuntu 18.04 para servir como o servidor DNS primário, o ns1
      • (Recomendado) Um segundo servidor Ubuntu 18.04 para servir como um servidor DNS secundário, o ns2
      • Servidores adicionais no mesmo datacenter que usarão seus servidores DNS

      Em cada um desses servidores, configure o acesso administrativo por um usuário sudo e um firewall seguindo nosso guia de configuração inicial do servidor Ubuntu 18.04.

      Se você não estiver familiarizado com os conceitos do DNS, é recomendável que você leia pelo menos as três primeiras partes da nossa Introdução ao gerenciamento do DNS.

      Exemplo de infraestrutura e objetivos

      Para os fins deste artigo, vamos assumir o seguinte:

      • Temos dois servidores que serão designados como nossos servidores de nome DNS. Vamos nos referir a eles como ns1 e ns2 neste guia.
      • Temos dois servidores de cliente adicionais que irão usar a infraestrutura DNS que criamos. Vamos chamá-los host1 e host2 neste guia. Você pode adicionar quantos quiser para sua infraestrutura.
      • Todos esses servidores existem no mesmo datacenter. Vamos assumir que este datacenter chama-se nyc3.
      • Todos esses servidores têm o modo de rede privada habilitado (e estão na sub-rede 10.128.0.0/16. É provável que você tenha que ajustar isso para seus servidores).
      • Todos os servidores estão conectados a um projeto executado em “example.com”. Como nosso sistema DNS será totalmente interno e privado, você não precisa comprar um nome de domínio. No entanto, usar um domínio que você possui pode ajudar a evitar conflitos com domínios de encaminhamento público.

      Com essas suposições, decidimos que é sensato usar um esquema de nomeação que usa “nyc3.example.com” para se referir à nossa sub-rede ou zona privada. Portanto, o Nome de domínio totalmente qualificado (FQDN) privado do host1 será host1.nyc3.example.com. Consulte a tabela a seguir com os detalhes relevantes:

      HostFunçãoFQDN privadoEndereço IP privado
      ns1Servidor DNS primárions1.nyc3.example.com10.128.10.11
      ns2Servidor DNS secundárion2.nyc3.example.com10.128.20.12
      host1Host genérico 1host1.nyc3.example.com10.128.100.101
      host2Host genérico 2host2.nyc3.example.com10.128.200.102

      Nota: A sua configuração existente será diferente, mas os nomes dos exemplos e endereços IP serão usados para demonstrar como configurar um servidor DNS para fornecer um DNS interno funcional. Você consegue adaptar essa configuração ao seu ambiente com facilidade, pela substituição dos nomes de host e endereços IP privados pelos seus. Não é necessário usar o nome regional do datacenter no seu esquema de nomeação, mas usamos ele aqui para denotar que esses hosts pertencem a uma rede privada de um datacenter particular. Se você usar vários datacenters, é possível configurar um DNS interno dentro de cada datacenter respectivo.

      Ao final deste tutorial, teremos um servidor DNS primário, ns1, e opcionalmente um servidor DNS secundário, ns2, que servirá como backup.

      Vamos começar pela instalação do nosso servidor DNS primário, o ns1.

      Como instalar o BIND nos servidores DNS

      Nota: As passagens que estiverem destacadas em vermelho são importantes! Normalmente, elas serão usadas para denotar algo que precisa ser substituído pelas suas próprias configurações ou que deve ser modificado ou adicionado a um arquivo de configuração. Por exemplo, se você ver algo como host1.nyc3.example.com, substitua-o pelo FQDN do seu próprio servidor. De forma similar, se você ver host1_private_IP, substitua-o pelo endereço IP privado do seu próprio servidor.

      Em ambos os servidores DNS, ns1 e ns2, atualize o cache de pacotes apt digitando:

      Agora, instale o BIND:

      • sudo apt-get install bind9 bind9utils bind9-doc

      Como configurar o Bind para o modo IPv4

      Antes de continuar, vamos colocar o BIND no modo IPv4, já que nossa rede privada usa exclusivamente o IPv4. Nos dois servidores, edite o arquivo de configuração padrão bind9 digitando:

      • sudo nano /etc/default/bind9

      Adicione “-4” ao final do parâmetro OPTIONS. Ele deve se parecer com o seguinte:

      /etc/default/bind9

      . . .
      OPTIONS="-u bind -4"
      

      Salve e feche o arquivo quando você terminar.

      Reinicie o BIND para implementar as alterações:

      • sudo systemctl restart bind9

      Agora que o BIND está instalado, vamos configurar o servidor DNS primário.

      Como configurar o servidor DNS primário

      A configuração do BIND consiste em vários arquivos, que estão incluídos no arquivo de configuração principal, o named.conf. Estes nomes de arquivos começam com named porque este é o nome do processo que o BIND executa (abreviação de “domain name daemon”). Vamos começar configurando o arquivo de opções.

      Como configurar o arquivo de opções

      No ns1, abra o arquivo named.conf.options para edição:

      • sudo nano /etc/bind/named.conf.options

      Acima do bloco options existente, crie um bloco ALC (lista de controle de acesso) new chamado “confiáveis”. É aqui que vamos definir uma lista de clientes para os quais consultas recursivas DNS serão permitidas (ou seja, seus servidores que estão no mesmo datacenter que o ns1). Usando nosso exemplo de endereço IP privado, serão adicionados o ns1, ns2, host1 e host2 à nossa lista de clientes confiáveis:

      /etc/bind/named.conf.options — 1 of 3

      acl "trusted" {
              10.128.10.11;    # ns1 - can be set to localhost
              10.128.20.12;    # ns2
              10.128.100.101;  # host1
              10.128.200.102;  # host2
      };
      
      options {
      
              . . .
      

      Agora que temos nossa lista de clientes DNS confiáveis, queremos editar o bloco options. Atualmente, o início do bloco se parece com o seguinte:

      /etc/bind/named.conf.options — 2 of 3

              . . .
      };
      
      options {
              directory "/var/cache/bind";
              . . .
      }
      

      Abaixo da diretriz directory, adicione as linhas de configuração destacadas (e substitua no endereço IP do ns1 apropriado) para que fique dessa forma:

      /etc/bind/named.conf.options — 3 of 3

              . . .
      
      };
      
      options {
              directory "/var/cache/bind";
      
              recursion yes;                 # enables resursive queries
              allow-recursion { trusted; };  # allows recursive queries from "trusted" clients
              listen-on { 10.128.10.11; };   # ns1 private IP address - listen on private network only
              allow-transfer { none; };      # disable zone transfers by default
      
              forwarders {
                      8.8.8.8;
                      8.8.4.4;
              };
      
              . . .
      };
      

      Quando você terminar, salve e feche o arquivo named.conf.options. A configuração acima especifica que apenas seus próprios servidores (os “confiáveis”) poderão consultar seu servidor DNS para domínios externos.

      Em seguida, vamos configurar o arquivo local para especificar nossas zonas de DNS.

      Como configurar o arquivo local

      No ns1, abra o arquivo named.conf.local para edição:

      • sudo nano /etc/bind/named.conf.local

      Com exceção de alguns comentários, o arquivo deve estar vazio. Aqui, vamos especificar nossa zona de encaminhamento e nossa zona inversa. As zonas de DNS designam um escopo específico para o gerenciamento e definição dos registros de DNS. Como todos nossos domínios estarão dentro do sub-domínio “nyc3.example.com”, usaremos ele como nossa zona de encaminhamento. Como os endereços IP privados dos nossos servidores estão no espaço de IP 10.128.0.0/16, uma zona inversa será configurada para que possamos definir pesquisas inversas dentro desse intervalo.

      Adicione a zona de encaminhamento com as linhas a seguir, substituindo o nome da zona pelo seu próprio e o endereço IP privado do servidor DNS secundário na diretriz allow-transfer:

      /etc/bind/named.conf.local — 1 of 2

      zone "nyc3.example.com" {
          type master;
          file "/etc/bind/zones/db.nyc3.example.com"; # zone file path
          allow-transfer { 10.128.20.12; };           # ns2 private IP address - secondary
      };
      

      Supondo que nossa sub-rede privada seja 10.128.0.0/16, adicione a zona reversa com as linhas a seguir (note que nosso nome da zona reversa inicia com “128.10”, que é a reversão do octeto reverso de “10.128”):

      /etc/bind/named.conf.local — 2 of 2

          . . .
      };
      
      zone "128.10.in-addr.arpa" {
          type master;
          file "/etc/bind/zones/db.10.128";  # 10.128.0.0/16 subnet
          allow-transfer { 10.128.20.12; };  # ns2 private IP address - secondary
      };
      

      Se seus servidores se estendem por várias sub-redes privadas mas estão no mesmo datacenter, certifique-se de especificar uma zona adicional e um arquivo de zona para cada sub-rede distinta. Quando terminar de adicionar todas as suas zonas desejadas, salve e saia do arquivo named.conf.local.

      Agora que nossas zonas estão especificadas em BIND, precisamos criar os arquivos correspondentes da zona de encaminhamento e da zona reversa.

      Como criar o arquivo da zona de encaminhamento

      O arquivo da zona de encaminhamento está onde definimos os registros DNS para pesquisas de encaminhamentos de DNS. Isso é, quando o DNS receber um nome de consulta, “host1.nyc3.example.com”, por exemplo, ele olhará no arquivo da zona de encaminhamento para resolver o endereço IP privado correspondente do host1.

      Vamos criar o diretório onde nossos arquivos de zona irão permanecer. De acordo com nossa configuração named.conf.local, esse local deve ser o /etc/bind/zones:

      • sudo mkdir /etc/bind/zones

      Vamos basear nosso arquivo da zona de encaminhamento no arquivo de zona amostral db.local. Copie-o para o local correto com os seguintes comandos:

      • sudo cp /etc/bind/db.local /etc/bind/zones/db.nyc3.example.com

      Agora, vamos editar nosso arquivo da zona de encaminhamento:

      • sudo nano /etc/bind/zones/db.nyc3.example.com

      Inicialmente, ele se parecerá com o seguinte:

      /etc/bind/zones/db.nyc3.example.com — original

      $TTL    604800
      @       IN      SOA     localhost. root.localhost. (
                                    2         ; Serial
                               604800         ; Refresh
                                86400         ; Retry
                              2419200         ; Expire
                               604800 )       ; Negative Cache TTL
      ;
      @       IN      NS      localhost.      ; delete this line
      @       IN      A       127.0.0.1       ; delete this line
      @       IN      AAAA    ::1             ; delete this line
      

      Primeiro, vamos editar o registro do SOA. Substitua o primeiro “localhost” pelo FQDN do ns1 e então substitua “root.localhost” por “admin.nyc3.example.com”. Toda vez que você editar um arquivo de zona, será necessário aumentar o valor serial antes de reiniciar o processo named. Vamos incrementá-lo para “3”. Agora, ele deve se parecer com isso:

      /etc/bind/zones/db.nyc3.example.com — updated 1 of 3

      @       IN      SOA     ns1.nyc3.example.com. admin.nyc3.example.com. (
                                    3         ; Serial
      
                                    . . .
      

      Em seguida, delete os três registros ao final do arquivo (depois do registro do SOA). Se não tiver certeza sobre quais linhas excluir, elas estão marcadas acima com um comentário “delete this line”.

      Ao final do arquivo, adicione os registros do servidor do seu nome com as linhas a seguir (substitua os nomes pelos seus próprios). Note que a segunda coluna especifica que esses registros são “NS”:

      /etc/bind/zones/db.nyc3.example.com — updated 2 of 3

      . . .
      
      ; name servers - NS records
          IN      NS      ns1.nyc3.example.com.
          IN      NS      ns2.nyc3.example.com.
      

      Agora, adicione os registros A para seus hosts que pertencem a esta zona. Isso inclui qualquer servidor cujo nome queremos que termine com “.nyc3.example.com” (substitua os nomes e endereços IP privados). Usando nossos nomes de exemplo e endereços IP privados, vamos adicionar registros A para o ns1, ns2, host1 e host2 desta forma:

      /etc/bind/zones/db.nyc3.example.com — updated 3 of 3

      . . .
      
      ; name servers - A records
      ns1.nyc3.example.com.          IN      A       10.128.10.11
      ns2.nyc3.example.com.          IN      A       10.128.20.12
      
      ; 10.128.0.0/16 - A records
      host1.nyc3.example.com.        IN      A      10.128.100.101
      host2.nyc3.example.com.        IN      A      10.128.200.102
      

      Salve e feche o arquivo db.nyc3.example.com.

      Nosso arquivo de exemplo final da zona de encaminhamento se parece com o seguinte:

      /etc/bind/zones/db.nyc3.example.com — updated

      $TTL    604800
      @       IN      SOA     ns1.nyc3.example.com. admin.nyc3.example.com. (
                        3     ; Serial
                   604800     ; Refresh
                    86400     ; Retry
                  2419200     ; Expire
                   604800 )   ; Negative Cache TTL
      ;
      ; name servers - NS records
           IN      NS      ns1.nyc3.example.com.
           IN      NS      ns2.nyc3.example.com.
      
      ; name servers - A records
      ns1.nyc3.example.com.          IN      A       10.128.10.11
      ns2.nyc3.example.com.          IN      A       10.128.20.12
      
      ; 10.128.0.0/16 - A records
      host1.nyc3.example.com.        IN      A      10.128.100.101
      host2.nyc3.example.com.        IN      A      10.128.200.102
      

      Agora, vamos seguir para o(s) arquivo(s) da zona reversa.

      Como criar o(s) arquivo(s) da zona reversa

      Os arquivos da zona reverso estão onde definimos os registros DNS PTR para pesquisas de DNS reverso. Isso é, quando o DNS recebe uma consulta pelo endereço IP, “10.128.100.101”, por exemplo, ele olhará no(s) arquivo(s) da zona reversa para resolver o FQDN correspondente, sendo ele, o “host1.nyc3.example.com” neste caso.

      No ns1, para cada zona reversa especificada no arquivo named.conf.local, crie um arquivo de zona reversa. Vamos basear nosso(s) arquivo(s) de zona reversa no arquivo de zona amostral db.127. Copie-o para o local correto com os seguintes comandos (subtituindo o nome do arquivo de destino para que ele corresponda à definição da sua zona reversa):

      • sudo cp /etc/bind/db.127 /etc/bind/zones/db.10.128

      Edite o arquivo de zona reversa que corresponde à(s) zona(s) reversa(s) definida(s) em named.conf.local:

      • sudo nano /etc/bind/zones/db.10.128

      Inicialmente, ele se parecerá com o seguinte:

      /etc/bind/zones/db.10.128 — original

      $TTL    604800
      @       IN      SOA     localhost. root.localhost. (
                                    1         ; Serial
                               604800         ; Refresh
                                86400         ; Retry
                              2419200         ; Expire
                               604800 )       ; Negative Cache TTL
      ;
      @       IN      NS      localhost.      ; delete this line
      1.0.0   IN      PTR     localhost.      ; delete this line
      

      De maneira similar ao arquivo de zona de encaminhamento, edite o registro do SOA e aumente o valor serial. Ela deve se parecer com isto:

      /etc/bind/zones/db.10.128 — updated 1 of 3

      @       IN      SOA     ns1.nyc3.example.com. admin.nyc3.example.com. (
                                    3         ; Serial
      
                                    . . .
      

      Agora, delete os dois registros ao final do arquivo (depois do registro do SOA). Se não tiver certeza sobre quais linhas excluir, elas estão marcadas acima com um comentário “delete this line”.

      Ao final do arquivo, adicione os registros do servidor do seu nome com as linhas a seguir (substitua os nomes pelos seus próprios). Note que a segunda coluna especifica que esses registros são “NS”:

      /etc/bind/zones/db.10.128 — updated 2 of 3

      . . .
      
      ; name servers - NS records
            IN      NS      ns1.nyc3.example.com.
            IN      NS      ns2.nyc3.example.com.
      

      Então, adicione os registros PTR para todos os seus servidores cujos endereços IP estão na sub-rede do arquivo de zona que está editando. No nosso exemplo, isso inclui todos os nossos hosts porque eles estão todos na sub-rede 10.128.0.0/16. Note que a primeira coluna consiste nos dois últimos octetos dos endereços IP privados dos seus servidores em reversed order. Certifique-se de substituir os nomes e endereços IP privados para corresponder aos seus servidores:

      /etc/bind/zones/db.10.128 — updated 3 of 3

      . . .
      
      ; PTR Records
      11.10   IN      PTR     ns1.nyc3.example.com.    ; 10.128.10.11
      12.20   IN      PTR     ns2.nyc3.example.com.    ; 10.128.20.12
      101.100 IN      PTR     host1.nyc3.example.com.  ; 10.128.100.101
      102.200 IN      PTR     host2.nyc3.example.com.  ; 10.128.200.102
      

      Salve e feche o arquivo de zona reversa (repita essa seção caso precise adicionar mais arquivos de zona reversa).

      Nosso arquivo de exemplo final de zona reversa se parece com o seguinte:

      /etc/bind/zones/db.10.128 — updated

      $TTL    604800
      @       IN      SOA     nyc3.example.com. admin.nyc3.example.com. (
                                    3         ; Serial
                               604800         ; Refresh
                                86400         ; Retry
                              2419200         ; Expire
                               604800 )       ; Negative Cache TTL
      ; name servers
            IN      NS      ns1.nyc3.example.com.
            IN      NS      ns2.nyc3.example.com.
      
      ; PTR Records
      11.10   IN      PTR     ns1.nyc3.example.com.    ; 10.128.10.11
      12.20   IN      PTR     ns2.nyc3.example.com.    ; 10.128.20.12
      101.100 IN      PTR     host1.nyc3.example.com.  ; 10.128.100.101
      102.200 IN      PTR     host2.nyc3.example.com.  ; 10.128.200.102
      

      Agora que terminamos de editar nossos arquivos, podemos verificá-los à procura de erros.

      Verificando a sintaxe de configuração do BIND

      Execute o comando a seguir para verificar a sintaxe dos arquivos named.conf*:

      Se seus arquivos de configuração nomeados não tiverem erros de sintaxe, você retornará ao seu prompt do shell e não verá nenhuma mensagem de erro. Se houver problemas com seus arquivos de configuração, reveja a mensagem de erro e a seção “Como configurar o servidor DNS primário”, e então tente o named-checkconf novamente.

      O comando named-checkzone pode ser usado para verificar a correção dos arquivos da sua zona. Seu primeiro argumento especifica um nome de zona e o segundo especifica o arquivo da zona correspondente, sendo que ambos estão definidos em named.conf.local.

      Por exemplo, para verificar a configuração da zona de encaminhamento “nyc3.example.com”, execute o seguinte comando (mude os nomes para que correspondam à sua zona de encaminhamento e arquivo):

      • sudo named-checkzone nyc3.example.com db.nyc3.example.com

      E para verificar a configuração da zona reversa “128.10.in-addr.arpa”, execute o seguinte comando (mude os números para que correspondam à sua zona reversa e arquivo):

      • sudo named-checkzone 128.10.in-addr.arpa /etc/bind/zones/db.10.128

      Quando todos os arquivos de configuração e zona estiverem livres de erros, você está pronto para reiniciar o serviço BIND.

      Reiniciando o BIND

      Reinicie o BIND:

      • sudo systemctl restart bind9

      Se você tiver o firewall UFW configurado, libere o acesso para o BIND digitando:

      Seu servidor de DNS primário agora está configurado e pronto para responder às consultas do DNS. Vamos seguir em frente para a criação do servidor DNS secundário.

      Configurando o servidor DNS secundário

      Na maioria dos ambientes, é uma boa ideia configurar um servidor DNS secundário que responda aos pedidos caso o primário fique indisponível. Felizmente, o servidor DNS secundário é muito mais fácil de configurar.

      No ns2, edite o arquivo named.conf.options:

      • sudo nano /etc/bind/named.conf.options

      Ao topo do arquivo, adicione o ACL com os endereços IP privados de todos os seus servidores confiáveis:

      /etc/bind/named.conf.options — updated 1 of 2 (secondary)

      acl "trusted" {
              10.128.10.11;   # ns1
              10.128.20.12;   # ns2 - can be set to localhost
              10.128.100.101;  # host1
              10.128.200.102;  # host2
      };
      
      options {
      
              . . .
      

      Abaixo da diretriz directory, adicione as seguintes linhas:

      /etc/bind/named.conf.options — updated 2 of 2 (secondary)

              recursion yes;
              allow-recursion { trusted; };
              listen-on { 10.128.20.12; };      # ns2 private IP address
              allow-transfer { none; };          # disable zone transfers by default
      
              forwarders {
                      8.8.8.8;
                      8.8.4.4;
              };
      

      Salve e feche o arquivo named.conf.options. Este arquivo deve se parecer exatamente com o arquivo named.conf.options do ns1, exceto por precisar ser configurado para escutar o endereço IP privado do ns2.

      Agora, edite o arquivo named.conf.local:

      • sudo nano /etc/bind/named.conf.local

      Definas as zonas subordinadas que correspondam às zonas mestras no servidor DNS primário. Note que como o tipo é “subordinado”, o arquivo não contém um caminho e há uma diretriz masters que deve ser configurada para o endereço IP privado do servidor DNS primário. Se você definiu várias zonas inversas no servidor DNS primário, certifique-se de adicionar todas elas aqui:

      /etc/bind/named.conf.local — updated (secondary)

      zone "nyc3.example.com" {
          type slave;
          file "db.nyc3.example.com";
          masters { 10.128.10.11; };  # ns1 private IP
      };
      
      zone "128.10.in-addr.arpa" {
          type slave;
          file "db.10.128";
          masters { 10.128.10.11; };  # ns1 private IP
      };
      

      Agora salve e feche o arquivo named.conf.local.

      Execute o comando a seguir para verificar a validade dos seus arquivos de configuração:

      Assim que for aprovado, reinicie o BIND:

      • sudo systemctl restart bind9

      Permita conexões DNS ao servidor pela alteração das regras do firewall UFW:

      Agora você tem servidores DNS primários e secundários para resoluções de nome e endereço IP da rede privada. Agora, você precisa configurar os seus servidores de cliente para usar os seus servidores DNS privados.

      Configurando os clientes DNS

      Antes que todos os seus servidores ACL “confiáveis” possam consultar seus servidores DNS, você precisa configurar cada um deles para usar o ns1 e o ns2 como servidores de nomes. Este processo varia dependendo do SO, mas para a maioria das distribuições do Linux, envolve a adição dos seus servidores de nomes ao arquivo /etc/resolv.conf.

      Clientes Ubuntu 18.04

      No Ubuntu 18.04, a rede é configurada com o Netplan, uma abstração que permite que você escreva configurações padronizadas de rede e aplique-as para softwares backend de rede incompatíveis. Para configurar o DNS, precisamos escrever um arquivo de configuração do Netplan.

      Primeiramente, encontre o dispositivo associado à sua rede privada consultando a sub-rede privada com o comando ip address:

      • ip address show to 10.128.0.0/16

      Output

      3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 inet 10.128.100.101/16 brd 10.128.255.255 scope global eth1 valid_lft forever preferred_lft forever

      Neste exemplo, a interface privada é a eth1.

      Em seguida, crie um novo arquivo em /etc/netplan chamado 00-private-nameservers.yaml:

      • sudo nano /etc/netplan/00-private-nameservers.yaml

      Cole lá dentro o seguinte conteúdo. Será necessário modificar a interface da rede privada, os endereços dos seus servidores DNS ns1 e ns2 e da zona do DNS:

      Nota: o Netplan usa o formato de serialização de dados YAML para seus arquivos de configuração. Como o YAML usa recuos e espaços em branco para definir sua estrutura de dados, certifique-se de que sua definição utilize recuos consistentes para evitar erros.

      /etc/netplan 00-private-nameservers.yaml

      network:
          version: 2
          ethernets:
              eth1:                                 # Private network interface
                  nameservers:
                      addresses:
                      - 10.128.10.11                # Private IP for ns1
                      - 10.132.20.12                # Private IP for ns2
                      search: [ nyc3.example.com ]  # DNS zone
      
      

      Salve e feche o arquivo quando você terminar.

      Em seguida, faça o Netplan tentar usar o novo arquivo de configuração utilizando o netplan try. Se houver problemas que causem uma perda de rede, o Netplan irá retroceder automaticamente as mudanças após um tempo limite:

      Output

      Warning: Stopping systemd-networkd.service, but it can still be activated by: systemd-networkd.socket Do you want to keep these settings? Press ENTER before the timeout to accept the new configuration Changes will revert in 120 seconds

      Se a contagem regressiva estiver atualizando corretamente ao fim, a nova configuração é, ao menos, funcional o suficiente para não interromper sua conexão via protocolo SSH. Pressione ENTER para aceitar a nova configuração.

      Agora, verifique o resolvedor DNS do sistema para determinar se sua configuração de DNS foi aplicada:

      • sudo systemd-resolve --status

      Role para baixo até ver a seção da sua interface de rede privada. Você deve ver os endereços IP privados dos seus servidores DNS listados primeiro, seguidos de alguns valores de retorno. Seu domínio deve estar no “DNS Domain”:

      Output

      . . . Link 3 (eth1) Current Scopes: DNS LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no DNS Servers: 10.128.10.11 10.128.20.12 67.207.67.2 67.207.67.3 DNS Domain: nyc3.example.com . . .

      Seu cliente agora deve estar configurado para usar seus servidores DNS internos.

      Clientes Ubuntu 16.04 e Debian

      Nos servidores Linux Ubuntu 16.04 e Debian, você pode editar o arquivo /etc/network/interfaces:

      • sudo nano /etc/network/interfaces

      Encontre lá dentro a linha dns-nameservers e anexe no início os seus próprios servidores de nomes na frente da lista que atualmente está lá. Abaixo dessa linha, adicione uma opção dns-search apontada para o domínio base da sua infraestrutura. No nosso caso, seria “nyc3.example.com”:

      /etc/network/interfaces

          . . .
      
          dns-nameservers 10.128.10.11 10.128.20.12 8.8.8.8
          dns-search nyc3.example.com
      
          . . .
      

      Salve e feche o arquivo quando você terminar.

      Agora, reinicie seus serviços de rede, aplicando as novas mudanças com os comandos a seguir. Certifique-se de substituir o eth0 pelo nome da sua interface de rede:

      • sudo ifdown --force eth0 && sudo ip addr flush dev eth0 && sudo ifup --force eth0

      Isso deve reiniciar sua rede sem interromper sua conexão atual. Se funcionou corretamente, você verá algo similar a isto:

      Output

      RTNETLINK answers: No such process Waiting for DAD... Done

      Verifique novamente se suas configurações foram aplicadas digitando:

      Você deve ver seus servidores de nomes no arquivo /etc/resolv.conf, além do seu domínio de busca:

      Output

      # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 10.128.10.11 nameserver 10.128.20.12 nameserver 8.8.8.8 search nyc3.example.com

      Seu cliente agora está configurado para usar seus servidores DNS.

      Clientes CentOS

      No CentOS, RedHat, e Fedora Linux, edite o arquivo /etc/sysconfig/network-scripts/ifcfg-eth0. Pode ser que você precise substituir o eth0 pelo nome da sua interface de rede primária:

      • sudo nano /etc/sysconfig/network-scripts/ifcfg-eth0

      Procure as opções DNS1 e DNS2 e defina-as para os endereços IP privados dos seus servidores de nomes primários e secundários. Adicione um parâmetro DOMAIN junto com o domínio base da sua infraestrutura. Neste guia, seria “nyc3.example.com”:

      /etc/sysconfig/network-scripts/ifcfg-eth0

      . . .
      DNS1=10.128.10.11
      DNS2=10.128.20.12
      DOMAIN='nyc3.example.com'
      . . .
      

      Salve e feche o arquivo quando você terminar.

      Agora, reinicie o serviço de rede digitando:

      • sudo systemctl restart network

      O comando pode ficar suspenso por alguns segundos, mas deve retornar você para o prompt em breve.

      Verifique se suas alterações foram aplicadas digitando:

      Você deve ver seus servidores de nomes e domínio de busca na lista:

      /etc/resolv.conf

      nameserver 10.128.10.11
      nameserver 10.128.20.12
      search nyc3.example.com
      

      Seu cliente agora deve conseguir se conectar aos seus servidores DNS e utilizá-los.

      Testando os clientes

      Use o nslookup para testar se seus clientes podem consultar seus servidores de nomes. Você deve conseguir fazer isso em todos os clientes que configurou e que estão no ACL “confiáveis”.

      Para clientes CentOS, pode ser necessário instalar o utilitário com:

      • sudo yum install bind-utils

      Podemos começar executando uma pesquisa direta.

      Pesquisa direta

      Por exemplo, é possível executar uma pesquisa direta para recuperar o endereço IP do host1.nyc3.example.com executando o seguinte comando:

      A consulta do “host1” expande-se para o “host1.nyc3.example.com” pelo fato da opção search estar configurada para o seu sub-domínio privado e as consultas de DNS tentarão procurar naquele sub-domínio antes de procurar o host em outro lugar. O resultado do comando acima se pareceria com o seguinte:

      Output

      Server: 127.0.0.53 Address: 127.0.0.53#53 Non-authoritative answer: Name: host1.nyc3.example.com Address: 10.128.100.101

      Em seguida, podemos verificar as pesquisas inversas.

      Pesquisa inversa

      Para testar a pesquisa inversa, consulte o servidor DNS com o endereço IP privado do host1:

      Deverá ver um resultado que se parece com o seguinte:

      Output

      11.10.128.10.in-addr.arpa name = host1.nyc3.example.com. Authoritative answers can be found from:

      Se todos os nomes e endereços IP resolverem os valores corretos, seus arquivos de zona estão configurados corretamente. Se receber valores inesperados, certifique-se de rever os arquivos de zona no seu servidor DNS primário (por exemplo, db.nyc3.example.com e db.10.128).

      Parabéns! Seus servidores DNS internos agora estão configurados corretamente! Agora, vamos falar sobre a manutenção dos seus registros de zona.

      Conservando os registros DNS

      Agora que você tem um DNS interno funcionando, é preciso conservar seus registros DNS para que eles reflitam com precisão o ambiente do seu servidor.

      Como adicionar um Host ao DNS

      Sempre que adicionar um host ao seu ambiente (no mesmo datacenter), adicione-o ao DNS. Aqui está uma lista de passos que você precisa seguir:

      Servidor de nomes primário

      • Arquivo de zona de encaminhamento: adicione um registro “A” para o novo host, incrementando o valor de “Serial”
      • Arquivo de zona inversa: adicione um registro “PTR” para o novo host, incrementando o valor de “Serial”
      • Adicione o endereço IP privado do seu novo host ao ACL “confiáveis” (named.conf.options)

      Teste os seus arquivos de configuração:

      • sudo named-checkconf
      • sudo named-checkzone nyc3.example.com db.nyc3.example.com
      • sudo named-checkzone 128.10.in-addr.arpa /etc/bind/zones/db.10.128

      Então, recarregue o BIND:

      • sudo systemctl reload bind9

      Seu servidor primário deve estar agora configurado para o novo host.

      Servidor de nomes secundário

      • Adicione o endereço IP privado do seu novo host ao ACL “confiáveis” (named.conf.options)

      Verifique a sintaxe de configuração:

      Então, recarregue o BIND:

      • sudo systemctl reload bind9

      Seu servidor secundário agora aceitará conexões do novo host.

      Configure o novo host para usar o seu DNS

      • Configure o /etc/resolv.conf para que use seus servidores DNS
      • Teste utilizando o nslookup

      Removendo o host do DNS

      Se você remover um host do seu ambiente ou quiser simplesmente removê-lo do DNS, remova todas as coisas que foram adicionadas quando adicionou o servidor ao DNS (ou seja, o inverso dos passos acima).

      Conclusão

      Agora, é possível consultar as interfaces de rede privadas dos seus servidores por nome ao invés de endereço IP. Isso torna mais fácil a configuração dos serviços e aplicativos porque você já não precisa se lembrar dos endereços IP privados e os arquivos serão mais fáceis de ler e entender. Além disso, é possível agora alterar suas configurações para que apontem para um novo servidor em um único lugar, o seu servidor DNS, ao invés de precisar editar uma variedade de arquivos de configuração distribuídos, facilitando a manutenção.

      Assim que tiver seu DNS interno configurado, e os seus arquivos de configuração estiverem usando FQDNs privados para especificar conexões de rede, é fundamental que seus servidores DNS estejam devidamente conservados. Se ambos ficarem indisponíveis, seus serviços e aplicativos que dependem deles deixam de funcionar corretamente. É por isso que é recomendável configurar o seu DNS com pelo menos um servidor secundário, além de manter backups funcionais de todos eles.



      Source link

      Understanding This, Bind, Call, and Apply in JavaScript


      The author selected the Open Internet/Free Speech Fund to receive a donation as part of the Write for DOnations program.

      The this keyword is a very important concept in JavaScript, and also a particularly confusing one to both new developers and those who have experience in other programming languages. In JavaScript, this is a reference to an object. The object that this refers to can vary, implicitly based on whether it is global, on an object, or in a constructor, and can also vary explicitly based on usage of the Function prototype methods bind, call, and apply.

      Although this is a bit of a complex topic, it is also one that appears as soon as you begin writing your first JavaScript programs. Whether you’re trying to access an element or event in the Document Object Model (DOM), building classes for writing in the object-oriented programming style, or using the properties and methods of regular objects, you will encounter this.

      In this article, you’ll learn what this refers to implicitly based on context, and you’ll learn how to use the bind, call, and apply methods to explicitly determine the value of this.

      Implicit Context

      There are four main contexts in which the value of this can be implicitly inferred:

      • the global context
      • as a method within an object
      • as a constructor on a function or class
      • as a DOM event handler

      Global

      In the global context, this refers to the global object. When you’re working in a browser, the global context is would be window. When you’re working in Node.js, the global context is global.

      Note: If you are not yet familiar with the concept of scope in JavaScript, please review Understanding Variables, Scope, and Hoisting in JavaScript.

      For the examples, you will practice the code in the browser’s Developer Tools console. Read How to Use the JavaScript Developer Console if you are not familiar with running JavaScript code in the browser.

      If you log the value of this without any other code, you will see what object this refers to.

      console.log(this)
      

      Output

      Window {postMessage: ƒ, blur: ƒ, focus: ƒ, close: ƒ, parent: Window, …}

      You can see that this is window, which is the global object of a browser.

      In Understanding Variables, Scope, and Hoisting in JavaScript, you learned that functions have their own context for variables. You might be tempted to think that this would follow the same rules inside a function, but it does not. A top-level function will still retain the this reference of the global object.

      You write a top-level function, or a function that is not associated with any object, like this:

      function printThis() {
        console.log(this)
      }
      
      printThis()
      

      Output

      Window {postMessage: ƒ, blur: ƒ, focus: ƒ, close: ƒ, parent: Window, …}

      Even within a function, this still refers to the window, or global object.

      However, when using strict mode, the context of this within a function on the global context will be undefined.

      'use strict'
      
      function printThis() {
        console.log(this)
      }
      
      printThis()
      

      Output

      undefined

      Generally, it is safer to use strict mode to reduce the probability of this having an unexpected scope. Rarely will someone want to refer to the window object using this.

      For more information about strict mode and what changes it makes regarding mistakes and security, read the Strict mode documentation on MDN.

      An Object Method

      A method is a function on an object, or a task that an object can perform. A method uses this to refer to the properties of the object.

      const america = {
        name: 'The United States of America',
        yearFounded: 1776,
      
        describe() {
          console.log(`${this.name} was founded in ${this.yearFounded}.`)
        },
      }
      
      america.describe()
      

      Output

      "The United States of America was founded in 1776."

      In this example, this is the same as america.

      In a nested object, this refers to the current object scope of the method. In the following example, this.symbol within the details object refers to details.symbol.

      const america = {
        name: 'The United States of America',
        yearFounded: 1776,
        details: {
          symbol: 'eagle',
          currency: 'USD',
          printDetails() {
            console.log(`The symbol is the ${this.symbol} and the currency is ${this.currency}.`)
          },
        },
      }
      
      america.details.printDetails()
      

      Output

      "The symbol is the eagle and the currency is USD."

      Another way of thinking about it is that this refers to the object on the left side of the dot when calling a method.

      A Function Constructor

      When you use the new keyword, it creates an instance of a constructor function or class. Function constructors were the standard way to initialize a user-defined object before the class syntax was introduced in the ECMAScript 2015 update to JavaScript. In Understanding Classes in JavaScript, you will learn how to create a function constructor and an equivalent class constructor.

      function Country(name, yearFounded) {
        this.name = name
        this.yearFounded = yearFounded
      
        this.describe = function() {
          console.log(`${this.name} was founded in ${this.yearFounded}.`)
        }
      }
      
      const america = new Country('The United States of America', 1776)
      
      america.describe()
      

      Output

      "The United States of America was founded in 1776."

      In this context, this is now bound to the instance of Country, which is contained in the america constant.

      A Class Constructor

      A constructor on a class acts the same as a constructor on a function. Read more about the similarities and differences between function constructors and ES6 classes in Understanding Classes in JavaScript.

      class Country {
        constructor(name, yearFounded) {
          this.name = name
          this.yearFounded = yearFounded
        }
      
        describe() {
          console.log(`${this.name} was founded in ${this.yearFounded}.`)
        }
      }
      
      const america = new Country('The United States of America', 1776)
      
      america.describe()
      

      this in the describe method refers to the instance of Country, which is america.

      Output

      "The United States of America was founded in 1776."

      A DOM Event Handler

      In the browser, there is a special this context for event handlers. In an event handler called by addEventListener, this will refer to event.currentTarget. More often than not, developers will simply use event.target or event.currentTarget as needed to access elements in the DOM, but since the this reference changes in this context, it is important to know.

      In the following example, we’ll create a button, add text to it, and append it to the DOM. When we log the value of this within the event handler, it will print the target.

      const button = document.createElement('button')
      button.textContent = 'Click me'
      document.body.append(button)
      
      button.addEventListener('click', function(event) {
        console.log(this)
      })
      

      Output

      <button>Click me</button>

      Once you paste this into your browser, you will see a button appended to the page that says “Click me”. If you click the button, you will see <button>Click me</button> appear in your console, as clicking the button logs the element, which is the button itself. Therefore, as you can see, this refers to the targeted element, which is the element we added an event listener to.

      Explicit Context

      In all of the previous examples, the value of this was determined by its context—whether it is global, in an object, in a constructed function or class, or on a DOM event handler. However, using call, apply, or bind, you can explicitly determine what this should refer to.

      It is difficult to define exactly when to use call, apply, or bind, as it will depend on the context of your program. bind can be particularly helpful when you want to use events to access properties of one class within another class. For example, if you were to write a simple game, you might separate the user interface and I/O into one class, and the game logic and state into another. Since the game logic would need to access input, such as key press and click, you would want to bind the events to access the this value of the game logic class.

      The important part is to know how to determine what object this refers to, which you can do implicitly with what you learned in the previous sections, or explicitly with the three methods you will learn next.

      Call and Apply

      call and apply are very similar—they invoke a function with a specified this context, and optional arguments. The only difference between call and apply is that call requires the arguments to be passed in one-by-one, and apply takes the arguments as an array.

      In this example, we’ll create an object, and create a function that references this but has no this context.

      const book = {
        title: 'Brave New World',
        author: 'Aldous Huxley',
      }
      
      function summary() {
        console.log(`${this.title} was written by ${this.author}.`)
      }
      
      summary()
      

      Output

      "undefined was written by undefined"

      Since summary and book have no connection, invoking summary by itself will only print undefined, as it’s looking for those properties on the global object.

      Note: Attempting this in strict mode would result in Uncaught TypeError: Cannot read property 'title' of undefined, as this itself would be undefined.

      However, you can use call and apply to invoke the this context of book on the function.

      summary.call(book)
      // or:
      summary.apply(book)
      

      Output

      "Brave New World was written by Aldous Huxley."

      There is now a connection between book and summary when these methods are applied. Let’s confirm exactly what this is.

      function printThis() {
        console.log(this)
      }
      
      printThis.call(book)
      // or:
      whatIsThis.apply(book)
      

      Output

      {title: "Brave New World", author: "Aldous Huxley"}

      In this case, this actually becomes the object passed as an argument.

      This is how call and apply are the same, but there is one small difference. In addition to being able to pass the this context as the first argument, you can also pass additional arguments through.

      function longerSummary(genre, year) {
        console.log(
          `${this.title} was written by ${this.author}. It is a ${genre} novel written in ${year}.`
        )
      }
      

      With call each additional value you want to pass is sent as an additional argument.

      longerSummary.call(book, 'dystopian', 1932)
      

      Output

      "Brave New World was written by Aldous Huxley. It is a dystopian novel written in 1932."

      If you try to send the exact same arguments with apply, this is what happens:

      longerSummary.apply(book, 'dystopian', 1932)
      

      Output

      Uncaught TypeError: CreateListFromArrayLike called on non-object at <anonymous>:1:15

      Instead, for apply, you have to pass all the arguments in an array.

      longerSummary.apply(book, ['dystopian', 1932])
      

      Output

      "Brave New World was written by Aldous Huxley. It is a dystopian novel written in 1932."

      The difference between passing the arguments individually or in an array is subtle, but it’s important to be aware of. It might be simpler and more convenient to use apply, as it would not require changing the function call if some parameter details changed.

      Bind

      Both call and apply are one-time use methods—if you call the method with the this context it will have it, but the original function will remain unchanged.

      Sometimes, you might need to use a method over and over with the this context of another object, and in that case you could use the bind method to create a brand new function with an explicitly bound this.

      const braveNewWorldSummary = summary.bind(book)
      
      braveNewWorldSummary()
      

      Output

      "Brave New World was written by Aldous Huxley"

      In this example, every time you call braveNewWorldSummary, it will always return the original this value bound to it. Attempting to bind a new this context to it will fail, so you can always trust a bound function to return the this value you expect.

      const braveNewWorldSummary = summary.bind(book)
      
      braveNewWorldSummary() // Brave New World was written by Aldous Huxley.
      
      const book2 = {
        title: '1984',
        author: 'George Orwell',
      }
      
      braveNewWorldSummary.bind(book2)
      
      braveNewWorldSummary() // Brave New World was written by Aldous Huxley.
      

      Although this example tries to bind braveNewWorldSummary once again, it retains the original this context from the first time it was bound.

      Arrow Functions

      Arrow functions do not have their own this binding. Instead, they go up to the next level of execution.

      const whoAmI = {
        name: 'Leslie Knope',
        regularFunction: function() {
          console.log(this.name)
        },
        arrowFunction: () => {
          console.log(this.name)
        },
      }
      
      whoAmI.regularFunction() // "Leslie Knope"
      whoAmI.arrowFunction() // undefined
      

      It can be useful to use the arrow function in cases where you really want this to refer to the outer context. For example, if you had an event listener inside of a class, you would probably want this to refer to some value in the class.

      In this example, you’ll create and append button to the DOM like before, but the class will have an event listener that will change the text value of the button when clicked.

      const button = document.createElement('button')
      button.textContent = 'Click me'
      document.body.append(button)
      
      class Display {
        constructor() {
          this.buttonText = 'New text'
      
          button.addEventListener('click', event => {
            event.target.textContent = this.buttonText
          })
        }
      }
      
      new Display()
      

      If you click the button, the text content will change to the value of buttonText. If you hadn’t used an arrow function here, this would be equal to event.currentTarget, and you wouldn’t be able to use it to access a value within the class without explicitly binding it. This tactic is often used on class methods in frameworks like React.

      Conclusion

      In this article, you learned about this in JavaScript, and the many different values it might have based on implicit runtime binding, and explicit binding through bind, call, and apply. You also learned about how the lack of this binding in arrow functions can be used to refer to a different context. With this knowledge, you should be able to determine the value of this in your programs.



      Source link