Configurar o DNS bind9 como mestre do noso dominio aloxado en namecheap

Neste artigo trataremolo caso de ter un novo hosting para nosa web e querer xestionar un server DNS propio para a xestión do dominio e ter xa mercado un nome de dominio, neste caso na empresa namecheap, para permitir que sexa accesible a tódolos dispositivos do mundo a través da internet.

Teoría sobre rexistros de recursos “RR” DNS

Este non pretende ser un artigo teórico polo que me centro na explicación dos rexistros de recursos “RR”.

Tódolos rexistros de de recursos, se definen en cada liña do arquivo coa base de datos, teñen o seguinte formato:

Propietario Indica o nome de dominio DNS que posee o rexistro de recursos.
Este nome é o mesmo que o do nodo da árbore da consola onde se atopa o rexistro de recursos.
TTL (Tempo de vida) Para a maior parte dos RR, este campo é opcional.
Indica o espazo de tempo utilizado por outros servidores DNS para determinar canto tarda a información na súa caché en caducar o rexistro e descartalo.
Clase Campo obrigatorio que contén texto nemotécnico estándar que indica a clase do rexistro de recursos.
Por exemplo “IN” para indicar que o RR pertence a clase Internet.
Tipo Contén un texto nemotécnico que indica o tipo de recurso definido. Por exemplo “A” indica que sería unha IPv4. É un campo obrigatorio.
Datos específicos do rexistro Campo de lonxitude variable e obrigatorio con información que describe ao recurso.

Tipos de rexistros máis usados:

A:

Descripción: Address (Dirección). Este rexistro se usa para traducir nomes de host a direccións IPv4.
Sintaxe: propietario clase ttl A IP_version4
Exemplo: blog.deliodc.com IN A 80.211.171.231

AAAA:

Descripción: Address (Dirección). Este rexistro se usa para traducir nomes de host a direccións IPv6.
Sintaxe: propietario clase ttl AAAA IP_version6
Exemplo: hostIPv6.exemplo.com. IN AAAA 1234:0:1:2:3:4:567:89ab

CNAME:

Descripción: Canonical Name (Nome Canónico).
Úsase para crear nomes de host adicionáis, é un alias. Hai que ter en conta que o nome do host ao que fas referencia debe haber sido definido previamente cun rexistro de tipo “A” ou “AAAA”.
Este tipo de rexistro é moi útil para a definición de subdominios, así como hosts virtuais que poidan usar servidores como o HTTPD Apache e así servir webs diferentes.
Sintaxe: propietario ttl clase CNAME nomeCanónico
Exemplo: www.deliodc.com CNAME blog.deliodc.com.
Onde blog.deliodc.com debe estar definido previamente nun rexistro de tipo A ou AAAA

NS:

Descripción: Name Server (Servidor de Nomes).
Indica qué servidores de nomes teñen total autoridade sobre un dominio concreto.
Cada dominio pódese asociar a calquer cantidade de servidores de nomes.
Sintaxe: propietario ttl IN NS nomeServidorNomeDominio
Exemplo: Mail eXchange (Rexistro de Intercambio de Correo).
Asocia un nome de dominio a unha lista de servidores de intercambio de correo para ese dominio.

MX:

Descripción: Propietario ttl clase MX preferencia hostIntercambiadorDeCorreo
Sintaxe: exemplo.com. MX 10 servidorcorreo1.exemplo.com.
Exemplo: O número, neste caso 10, indica a preferencia, e ten sentido no caso de existir varios servidores de correo.
A menor número maior é a preferencia.

PTR:

Descripción: Pointer (Indicador). Traduce direccións IP en nomes de dominio. También conocido como ‘rexistro inverso’, xa que funciona a inversa do rexistro “A”.
Sintaxe: propietario ttl clase PTR nomeDominioDestino
Exemplo: 1.0.0.10.in-addr.arpa. PTR host.exemplo.com.

SOA:

Descripción: Start Of Authority (Autoridad da zona). Proporciona información sobre o servidor DNS primario da zona.
Sintaxe: propietario clase SOA servidorNomes EmailpersoaResponsable (numeroSerie intervaloActualización intervaloReintento caducidade tempoDeVidaMínimo).
Código de exemplo:
; O punto e coma indica o inicio dun comentario, non é procesado.

