DNSの問題、サイトがオフライン。 nslookupは定期的に失敗し、Dig / Hostは一貫して機能します
私のサイトは一日のほとんどの間断続的にダウンしていて、その理由をデバッグしようと夢中になっています。 DNSサーバーをISPからGoogleに変更したため、DNSの問題のようです8.8.8.8私の個人的なブラウザのためにそれを修正しました。しかし、今ではそれも失敗しています！ DownForEveryoneOrJustMeは、アップしていると言っていますが、そうではないというユーザーからの苦情がいくつかあります。
nslookupは断続的です：
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
一日中、それが結果を返すこともありますが、今はそうではありません。 GoDaddy DNSネームサーバーの1つで試してみると（信頼できると思いますか？whoisから取得しました）、次のようになります。
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.
もう1つはより不安定です：
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.
ただし、繰り返し試行しても、Digは常に次の情報を返します。
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も同様に一貫して機能します。
いくつかの質問：
DigとHostが一貫して機能するのに、nslookupが機能しないのはなぜですか？- 信頼できるネームサーバーを決定するにはどうすればよいですか。
whoisはそこで機能しますか？
私の理論では、GoDaddyネームサーバーは不安定で、ある時点でGoogleの8.8.8.8 を求めました www.coachup.comそして無応答を得た、それはしばらくの間それを否定的にキャッシュした。それはもっともらしいと思いますか？しかし、それはnslookupでのみ不安定であり、DigまたはHostでは不安定です。
また、 Heroku status は、昨日「DNSメンテナンス」を行っていたことを示しています。それはどういうわけかこれを引き起こす可能性がありますか？今は緑だそうです。
* DigとHostが一貫して機能するのに、nslookupが機能しないのはなぜですか？
Digを実行したときに、オプション「ANY」を使用したため、「A」レコードだけでなく、CNAMEなどの他のレコードも検索していたことを意味します。 nslookupが「A」レコードを探していたとき。興味深いのは、「Dig @ 8.8.8.8 www.coachup.com」を実行したときに応答がなかったのに、「Dig @ 8.8.8.8 www.coachup.comcname」を実行したときに応答があったことです。
*信頼できるネームサーバーを特定するにはどうすればよいですか。 whoisはそこで働いていますか？
whoisは主に管理データベースであり、実際のネームサーバーを特定するには、「Dig + tracewww.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 ;;グローバルオプション：+ cmd 。 3600000 IN NS G.ROOT-SERVERS.NET。 。3600000IN NS K.ROOT-SERVERS.NET。 。3600000INNS D.ROOT-SERVERS.NET。 。3600000IN NS J.ROOT-SERVERS.NET。 。3600000IN NS M.ROOT-SERVERS.NET。 。3600000IN NS C.ROOT-SERVERS.NET。 。3600000IN NS I.ROOT-SERVERS.NET。 。3600000IN NS H.ROOT-SERVERS。 NET。 。3600000IN NS F.ROOT-SERVERS.NET。 。3600000IN NS A.ROOT- SERVERS.NET。 。3600000IN NS B.ROOT-SERVERS.NET。 。3600000IN NS E。 ROOT-SERVERS.NET。 。 3600000 IN NS L.ROOT-SERVERS.NET。 ;; 18ミリ秒 comで192.168.10.109＃53（192.168.10.109）から512バイトを受信しました。 172800 IN NS j.gtld-servers.net。 com。172800INNS h.gtld-servers.net。 com。172800INNS f.gtld-servers.net。 com。172800INNS d.gtld-servers.net 。 com。172800INNS a.gtld-servers.net。 com。172800INNS l.gtld -servers.net。 com。172800INNS k.gtld-servers.net。 com。172800INNS = g.gtld-servers.net。 com。172800INNS b.gtld-servers.net。 com。172800INNS m.gtld-servers.net。 com。172800INNS c.gtld-servers.net。 com。172800IN= NS i.gtld-servers.net。 com。 172800 IN NS e.gtld-servers.net。 ;; 133ミリ秒 coachup.comで192.33.4.12＃53（192.33.4.12）から505バイトを受信しました。 172800 IN NS ns35.domaincontrol.com。 coachup.com。172800INNS ns36.domaincontrol.com。 ;; 138 ms www.coachup.com。3600INCNAME chiba-9316.herokussl.com。 ;; 33ミリ秒で208.109.255.18＃53（208.109.255.18）から68バイトを受信しました
あなたの権威ネームサーバーはセクションにあります-
coachup.com。 172800 IN NS ns35.domaincontrol.com。 coachup.com。172800INNS ns36.domaincontrol.com。
*問題はHerokuにあると思われ、googleやその他の一部のDNSサーバーは存在しないレコード応答をキャッシュし、その後、ネガティブキャッシュから応答を開始しました。ネガティブキャッシュの有効期限が切れると機能するはずです。私の推測では、まだ推測ですが、権威ネームサーバーはcname応答を提供しましたが、Herokに問題があると仮定して、googlednsサーバーは「chiba-9316.herokussl.com。」の解決を完了できませんでした。
これをテストするために、私はいくつかのパブリックdnsサーバーでDigを実行します-これはサイトから取得しました " http://pcsupport.about.com/od/tipstricks/a/free-public-dns-servers.htm "。すべてがCNAMEに応答しましたが、グーグルを含むいくつかは「A」レコードクエリに応答しませんでした-
「A」レコードの要求。注：googlednsは「8.8.8.8」です
[daniel @ kauai〜] $ for dns in $（awk '{print $ 2}'/tmp/dnsservers）;エコーを行う== $ dns ===; @ $ dnswww.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 ===
CNAMEクエリのリクエスト-
[daniel @ kauai〜] $ for dns in $（awk '{print $ 2}'/tmp/dnsservers）;エコーを行う== $ dns ===; @ $ dnswww.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。