Fix user specified ndots option

[fcrisciani]

Setting ndots to 0 does not allow to resolve search domains
The default will remain ndots:0 that will directly resolve
services, but if the user specify a different ndots value
just propagate it into the container

Signed-off-by: Flavio Crisciani flavio.crisciani@docker.com

[codecov-io]

Codecov Report

❗ No coverage uploaded for pull request base (master@862df3a). Click here to learn what that means.
The diff coverage is 100%.

@@            Coverage Diff            @@
##             master    #2065   +/-   ##
=========================================
  Coverage          ?   40.59%           
=========================================
  Files             ?      138           
  Lines             ?    22170           
  Branches          ?        0           
=========================================
  Hits              ?     8999           
  Misses            ?    11853           
  Partials          ?     1318

Impacted Files	Coverage Δ
sandbox_dns_unix.go	53.18% <100%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 862df3a...9863928. Read the comment docs.

[eyz]

This PR #2065 resolves an issue introduced by PR #1995, where user-defined ndots, such as ndots:1 would be dropped, and thus user-specified search domains MYDOMAIN.COM where not checked for a host host -- where the FQDN is host.MYDOMAIN.COM in this example. From my research, ndots:# specifies the maximum number of domain dots allowed to search across, of the defined search domains.

After this PR (#2065) is applied, ndots:1 resolution works once again -

bash-4.4# ping host
PING host (10.210.102.152): 56 data bytes
64 bytes from 10.210.102.152: seq=0 ttl=127 time=0.716 ms
^C
--- host ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.716/0.716/0.716 ms

bash-4.4# ping host.MYDOMAIN.COM
PING host.MYDOMAIN.COM (10.210.102.152): 56 data bytes
64 bytes from 10.210.102.152: seq=0 ttl=127 time=0.576 ms
^C
--- host.MYDOMAIN.COM ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.576/0.576/0.576 ms

bash-4.4# hostname
h3o-gitlab-runner-latest-5-tsgijvijrh1hvhm7dwqvczu9b.nostack

bash-4.4# ping h3o-gitlab-runner-latest-1-3rdayq3uiw13s6u9wbc383uu0
PING h3o-gitlab-runner-latest-1-3rdayq3uiw13s6u9wbc383uu0 (10.100.1.11): 56 data bytes
64 bytes from 10.100.1.11: seq=0 ttl=64 time=0.599 ms
64 bytes from 10.100.1.11: seq=1 ttl=64 time=0.247 ms
^C
--- h3o-gitlab-runner-latest-1-3rdayq3uiw13s6u9wbc383uu0 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.247/0.423/0.599 ms

For reference, here is the /etc/docker/daemon.json for the above example -

{  
   "dns-search":[  
      "MYDOMAIN.COM"
   ],
   "dns-opts":[  
      "ndots:1"
   ]
}

For reference, here is the /etc/resolv.conf for the above example -

# cat /etc/resolv.conf 
search MYDOMAIN.COM
nameserver 127.0.0.11
options ndots:1

[ddebroy]

LGTM. @eyz's observation and results makes sense: earlier due to ndots:0 being specified by Docker, the container's resolver was not re-trying with search domains appended. Now it will.