@ IN SOA nombreServidor.exemplo.com. administracion.exemplo.com. (
 1 ; Número de serie, podes usar o formato que queiras, sempre e cando
   ; actualices este número ao modificar a base de datos cun número superior.

 3600 ; actualizar [1h]
 600 ; reintentar [10m]
 86400 ; caducar [1d]
 3600) ; TTL mínimo [1h]

O propietario (servidor DNS principal) se especifica cunha “@” porque o nome do dominio é o mesmo que o orixen de todolos datos da zona (exemplo.com, ou no caso do meu blog deliodc.com). Se trata dunha convención de nomenclatura estándar para rexistros de recursos e se usa máis a miudo nos rexistros SOA. O número de serie é o número da versión de esta base de datos.|

TXT:

Descripción: TeXT (Información textual).
Permite aos dominios identificarse de modos arbitrarios.
Sintaxe: propietario ttl clase TXT cadeaDeTexto.
Exemplo: exemplo.com. TXT “Exemplo de información do nome de dominio adicional.”

SPF:

Descripción: Sender Policy Framework.
É un rexistro de tipo TXT que vai creado nunha zona directa do DNS, na cal se pon as informacións do propio servidor de correo coa sintaxis SPF.
Se utiliza para evitalo envío de correos suplantando identidades.
Polo tanto, axuda a combatilo SPAM, xa que, neste rexistro se especifica cal ou cales hosts están autorizados a enviar correo dende o dominio dado.
O servidor que recibe, consulta o SPF para comparar a IP dende a cal lle chega, cos datos deste rexistro.
Sintaxe: propietario ttl clase IN SPF cadeaDeTexto
Exemplo: exemplo.com IN SPF "v=spf1 a:mail.exemplo.com -all"

Instalación e configuración do Bind9 en Debian 9

Este artigo vai da súa instalación en Debian, Debian adoita poñer outros nomes aos aplicativos con respecto aos que poñen os fabricantes, para outras distros busca por “named”.

Instalación dos paquetes en Debian

Non ten moita historia, todo se fai con apt dende os repos oficiáis de Debian.

Actualizámolos repos e procedemos coa instalación dos paquetes precisos:
sudo apt-get update && sudo apt-get install bind9 bind9utils bind9-doc

Configuración de bind9

AVISO: Como en namecheap nos van pedir 2 servidores dns vamos ter que facer “trampa” facendo que o servidor DNS secundario apunte ao primario que sería o mestre do domino. Esto o fago por que non dispoño dun segundo DNS e namecheap se empeñan en exisir un segundo dns.

Configurar /etc/hosts do hosting para que apunte aos nosos servidores DNS

Engadimos os seguintes rexistros ao /etc/hosts do noso hosting:
127.0.0.1           localhost           # Este xa viría no propio arquivo.
<a.nosa.ip.pública> ns1.deliodc.com ns1 # A ip pública do noso hosting (sen < >), seguido da url ao noso servidor dns co noso nome dominio.
<a.nosa.ip.pública> ns2.deliodc.com ns2 # O mesmo que antes, mudando o ns1 por ns2.
Actualizamos a información do sistema con:
sudo hostname -F /etc/hostname

Configuración do server Master

Configuración do server que actuará como mestre da zona.

AVISO: Como so dispoño de 1 engado un rexistro para “simular” o servidor escravo que require namecheap.

Arquivo de opcións /etc/bind/named.conf.options

En “/etc/bind/named.conf.options” se engaden ás opcións que van en blocos “options {}.

Editamos este arquivo para atender só as peticións no noso dominio.

sudo vi /etc/bind/named.conf.options
Aspecto por defecto de /etc/bind/named.conf.options (sen os comentarios):
options {
        directory "/var/cache/bind";

        dnssec-validation auto;

        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };
};

Como queremos que o servidor non resolva peticións de outros nomes de dominios que non xestiona o configuraremos coma “authoritative-only”, xa que non nos interesa habilitar a recursión neste server, o que nos faría estar trasladando peticións a outros DNS externos e esto pode facer que saturen o teu servidor DNS ou o usen para enviar consultas “encubertas” a outros servidores DNS externos e facer que o teu sexa recoñecido como atacante nun DDOS.

Se non pode resolver as peticións do dominio, non consulta a outros servidores DNS para resolvela petición do cliente, moi recomendable se queres ter un DNS “sinxelo”.

