O cache de DNS não está limpando o Mac OSX

Question

Algo estranho está acontecendo na minha máquina. Estou esperando em um domínio para se propagar. Eu visito a página em cromo e ainda não está lá. mas se eu olhar em outra máquina, em outro ISP, está lá.

Eu tentei liberar o cache com dscacheutil -flushcache e sudo killall -HUP mDNSResponder e ainda não está lá.

Se eu usar dig , recebo isso, que tem as entradas de dns incorretas:

; <<>> DiG 9.8.3-P1 <<>> http://www.xxx.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 37789
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;http://www.xxx.com.    IN  A

;; AUTHORITY SECTION:
xxx.com.    3174    IN  SOA dns1.registrar-servers.com. hostmaster.registrar-servers.com. 2014090300 3600 1801 604800 3601

;; Query time: 31 msec
;; SERVER: 10.0.0.1#53(10.0.0.1)
;; WHEN: Fri Oct 17 09:26:21 2014
;; MSG SIZE  rcvd: 119

se eu usar dig +trace , as duas últimas etapas mostrarão as entradas corretas do DNS:

;; Received 448 bytes from 000.0.00.00#53(000.0.00.00) in 79 ms

xxx.com.    86400   IN  NS  ns1.correctns.com.
000.0.00.00.    86400   IN  NS  ns2.correctns.com.
;; Received 96 bytes from 1000.0.00.00#53(1000.0.00.00) in 78 ms

000.0.00.00.    86400   IN  SOA ns1.correctns.com. ns2.correctns.com. 2014101603 86400 7200 3600000 86400
;; Received 138 bytes from 66.117.5.83#53(66.117.5.83) in 68 ms

Honestamente, não sei o que estou vendo aqui, mas parece que está armazenando as informações incorretas no cache e, em seguida, sempre me referindo a isso em vez das novas informações da +trace run?

Eu tenho isso acontecer com muita freqüência. Existe alguma maneira que eu possa forçá-lo a procurar no lugar certo?

    

Answer 1

Parece que está sendo armazenado em cache pelo servidor DNS em 10.0.0.1 (provavelmente seu roteador). Existem dois níveis potenciais de cache envolvidos, e liberar um deles não afeta o outro. Deixe-me ver as opções:

• dig +trace domainname.com rastreia a consulta DNS por meio de servidores autoritativos, no seu caso, obtendo a resposta final de 66.117.5.83.

• dig domainname.com apenas envia a consulta para o servidor DNS configurado nas configurações de rede (no seu caso 10.0.0.1). Normalmente, esse é apenas um servidor de cache, que lembra os resultados que ele consultou antes e distribui a mesma resposta até que seu tempo de vida expire (em xxx.com. 3174 IN SOA dns1.registrar-servers.com... , faltam 3174 segundos).

• Usar o domínio com programas normais (não orientados ao DNS) como o Chrome passa pelo resolvedor do OS X, que verifica seu cache (a mesma política TTL se aplica aqui) e, se não estiver lá, verifica o servidor DNS configurado ( lembre-se de que é provavelmente um servidor de cache).

A redefinição do cache do OS X não afeta o cache no servidor DNS. Além disso, observe que mesmo que você redefina seu servidor DNS (por exemplo, reinicializando seu roteador), outros servidores DNS em toda a rede ainda poderão ter as informações antigas armazenadas em cache. Em geral, quando você faz uma alteração no DNS, precisa esperar que o TTL expire antes de assumir que as novas informações estão disponíveis em todos os lugares.

(E, na verdade, há outro nível com o qual você precisa se preocupar - seus servidores DNS secundários só verificam atualizações periódicas no servidor principal, portanto, é necessário aguardar a atualização do secundário, ENTÃO para que o TTL expire todos os antigos informações de vários caches ...)

    

Answer 2

Tudo funcionando bem, até onde eu sei. O domínio xxx.com parece estar sincronizado e funcionando bem. Também percebi que você usou dig http://www.xxx.com . O Dig não entende URLs, tente apenas com a parte do nome de domínio, dig www.xxx.com , para obter uma resposta correta.

$ dig www.xxx.com

; <<>> DiG 9.9.5-3-Ubuntu <<>> www.xxx.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45553
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
www.xxx.com.            86331   IN      A       141.0.173.173

;; Query time: 0 msec
;; SERVER: 
;; WHEN: Sun Oct 19 16:44:50 MDT 2014
;; MSG SIZE  rcvd: 56

Aqui estão os detalhes do servidor de nomes.

$ checksoa xxx.com

     Serial #   RTT(ms)  Version                       Nameservers (name, IP, SOA mname field) for xxx.com

    2014040205      80   not currently available       ns4.serverstack.com       69.55.56.130                       SOA: ns1.serverstack.com
    2014040205     111   not currently available       ns1.serverstack.com       69.55.62.180                       SOA: ns1.serverstack.com
    2014040205     185   not currently available       ns2.serverstack.com       141.0.173.228                      SOA: ns1.serverstack.com
    2014040205     174   not currently available       ns3.serverstack.com       87.233.226.25                      SOA: ns1.serverstack.com

Você pode ter que limpar seus caches DNS locais se isso não estiver sendo atualizado. O cache negativo TTL é o que você recebe em registros recém-adicionados. Nesse caso, o TTL negativo é de 1800 segundos para o xxx.com, portanto, você pode esperar apenas 30 minutos e ele resolverá por conta própria.

Este é um problema comum. Você faz uma alteração de DNS para adicionar um novo registro e então procura o nome imediatamente, antes de levar alguns minutos para se propagar para todos os servidores de nomes, de modo que você recebe uma entrada de cache negativa antes de ser ao vivo e, portanto, tempo (30 minutos) ou recorrer ao armazenamento de caches DNS locais para que funcione.

PS: Para aqueles que me repreenderem por acreditar que o xxx.com era o verdadeiro domínio, não se incomode. Eu sei que é falso, mas meu ponto é deixar nos domínios reais caso contrário, a ajuda é limitada. Eu odeio adivinhar tanto quanto o próximo cara. Use os domínios reais das pessoas.