Opened 5 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:
Has a Patch: no 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:


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
--2015-07-28 13:09:21--
Resolving failed: Operation timed out.
wget: unable to resolve host address ‘’
~> wget --timeout 10.1
--2015-07-28 13:09:35--
Resolving 2a00:1450:4001:803::1007,,, ...
Connecting to|2a00:1450:4001:803::1007|:80... failed: Network is unreachable.
Connecting to||: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.

Change History (0)

Note: See TracTickets for help on using tickets.