#12250: Problems when relying on secondary DNS server
--------------------------+------------------------------
Reporter: TwoFx | Owner: bonefish
Type: bug | Status: new
Priority: normal | Milestone: Unscheduled
Component: Build System | Version: R1/Development
Keywords: | Blocked By:
Blocking: | Has a Patch: 0
Platform: All |
--------------------------+------------------------------
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.
--
Ticket URL: <https://dev.haiku-os.org/ticket/12250>
Haiku <https://dev.haiku-os.org>
Haiku - the operating system.