DNS 不能通过来自 pod 的 TCP 工作

Question

我有一个 Openshift Origin 安装（v. 1.2.1，但也在 1.3.0 上重现了这个问题），我正在尝试通过服务名称从 DNS 获取 pod 的 IP。假设我的节点有 IP 192.168.58.6，我在项目“hz-test”中寻找无头服务“hz”的 pod。当我尝试通过 UDP 向 dnsmasq（安装在节点上并将请求转发到 Kubernetes 的 SkyDNS）发送 DNS 请求时，一切顺利：

# dig +notcp +noall +answer hz.hz-test.svc.cluster.local @192.168.58.6  
hz.hz-test.svc.cluster.local. 14 IN A   10.1.2.5
<and so on...>

但是，当我将传输协议切换到 TCP 时，我收到以下错误：

# dig +tcp +noall +answer hz.hz-test.svc.cluster.local @192.168.58.6  
;; communications error to 192.168.58.6#53: end of file

查看 tcpdump 输出后，我发现，在建立 TCP 连接 (SYN - SYN/ACK - ACK) 后，dnsmasq 立即发送回 FIN/ACK，并且当 DNS 客户端尝试使用此连接发送其请求时, dnsmasq 发回 RST 数据包而不是 DNS 应答。我尝试从节点本身通过 TCP 执行相同的 DNS 查询，并且 dnsmasq 给了我通常的响应，即它通过 TCP 正常工作，并且仅当我尝试从 pod 执行请求时才出现问题。另外，我尝试通过 TCP 将相同的查询直接从 pod 发送到 Kubernetes 的 DNS（避免 dnsmasq），这个查询也可以。

那么，为什么节点上的 dnsmasq 会忽略来自 pod 的 TCP 请求，以及为什么任何其他通信都可以？这是应该的行为吗？

感谢任何帮助和想法。

Answer 1

最后，原因是dnsmasq被配置为监听节点的IP（listen-adress=192.168.58.6）。使用这样的配置，dnsmasq 绑定到 所有 节点的网络接口，但尝试拒绝用户空间中的“错误”连接（即自行拒绝）。

我不太明白，为什么 dnsmasq 决定使用这种配置禁止从 pod 到 192.168.58.6 的请求，但我通过将“listen-address”更改为

interface=eth0
bind-interfaces

这迫使 dnsmasq 实际上只绑定到 IP 为 192.168.58.6 的 NIC。之后 dnsmasq 开始接受所有 TCP 请求。