Tiempo requerido para la creación de un dominio
Para la gran mayoría de dominios, los servidores de nombres de la autoridad de registro delegan su función en otros que nosotros, los registrantes, elijamos. Estos normalmente pertenecen al registrador. Por ejemplo (y sin ánimo de hacer publicidad), yo adquirí mi dominio con un registrador llamando Gandi, y uso los servidores de nombres que éste me ofrece:
- DNS1: a.dns.gandi.net
- DNS2: b.dns.gandi.net
- DNS3: c.dns.gandi.net
Al crear un dominio, esta información se guarda en el servidor de nombres de la autoridad de registro (campo «NS»), apuntando así a los servidores en los que delega. Son estos últimos los que almacenan el archivo de zona (zone file).
Lo que quería comentar hoy es que la resolución de nombres no funciona inmediatamente después de adquirir el dominio. A pesar de que los nameservers de nuestro registrador sean rápidos (en mi caso 20 minutos), no podremos acceder hasta que sus homólogos en la autoridad de registro no sean actualizados. Cuando compré mi dominio, hice unas pruebas para observar esto:
[standard@localhost ~]$ dig okaeri.re ANY
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.2.rc1.fc16 <<>> okaeri.re ANY
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 19695
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;okaeri.re. IN ANY
;; AUTHORITY SECTION:
re. 4972 IN SOA nsmaster.nic.fr. hostmaster.nic.fr. 2222233858 3600 1800 3600000 5400
;; Query time: 23 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Tue Sep 11 00:06:03 2012
;; MSG SIZE rcvd: 89
Justo después de obtener mi dominio, hice una petición DNS al servidor de nombres de mi ISP (por defecto si no se especifica otro), y como era de esperar se nos responde con status: NXDOMAIN (Non Existent Domain). Ahora preguntamos directamente a mi registrador:
[standard@localhost ~]$ dig okaeri.re @a.dns.gandi.net ANY
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.2.rc1.fc16 <<>> okaeri.re @a.dns.gandi.net ANY
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 35745
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;okaeri.re. IN ANY
;; Query time: 130 msec
;; SERVER: 173.246.97.2#53(173.246.97.2)
;; WHEN: Tue Sep 11 00:08:47 2012
;; MSG SIZE rcvd: 27
Obtenemos status: REFUSED. Esto quiere decir que, por alguna razón, no se nos quiere responder. No he encontrado referencias sobre este mensaje en relación a la creación del dominio, pero imagino que será el comportamiento normal, por estar en proceso la transferencia de zonas del servidor maestro (a) a los esclavos (b y c).
Vuelvo a repetir 16 minutos después:
[standard@localhost ~]$ dig okaeri.re @a.dns.gandi.net ANY
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.2.rc1.fc16 <<>> okaeri.re @a.dns.gandi.net ANY
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22399
;; flags: qr aa rd; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;okaeri.re. IN ANY
;; ANSWER SECTION:
okaeri.re. 10800 IN A 217.70.184.38
okaeri.re. 10800 IN MX 10 spool.mail.gandi.net.
okaeri.re. 10800 IN MX 50 fb.mail.gandi.net.
okaeri.re. 10800 IN SOA a.dns.gandi.net. hostmaster.gandi.net. 1245946533 10800 3600 604800 10800
okaeri.re. 86400 IN NS b.dns.gandi.net.
okaeri.re. 86400 IN NS a.dns.gandi.net.
okaeri.re. 86400 IN NS c.dns.gandi.net.
;; Query time: 136 msec
;; SERVER: 173.246.97.2#53(173.246.97.2)
;; WHEN: Tue Sep 11 00:23:18 2012
;; MSG SIZE rcvd: 197
Bien, ahora sí que funciona (status: NOERROR). Sin embargo, sigo sin poder acceder desde mi navegador, y el comando dig me responde lo mismo que el primer código mostrado (con un status: NXDOMAIN). Esto se debe a que todavía la autoridad de registro no ha escrito el campo NS. Veámoslo:
[standard@localhost ~]$ dig re. NS
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.2.rc1.fc16 <<>> re. NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25585
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;re. IN NS
;; ANSWER SECTION:
re. 172800 IN NS g.ext.nic.fr.
re. 172800 IN NS d.nic.fr.
re. 172800 IN NS e.ext.nic.fr.
re. 172800 IN NS d.ext.nic.fr.
re. 172800 IN NS f.ext.nic.fr.
;; Query time: 42 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Tue Sep 11 00:06:39 2012
;; MSG SIZE rcvd: 110
Primero tenemos que averiguar los servidores de la autoridad de registro. Son los que aparecen en «ANSWER SECTION». Pertenecen a AFNIC (Association Française pour le Nommage Internet en Coopération). Preguntamos en este punto a cualquiera de ellos sobre nuestro dominio:
[standard@localhost ~]$ dig okaeri.re @d.nic.fr ANY
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.2.rc1.fc16 <<>> okaeri.re @d.nic.fr ANY
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 36836
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;okaeri.re. IN ANY
;; AUTHORITY SECTION:
re. 5400 IN SOA nsmaster.nic.fr. hostmaster.nic.fr. 2222233859 3600 1800 3600000 5400
;; Query time: 50 msec
;; SERVER: 194.0.9.1#53(194.0.9.1)
;; WHEN: Tue Sep 11 00:23:56 2012
;; MSG SIZE rcvd: 89
Nada. Efectivamente, y a pesar de que los servidores de Gandi están listos, los de AFNIC todavía siguen sin ver el dominio.
[standard@localhost ~]$ dig okaeri.re @d.nic.fr ANY
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.2.rc1.fc16 <<>> okaeri.re @d.nic.fr ANY
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36289
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;okaeri.re. IN ANY
;; AUTHORITY SECTION:
okaeri.re. 172800 IN NS a.dns.gandi.net.
okaeri.re. 172800 IN NS b.dns.gandi.net.
okaeri.re. 172800 IN NS c.dns.gandi.net.
;; Query time: 51 msec
;; SERVER: 194.0.9.1#53(194.0.9.1)
;; WHEN: Tue Sep 11 03:23:59 2012
;; MSG SIZE rcvd: 88
Ahora sí que sí. Volví a comprobar tres horas después, y ya era visible. Podía acceder a mi dominio desde el navegador. No está nada mal. En tan poco tiempo se tiene un dominio listo.
Para reducir recursos, las peticiones DNS se guardan en una caché, durante un tiempo llamado «Time To Live» (TTL), que establecemos en el archivo de zona. Pero ¿nos afecta el TTL en el caso de un nuevo dominio? No, por la sencilla razón de que si el dominio es nuevo, no está en ninguna caché, porque antes no existía. El retraso de tres horas visto aquí es debido a la tardanza en escribir el campo NS en la autoridad de registro, que está fuera de nuestro control.