フレッツ光のDNSサーバー使うかつ特定条件下でterraform planできなくなる

分かればシンプルなのですが、解決策にたどり着くまで、色々あったので書いていきます。
「そうはならんやろ」「なっとるやろがい!!」案件です。本質的にはまだ謎な部分もあるのですが...

## TR;DR

- 回線にフレッツ光を使っており、プロバイダDNSを使用している
- （PPPoEでIPv4通信とIPoEでIPv6通信を併用している）？
- Terraformのawsプロバイダ 4系を使っている
- [aws2-wrap](https://github.com/linaro-its/aws2-wrap) などで認証情報をAssumeRoleしている
    - 弊社のterraform実行環境については[こちら](https://hi1280.hatenablog.com/entry/2022/02/12/223500)に詳しく記載があります
- dig @flets-east.jp [sts.ap-northeast-1.amazonaws.com](http://sts.ap-northeast-1.amazonaws.com/)
    - これがconnection timed out; no servers could be reachedになる
    - windowsだとnetstat

## 解決策

DNSサーバーを8.8.8.8/4.4.4.4などに変更する
※macだとネットワークの環境設定より

変更前
```bash
% cat /etc/resolv.conf                               
search flets-east.jp iptvf.jp
nameserver 2001:f70:c380:600::1
nameserver 192.168.100.1
```

変更後
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/692378/37c7080b-f79e-13f9-605b-5832df3b65c7.png)

```bash
% cat /etc/resolv.conf                               
search flets-east.jp iptvf.jp
nameserver 8.8.8.8
nameserver 8.8.4.4
```

## 事象

awsプロバイダ 4系を使っているディレクトリでplanをすると以下のエラーとなります。

```bash
% terraform plan
╷
│ Error: configuring Terraform AWS Provider: IAM Role (arn:aws:iam::791461570807:role/OrganizationAccountAdminRole) cannot be assumed.
│ 
│ There are a number of possible causes of this - the most common are:
│   * The credentials used in order to assume the role are invalid
│   * The credentials do not have appropriate permission to assume the role
│   * The role ARN is not valid
│ 
│ Error: operation error STS: AssumeRole, https response error StatusCode: 0, RequestID: , request send failed, Post "https://sts.ap-northeast-1.amazonaws.com/": dial tcp: lookup sts.ap-northeast-1.amazonaws.com: i/o timeout
│ 
│ 
│   with provider["registry.terraform.io/hashicorp/aws"],
│   on main.tf line 1, in provider "aws":
│    1: provider "aws" {
```

### 背景

- 3系では問題なく通っており謎でした
- 新規AWSアカウントで環境を作っており、記述方法がおかしいのかと思っていました
- 丁度4系で作った別の環境がありそこで試しても同じエラーでした
    - ここで自分の環境依存ということに気付く
    - 偶然テザリングしてモバイル回線を使うと通る

 
> ## 認証方法の変更
> 
> AWS　Providerの認証方法は大きく分けて3つあります。そして上から順に優先して使われます。
> 
> 1. **`provider`**ブロック内で指定する
>     - **`profile`**とか**`assume_role`**といったarugumentを使う方法です。
> 2. 環境変数
>     - **`AWS_ACCESS_KEY_ID`**とか**`AWS_SECRET_ACCESS_KEY`**とか**`AWS_PROFILE`**とかですね。
> 3. クレデンシャル/コンフィグファイル
>     - **`~/.aws/credentials`**や**`/.aws/config`**に書かれている内容を使います。
> 
> v3では上記1から設定されているか調べて、その値が無効な場合、次の2の設定を調べます。2も無効な場合は3を調べます。というように「無効だったら次の優先度の設定を調べる」という挙動になっています。
> 
> v4では1から設定されているか調べて、「設定されているけど無効だったら即エラーを返す」という挙動に変更になりました。SDKやCLIと挙動を揃える意図だそうです。
> 
> [https://dev.classmethod.jp/articles/terraform-aws-provider-version-4/#toc-7](https://dev.classmethod.jp/articles/terraform-aws-provider-version-4/#toc-7) より
> 

4系に上がり認証情報が変更になったことがトリガーになっていそうです。

## ハマった原因

2つ目は参考にならない気がする…

### digではなくhostを使ってしまった
ネットワーク的なエラーと分かれば、pingとdnsを確認するのは癖ではあります
時間を溶かした大きな敗因はdigの時点で気づけず、hostで満足してしまったことです

```bash
% dig sts.ap-northeast-1.amazonaws.com 

; <<>> DiG 9.10.6 <<>> sts.ap-northeast-1.amazonaws.com
;; global options: +cmd
;; connection timed out; no servers could be reached
```

後でやりましたが、以下もエラーなのでおかしいことに気付くべきだった

```bash
dig www.yahoo.co.jp

; <<>> DiG 9.10.6 <<>> www.yahoo.co.jp
;; global options: +cmd
;; connection timed out; no servers could be reached
```

```bash
dig flets-east.jp@sts.ap-northeast-1.amazonaws.com 

; <<>> DiG 9.10.6 <<>> www.yahoo.co.jp
;; global options: +cmd
;; connection timed out; no servers could be reached
```

（後で気付く）別のdnsサーバー指定すると解決した

```bash
% dig @8.8.8.8 sts.ap-northeast-1.amazonaws.com

; <<>> DiG 9.10.6 <<>> @8.8.8.8 sts.ap-northeast-1.amazonaws.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30446
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;sts.ap-northeast-1.amazonaws.com. IN	A

;; ANSWER SECTION:
sts.ap-northeast-1.amazonaws.com. 9 IN	A	52.119.222.22

;; Query time: 48 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Dec 27 13:55:39 JST 2022
;; MSG SIZE  rcvd: 77
```

pingは通る

```bash
% ping sts.ap-northeast-1.amazonaws.com                            
PING sts.ap-northeast-1.amazonaws.com (27.0.2.249): 56 data bytes
64 bytes from 27.0.2.249: icmp_seq=0 ttl=231 time=49.034 ms
64 bytes from 27.0.2.249: icmp_seq=1 ttl=231 time=47.824 ms
64 bytes from 27.0.2.249: icmp_seq=2 ttl=231 time=51.817 ms
```

hostも何故か解決する

```bash
% host sts.ap-northeast-1.amazonaws.com                            
sts.ap-northeast-1.amazonaws.com has address 27.0.2.249
```

## RTX810を使っていた

一般の誤家庭※なので[こちら](https://qiita.com/myu_mx/items/c89d156e34e5e86c48ee)の通りRTX810を使っています。
とは言ってもGUIでポチポチ設定ている程度です。今まで快適なインターネットでした

:::note warn
※インフラエンジニア界隈の一般を逸脱した環境に使うネットミーム
:::

- PPPoEでIPv4通信
    - DNSサーバーは8.8.8.8
- IPoEでIPv6通信
    - **プロバイダのものを使用(※GUIだと指定できないため)**
    - あまり意識していませんでした
- その他はデフォルト
    - FW等もデフォルト

※v4,v6併用するときに支障があるのか指定できない
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/692378/a459612b-f7ac-5335-ea95-6a09bd054497.png)


configはこうなる

```bash
dns service fallback on
dns server dhcp lan2
dns server select 500000 dhcp lan2 any .
dns server select 500001 8.8.8.8 8.8.4.4 any . restrict pp 1
dns private address spoof on
```

切り分けとしてFWをオフにしたり、IPoEの接続を削除したりしました。

ネットワークあるあるですが、dnsなどはネットワーク側を変えても端末側に残るためPC再起動もしくは同等のコマンド実行をしないと事象が切り替わらないことがあります。

```bash
# macのネットワーク再起動
sudo ifconfig en0 up                                                                                                      
sudo ifconfig en0 down

# windowsのネットワーク再起動（多分）
netsh interface set interface name="アダプター名" disable
netsh interface set interface name="アダプター名" enable
# windowsのdnsキャッシュクリア（多分）
ipconfig /flushdns
```

初期でDNSの筋を潰していてRTXのFWかIPv6通信に謎のパケット遮断があるのかと疑っていたため、macかRTXに静的ルーティング書けば良いのでは？と思っていました。。。

再起動で事象が変わることから(&日を置き冷静に考えると)、DNSぽっさを徐々に感じ始めます。
色々やっているうちにmacからDNSサーバーを確認すると…8.8.8.8じゃなくねとなり。
あくまでも、search以外はルーターを指してますが、先述の通りIPoEはのDNSサーバーはDHCPです

```bash
% cat /etc/resolv.conf                               
search flets-east.jp iptvf.jp
nameserver 2001:f70:c380:600::1
nameserver 192.168.100.1
```

冒頭に記載のdigで諸々確認を行い、全てを理解しDNSサーバーを変更しました

macだと手軽なネットワーク設定から行います。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/692378/37c7080b-f79e-13f9-605b-5832df3b65c7.png)

```bash
% cat /etc/resolv.conf                               
search flets-east.jp iptvf.jp
nameserver 8.8.8.8
nameserver 8.8.4.4
```



### 【余談】RTX側の変更も難しい

ちなみにsearch flets-east.jp iptvf.jpは勝手に降ってきます… [参考](https://go-journey.club/archives/3694)
結局search（検索ドメイン）は関係なく、DNSサーバーのみ変えれば良さそうなのでスルーします

このままRTX側も変更します…と思ったのですが

変更前

```bash
dns service fallback on
dns server dhcp lan2
dns server select 500000 dhcp lan2 any .
dns server select 500001 8.8.8.8 8.8.4.4 any . restrict pp 1
dns private address spoof on
```

変更

```bash
no dns server dhcp lan2
no dns server select 500000 dhcp lan2 any .
dns server select 500000 2001:4860:4860::8888 2001:4860:4860::8844 aaaa lan2
```

変更後

```bash
dns service fallback on
dns server select 500000 2001:4860:4860::8888 2001:4860:4860::8844 aaaa lan2
dns server select 500001 8.8.8.8 8.8.4.4 any . restrict pp 1
dns private address spoof on
```

色々やっているうちに何も名前解決できなくなった。

ちなみに以下の設定でも繋がらない

> 
> 
> 
> [IPv4 PPPoE接続](http://www.rtpro.yamaha.co.jp/RT/docs/pppoe/index.html)などのインターネット接続とIPv6 IPoE接続を併用すると、DNSサーバーの設定によりIPv6 IPoEを経由した名前解決に失敗し、インターネット接続ができなくなることがあります。その場合は、以下の設定例を参考にしてDNSサーバーの設定を変更してしてください。DNSサーバーの問い合わせ優先順位については
> 
> [DNSの設定](http://www.rtpro.yamaha.co.jp/RT/manual/rt-common/dns/dns_chapter.html)を参照してください。
> 
> (例) IPv6 IPoE接続 と IPv4 PPPoE接続 (PPインターフェースが 1) の併用時、以下の設定を行うことで、両方のインターネット接続が可能となります。
> 
> [http://www.rtpro.yamaha.co.jp/RT/docs/ipoe/index.html](http://www.rtpro.yamaha.co.jp/RT/docs/ipoe/index.html)
> 

なにもわからない。大人しくmac側でDNSサーバーを固定します。
書いているうちに、誤家庭でPPPoEでIPv4通信とIPoEでIPv6通信を併用している環境でしか再現しない気もしてきた…
（同じようにハマった方コメント頂けると嬉しいです）

🎍おかげさまでplanは通るようになりましたが、本筋の作業は来年に持ち越しです🎍

エンジニア採用しているので、Organizationのリンクより。興味があれば私宛でも、採用ページからでも🙏