Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
DNS is broken in new Ubuntu+systemd deployment #2096
Concourse version: 3.9.2
I just set up this new Concourse installation a couple days ago. I've got a job with
I know the jobs are properly configured because I can use an HTTP proxy as a workaround for the git resource:
But I wasn't able to get the docker image resource to work by setting the proxy in the concourse worker; perhaps this PR (which fixes this issue) isn't in yet, or maybe this issue means that it's still not fixed.
Let's hijack a build container
If I hijack a build container and start poking around,
So manually resolving DNS looks like this:
# nslookup www.baidu.com nslookup: can't resolve '(null)': Name does not resolve nslookup: can't resolve 'www.baidu.com': Try again
(I'm using baidu because I'm in China and Google is blocked) But even if I manually specify the DNS server (in this case, Baidu's equivalent of 22.214.171.124), name resolution fails:
nslookup www.baidu.com 126.96.36.199 Server: 188.8.131.52 Address 1: 184.108.40.206 nslookup: can't resolve 'www.baidu.com': Try again
Whereas on the host box itself, name resolution works just fine:
$ nslookup www.baidu.com 220.127.116.11 Server: 18.104.22.168 Address: 22.214.171.124#53 Non-authoritative answer: www.baidu.com canonical name = www.a.shifen.com. Name: www.a.shifen.com Address: 126.96.36.199 Name: www.a.shifen.com Address: 188.8.131.52
This looks like a UDP forwarding issue, so I ran these commands:
sudo ufw disable sudo iptables -I FORWARD -j ACCEPT
As well as re-enabling UFW and setting its default forward policy to ACCEPT as described here, but that didn't help.
TCP and ICMP forwarding works just fine though; if I know the IP address of a web server (like www.baidu.com), I can ping it and get a web page from it:
$ ping 184.108.40.206 PING 220.127.116.11 (18.104.22.168): 56 data bytes 64 bytes from 22.214.171.124: seq=0 ttl=54 time=2.947 ms 64 bytes from 126.96.36.199: seq=1 ttl=54 time=2.788 ms ... $ curl http://188.8.131.52/ <!DOCTYPE html> <!--STATUS OK--><html> <head><meta http-equiv ...
Since it's a UDP forwarding issue and not a DNS issue, none of the Gardner DNS settings help at all.
It looks like UDP forwarding to containers is somehow not setup properly by gardener. In this issue someone mentions using