TL;DR 解决方案:DIG 无法用于验证 DNS 转发策略，因为 DNS 解析是由根服务器执行的
我正在尝试创建 DNS 出站转发策略，用于将 DNS 请求转发到特定名称服务器。它将在本地设置中实现，但我目前只是使用公共(public) DNS 服务器(例如 1.1.1.1)对其进行测试。我已经创建了 DNS 出站策略，但来自内部虚拟机的每个请求仍然使用元数据服务器:169.254.169.254
当前设置: 我已经创建了一个 VPC，定义了一个子网，并创建了一个连接到该子网的虚拟机。
resource "google_compute_network" "vpc-hub" {
name = "vpc-hub"
depends_on = [
google_project_iam_member.assign-roles,
google_project_service.enable_apis
]
}
resource "google_compute_subnetwork" "vpc-subnet-hub" {
name = "vpc-subnet-hub"
ip_cidr_range = "10.0.0.0/16"
region = "europe-west1"
network = google_compute_network.vpc-hub.id
depends_on = [
google_compute_network.vpc-hub
]
}
resource "google_compute_instance" "hub-vm" {
name = "hub-vm"
machine_type = "e2-medium"
zone = "europe-west1-b"
depends_on = [
google_compute_subnetwork.vpc-subnet-hub
]
boot_disk {
initialize_params {
image = "debian-cloud/debian-9"
}
}
network_interface {
subnetwork = google_compute_subnetwork.vpc-subnet-hub.name
access_config {
}
}
metadata_startup_script = file("${path.module}/startup_install.sh")
}
启动脚本安装 dnsutils。此外，我还定义了一条防火墙规则，以便能够通过 SSH 连接到它:
resource "google_compute_firewall" "ssh-rule-hub" {
name = "demo-ssh"
network = google_compute_network.vpc-hub.name
allow {
protocol = "tcp"
ports = ["22"]
}
source_ranges = ["REDACTED]
depends_on = [
google_compute_network.vpc-hub
]
}
问题: 我通过指定公共(public)名称服务器 1.1.1.1 创建了 DNS 转发策略:
resource "google_dns_policy" "dns-policy" {
name = "dns-policy"
enable_inbound_forwarding = false
enable_logging = false
alternative_name_server_config {
target_name_servers {
ipv4_address = "1.1.1.1"
forwarding_path = "default"
}
}
networks {
network_url = google_compute_network.vpc-hub.id
}
depends_on = [
google_compute_network.vpc-hub
]
}
当我通过 SSH 连接到虚拟机并尝试使用 dig 向任何域发送 DNS 请求时。它始终使用计算引擎内的内部元数据服务器 - 因此不使用 1.1.1.1 来检索 IP。相反，答案始终由元数据服务器提供:169.254.169.254。为什么会这样呢？ Dig 的输出如下所示:
bash 命令:dig google.com
; <<>> DiG 9.10.3-P4-Debian <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60323
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 300 IN A 64.233.184.101
google.com. 300 IN A 64.233.184.139
google.com. 300 IN A 64.233.184.102
google.com. 300 IN A 64.233.184.100
google.com. 300 IN A 64.233.184.113
google.com. 300 IN A 64.233.184.138
;; Query time: 18 msec
;; SERVER: 169.254.169.254#53(169.254.169.254)
;; WHEN: Tue Apr 26 12:09:53 UTC 2022
;; MSG SIZE rcvd: 135
编辑:bash 命令 dig google.com +trace 的输出
; <<>> DiG 9.10.3-P4-Debian <<>> google.com +trace
;; global options: +cmd
. 510859 IN NS a.root-servers.net.
. 510859 IN NS b.root-servers.net.
. 510859 IN NS c.root-servers.net.
. 510859 IN NS d.root-servers.net.
. 510859 IN NS e.root-servers.net.
. 510859 IN NS f.root-servers.net.
. 510859 IN NS g.root-servers.net.
. 510859 IN NS h.root-servers.net.
. 510859 IN NS i.root-servers.net.
. 510859 IN NS j.root-servers.net.
. 510859 IN NS k.root-servers.net.
. 510859 IN NS l.root-servers.net.
. 510859 IN NS m.root-servers.net.
;; Received 239 bytes from 169.254.169.254#53(169.254.169.254) in 22 ms
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 86400 IN DS 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
com. 86400 IN RRSIG DS 8 1 86400 20220510050000 20220427040000 47671 . hGerEs3N471ZCOosNSuakxBfxXh8H+qPP9UxVBakXvVfgLofu40+aNyw X9tfaNxmyFP7LUJDRBrURhNjN1cOdJhbTqa54AXvTlPbd31N5MRF3ZHT seJJLCe8Hv2UYLrnLSzAArpD2M+N0XI+3A6wR8/fE4/q0NULX0gpKxS9 Y/zHpr/Mu/2I8DLmI8sE411vSlK2MFxWj2LfQ0TAocjnmqkZQK9GfqQ4 IEDjcc2OV41JlxSKYtAy9OI3HJPfXcIrmo4aO9Qvoe1ZKn1fu46IUYpo zx1n5NgX4Ou8kOgjePMkpGMlvjLVY2KMxYdln7v4FCRB7mb1WsBp5H+3 3Sv7vQ==
;; Received 1170 bytes from 192.33.4.12#53(c.root-servers.net) in 10 ms
google.com. 172800 IN NS ns2.google.com.
google.com. 172800 IN NS ns1.google.com.
google.com. 172800 IN NS ns3.google.com.
google.com. 172800 IN NS ns4.google.com.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20220503042354 20220426031354 37269 com. vPwsL+I4ptKlrtrsZXrs/Z3/1Ebd3eBCm5f73FcuoljLz9RHDPdxfGCd rHmK3oWXZIErmCLYy6NgcpiMEM+JiqTQm/mNFhVfoFTGicCB9JwGgA3p XfgAB6w/hsNvtqTVuFsszhq4+CjXf1+ky0hFzTHACJ3bPmEeMa80ASwX EHu+vpL9LdLSZrtS68G2ieGvjrwcn6EZfmfJIly3i8UU9g==
S84BKCIBC38P58340AKVNFN5KR9O59QC.com. 86400 IN NSEC3 1 1 0 - S84BUO64GQCVN69RJFUO6LVC7FSLUNJ5 NS DS RRSIG
S84BKCIBC38P58340AKVNFN5KR9O59QC.com. 86400 IN RRSIG NSEC3 8 2 86400 20220504051944 20220427040944 37269 com. G/tnTZRrBZApHzz+bWDsUrDBa6PcH5O15adPaWvIlvIMe1FQUYFRJeMm pzJ586JzBfz5bE+5IjU0uAh6AnWrDVtryUig0CUpMVDn8mm8Axa9QTu/ 1h3hwE6HbKx/4d7hNpZIuKGH98iMKJLaYdfJHFLRV85/AOT9HdL2ihtF t2wOZ3Px0Wo6QVxpwth2hO2iLw0k/tszErnHw6BqxEAebQ==
;; Received 836 bytes from 192.41.162.30#53(l.gtld-servers.net) in 8 ms
google.com. 300 IN A 142.251.5.101
google.com. 300 IN A 142.251.5.113
google.com. 300 IN A 142.251.5.100
google.com. 300 IN A 142.251.5.138
google.com. 300 IN A 142.251.5.102
google.com. 300 IN A 142.251.5.139
;; Received 135 bytes from 216.239.32.10#53(ns1.google.com) in 1 ms
最佳答案
SERVER地址169.254.169.254并不意味着响应的服务器。该地址是元数据服务器，它知道如何将内部(项目指定)和全局域名转发到正确的 DNS 服务器。该地址是一项虚拟化服务，提供 DNS、DHCP 和 NTP 等多种服务。
关于google-cloud-platform - 谷歌CP : Can't get Compute Engine VMs to contact a specific public DNS name server after applying a DNS outbound forwarding policy，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/72013857/