在 gslin 這邊看到「Stripe 遇到 AWS 上 DNS Resolver 的限制」講到 VPC DNS Quotas 的限制
這次 Stripe 在描述 trouble shooting 的過程：「The secret life of DNS packets: investigating complex networks」。
其中一個頗有趣的架構是他們在每台主機上都有跑 Unbound，然後導去中央的 DNS Resolver，再決定導去 Consul 或是 AWS 的 DNS Resolver …
DNS traffic 架構：
偶爾會出現大量 SERVFAIL
因本家企業也是採用 Multi Account + Unbound 的方法處理 Private and Public DNS 解析，像遇到這種 traffic 夠大量的架構很容易採到各種 Limit，在這個案裡中所有的流量都是透過 Unbound 去問 VPC Resolver，就會採到 AWS 說的「每個 EC2 每秒最多 1024 個封包」
在架構設計上還是要盡可能的「分散」處理各種需求，針對這個案例可能的優化/解法：
- 在每個 EC2 安裝 Unbound 直接問到對應的 DNS Server
- 在每個 Account 建立 NLB + t3.family 的 Unbound，透過 DHCP OptionSet 設定 dnserver。
兩個方法各有優劣
- 第一個方法在 AMI 的客製上會多一些，但是採到 VPC DNS Quotas 的機會大幅降低
- 第二個方法直接在架構上調整，不會影響現有的服務使用，但是成本相對會高一些，也必須管理一套 Unbound Service。