AWS CloudfFrontでエラー「the request could not be satisfied Bad request」

こんにちは。
今回はAWS cloudforntのトラブル対応記事です。

仕事で運用しているサイトが、下記の事象にぶち当たったので、メモします。

事象

事象としては、下記のようなエラーがいきなり出るようになったというものです。
the request could not be satisfied
Bad request

原因

サイトの名前解決ができなくなっていました。
digやnslookupコマンドでの名前解決ができず、
whoisで更新日 (Updated Date)を確認したところ、
事象発生時のほぼ数時間前ぐらいに作業がされていました。
レジストラ（○名前.comとか）に 問い合わせたところ、
先方の作業ミスがあったっぽく、名前解決ができていない状態となっていました。

トラブル調査に役立ったこと

ちなみに、digの「+trace」オプションをつけると、
ルートディレクトリから順番に名前解決をトレースしてくれるため
どこで名前解決がストップしているかがわかります。
例 dig +trace www.google.com

一般的に名前解決で「www.google.com」を解決する場合、下記の流れとなります。
（１）ルートドメインに問い合わせる。
　　問合せ：「www.google.com」知ってる？
　　回答　：知らんけど「com」ドメインを管理してる奴は知ってる
　　　　　　→NSレコードの「com」管理のネームサーバを回答する


（２）comドメインを管理しているネームサーバへ問い合わせる
　　問合せ：「www.google.com」知ってる？
回答　：知らんけど「google.com」ドメインを管理してる奴は知ってる
　　　　　　→NSレコードの「google.com」管理のネームサーバを回答する


（３）google.comドメインを管理しているネームサーバへ問い合わせる
　　問合せ：「www.google.com」知ってる？
回答　：知ってる。IPは「xxx.xxx.xxx.xxx」です〜。

digの「+trace」オプションをつけると、
上記の流れに沿った形で、どこで名前解決が止まるかがわかるため、
どこで設定がミスしているかが分かり易かったです。

例えば、存在しない「wwww.google.com」を名前解決してみるとします。コマンド「dig +trace wwww.google.com」です。
下記の結果で42行目で、「google.com」までしかたどり着いておらず、
「wwww.google.com」まで行き着いていないのがわかるかと思います。

