作为 CNAME 记录的主机名在 AWS 环境之外可以正确解析，但在 AWS 内部，它可以从某些账户中的 EC2 实例正确解析，而在其他账户中却始终解析失败（NXDOMAIN）。
作为 A 记录的主机名在任何地方都能正确解析。
我已经使用 nslookup 和 dig 来检查名称解析。
为了排除由于解析路径上某些解析器中的不良缓存条目而导致的失败，我在解析失败的机器上运行了 200 次 dig 命令。
如果我使用 dig 的 +trace 选项，我会看到所有 200 种情况的 CNAME 结果，并且不同情况使用不同的解析器。
如果我删除 +trace 选项，则所有 200 种情况的解析都会失败。
有人知道出了什么问题吗？
参见下面的输出..
# dig SUCCEEDS with +trace
$ dig +trace es-stage.guardinex.com
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.5.2 <<>> +trace es-stage.guardinex.com
;; global options: +cmd
. 518400 IN NS M.ROOT-SERVERS.NET.
. 518400 IN NS A.ROOT-SERVERS.NET.
. 518400 IN NS B.ROOT-SERVERS.NET.
. 518400 IN NS C.ROOT-SERVERS.NET.
. 518400 IN NS D.ROOT-SERVERS.NET.
. 518400 IN NS E.ROOT-SERVERS.NET.
. 518400 IN NS F.ROOT-SERVERS.NET.
. 518400 IN NS G.ROOT-SERVERS.NET.
. 518400 IN NS H.ROOT-SERVERS.NET.
. 518400 IN NS I.ROOT-SERVERS.NET.
. 518400 IN NS J.ROOT-SERVERS.NET.
. 518400 IN NS K.ROOT-SERVERS.NET.
. 518400 IN NS L.ROOT-SERVERS.NET.
;; Received 239 bytes from 10.0.0.2#53(10.0.0.2) in 0 ms
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
com. 86400 IN DS 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
com. 86400 IN RRSIG DS 8 1 86400 20221125050000 20221112040000 18733 . I5it4epK25laf74ZFhYWR/3wGGjsFroYCirdzIyMrzs4vJMU0XLVs+Ws veV+vnXqmVuN5HkJJwcR5Ff43mCZ+KhypfArYQ/RNtGazBKz0gX5wxZ6 2ub1SVr3318yAMtl3iN2N44RB6ZBiEKlur0heBFoBFqW8LpR7/89PqYV lHOTKZGDKGCNZedLPa+ukQcgp2YRdXOZFV3kNgXeKGlxYfK9Nv8eVqnP Tc5bQY1DlZvU026MB9SJG4lY0v4AXPt0gu0iyenC50RTIdVbiq/R2PHj hn92tvVzOZkmyWvchHTP5uvyRAm/ktkqQL+R6i9B+/fqIdyuEw2YEgZI ktNOhw==
;; Received 1185 bytes from 192.112.36.4#53(G.ROOT-SERVERS.NET) in 45 ms
guardinex.com. 172800 IN NS ns-270.awsdns-33.com.
guardinex.com. 172800 IN NS ns-986.awsdns-59.net.
guardinex.com. 172800 IN NS ns-1152.awsdns-16.org.
guardinex.com. 172800 IN NS ns-1855.awsdns-39.co.uk.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q2D6NI4I7EQH8NA30NS61O48UL8G5 NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20221119052449 20221112041449 53929 com. hYUTcpX5l7kJAr78hLqD/FuTq2H6w3My4YrnqfpuOkpuv3n4r5aLG63b vo3cRytvqc2usP+YMVpPDRkzPbGbOJZL0M6R2U8w0oQPcSstUL27jjJ7 xgInCLHW1iRj4NlGFay8pE5Fw3Rz9P65s0AXX0QEeQ6VwKZmW9MXDlp/ H14cc7l2zzG6ZXrHUNJwzid1r6kONuadYYxYA58dLPdq5g==
LJ4SG1LGI8CMLK7J08OKU0C0S3K2UNVB.com. 86400 IN NSEC3 1 1 0 - LJ4T61EATV8L0OEI963F53KIKOBLB229 NS DS RRSIG
LJ4SG1LGI8CMLK7J08OKU0C0S3K2UNVB.com. 86400 IN RRSIG NSEC3 8 2 86400 20221116051525 20221109040525 53929 com. QzChq+rEDnhDgTdLf/qq0Jle7AKE1HPg0dfdx1+mzjxYsUTjIQNj3FQ1 OXE7vffUqLumBHuqtlWLZqYUqosElGv3PVGyhR7u50goIVOcTdZ1hjtd NivYJ81eaZPmvjcLdxmMN4fel7kRoDmS/y81oIbadOpu9ebJsocF5p8h R79mQ6rz8CfNYuGcVmJLgwwDRYQRzX+PLhJ3eJJZ3NyQSg==
;; Received 753 bytes from 192.43.172.30#53(i.gtld-servers.net) in 19 ms
es-stage.guardinex.com. 3600 IN CNAME search-guardinex-es-stage-qh6d74ilnpedsg2si4pvd4g2ea.us-west-1.es.amazonaws.com.
guardinex.com. 172800 IN NS ns-1152.awsdns-16.org.
guardinex.com. 172800 IN NS ns-1855.awsdns-39.co.uk.
guardinex.com. 172800 IN NS ns-270.awsdns-33.com.
guardinex.com. 172800 IN NS ns-986.awsdns-59.net.
;; Received 278 bytes from 205.251.195.218#53(ns-986.awsdns-59.net) in 1 ms
# dig FAILS WITHOUT +trace
$ dig es-stage.guardinex.com
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.5.2 <<>> es-stage.guardinex.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 47207
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;es-stage.guardinex.com. IN A
;; AUTHORITY SECTION:
guardinex.com. 300 IN SOA ns-1536.awsdns-00.co.uk. awsdns- hostmaster.amazon.com. 1 7200 900 1209600 86400
;; Query time: 2 msec
;; SERVER: 10.0.0.2#53(10.0.0.2)
;; WHEN: Sat Nov 12 12:43:00 UTC 2022
;; MSG SIZE rcvd: 135
# dig SUCCEEDS WITHOUT +trace (on a different AWS account)
$ dig es-stage.guardinex.com
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.5.2 <<>> es-stage.guardinex.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4172
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;es-stage.guardinex.com. IN A
;; ANSWER SECTION:
es-stage.guardinex.com. 300 IN CNAME search-guardinex-es-stage-qh6d74 ilnpedsg2si4pvd4g2ea.us-west-1.es.amazonaws.com.
search-guardinex-es-stage-qh6d74ilnpedsg2si4pvd4g2ea.us-west-1.es.amazonaws.com. 60 IN A 54.177.125.22
search-guardinex-es-stage-qh6d74ilnpedsg2si4pvd4g2ea.us-west-1.es.amazonaws.com. 60 IN A 52.53.54.78
;; Query time: 5 msec
;; SERVER: 172.31.0.2#53(172.31.0.2)
;; WHEN: Sat Nov 12 12:49:32 UTC 2022
;; MSG SIZE rcvd: 173
答案1
根本原因是解析失败的账户有自己的私有 DNS 区域，其中包含 guardinex.com 条目，这与公共 DNS 区域中的 guardinex.com 条目冲突......
删除私有 DNS 区域，现在就可以正常工作了。将记录移至公共区域。