El server DNS conoce la autoridad pero no proporciona la respuesta

Estoy intentando conectar con una dirección que sea accesible vía una VPN. El server DNS de mi ISP parece saber dónde están las autoridades para el dominio, pero no puede devolver la respuesta / dirección IP. Al usar la autoridad directamente puedo get la IP sin embargo.

selene:app-resource-hub work$ dig jenkins.tescloud.com +all @2001:8b0:856:1::1 ; <<>> DiG 9.8.3-P1 <<>> jenkins.tescloud.com +all @2001:8b0:856:1::1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32447 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 0 ;; QUESTION SECTION: ;jenkins.tescloud.com. IN A ;; ANSWER SECTION: jenkins.tescloud.com. 47 IN CNAME jenkins-az1.management.tescloud.com. ;; AUTHORITY SECTION: tescloud.com. 161304 IN NS ns-1057.awsdns-04.org. tescloud.com. 161304 IN NS ns-1754.awsdns-27.co.uk. tescloud.com. 161304 IN NS ns-399.awsdns-49.com. tescloud.com. 161304 IN NS ns-831.awsdns-39.net. ;; Query time: 33 msec ;; SERVER: 2001:8b0:856:1::1#53(2001:8b0:856:1::1) ;; WHEN: Thu Jul 16 12:56:15 2015 ;; MSG SIZE rcvd: 212 selene:app-resource-hub work$ dig jenkins.tescloud.com +all @ns-1057.awsdns-04.org. ; <<>> DiG 9.8.3-P1 <<>> jenkins.tescloud.com +all @ns-1057.awsdns-04.org. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 628 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;jenkins.tescloud.com. IN A ;; ANSWER SECTION: jenkins.tescloud.com. 60 IN CNAME jenkins-az1.management.tescloud.com. jenkins-az1.management.tescloud.com. 60 IN A 10.17.12.222 ;; AUTHORITY SECTION: tescloud.com. 172800 IN NS ns-1057.awsdns-04.org. tescloud.com. 172800 IN NS ns-1754.awsdns-27.co.uk. tescloud.com. 172800 IN NS ns-399.awsdns-49.com. tescloud.com. 172800 IN NS ns-831.awsdns-39.net. ;; Query time: 278 msec ;; SERVER: 205.251.196.33#53(205.251.196.33) ;; WHEN: Thu Jul 16 12:56:26 2015 ;; MSG SIZE rcvd: 228 selene:service-site-assets work$ dig jenkins- az1.management.tescloud.com. +all @2001:8b0:856:1::1 ; <<>> DiG 9.8.3-P1 <<>> jenkins-az1.management.tescloud.com. +all @2001:8b0:856:1::1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47843 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 0 ;; QUESTION SECTION: ;jenkins-az1.management.tescloud.com. IN A ;; AUTHORITY SECTION: tescloud.com. 158420 IN NS ns-1057.awsdns-04.org. tescloud.com. 158420 IN NS ns-1754.awsdns-27.co.uk. tescloud.com. 158420 IN NS ns-399.awsdns-49.com. tescloud.com. 158420 IN NS ns-831.awsdns-39.net. ;; Query time: 103 msec ;; SERVER: 2001:8b0:856:1::1#53(2001:8b0:856:1::1) ;; WHEN: Thu Jul 16 13:44:19 2015 ;; MSG SIZE rcvd: 190 

Usted está recibiendo una respuesta. Es el logging CNAME en el primer ejemplo. El server remoto no es realmente necesario para hacer la búsqueda secundaria desde el CNAME hasta el resultado final para usted, aunque casi todo el mundo siempre lo hace. Así que tu resultado no está mal, es extraño. Si desea continuar invirtiendo, lo siguiente que vería sería si el server al que envió la primera pregunta puede resolver jenkins-az1.management.tescloud.com. como debería.

La tercera consulta que realizó es la pertinente. Está viendo una respuesta no autorizada con cero respuestas y un código de NOERROR . Esto significa que "no hay loggings con ese nombre y tipo, pero hay otros loggings con ese nombre y un tipo diferente". Es similar a NXDOMAIN , pero está indicando que existen otros loggings con ese nombre. En otras palabras, la información no estaba allí cuando su ISP lo pidió y se ha acordado de esto.

En cuanto a por qué su ISP no ha olvidado esto … mirar su logging SOA:

 tescloud.com. 900 IN SOA ns-1754.awsdns-27.co.uk. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400 

El último dígito en ese logging SOA se conoce como el valor NCACHE o valor de caching negativo. Esta es su instrucción a los serveres de nombres en Internet sobre cuánto time deben recordar la ausencia de un logging. (es decir, cuánto time para recordar una respuesta "negativa"),

Actualmente está instruyendo a los serveres DNS en Internet a recordar una respuesta negativa de 86400 segundos, que es de 24 horas. Muchos serveres de nombres aplicarán un período máximo de almacenamiento en caching negativo menor que esto, pero algunos no lo harán, y hay muchas probabilidades de que al realizar estas testings los serveres de nombres del ISP todavía tuvieran la ausencia de ese logging negativo en caching.

Este problema probablemente se resolverá en algún momento dentro de las próximas 24 horas, pero en el ínterin probablemente debería bajar su valor NCACHE a algo más razonable. (una hora como máximo)