dig +trace wwww.google.com|nl 
       
     1 ; <<>> DiG 9.9.7-P3 <<>> +trace wwww.google.com
     2 ;; global options: +cmd
     3 .   405358 IN NS a.root-servers.net.
     4 .   405358 IN NS b.root-servers.net.
     5 .   405358 IN NS c.root-servers.net.
     6 .   405358 IN NS d.root-servers.net.
     7 .   405358 IN NS e.root-servers.net.
     8 .   405358 IN NS f.root-servers.net.
     9 .   405358 IN NS g.root-servers.net.
    10 .   405358 IN NS h.root-servers.net.
    11 .   405358 IN NS i.root-servers.net.
    12 .   405358 IN NS j.root-servers.net.
    13 .   405358 IN NS k.root-servers.net.
    14 .   405358 IN NS l.root-servers.net.
    15 .   405358 IN NS m.root-servers.net.
    16 ;; Received 811 bytes from 192.168.10.1#53(192.168.10.1) in 11 ms
       
    17 com.   172800 IN NS c.gtld-servers.net.
    18 com.   172800 IN NS m.gtld-servers.net.
    19 com.   172800 IN NS g.gtld-servers.net.
    20 com.   172800 IN NS a.gtld-servers.net.
    21 com.   172800 IN NS d.gtld-servers.net.
    22 com.   172800 IN NS h.gtld-servers.net.
    23 com.   172800 IN NS k.gtld-servers.net.
    24 com.   172800 IN NS l.gtld-servers.net.
    25 com.   172800 IN NS e.gtld-servers.net.
    26 com.   172800 IN NS b.gtld-servers.net.
    27 com.   172800 IN NS f.gtld-servers.net.
    28 com.   172800 IN NS j.gtld-servers.net.
    29 com.   172800 IN NS i.gtld-servers.net.
    30 com.   86400 IN DS 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
    31 com.   86400 IN RRSIG DS 8 1 86400 20180303050000 20180218040000 41824 . e4mOupNuYWJ+LTY5y6ZRQVx/c94FwZQ+vAa3PPrLa3CPOXJcVcs0lXju cWF6IEczarWIfNpfivvjEGVOD/2HjYwZfDDg4Sr1+wYcIfxlRNOV6aH+ 7T79d9dVLpjdBgzVlnv0dL+e6BZDxRT5fKMJQ35t+yVDFCOiEFUreaeg v99MGChSnNi72m8oMWhFWOERsJx9MsypgesKc19S4JmLYAJ+1sitKIVu C49/8Koqtk0DiWFlyx8Aay03VtlSTA7iPNB4fBoJiZsq3rV2gnZaNFoJ YXVZlZh10NcG0w0b65WJ37e3Oau7BE+jjxlTCN8Tslkq2ZhTVN1d5hUK XtsxjA==
    32 ;; Received 1175 bytes from 192.36.148.17#53(i.root-servers.net) in 20 ms
       
    33 google.com.  172800 IN NS ns2.google.com.
    34 google.com.  172800 IN NS ns1.google.com.
    35 google.com.  172800 IN NS ns3.google.com.
    36 google.com.  172800 IN NS ns4.google.com.
    37 CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A NS SOA RRSIG DNSKEY NSEC3PARAM
    38 CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20180225054804 20180218043804 46967 com. vvxe628HQa7sONZv2L/ptP74rr2WW1HxmxvlM3WTPHCmsTN+UIBOo90Z 1nksPuV5FYcve0LrAMjA/ymC+53qe6evfYq8tSzztmDju08vB9aHdEbl HcLhye4Uto6aolUS8vKHuavugWlXEzC/sblUdn1LXXfymspW8vEzOdx2 PV4=
    39 S848U70KJDCTE8UH1N07QH2EK7LNOUC6.com. 86400 IN NSEC3 1 1 0 - S84CEFMDU6ABFSN4V0L2VLLOASCD5IV2 NS DS RRSIG
    40 S848U70KJDCTE8UH1N07QH2EK7LNOUC6.com. 86400 IN RRSIG NSEC3 8 2 86400 20180223055059 20180216044059 46967 com. cOGkkHKLaftNhuKP7FzJzIAlLIHXvdx68hEyMGVTsNm5pyuy1gDFheKn KrR47y8UYjVK0eiSYCvEpVxh6SicNa/Ja+zyCLnphrcuSLEP1eHMKMZw 0ThMiix6Bb2xLv2UjljonmOfs65QGDuGoB4XIzXgR6yYtmzV9jdDRd8C Nhg=
    41 ;; Received 693 bytes from 192.48.79.30#53(j.gtld-servers.net) in 63 ms
       
    42 google.com.  60 IN SOA ns1.google.com. dns-admin.google.com. 186132518 900 900 1800 60
    43 ;; Received 83 bytes from 216.239.36.10#53(ns3.google.com) in 48 ms 
こんな感じで、レジストラ（○名前.comとか）が
作業ミスしているのが分かりました。
皆さんも良かったら便利なオプションなので使って見てください。

コメント

コメントを投稿

このブログの人気の投稿

AWS 証明書の更新でエラー「New certifcate is missing one ore more Extended key usages supported by currently imported certificate」

イメージ
こんにちは。 AWSのACMで自前で用意したSSL証明書を利用している場合、 SSL証明書の更新機能というものがあり便利です。 というのもAWSのシステム構成では、 cloudfrontやELB等、同一のSSL証明書を 複数の場所で利用している可能性があります。 １箇所ごとにSSL証明書を更新すると更新漏れするかもしれないので、 SSL証明書そのものを更新した方が、より確実に作業できます。 しかし、今回はそんな手順でエラーが出てしまいました。 事象 エラー内容は下記です。 「New certifcate is missing one ore more Extended key usages supported by currently imported certificate」 原因調査 どうやら「key usages：鍵の用途」というのがポイントのようです。 AWSのサイトを見ますと、 https://docs.aws.amazon.com/ja_jp/acm/latest/userguide/import-reimport.html   「新しい キー用途 拡張機能を追加できますが、既存の拡張機能の値を削除することはできません。 」とあります。 で、証明書を取得した人に聞いたところ 証明書の発行会社を前回と変えたとのことです。 ただ申請時に使用法を指定する項目等はなかったため、 会社によっては、使用法が指定できず、ACMで更新が不可となるようです。 そのほか、理解に下記のサイトが役に立ちました。 SSL証明書 http://www.trustss.co.jp/smnSignature350.html 対応 更新ができないので、地道に新しいSSL証明書をアップロードし切替しました。 切替した後は、コマンドで証明書の期限を確認し、 心理的にも安心して作業完了しました。 FQDN="www.google.com" #確認対象のFQDNを入力 openssl s_client -connect ${FQDN}: 443 < /dev/null 2> /dev/null | openssl x509 -text |gr...
続きを読む