Problemas de DNS, site offline. O nslookup falha periodicamente, dig / host trabalha consistentemente

3

Meu site foi desativado intermitentemente durante grande parte do dia e estou ficando louco tentando depurar o motivo. Parece ser um problema de DNS desde que eu mudei meus servidores DNS do meu ISP para o 8.8.8.8 do Google para o meu navegador pessoal. Mas agora isso também está falhando! DownForEveryoneOrJustMe diz que está em alta, embora eu esteja recebendo algumas reclamações de usuários que não são.

nslookup é intermitente:

16:04: ~/d/coachup (master) > nslookup www.coachup.com 8.8.8.8
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
*** Can't find www.coachup.com: No answer

Durante todo o dia, às vezes, isso retornou um resultado, mas não é agora. Quando eu tento com um dos meus servidores de nomes DNS GoDaddy (que eu acho que são autoritários? Eu peguei eles de whois ) eu recebo:

16:06: ~/d/coachup (master) > nslookup www.coachup.com NS36.DOMAINCONTROL.COM
Server:         NS36.DOMAINCONTROL.COM
Address:        208.109.255.18#53

www.coachup.com canonical name = chiba-9316.herokussl.com.

O outro é mais esquisito:

16:07: ~/d/coachup (master) > nslookup www.coachup.com NS35.DOMAINCONTROL.COM
Server:         NS35.DOMAINCONTROL.COM
Address:        216.69.185.18#53

*** Can't find www.coachup.com: No answer

16:08: ~/d/coachup (master) > nslookup www.coachup.com NS35.DOMAINCONTROL.COM
Server:         NS35.DOMAINCONTROL.COM
Address:        216.69.185.18#53

www.coachup.com canonical name = chiba-9316.herokussl.com.

No entanto, mesmo com tentativas repetidas, dig sempre volta com informações:

16:08: ~/d/coachup (master) > dig @8.8.8.8 www.coachup.com ANY

; <<>> DiG 9.8.3-P1 <<>> @8.8.8.8 www.coachup.com ANY
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49917
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.coachup.com.               IN      ANY

;; ANSWER SECTION:
www.coachup.com.        2815    IN      CNAME   chiba-9316.herokussl.com.

;; Query time: 32 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Dec 18 16:09:25 2013
;; MSG SIZE  rcvd: 68

16:09: ~/d/coachup (master) > dig @NS35.DOMAINCONTROL.COM www.coachup.com ANY

; <<>> DiG 9.8.3-P1 <<>> @NS35.DOMAINCONTROL.COM www.coachup.com ANY
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58865
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;www.coachup.com.               IN      ANY

;; ANSWER SECTION:
www.coachup.com.        3600    IN      CNAME   chiba-9316.herokussl.com.

;; AUTHORITY SECTION:
coachup.com.            3600    IN      NS      ns36.domaincontrol.com.
coachup.com.            3600    IN      NS      ns35.domaincontrol.com.

;; Query time: 309 msec
;; SERVER: 216.69.185.18#53(216.69.185.18)
;; WHEN: Wed Dec 18 16:09:39 2013
;; MSG SIZE  rcvd: 120

host funciona de forma semelhante de forma consistente.

Algumas perguntas:

  • Por que dig e host funcionam de forma consistente, mas não nslookup ?
  • Como eu determino meus servidores de nomes autorizados? O whois trabalha lá?

Minha teoria de trabalho é que o servidor de nomes GoDaddy foi escamoso, e em um ponto quando o 8.8.8.8 do Google pediu por www.coachup.com e obteve uma não resposta, ele armazenou em cache isso negativamente por um tempo. Isso parece plausível? Mas então é apenas escamosa com nslookup e não com dig ou host .

Além disso, o status Heroku mostra que eles estavam fazendo "manutenção de DNS" ontem. Isso poderia causar isso de alguma forma? Diz que é verde agora.

    
por Gabe Durazo 18.12.2013 / 22:17

1 resposta

3

* Por que escavar e hospedar funcionam consistentemente, mas não nslookup?

Porque quando você correu, você usou a opção 'ANY', isso significa que você não estava apenas procurando por um registro 'A', mas também por outros registros, como o CNAME. Enquanto nslookup estava procurando por um registro 'A'. O que é interessante é quando eu fiz 'dig @ 8.8.8.8 www.coachup.com' eu não tenho resposta, mas quando eu fiz 'dig @ 8.8.8.8 www.coachup.com cname' eu tenho uma resposta.

* Como eu determino meus servidores de nomes autorizados? O whois trabalha lá?

whois é principalmente um banco de dados administrativo, para determinar seus servidores de nomes reais, use 'dig + trace www.coachup.com' -

[root@kauai ~]# dig +trace www.coachup.com

; > DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.6 > +trace www.coachup.com
;; global options: +cmd
.                       3600000 IN      NS      G.ROOT-SERVERS.NET.
.                       3600000 IN      NS      K.ROOT-SERVERS.NET.
.                       3600000 IN      NS      D.ROOT-SERVERS.NET.
.                       3600000 IN      NS      J.ROOT-SERVERS.NET.
.                       3600000 IN      NS      M.ROOT-SERVERS.NET.
.                       3600000 IN      NS      C.ROOT-SERVERS.NET.
.                       3600000 IN      NS      I.ROOT-SERVERS.NET.
.                       3600000 IN      NS      H.ROOT-SERVERS.NET.
.                       3600000 IN      NS      F.ROOT-SERVERS.NET.
.                       3600000 IN      NS      A.ROOT-SERVERS.NET.
.                       3600000 IN      NS      B.ROOT-SERVERS.NET.
.                       3600000 IN      NS      E.ROOT-SERVERS.NET.
.                       3600000 IN      NS      L.ROOT-SERVERS.NET.
;; Received 512 bytes from 192.168.10.109#53(192.168.10.109) in 18 ms

