AWS以外のレジストラでドメイン取ったらハマッた話

## オチ
原因がしょーもないので先にオチ。

レジストラからの認証メール放置して<font color="red">利用制限食らった。</font>~~あほくさ~~
## ことの始まり
現場でEC2のSSL化を依頼されました。~~俺はインフラマンじゃねぇ~~
要件は以下でした。

- EC2は2台
- プロトコルはHTTPとWebSocket
- 一台は画面(HTTP)、もう一台はAPI（HTTPとWebsocket）

ドメインはインフラの方が取ってくれるとのことでしたのでAWS側の設定を担当しました。

## 構成
とりあえず私からは以下の提案をしました。

- EC2の前段にALBを設置
- InternetからALBまではHTTPS
- AWS内部はHTTP
- front.hoge.comで画面、api.hoge.comでAPIというようにホストベースでルーティングする
- 証明書はACMで取得する

![cloud.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/177957/e1fe71e3-4c13-499c-b783-20e379088d0d.jpeg)

## ドメイン取得

インフラの方がドメイン取得時にNS必要だからちょーだいと言われたので
Route53で取る予定のドメイン名でレコードセット作ってNSをお渡ししました。

なんかやたらなれてない感じだったのでやな匂いは感じてました。

## AWS設定
とりあえずドメインは取得できたので、ここからは私のお仕事です。

構成管理は特に必要ないとのことでCloudFormationではなくManagementConsoleでポチポチしました。

※ALBの詳しい設定は[Developers.io見て](https://dev.classmethod.jp/cloud/aws/alb-application-load-balancer/)

1. ACMで証明書の発行
    *.hoge.comでワイルドカード証明書を発行しました。認証にはDNS認証を利用しました。

    Route53にレコードセット追加するボタンがあるのでポチして待機です。
2. ターゲットグループの作成
    画面とAPI、Websocket用のターゲットグループを作成して、ヘルスチェック設定をしました
    
3. インスタンス登録
    ターゲットグループに画面とAPI、Websocketのインスタンスをそれぞれ登録しました。

4. ALB用のセキュリティグループを作成
    443のみ開放します。
5. 各インスタンスのセキュリティグループを変更
    既にインスタンスの対象ポートがinternet公開されていたので~~ﾏｼﾞｶﾞﾖ~~ソースを先程作ったALBのセキュリティグループに変更します。
6. ALBの作成
    プロトコルはHTTPS、ポートは443を選択し、セキュリティグループ、証明書ともに前段で作成したものを設定します。

7. ALBのリスナールール
    以下の用に設定しました。
    defalut=>固定レスポンス403
    front.hoge.com=>画面のターゲットグループに転送
    api.hoge.com=>APIのターゲットグループに転送
    websocket.hoge.com=>WebSocketのターゲットグループに転送
8. Route53にレコードセット追加
    先程リスナールールに追加したHostを登録します。
    それぞれのHostのレコードセットを作り、ALBのAレコードを設定します。

## 検証

ここまででWebブラウザで確認できる状態になったので登録したhostでアクセスして確認しました。
(画面のformActionがhttpのままでMixedContentsになっててんやわんやはした)

nslookupでも引けるのでお仕事終わり！終了と思ってました。

## 2週間後

アプリ作ってたエンジニアからEC2落ちてません？と連絡受ける

ManagementConsoleでEC2が元気なことを確認
どーせアプリ側が落ちて503とかなってるんじゃないの？と思ってURLにアクセス

<font color="red">
DNS_PROBE_FINISHED_NXDOMAIN
</font>

ﾌｧｯ!?ってなりました。
まさかRoute53が障害起こしたか？と思い、障害情報見るも真緑
[ここでみれるよ](https://status.aws.amazon.com)

## 調査開始
とりあえずnslookupでさがしてみる

```
>nslookup front.hoge.com 8.8.8.8
# NXDOMAIN
>nslookup front.hoge.com 8.8.4.4
# NXDOMAIN
>nslookup front.hoge.com {Route53のNS}
# IP帰ってくる
```

これでAWS側の問題じゃないことがわかりました。
なのでドメイン側のNS設定を疑いました。


```
>whois hoge.com

Name Server: ns-***.awsdns-**.net.
Name Server: ns-***.awsdns-**.com.
Name Server: ns-***.awsdns-**.co.uk.
Name Server: ns-***.awsdns-**.org.
```

なんか末尾に「.」ついてる。
ggると末尾削除せいって記事があったのでこれのせいでNSみつけらんないのかなとおもった
~~たしかに私がNS送ったときに「.」つけたまま送ったけど、削除してくれよ~~

とりあえず末尾削除してもらって、NSの変更待ちで次の週まで経過観察してみることに
(結果的にこれは関係ありませんでした。結局末尾ついたままでいいのかだれか教えて)

## 次の週
3日経ってもうDNS反映されとるやろと思い

```
>whois hoge.com

Name Server: ns-***.awsdns-**.net
Name Server: ns-***.awsdns-**.com
Name Server: ns-***.awsdns-**.co.uk
Name Server: ns-***.awsdns-**.org
```

いけるやん！と華麗にnslookup、NXDOMAIN

とりあえずdigで権威DNSから調べはじめました。

`dig +trace front.hoge.com`

<font color="red">そもそも権威DNSでみつからない</font>

このあたりでドメイン取得がうまくいってないことを確信し、レジストラのよくある質問を舐め回すように見てました。

## 発覚

んで、ドメイン取得の手順読んでたら、最後に認証メール飛ばすから期間内にリンク踏むんやでー。2週間経ったら利用制限するんやでーの記述を発見。

ドメイン取ったインフラにURL付きでこれやった？って~~問い詰める~~聞くと、案の定知らんとの回答。

しかもドメイン管理者のメールアドレスは別の人に設定されていたため、その人にまた連絡。

無事リンク踏んだと連絡をもらい、nslookupするとIPが見つかりました。


## 結論
<font color="red">マニュアルちゃんと読め</font>
まぁミスオペの調査の経験になったからよし。二度と経験したくないけど