Including the list correctly. On Tue, Jan 31, 2017 at 4:06 PM, Clayton Coleman <[email protected]> wrote:
> > > On Jan 30, 2017, at 1:51 AM, Srinivas Naga Kotaru (skotaru) < > [email protected]> wrote: > > Hi > > > > Observed 2 different behaviors in my platform. not sure this is expected > behavior or not. Can you clarify for below behaviors? > > > > 1. Name resolution not working for external domains although ping > and curl commands working as expected > > > > Examples: > > > > # oc rsh kong-app3-792309857-1i4xk > > > > # ping -c1 google.com > > PING google.com (216.58.204.110) 56(84) bytes of data. > > 64 bytes from par10s28-in-f14.1e100.net (216.58.204.110): icmp_seq=1 > ttl=47 time=85.7 ms > > > > #$ curl -IL google.com > > HTTP/1.1 302 Found > > Cache-Control: private > > Location: http://www.google.com.co/?gfe_rd=cr&ei=6d6OWOCgJPLU8ge42JWoCA > > Date: Mon, 30 Jan 2017 06:36:25 GMT > > Content-Length: 262 > > Content-Type: text/html; charset=UTF-8 > > Via: 1.1 rtp5-dmz-wsa-1-mgmt.cisco.com:80 (Cisco-WSA/8.8.0-085) > > Connection: keep-alive > > > > HTTP/1.1 200 OK > > Date: Mon, 30 Jan 2017 06:36:26 GMT > > Expires: -1 > > Cache-Control: private, max-age=0 > > P3P: CP="This is not a P3P policy! See https://www.google.com/ > support/accounts/answer/151657?hl=en for more info." > > Server: gws > > X-XSS-Protection: 1; mode=block > > X-Frame-Options: SAMEORIGIN > > Set-Cookie: NID=95=pwFoBQb-ktya5LeVlXGLKPJX2N-fLE_ > oIw37Wq2F7FFOeuJp0rObVHRJw7jRg9luz3Jq4f3CQadMWr6RonTJot0oxSEcx- > NGKS8cDaksuT5t3mqTtPZaKb20HRjn9ffF; expires=Tue, 01-Aug-2017 06:36:26 > GMT; path=/; domain=.google.com.co; HttpOnly > > Accept-Ranges: none > > Vary: Accept-Encoding > > Transfer-Encoding: chunked > > Content-Type: text/html; charset=ISO-8859-1 > > Via: 1.1 rtp5-dmz-wsa-1-mgmt.cisco.com:80 (Cisco-WSA/8.8.0-085) > > Connection: keep-alive > > > > # cat /etc/resolv.conf > > search oneid-rtp.svc.cluster.local svc.cluster.local cluster.local > cisco.com > > nameserver 64.101.6.21 > > nameserver 144.254.71.184 > > nameserver 173.38.200.100 > > nameserver 173.38.165.13 > > options timeout:1 attempts:1 > > options ndots:5 > > > > > > # dig google.com > > > > ; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3.1 <<>> google.com > > ;; global options: +cmd > > ;; Got answer: > > ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 21380 > > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > > Refused is not normal - does your node have dnsmasq and if so, are there > any config changes there? We are moving more to having all pods only speak > to the node via dnsmasq > > > > ;; QUESTION SECTION: > > ;google.com. IN A > > > > ;; Query time: 1 msec > > ;; SERVER: 64.101.6.21#53(64.101.6.21) > > ;; WHEN: Mon Jan 30 06:38:07 UTC 2017 > > ;; MSG SIZE rcvd: 28 > > > > # nslookup google.com > > Server: 64.101.6.21 > > Address: 64.101.6.21#53 > > > > ** server can't find google.com: REFUSED > > > > #host gogole.com > > Host gogole.com not found: 5(REFUSED) > > > > Queries against 1st server from POD /etc/resolve.conf ( This is node IP > address where POD has been running) > > > > sh-4.2$ dig +short google.com @64.101.6.21 > > sh-4.2$ > > > > sh-4.2$ nslookup google.com 64.101.6.21 > > Server: 64.101.6.21 > > Address: 64.101.6.21#53 > > > > ** server can't find google.com: REFUSED > > > > However DNS queries aginst 2nd server from POD /etc/resolve.conf works > fine ( This IP represent our corproate DNS servers borrowed from HOST > /etc/resolve.conf) > > > > dig +short google.com @144.254.71.184 > > 216.58.204.110 > > > > sh-4.2$ nslookup google.com 144.254.71.184 > > Server: 144.254.71.184 > > Address: 144.254.71.184#53 > > > > Non-authoritative answer: > > Name: google.com > > Address: 216.58.204.110 > > > > 2. Service resolution working as expected. However different DNS > clients behaving differently with and without service FQDN. Dig doesn’t > working without FQDN, > > > Dig doesn't check the search path by default - you have to ask for it > (+search) > > > > > > sh-4.2$ dig kong-database2 > > ;; QUESTION SECTION: > > ;kong-database2. > IN A > > > > with FQDN it is working > > > > sh-4.2$ dig kong-database2.oneid-rtp.svc.cluster.local > > ;; ANSWER SECTION: > > kong-database2.oneid-rtp.svc.cluster.local. 30 IN A 172.29.2.1 > > > > > > nslookup working with or without FQDN > > > > sh-4.2$ nslookup kong-database2 > > Server: 64.101.6.21 > > Address: 64.101.6.21#53 > > > > Non-authoritative answer: > > Name: kong-database2.oneid-rtp.svc.cluster.local > > Address: 172.29.2.1 > > > > sh-4.2$ nslookup kong-database2.oneid-rtp.svc.cluster.local > > Server: 64.101.6.21 > > Address: 64.101.6.21#53 > > > > Non-authoritative answer: > > Name: kong-database2.oneid-rtp.svc.cluster.local > > Address: 172.29.2.1 > > > > > > -- > > *Srinivas Kotaru* > > _______________________________________________ > dev mailing list > [email protected] > http://lists.openshift.redhat.com/openshiftmm/listinfo/dev > >
_______________________________________________ dev mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