com.                    172800  IN      NS      j.gtld-servers.net.
com.                    172800  IN      NS      h.gtld-servers.net.
com.                    172800  IN      NS      f.gtld-servers.net.
com.                    172800  IN      NS      d.gtld-servers.net.
com.                    172800  IN      NS      a.gtld-servers.net.
com.                    172800  IN      NS      l.gtld-servers.net.
com.                    172800  IN      NS      k.gtld-servers.net.
com.                    172800  IN      NS      g.gtld-servers.net.
com.                    172800  IN      NS      b.gtld-servers.net.
com.                    172800  IN      NS      m.gtld-servers.net.
com.                    172800  IN      NS      c.gtld-servers.net.
com.                    172800  IN      NS      i.gtld-servers.net.
com.                    172800  IN      NS      e.gtld-servers.net.
;; Received 505 bytes from 192.33.4.12#53(192.33.4.12) in 133 ms

coachup.com.            172800  IN      NS      ns35.domaincontrol.com.
coachup.com.            172800  IN      NS      ns36.domaincontrol.com.
;; Received 117 bytes from 192.54.112.30#53(192.54.112.30) in 138 ms

www.coachup.com.        3600    IN      CNAME   chiba-9316.herokussl.com.
;; Received 68 bytes from 208.109.255.18#53(208.109.255.18) in 33 ms

Seus servidores de nomes oficiais estão na seção -

coachup.com.            172800  IN      NS      ns35.domaincontrol.com.
coachup.com.            172800  IN      NS      ns36.domaincontrol.com.

* Eu suspeitaria que o problema era com o Heroku, e o google e outros servidores de DNS armazenavam em cache a resposta de registro inexistente, e depois disso eles começaram a responder a partir do cache negativo. Deve funcionar assim que o cache negativo expirar. Meu palpite é, ainda, um palpite, seu servidor de nomes autoritativo forneceu a resposta cname, mas os servidores dns do google não conseguiram completar a resolução para 'chiba-9316.herokussl.com.', Assumindo que Herok tinha um problema.

Para testar isso, eu corro uma escavação em vários servidores DNS públicos - que eu tenho do site " link ". Todos responderam pelo CNAME, mas alguns incluindo o google não responderam por uma consulta de registro 'A' -

Solicite um registro 'A'. Nota: o google dns é '8.8.8.8'


[daniel@kauai ~]$ for dns in $(awk '{print $2}' /tmp/dnsservers ); do echo ==$dns===; dig @$dns www.coachup.com. +short ;done
==209.244.0.3===
chiba-9316.herokussl.com.
elb002794-1867396571.us-east-1.elb.amazonaws.com.
50.16.224.113
23.23.124.44
23.23.101.90
==8.8.8.8===
==8.26.56.26===
chiba-9316.herokussl.com.
elb002794-1867396571.us-east-1.elb.amazonaws.com.
23.23.124.44
23.23.101.90
50.16.224.113
==208.67.222.222===
chiba-9316.herokussl.com.
elb002794-1867396571.us-east-1.elb.amazonaws.com.
50.16.224.113
23.23.101.90
23.23.124.44
==156.154.70.1===
chiba-9316.herokussl.com.
elb002794-1867396571.us-east-1.elb.amazonaws.com.
23.23.124.44
23.23.101.90
50.16.224.113
==198.153.192.40===
chiba-9316.herokussl.com.
elb002794-1867396571.us-east-1.elb.amazonaws.com.
23.23.101.90
50.16.224.113
23.23.124.44
==81.218.119.11===
chiba-9316.herokussl.com.
elb002794-1867396571.us-east-1.elb.amazonaws.com.
23.23.124.44
23.23.101.90
50.16.224.113
==195.46.39.39===
chiba-9316.herokussl.com.
elb002794-1867396571.us-east-1.elb.amazonaws.com.
50.16.224.113
23.23.101.90
23.23.124.44
==23.90.4.6===
chiba-9316.herokussl.com.
elb002794-1867396571.us-east-1.elb.amazonaws.com.
23.23.101.90
23.23.124.44
50.16.224.113
==216.146.35.35===
chiba-9316.herokussl.com.
elb002794-1867396571.us-east-1.elb.amazonaws.com.
50.16.224.113
23.23.101.90
23.23.124.44
==89.233.43.71===
chiba-9316.herokussl.com.
elb002794-1867396571.us-east-1.elb.amazonaws.com.
23.23.101.90
50.16.224.113
23.23.124.44
==74.82.42.42===
==109.69.8.51===

Solicitar uma consulta CNAME -


[daniel@kauai ~]$ for dns in $(awk '{print $2}' /tmp/dnsservers ); do echo ==$dns===; dig @$dns www.coachup.com. +short cname ;done
==209.244.0.3===
chiba-9316.herokussl.com.
==8.8.8.8===
chiba-9316.herokussl.com.
==8.26.56.26===
chiba-9316.herokussl.com.
==208.67.222.222===
chiba-9316.herokussl.com.
==156.154.70.1===
chiba-9316.herokussl.com.
==198.153.192.40===
chiba-9316.herokussl.com.
==81.218.119.11===
chiba-9316.herokussl.com.
==195.46.39.39===
chiba-9316.herokussl.com.
==23.90.4.6===
chiba-9316.herokussl.com.
==216.146.35.35===
chiba-9316.herokussl.com.
==89.233.43.71===
chiba-9316.herokussl.com.
==74.82.42.42===
chiba-9316.herokussl.com.
==109.69.8.51===
chiba-9316.herokussl.com.

    
por 19.12.2013 / 01:06