我想知道为什么AWS DNS服务器(10.0.0.2和169.254.169.253(需要很长时间才能为我的ECS任务返回正确的IP地址。
我目前的设置如下：
- dev.private是Route53托管的区域
- 使用TTL 0和a类型dns条目的ECS服务(在deepstream.dev.private下注册(
- 一个nginx服务，它完成SSL终止并将请求转发到ECS服务
当第一次创建EC2实例并安装nginx时，所有东西都使用指向10.0.0.2 的解析器
但是，当杀死ECS任务时：
- 它已从路由53中删除(预期(
- 将新任务条目输入到具有新IP的路由53中(预期(
- 新条目没有显示在nginx中(它返回(3：未找到主机((
- 使用dig时，新条目不会显示(dig@1.0.0.2 deepstream.dev.private(
dig @10.0.0.2 deepstream.dev.private
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.amzn2.0.2 <<>> @10.0.0.2 deepstream.dev.private
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10878
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;deepstream.dev.private. IN A
;; Query time: 0 msec
;; SERVER: 10.0.0.2#53(10.0.0.2)
;; WHEN: Tue Apr 14 03:33:39 UTC 2020
;; MSG SIZE rcvd: 51
这表明没有答案
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.amzn2.0.2 <<>> @10.0.0.2 deepstream.dev.private
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15576
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;deepstream.dev.private. IN A
;; ANSWER SECTION:
deepstream.dev.private. 0 IN A 10.0.2.214
;; Query time: 1 msec
;; SERVER: 10.0.0.2#53(10.0.0.2)
;; WHEN: Tue Apr 14 03:35:00 UTC 2020
;; MSG SIZE rcvd: 56
因此，总结测试场景：
- Dig返回IP，一切顺利
- 杀死ECS任务后，Route53条目立即被删除
- 不到10秒(重启ECS上的docker所需的时间(，新的路由53条目添加了IP
- 5分钟后，新条目通过dig返回
多次运行，似乎持续了五分钟，感觉就像某个地方的缓存。
在崩溃或部署后，一个新的ECS实例不能指望需要5分钟才能被引用，这将是不可接受的停机时间。
这似乎与ECS用于提供服务发现的Cloud Map命名空间中的负DNS缓存有关。在2020年9月14日之前，仅具有VPC解析的命名空间的默认(和固定(负缓存TTL(换句话说，命名空间SOA记录的TTL(为300秒(您的5分钟值(，具有公共DNS解析的命名空间为900秒。
根据链接的GitHub问题，新创建的命名空间的默认值现在分别为15秒和60秒。
我也遇到过这个问题，很难找到原因，因为只有当可用任务数一直下降到0时才会发生这种情况，从而导致缓存的NXDOMAIN响应。
至少在撰写本文时，不可能手动修改此值(尽管根据GitHub问题，这正在进行中(，因此唯一的解决方案是重新创建命名空间以获得新的较低默认值。