Engadimos as novas liñas en /etc/bind/named.conf.options :
options {
        directory "/var/cache/bind";

        ;# Deshabilitámola recursión das consultas DNS:
        recursion no;

        ;# Non permitimos a transferencia de consultas a través do noso DNS:
        allow-transfer { none; };

        dnssec-validation auto;

        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };
};

Gardamos as mudanzas e pechámolo arquivo.

Creación de arquivos de zona

Estos son os arquivos nos que se definen os rexistros que indican a que ip se resolve un nome de dominio.

O nome do ficheiro soe ter o formato “db.<nome_dominio>”.

NOTA: Unha vez máis lembro que estou a usar o meu dominio deliodc.com coma exemplo, ti has de configurar o teu.

Copiamos o arquivo de exemplo /etc/bind/db.local para ter unha base coa que traballar no meu caso lle chamo “db.deliodc.com”:
cp -v /etc/bind/db.local /etc/bind/db.deliodc.com
Copiamos o arquivo de zona inversa “/etc/bind/db.127” no meu caso lle chamo “db.80.211.171.231”:
cp -v /etc/bind/db.127 /etc/bind/db.80.211.171.231

Definición da nosa zona

No meu caso sería “deliodc.com” e o arquivo estaría en “/etc/bind/db.deliodc.com”.

O abrimos con permisos de root:
vi /etc/bind/db.deliodc.com
O arquivo terá esta aparencia que é a que ven por defecto /etc/bind/db.local:
;
; BIND data file for local loopback interface
;
$TTL    604800
@       IN      SOA     localhost. root.localhost. (
                              2         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800)       ; Negative Cache TTL
;
@       IN      NS      localhost.
@       IN      A       127.0.0.1
@       IN      AAAA    ::1

Aquí viría a parte na que configuras os teus subdominios.

NOTA: Repito os TEUS non utilices deliodc.com

No meu caso o meu arquivo “/etc/bind/db.deliodc.com” quedaría así:
$TTL    3600
@       IN      SOA     ns1.deliodc. administrador.deliodc.com. (
                        2018011618      ; Serial
                        3600            ; Refresh (1h)
                        600             ; Retry      (10m)
                        86400           ; Expire     (1d)
                        3600)           ; Negative Cache TTL (1d)

; DNS Servers:
                IN      NS      ns1.deliodc.com.
                IN      NS      ns2.deliodc.com.
ns1             IN      A       80.211.171.231
ns2             IN      A       80.211.171.231

; Other A records and subdomains:
@               IN      A       80.211.171.231
www             IN      A       80.211.171.231
blog            IN      A       80.211.171.231

Fíxate en que eliminei o comentario de cabeceira, todo o que vai despois de “;” ata o seguinte salto de liña, Bind o considera un comentario e non o procesa.

AVISO: Os nomes de dominio sempre han de rematar en punto non é unha errata nomes como “ns1.deliodc.com.”

Na liña:

