#weavenetwork

Hello folks! I'm looking into using weave + weavedns, and it looks great. The only issue I'm having at the moment is that the DNS resolver only knows about local names - from what I can tell, it should delegate to some upstream DNS server for domains outside of .weave.local, but I'm not seeing that behavior.

Add --with-dns to the weave command, will replace /etc/resolv.conf with its own nameserver - so the info I found that "uses the local resolver, which will do whatever is configured in /etc/resolv.conf" seems to be outdated

any idea what I might be doing wrong, or how I can use an upstream DNS with weavedns?

I am using 0.9.0 by the way

the sentence about "uses the local resolver" refers to the host.

aha

i.e. yes, --with-dns will replace /etc/resolv.conf *in the container*. the entry will point to weavedns, which in turn should use the resolv.conf from the *host* for resolving non-weave.local domains.

that sounds like a good strategy

it's a brilliant strategy :) but the question remains why it doesn't work for you.

indeed :)

does name resolution work ok on your host?

yes

I am using the example "To summarise" from this blog post: http://weaveblog.com/2014/11/28/weavedns-now-wi...

on a virtualbox running Ubuntu 14.04 LTS

anything interesting in the weavedns logs?

good question, where would I find those?

docker logs weavedns

lots of these: [dns msgid 39671] Failed lookup for external name archive.ubuntu.com

run `nslookup www.google.com` in the container and post the entries which get added to the log file.

moonfish: these are the logs from the start: https://gist.github.com/magnars/f896f3a12f509e2...

which entries got added by the nslookup?

there was no nslookup on the ubuntu container, but pinging www.google.com gave another line like this: WARNING: 2015/03/06 09:58:48.154009 [dns msgid 57170] Failed lookup for external name www.google.com.

ok

check what's in the resolv.conf in the weavedns container.

nameserver 172.17.42.1

are you sure? *inside* the weavedns container?

no

that's in the regular container

sec

grab docker-ns from https://raw.githubusercontent.com/zettio/weave/... and then run `docker-ns weavedns cat /etc/resolv.conf`

thanks

running `sudo docker-ns weavedns cat /etc/resolv.conf` gives the same output as in the host /etc/resolv.conf

that's good and bad. it's good because that's what it should look like. it's bad because the problem therefore must be elsewhere :(

what *is* in that file?

this: https://gist.github.com/magnars/e2c5b4c931442e5...

that suddenly makes sense, doesn't it

because the nameserver we're using is on the same subnet that weave has taken over

erhm. yes. you don't want to use a sub-net for weave that is already used by something else!

so... well spotted :)

hah, wow, thanks for your help in this

that's what I get for just following along with the example

I'm curious... your existing use of 10.0.2 - is that something you/somebody explicitly configured, or is it a result of some other piece of software picking a "random" subnet?

it some IT department in another building who set this up (the hipad.no guys)

again, thanks so much for the help - I wonder, does it make sense to warn about this someplace? or is it a freak accident? :)

we could add a warning to the weavedns logs when the nameserver in resolv.conf is in the weave subnet.

damn, changing the subnet didn't resolve the issue - and it can reach the dns-server at 10.0.2.3 now (via ping at least)

have filed https://github.com/zettio/weave/issues/437 for the first issue.

what CIDR did you give to weavedns?

yeah, so running `dig @10.0.2.3 www.google.com A` from the container works, but `dig @172.17.42.1 www.google.com A` results in another "Failed lookup for external name www.google.com";

"sudo weave launch-dns 10.0.0.2/16"

err, that's wrong though.

i.e. that CIDR contains your nameserver.

aha

10.0.0.2/24 should work.

thanks, time to start reading up on CIDR I guess

you should figure out what network your nameserver is on. check the route entries on your host. Then make sure whatever network you pick for weavedns does not overlap with that network.

yay, now it works :) so good news, the issue in 437 is what I stumbled over (repeatedly)

great

thanks so much!

you are welcome. we are always interested to hear about weave use cases, so let us know what you are doing. Once you have it working :)

will do :)

I'm experimenting with attaching/detaching docker containers with weave. It seems pretty consistent that when attaching to an IP that has previously been used (and detached), the attachment is immediately visible in `weave ps`, but it takes a few seconds to actually connect. Attaching to new IPs is instant. Is this expected behavior?

(I am curling from a different container that is attached to the weave network)

yes. arp tables/caches need some time to update

any way I can force a refresh?

the use case I'm looking at seamless deploys, spinning up a new application container and switching over to it, without other services needing to be restarted/linked

possibly. I'm not an arp expert.

it seems everything is going to be fine untill I run out of new IPs to assign to containers :)

re-cycling IPs should be fine, and any update delays *should* be quite small. If you have an easily reproducible example for when there is a long delay, please file an issue.

thanks, I'll do that

Am I right in saying I can use nameserver.MDNSClient to issue queries to a weave dns server?

chuhnk: Mmmm you probably could, yes

cool

noticed you only return one dns record

will that change any time soon?

chuhnk: Yes indeed, it's being worked on: https://github.com/zettio/weave/pull/429

cool

It sounds like you have an interesting use in the works, care to share?

:)

let me get some code written first, need to prove it works

fair enough!