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。当我尝试发送到的dnsmasq DNS请求（这是安装在节点和将请求转发到Kubernetes' SkyDNS）在UDP上，一切顺利的话：

# 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答案。我试图通过节点iteself对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决定，从荚192.168.58.6要求用这样的配置被禁止的，但我得到了它，通过改变“听地址”努力

interface=eth0 
bind-interfaces 

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