Opened 9 years ago
#12250 new bug
Problems when relying on secondary DNS server
Reported by: | TwoFx | Owned by: | bonefish |
---|---|---|---|
Priority: | normal | Milestone: | Unscheduled |
Component: | Build System | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
This is hrev49292.
I have manually set primary and secondary DNS servers on Windows. The primary one is not available depending on where I am, but falling back to the secondary one is usually no problem. VirtualBox correctly communicates those settings to Haiku, so my /boot/system/settings/network/resolv.conf looks something like this:
nameserver 10.0.0.101 nameserver 8.8.8.8 domain fritz.box
Now, attempting to build Haiku results in all targets of type DownloadLocatedFile1
failing, which means that it is not possible to build Haiku (I guess it can be bootstrapped, I have not tried that). The reason for this is simple: wget is called with the argument --timeout 10. That this is the problem is easily verified:
~> wget --timeout 10 google.com --2015-07-28 13:09:21-- http://google.com/ Resolving google.com... failed: Operation timed out. wget: unable to resolve host address ‘google.com’ ~> wget --timeout 10.1 google.com --2015-07-28 13:09:35-- http://google.com/ Resolving google.com... 2a00:1450:4001:803::1007, 173.194.116.169, 173.194.116.167, ... Connecting to google.com|2a00:1450:4001:803::1007|:80... failed: Network is unreachable. Connecting to google.com|173.194.116.169|:80... connected. HTTP request sent, awaiting response... 302 Found
Compare this to the values that can be found in /boot/system/develop/headers/posix/resolv.h
:
130 #define MAXNS 3 /* max # name servers we'll track */ ... 134 #define RES_TIMEOUT 5 /* min. seconds between retries */ ... 139 #define RES_DFLRETRY 2 /* Default #/tries. */
It appears the requests at 0 and 5 seconds go to the first DNS server, and at 10 seconds, the second DNS server would be tried, but when building Haiku, the timeout is already reached and the target fails. So, either the timeout when building Haiku needs to be increased or the order in which DNS servers are queried needs to be modified.
Regarding the latter idea: I tested the same on Debian (with /etc/resolv.conf and /usr/include/resolv.h exactly matching) and wget succeeds with a timeout of 10, fails with a timeout of 5, but succeeds again with a timeout of 5.1. I assume that Debian recognizes that the request to the first DNS server was unsuccessful and tries the other DNS servers before retrying the first one. An advantage of that is that all other DNS requests (for instance when browsing the web) are delayed by "only" 5 seconds rather than the 10 seconds observed on Haiku when having to fall back to a secondary DNS server.