Cuando un dominio no resuelve en los resolvers DNS públicos de Google (8.8.8.8 y 8.8.4.4), lo primero que piensas es que tiene algún fallo en sus registros DNS (los NS de la zona, por ejemplo), que el dominio ha caducado…etc. Pero cuando compruebas que todo es correcto y que el resto de resolvers responden bien a a las consultas DNS, entonces se acaban las ideas.

Buscando errores similares, llegué a un artículo que comentaba:

Google’s Public DNS service is now performing DNSSEC validation for all DNS queries by default!
…
We have recently enabled validation by default globally, and you should now get SERVFAIL for validation failures. Apologies again for the original, unclear announcement.

Es decir, Google ha habilitado la validación DNSSEC por defecto. El caso que nos ocupaba, sin embargo, no tenía registro DNSSEC alguno en la zona y aún así, fallaba. Haciendo pruebas, usando la opción +cd del comando dig, que evita cualquier comprobación DNSSEC, la resolución era correcta (en este ejemplo, usamos un dominio de DNSSEC de pruebas):

$ dig www.dnssec-failed.org @8.8.8.8 +short +cd
68.87.109.242
69.252.193.191

pero, sin dicha opción, devuelve error:

$ dig www.dnssec-failed.org @8.8.8.8
;; Got answer:
;; ->>HEADERSERVFAIL, id: 61010

Por tanto, hay algo relativo a DNSSEC que está fallando. Tirando del hilo, existe un registro DNS llamado DS (punto 5 del RFC 4034) que se usa para comprobar la confianza de la zona padre a la zona hija (recordemos la estructura de un dominio como un árbol de zonas). En el caso del dominio anterior (y en el caso del dominio con el cuál teníamos problemas), este registro existe:

$ dig ds dnssec-failed.org +short
106 5 2 AE3424C9B171AF3B202203767E5703426130D76EF6847175F2EED355 F86EF1CE
106 5 1 4F219DCE274F820EA81EA1150638DABE21EB27FC


Pero como decía, en la zona del dominio con el que teníamos el problema, no había nada relativo a DNSSEC, por tanto ¿de dónde sale ese registro DS?

Si miramos las zonas de los TLDs, vemos que la mayoría tienen este registro ya añadido. Por ejemplo, para el .org, se puede preguntar a un NS raíz por su registro:


$ dig ds org @i.root-servers.net. +short
9795 7 2 3922B31B6F3A4EA92B19EB7B52120F031FD8E05FF0B03BAFCF9F891B FE7FF8E5
9795 7 1 364DFAB3DAF254CAB477B5675B10766DDAA24982


y si preguntamos a los servidores NS de la zona .org por el DS del dominio dnssec-failed.org:

$ dig ds dnssec-failed.org @a0.org.afilias-nst.info. +short
106 5 1 4F219DCE274F820EA81EA1150638DABE21EB27FC
106 5 2 AE3424C9B171AF3B202203767E5703426130D76EF6847175F2EED355 F86EF1CE


también nos lo devuelve. Esto permite comprobar en cascada la veracidad de las respuestas a las consultas DNS de los servidores DNS de dicho dominio. Para saber cómo funciona dicho registro y DNSSEC en general con más profundidad, en el Blog de Inittab viene perfectamente explicado.

Sin embargo, quien realmente añade el registro DS es el registrador del dominio (recordemos que este registro tiene que estar en la zona .net, .com, .org…etc y esto solo lo puede hacer el registrador) y efectivamente, entrando en el panel de control del register con el que está el dominio registrado, vemos que tenía una entrada DS añadida. Una vez borrada ésta, ya que no existen más registros DNSSEC para el dominio y no se hace uso de sus funcionalidades, los resolvers de Google ya empiezan a responder correctamente. La otra opción, es implementar DNSSEC pero eso va más poco a poco y requiere de tiempo y bastantes pruebas.