Bug 1568095 - Extra dns quires sent out when curl $svc_name form pods
Summary: Extra dns quires sent out when curl $svc_name form pods
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Networking
Version: 3.10.0
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: ---
: 3.11.0
Assignee: Ben Bennett
QA Contact: Meng Bo
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-04-16 18:40 UTC by Weibin Liang
Modified: 2018-05-01 19:36 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-05-01 19:36:05 UTC
Target Upstream Version:


Attachments (Terms of Use)
dns packets (19.30 KB, text/plain)
2018-04-16 18:40 UTC, Weibin Liang
no flags Details

Description Weibin Liang 2018-04-16 18:40:54 UTC
Created attachment 1422673 [details]
dns packets

Description of problem:
Comparing dns query packets when curl $svc_name:8080 form node and pod, pod send four more query packets.

Version-Release number of selected component (if applicable):
oc v3.10.0-0.15.0

How reproducible:
Every time

Steps to Reproduce:
## In the Node:
[root@host-172-16-120-10 ~]# curl red-service.p1.svc.cluster.local.:8080
Hello Red Pod-1 Example
[root@host-172-16-120-10 ~]# cat /etc/resolv.conf 
# nameserver updated by /etc/NetworkManager/dispatcher.d/99-origin-dns.sh
# Generated by NetworkManager
search cluster.local openstacklocal
nameserver 172.16.120.10

One type of dns query sent out for  red-service.p1.svc.cluster.local.

## In the master:
[root@host-172-16-120-135 dnsmasq.d]# oc get pods -o wide
NAME         READY     STATUS    RESTARTS   AGE       IP            NODE
blue-pod-1   1/1       Running   0          3h        10.129.0.16   172.16.120.10
red-pod-1    1/1       Running   0          3h        10.129.0.17   172.16.120.10
[root@host-172-16-120-135 dnsmasq.d]# oc rsh blue-pod-1 
/ # cat /etc/resolv.conf 
nameserver 172.16.120.10
search p1.svc.cluster.local svc.cluster.local cluster.local openstacklocal
options ndots:5
/ # curl red-service.p1.svc.cluster.local.:8080
Hello Red Pod-1 Example

Five type of dns queries sent out for:
red-service.p1.svc.cluster.local.p1.svc.cluster.local.
red-service.p1.svc.cluster.local.svc.cluster.local.
red-service.p1.svc.cluster.local.cluster.local.
red-service.p1.svc.cluster.local.openstacklocal.
red-service.p1.svc.cluster.local.

Actual results:
Five type of dns queries sent out

Expected results:
only one dns query sent out for red-service.p1.svc.cluster.local.

Additional info:
Testing log of capturing dns packets is attached.

Comment 1 Ben Bennett 2018-04-16 19:23:44 UTC
Weibin, can you set:

option ndots 5

On the node's resolv.conf and see if it tries to resolve using the search path?

I am not sure why the trailing . is being ignored.  That should mean that it is an absolute name and the search path should not be used.  But it clearly is... this may be a resolver bug :-(

Comment 2 Weibin Liang 2018-04-16 19:43:02 UTC
Ben, when disable options ndots:5 in pod's /etc/resolv.con, then only one type of dns query send out for red-service.p1.svc.cluster.local.

[root@host-172-16-120-135 dnsmasq.d]# oc rsh blue-pod-1 
/ # cat /etc/resolv.conf 
nameserver 172.16.120.10
search p1.svc.cluster.local svc.cluster.local cluster.local openstacklocal
#options ndots:5

Get same wrong results when set options ndots:5 in node's resolv.conf.

Comment 3 Weibin Liang 2018-04-16 20:11:44 UTC
Same curl results using local:8080 and local.:8080


[root@host-172-16-120-135 dnsmasq.d]# oc rsh red-pod-1 curl blue-service.p1.svc.cluster.local:8080
Hello Blue Pod-2 Example
[root@host-172-16-120-135 dnsmasq.d]# oc rsh red-pod-1 curl blue-service.p1.svc.cluster.local.:8080
Hello Blue Pod-2 Example
[root@host-172-16-120-135 dnsmasq.d]#

Comment 4 Ben Bennett 2018-05-01 19:29:34 UTC
Can you try the same test please with:
  getent hosts blue-service.p1.svc.cluster.local

And
  getent hosts blue-service.p1.svc.cluster.local.

And then:
  getent hosts google.com
  getent hosts google.com.

I'm not sure if curl is misbehaving or the resolver.  I'm pretty sure it is not us.

Comment 5 Weibin Liang 2018-05-01 19:36:05 UTC
[root@weliang-rhel75-master .ssh]# getent ahostsv4 google.com
172.217.13.238  STREAM google.com
172.217.13.238  DGRAM  
172.217.13.238  RAW    
[root@weliang-rhel75-master .ssh]# getent ahostsv4 google.com.
172.217.13.238  STREAM google.com
172.217.13.238  DGRAM  
172.217.13.238  RAW    
[root@weliang-rhel75-master .ssh]# ping google.com
PING google.com (172.217.13.238) 56(84) bytes of data.
64 bytes from iad23s61-in-f14.1e100.net (172.217.13.238): icmp_seq=1 ttl=46 time=33.3 ms
64 bytes from iad23s61-in-f14.1e100.net (172.217.13.238): icmp_seq=2 ttl=46 time=33.3 ms
^C
--- google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 33.329/33.338/33.348/0.182 ms
[root@weliang-rhel75-master .ssh]# ping google.com.
PING google.com (172.217.13.238) 56(84) bytes of data.
64 bytes from iad23s61-in-f14.1e100.net (172.217.13.238): icmp_seq=1 ttl=46 time=33.2 ms
64 bytes from iad23s61-in-f14.1e100.net (172.217.13.238): icmp_seq=2 ttl=46 time=33.3 ms
^C
--- google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 33.219/33.283/33.347/0.064 ms
[root@weliang-rhel75-master .ssh]#


Note You need to log in before you can comment on or make changes to this bug.