@       IN      SOA     ns1.deliodc. admin.deliodc.com. (

Definimos que “ns1.deliodc.” (engadir o punto ao final) é o servidor de nomes autorizado da zona, logo ven seguido dunha dirección de email para contactar co administrador da zona, onde o “@” é sustituido por un punto.

Na liña:

                        2018011618      ; Serial

Definimos o número de serie do rexistro, este se ha de incrementar sempre que fagamos cambios no arquivo.

AVISO: OLLIÑO CO NÚMERO DE SERIE.

Un dos principais problemas a hora da propagación é que alguén meta un número de máis, cando isto pasa é un follón decirlle literalmente ao resto do mundo que o novo número de serie que queiras indicar é superior ao anterior, soe ser un dos quebradeiros de cabeza máis comúns. A min nunca me sucedeu pero supoño que se “soluciona” agardando a que os outros DNS xa non teñan en caché a túa zona.

No meu caso para o número de serie utilizo o formato “ano,mes,día,hora”:
AAAAMMDDHH

Valdría comezar a contar dende 1, sempre e cando os posteriores números sexan superiores para que os outros DNS recoñezan que hai unha nova versión do mesmo.

O importante é que sempre utilices o teu formato e este se vaia incrementado numéricamente.

Crear arquivo coa zona inversa

A zona inversa é “opcional” non tela só supón que nadie podrá consultar con que dominios está asociada a ip pública.

AVISO: Volvo a repetir que en estos exemplos utilizo os meus datos, ti terás que utilizar a túa ip.

Para crear a zona inversa de deliodc.com. fago o arquivo /etc/bind/db.80.211.171.231

Podemos copiar o arquivo que ven por defecto para ter outra prantilla da que partir:
sudo cp -vp /etc/bind/db.127 etc/bind/db.<a.ip.normal.do.teu.sitio>

O nome do arquivo serve para identificalo, lle poñemos a ip normal sen poñela inversa, mesmo lle podes poñer reverse.exemplo.com como nome de arquivo, mais por convención adoita ser db.ip.

O arquivo terá esta aparencia que é a que ven por defecto /etc/bind/db.127:
;
; BIND data file for local loopback interface
;
$TTL    604800
@       IN      SOA     localhost. root.localhost. (
                              1         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800)       ; Negative Cache TTL
;
@       IN      NS      localhost.
1.0.0   IN      PTR     localhost.

Podrás ver que o número de serie é “1 “ , calquer número superior coma “2” ou “2018011700” sera considerado nova versión e fará que os outros DNS actualicen a información sobre a túa zona.

O editamos e facemos unha configuración similar a feita anteriormente coa zona do dominio:
$TTL    3600
@       IN      SOA     deliodc.com. admin.deliodc.com. (
                        2018011700      ; Serial
                        3600            ; Refresh
                        600             ; Retry
                        86400           ; Expire
                        3600)          ; Negative Cache TTL
; Name servers:
        IN      NS      ns1.deliodc.com.
        IN      NS      ns2.deliodc.com.

; PTR Records:
231     IN      PTR     ns1.deliodc.com.
231     IN      PTR     ns2.deliodc.com.
231     IN      PTR     www.deliodc.com.
231     IN      PTR     blog.deliodc.com.

Unha vez máis lembro que o ns2 é por que namecheap pide indicar 2 DNS, e un “truco” para poder ter un só servidor e que nos permitan xestionar a nós o DNS.

Gardámolos cambios e pechámolo arquivo.

Agregar os nosos arquivos de zona a configuración de bind /etc/bind/named.conf.local

Estas zonas son ás que xestiona o noso servidor DNS, e no arquivo “/etc/bind/named.conf.local” é onde lle indicamos a bind a definición das zonas cunhas definicións de zona moi básicas xa que enlazaremos estas definicións aos arquivos creados previamente.

AVISO: No meu exemplo uso o meu domino deliodc.com non te esquezas de usar o teu.

IMPORTANTE: Este paso é crucial, xa que se non por moito arquivo de zona que definamos bind non o vai a cargar en memoria e polo tanto non terá ás nosas zonas definidas.

Editamos “/etc/bind/named.conf.local” e engadimos ás seguintes liñas ao final do mesmo:
zone "deliodc.com" {
    type master;
    file "/etc/bind/db.deliodc.com";
};
Liña: Explicación:
1 Inicio da definición da zona na configuración de bind, no meu caso lle indico “deliodc.com”
2 Indica que será de tipo maestro, non colle a configuración de outro servidor DNS.
3 Moi importante indicamos onde está o arquivo que define a zona, cuxo contido podría ir aquí mesmo pero sempre é bo compartimentar ás configuracións.

Creación de zona de consultas inversas

As consultas inversas se trata de que aportando unha ip obteñamos o dominio asociado a ela.

NOTA: Lembra que estou usando a miña IP pública, ti terás que configurar a túa.

No noso caso contamos só cunha IP pública a cal é a única do noso dominio “80.211.171.231” (non te esquezas de usar a túa IP pública) polo tanto o nome da zona o poñemos coa IP ao revés da seguinte maneira “231.171.211.80” logo se engade “.in-addr.arpa” quedando todo como:

231.171.211.80.in-addr.arpa

Voltamos a editar o arquivo “/etc/bind/named.conf.local” para indicar a nova zona inversa e onde está o seu ficheiro de definición da zona.

O final do arquivo /etc/bind/named.conf.local engadimos:
zone "231.171.211.80.in-addr.arpa"{
        type master;
        file "/etc/bind/db.80.211.171.231";
};

Como podes observar pola estructura da definición e similar a da zona “normal”

Gardamos os cambios e pechámolo arquivo.

Probando que as configuracións estén correctas

Unha vez creado os arquivos coa configuración de zona, rexistradas ditas zonas no named.conf.local, antes de cargar a nova config ou iniciar o bind, é mellor comprobar a súa configuración.

Para comprobar configuracións hai 2 programas que veñen coa instalación de bind:

named-checkconf

Na Documentación oficial de named-checkconf se poden atopar moitos parámetros de interés, eu só me limitarei aos máis básicos “-z” e “-p”.

Comprobar se as configuracións básicas do servidor en named.conf e ficheiros enlazados están OK a nivel de sintaxe (require root):
named-checkconf -z

Nos dará como resultado un resume do estado dos ficheiros que atopou, hai que fixarse se atopa todos os que creamos, se non é que nos faltou indicar algún “file”.

Exemplo de execución de “named-checkconf -z”:
# named-checkconf -z

zone deliodc.com/IN: loaded serial 2018011618
zone 231.171.211.80.in-addr.arpa/IN: loaded serial 2018011700
zone localhost/IN: loaded serial 2
zone 127.in-addr.arpa/IN: loaded serial 1
zone 0.in-addr.arpa/IN: loaded serial 1
zone 255.in-addr.arpa/IN: loaded serial 1

Como se pode ver atopa ás zonas “deliodc.com” e “231.171.211.80.in-addr.arpa”.

Se queremos ver toda a configuración que sería cargada, esto é procesando todos os ficheiros que se enlazan entre eles e devolvendo a saída coma se fora 1 so ficheiro, fariamos uso de:

# named-checkconf -p

Omito o seu resultado por ser demasiado longo.

Na súa documentación oficial podemos leer o seguinte:

-p This option prints out the named.conf and included files in canonical form if no errors were detected. See also the -x option.

O -x sería para ofuscar os datos sensibles por se queremos compartir os resultados do comando con outra xente.

Usando named-checkzone

Unha vez comprobada que a configuración xeral está ben, vamos comprobar a configuración das novas zonas.

Como sempre na Documentación oficial dan tódolos detalles e parámetros admitidos, eu só farei un uso básico da ferramenta.

Como root comprobamos se as zonas configuradas están ben, primeiro “deliodc.com” definida en “/etc/bind/db.deliodc.com”:
named-checkzone deliodc.com /etc/bind/db.deliodc.com
Se todo vai ben nos devolverá unha mensaxe parecida a esta amosando o número de serie introducido na zona:
zone deliodc.com/IN: loaded serial <número de serie>
OK
Para zona inversa o uso do comando sería case o mesmo:
named-checkzone 231.171.211.80.in-addr.arpa db.80.211.171.231

Con isto xa deberías de estar seguro de que ás configuracións están ben definidas e listas para ser cargadas por bind, sen haberte arriscado a lanzar o inicio de bind e que este fixera ditas comprobacións.

Iniciar o servidor DNS bind9

Na sección das ferramentas “named-checkconf” e “named-checkzone” poidemos ver como comprobar de xeito manual sen iniciar bind que a config esté OK.

Nesta sección nos centraremos no servizo xa que nos interesa que esté o maior tempo posible activo resolvendo nomes do noso dominio.

Iniciar o servizo bind9

Facemos uso dos seguintes comandos coma root, engado 1 segundo de repouso para que status lle de tempo a reflexalos posibles logs de erro:
systemctl start bind9 && sleep 1 && systemctl status bind9

Se todo vai ben, se verá o verde e sen mensaxes de erro.

Habilitar o inicio automático de bind9 coa máquina

Esto é opcional, mais se temos un servidor de producción nos interesará que sempre esté activo o DNS, se non nadie vai poder resolver o nome de dominio a nosa ip. So estariamos accesibles a través da ip.

Habilitar o inicio automático do servizo co inicio da máquina:
systemctl enable bind9

Comprobacións de DNS lado cliente

Ata agora vimos como comprobar o backend a parte interna do servidor, mais unha vez habilitado nos interesará facerlle probas manuais para ver que esté a resolver ben e así descubrir pequenos erros que non sexan de sintaxe.

Comprobando se o DNS resolve ben as peticións con dig

Agora xa teriamos un servidor DNS xestor do noso dominio e resolvedor das direccións tanto do dominio como dos subdominios, mais se queremos comprobar que resolve ben, podemos facelo dende o noso computador alleo ao server ou outro (tamén a nivel local con 127.0.0.1 mais dende fora estaremos seguros de que funciona ben).

Usamos dig para resolver deliodc.com pedíndolle que resolva a consulta coa IP pública do noso hosting para que sexa o noso bind9 o que resolva a petición:
 dig @80.211.171.231 deliodc.com

; <<>> DiG 9.11.2-P1 <<>> @80.211.171.231 deliodc.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45489
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;deliodc.com.                   IN      A

;; ANSWER SECTION:
deliodc.com.            3600    IN      A       80.211.171.231

;; AUTHORITY SECTION:
deliodc.com.            3600    IN      NS      ns1.deliodc.com.
deliodc.com.            3600    IN      NS      ns2.deliodc.com.

;; ADDITIONAL SECTION:
ns1.deliodc.com.        3600    IN      A       80.211.171.231
ns2.deliodc.com.        3600    IN      A       80.211.171.231

;; Query time: 64 msec
;; SERVER: 80.211.171.231#53(80.211.171.231)
;; WHEN: Ven Xan 19 17:23:32 CET 2018
;; MSG SIZE  rcvd: 124
Se nos fixamos en “ANSWER SECTION” nos devolve que deliodc.com se resolve como asociada a 80.211.171.231 :
;; ANSWER SECTION:
deliodc.com.            3600    IN      A       80.211.171.231

Esto indica que o servidor DNS está a resolver ben a petición, no caso de que non a resolvera non aparecería a IP.

Logo en “AUTHORITY SECTION” veremos que os encargados de dita zona son os servidores de nomes asignados na mesma:
;; AUTHORITY SECTION:
deliodc.com.            3600    IN      NS      ns1.deliodc.com.
deliodc.com.            3600    IN      NS      ns2.deliodc.com.

Salvo que o control do dominio non esté transferido de todo e todavía esté no control de namecheap ou a compañía coa que contrámolo dominio que xa veremos nas seguintes seccións como facelo, ou ben pode indicar a IP pública do servidor, esto último tamén sería aceptable a falta de configurar o dominio para que apunte ao noso BIND.

Configurando namecheap para que apunte aos nosos DNS

Unha vez vemos que todo funciona correctamente tanto en local (dentro do noso propio hosting) e remotamente (resolvemos os nomes de dominio e subdominio dende o noso computador indicando a IP pública do noso DNS).

Pasamos a configurar o noso dominio, neste caso o meu “deliodc.com” o cal xa paguei por él.

Acceso ao panel de administración do dominio

Vamos a https://www.namecheap.com/ , nos damos de alta co noso usuario.

Na sección “Dashboard” https://ap.www.namecheap.com/

Seleccionamos no listado o noso dominio, e prememos no botón “manage”.

Xestión do dominio

Baixamos ata a subsección “NAMESERVERS”, no combo despregable seleccionamos “Custom DNS”, nel engadimos os dous campos que nos requiren que son 2 servidores DNS.

ns1.deliodc.com
ns2.deliodc.com

NOTA: Por eso fixen un “falso” ns2.deliodc.com , para que “traguen” e me permitan xestionar o DNS do meu dominio.

Dámoslle a “v” verde ou a confirmar a mudanza.

Básicamente este paso fará que namecheap redirixa ns1.deliodc.com e ns2 como servidores DNS do dominio e aquí é a parte na que se “encola” o noso servidor DNS persoal ao nome rexistrado con https://namecheap.com

E listo, agora teremos que agardar o minuto para que namecheap configure internamente esta mudanza, e logo para poder resolver o noso dominio cos nosos DNS dende outro servidor DNS calquera, vamos en calquer equipo de internet.

Normalmente para a propagación “total” do novo cambio de dominio, deberemos agardar sobre 24 ou 48 horas, mentres se vai propagando a nova configuración e os DNS do mundo van actualizando as súas cachés.

Logo dun día ou un bo tempo… veremos que xa nos resolve ben coa nosa ip pública do hosting e como donos do noso dominio:

dig deliodc.com

; <<>> DiG 9.11.2-P1 <<>> deliodc.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58224
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;deliodc.com.                   IN      A

;; ANSWER SECTION:
deliodc.com.            3600    IN      A       80.211.171.231

;; Query time: 56 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Ven Xan 19 17:45:36 CET 2018
;; MSG SIZE  rcvd: 56

Agora non teremos que facer nada máis e xa estamos no “aire” en internet :)

Logo podremos engadir e retirar subdominos configurando os arquivos de zona correspondentes e sempre incrementando o número de serie ;)

Tamén presta atención aos logs pois podrás comezar a recibir moooitas peticións “estranas” hai moito bot tratando de explotar servidores DNS para facelos atacar os seus obxetivos.