Trouble with domain to container resolution on OS X about skydock HOT 14 CLOSED

@gijs have a look at the OSX weirdness paragraphs here

Maybe the same?

from skydock.

@asbjornenge thx for pointing there. It's that article that got me started in the first place ;) Adding the DNS server to OS X Network Preferences didn't do the trick in my case though :(

May I ask what your Network Prefs settings look like? Mine looks like this at the moment:

thx

from skydock.

@gijs yeah, looks correct to me... Did you try with only the skydns container ip? Don't know if I have any other tips I'm afraid. Everything looks correct... weird..

from skydock.

@gijs oh, hang on... might it be that your vm can't talk to the network?

Error: Failure to Forward DNS Request "read udp 8.8.8.8:53: i/o timeout

Can you dig @8.8.8.8 from the host? And also from within a container?

from skydock.

On 8 Sep 2014 12:42, "asbjornenge" [email protected] wrote:

@gijs oh, hang on... might it be that your vm can't talk to the network?

Error: Failure to Forward DNS Request "read udp 8.8.8.8:53: i/o timeout

This is probably a red herring.

Can you dig @8.8.8.8 from the host? And also from within a container?

But this is still a good thing to check.

—
Reply to this email directly or view it on GitHub.

from skydock.

Hmmm something magical happened...
I was trying nslookup in OSX to see if that worked.
Then this showed:

$ nslookup elasticsearch.dev.docker.dev
Server:     172.17.42.1
Address:    172.17.42.1#53

Name:   elasticsearch.dev.docker.dev
Address: 172.17.0.13

And this showed in $ docker logs skydns:

2014/09/08 11:44:28 Received DNS Request for "elasticsearch.dev.docker.dev." from "10.2.0.1:60197"

And voila! It works in the browser in OS X... out of the blue...
(too early to be happy though, as I dont yet understand the details of this magic)

Now I'm curious if container-to-container dns is working. thx so far, I'll close this for now.

ps. I could ping and dig 8.8.8.8 both from within a container and from the CoreOS VM.. not sure about that error indeed.

from skydock.

I left it alone for an hour or so, and then the browser window that I opened didn't respond anymore.

Had to run $ nslookup elasticsearch.dev.docker.dev again, then the browser came back to life...

Something to do with timeouts/ttls? This is a bit fragile....

from skydock.

Strange....someone (maybe me or someone else needs to port skydns2 to
skydock.). I have got skydns(2) running for months on a public server with
no ill effect.
On 8 Sep 2014 13:48, "Gijs Nijholt" [email protected] wrote:

Hmmm... I left it alone for an hour or so, and then the browser window
that I opened didn't respond anymore.

Had to run $ nslookup elasticsearch.dev.docker.dev again, then the
browser came back to life...

Something to do with timeouts/ttls? This is a bit fragile....

—
Reply to this email directly or view it on GitHub
#73 (comment)
.

from skydock.

A note on curl that just hit me today... curl by default uses (only?) ipv6. So I need to tell it to use ipv4 in order to get it working...

❯ curl elasticsearch.taghub.kiwi:9200   
curl: (6) Could not resolve host: elasticsearch.taghub.kiwi

❯ curl elasticsearch.taghub.kiwi:9200 -4
{
  "status" : 200,
  "name" : "Stegron"
  ...

from skydock.

This whole issue seems to be related to how operating systems handle dns lookups. It seems they are always querying both A and AAAA records. How they handle the results can vary between OS and application. Especially when there are only A results and no AAAA results present some systems behave, in lack of a better word; surprisingly.

Now, if docker had full ipv6 support, we could populate those records and solve this problem. But for now we are in a pickle. Disabling ipv6 or prioritising ipv4 dns queries for all containers is a huge PITA.

I've been fiddling with my own dns server for discovery over here. I recently added a --ipv4-only flag that will return A records even for AAAA queries. This actually seems to solve the problem. I'm not a DNS expert, so I don't know if it's appropriate or not, but it does work! 🚀

@miekg is this totally bonkers? Or a valid workaround while waiting for ipv6...?

from skydock.

Pretty amazed that --ipv4-only works at all....

What could be an issue here is that skydns (I must double check this) returns an NXDOMAIN for AAAA, which means a A lookup is useless as the node does not exist. It should return NODATA so that a follow-up A lookup is done.

Is a possible to show 'dig A' and 'dig AAAA' responses here?

from skydock.

@miekg AHA! That makes sense... I will try returning NODATA for the AAAA.

❯ dig postgresql.dance.kiwi A
// =>
;; QUESTION SECTION:
;postgresql.dance.kiwi.     IN  A

;; ANSWER SECTION:
postgresql.dance.kiwi.  5   IN  A   172.17.1.37


❯ dig "postgresql.dance.kiwi" AAAA
// =>
;; QUESTION SECTION:
;postgresql.dance.kiwi.     IN  AAAA

;; ANSWER SECTION:
postgresql.dance.kiwi.  5   IN  A   172.17.1.37

And none of the distributions I have tried are complaining anymore. Still, that NODATA is probably the correct fix. Thanks!

from skydock.

This being skydns(1) it should still do the right thing. I'm pretty sure skydns2 does so. Anyway I will work on getting skydock into skydns2.

from skydock.

@miekg no sorry, this was rainbow-dns responses (with --ipv4-only). I don't have skydock set up anymore...

But a 👍 for gettings skydns2 into skydock

from skydock.