If DNS server = local IP address of router, a program can perform only 1 data transfer per 15 seconds

[BlazeTester]

I recommend to enhance TrueOS Handbook Chapter 5.2.3. "Network Configuration.." with the following text (in a blue Note Box):

"If the local IP address of your router is chosen as DNS server address, your router will act as DNS proxy server.
However, this can lead to delays between consecutive data transfers:
For example, a delay of about 15 seconds between every IP connection that is established by AppCafe or Update Manager is possible.
If you observe such a problem, it can be solved by performing the following steps:

1. Remove the local IP address of your router from the DNS field.
2. Enter the IP address of the DNS server of your Internet service provider or choose a DNS server from the list of public DNS servers.
   These steps have to be performed for IPv6 too."
   (Hint: My hardware supports only IPv4; therefore, I couldn't test IPv6 and couldn't verify the last sentence "These steps have to be performed for IPv6 too.").

I recommend this enhancement of TrueOS Handbook because of the following observations:
Parameters:
I examined all network traffic by installing TrueOS 18.03 (stable) in VirtualBox and checking its network traffic under the host system OSX with the network monitor Private Eye.
I allocated in the processor menu of VirtualBox all 4 "virtual CPU cores" of my Intel Core i5-2415M with 2 Cores 4 Threads to guest operating system TrueOS.
Despite BSDstats' self-description "Monthly script for reporting anonymous statistics about your machine", BSDstats contacts bsdstats.org on every booting of TrueOS; therefore, for some tests, I disabled BSDstats' "Start on Boot" via Service Manager in the Control Panel in order to recognize the Internet server contacts performed by Update Manager.
(Side note:
If I reboot TrueOS via "Leave > Restart", Update Manager and BSDstats are the only programs that initiate Internet server contacts on booting of TrueOS.
However, if I choose "Leave > Power Off" in Lumina Desktop and perform a "cold" start of TrueOS afterwards, on every booting of TrueOS, an unidentified program establishes either 1 or 6 contacts to various Google servers.
If 6 contacts to Google servers occur, they are always initiated simultaneously.
These contacts occur 10 to 2 seconds before the login window appears, or 20 to 28 seconds after the point of time when the login window appeared: 10 to 2 seconds before the login window appears, if I entered my ISP's DNS server address in Network Manager's DNS field; 20 to 28 seconds after the point of time when the login window appeared, if I entered the local IP address of my router in Network Manager's DNS field.
These contacts to Google servers occur only if I installed TrueOS 18.03 from the ISO image; if I update TrueOS 17.12 via Update Manager to the level of TrueOS 18.03, these contacts to Google servers do not occur.
The programs Thunderbird and Firefox are installed only if I install TrueOS 18.03 from the ISO image; if I update TrueOS 17.12 via Update Manager to the level of TrueOS 18.03, Thunderbird and Firefox are not installed; therefore, maybe a program that is installed with Thunderbird and Firefox causes these contacts to Google servers.
After the deletion of Thunderbird and Firefox via AppCafe, the unidentified program is still present and establishes a contact to Google server par21s05-in-f4.1e100.net. Interesting detail: when I type a homepage address in Firefox' address field, Firefox also contacts the same Google server in order to give autocompletion suggestions).

Observations in case the local IP address of my router is chosen as DNS server address in Network Manager's DNS field:
When TrueOS 18.03 (stable) shows its login window, I enter my user password and press the arrow button to start Lumina Desktop.
After about 60 seconds after pressing that arrow button, Update Manager's update check that is performed on every booting begins to contact Internet servers 16 times.
Between each of the first 8 Internet server contacts, a delay of about 15 seconds occurs.
Between the 8th and the 9th Internet server contact, a delay of 5 seconds occurs.
Between each of the 5 Internet server contacts "in the middle", a delay of about 15 seconds occurs.
Between the 13th and the 14th Internet server contact, a delay of 5 seconds occurs.
Between each of the last 3 Internet server contacts, a delay of about 15 seconds occurs.

The shorter delay between the 8th and the 9th Internet server contact, and between the 13th and the 14th Internet server contact, respectively, probably indicates that this update check is performed by three independent subprocesses:
The first subprocess performs 8 Internet server contacts, the second one 5 Internet server contacts, and the third one performs 3 Internet server contacts.
(Sometimes, the postulated first subprocess performs 6 Internet server contacts, the second one 6 Internet server contacts, and the third one performs 4 Internet server contacts; in that case, the 5 seconds-boundaries between the three sets of Internet server contacts are shifted).

When I switch BSDstats on so that it contacts bsdstats.org on every booting of TrueOS, I observe the following behavior:
Between each of BSDstats' 5 (or more) bsdstats.org-contacts, a delay of about 15 seconds occurs.
Between (most of) the Internet server contacts of Update Manager, a delay of about 15 seconds occurs.
But the Internet server contacts of BSDstats and Update Manager are interwoven with each other:
The interval between an Internet server contact of BSDstats and an Internet server contact of Update Manager is only 0 to 9 seconds (depending on the start times of both programs).
As BSDstats and Update Manager are independent programs, each of them can perform data transfers independently; i.e., both programs don't have to wait for each other - thus, there's no 15 seconds-interval between an Internet server contact of BSDstats and an Internet server contact of Update Manager.
Therefore, in the paragraph above, I suppose that Update Manager's update check can be divided into three independent subprocesses that don't interfere with each other, because there's also no 15 seconds-interval between their three sets of Internet server contacts.

When I start Update Manager in the Control Panel, it begins to contact Internet servers 4 times.
Between each of these 4 Internet server contacts, a delay of about 15 seconds occurs.

When I press the "Save Settings"-button in Update Manager's Settings tab, an update check is initiated and contacts Internet servers 24 times.
Here, I observe four different intervals between these 24 contacts: 0 seconds, 5 seconds, 10 seconds, and 15 seconds.
Sometimes, these 24 contacts are especially well ordered:
3 contacts occur simultaneously; after a delay of 15 seconds, 3 further contacts occur simultaneously, and so on, until 12 contacts have been performed.
Among the following 12 contacts, the interval between 8 contacts is 15 seconds, and the interval between two pairs of contacts is 5 seconds.
So, if I postulate that these 24 Internet server contacts are performed by several independent subprocesses, the Internet server contacts that occur within each subprocess have an interval of 15 seconds relative to each other.

TrueOS update via Update Manager:
The observations mentioned in this paragraph have been done on TrueOS-2017-07-05 and TrueOS 17.12; nevertheless, if TrueOS 18.03 will get an update, it will probably show the same behavior:
When Update Manager finds a TrueOS update, it usually consists of hundreds of files; every single file download requires the establishment of an Internet server contact.
While these files are being downloaded, I observe the following structuring:
Between each of the first 5 Internet server contacts, a delay of about 15 seconds occurs.
Between the 5th and the 6th Internet server contact, a delay of 5 seconds occurs.
From the 6th to the 10th Internet server contact, between each of these 5 contacts, a delay of about 15 seconds occurs.
Between the 10th and the 11th Internet server contact, a delay of 5 seconds occurs.
The following Internet server contacts show an analogous structuring.
This shows that the download process is structured in groups of 5.
Only if a file is so big that its download itself takes several seconds or more time, the time span until the following file download starts is longer than 15 seconds.
The great quantity of 15 seconds-intervals sums up to huge time spans so that a TrueOS update takes many hours.

AppCafe under TrueOS 18.03:
When I start AppCafe, 4 Internet server contacts occur within 1 second; then, after 6 seconds, 2 further Internet server contacts occur within 1 second.
When I click on the button "Office Suites", 10 Internet server contacts occur within 2 seconds.
Then I choose "libreoffice" in the list of office suites, start its download and switch to AppCafe's "Pending" tab to observe the download process.
In the first step of the download process, AppCafe updates TrueOS repository catalogues; after that, the download of 38 LibreOffice packages is performed.
During the update of TrueOS repository catalogues, 10 Internet server contacts occur; the interval between each of these Internet server contacts is mostly 15 seconds; but one interval is 2 seconds, and two intervals are 5 seconds.
While the download of the 38 LibreOffice packages is performed, a structuring of groups of 5 (analogous to Update Manager's download of a TrueOS update) is observed:
Between each of the first 5 Internet server contacts, a delay of about 15 seconds occurs.
Between the 5th and the 6th Internet server contact, a delay of 5 seconds occurs.
From the 6th to the 10th Internet server contact, between each of these 5 contacts, a delay of about 15 seconds occurs.
Between the 10th and the 11th Internet server contact, a delay of 5 seconds occurs.
The following Internet server contacts show an analogous structuring.
Only if a package is so big that its download itself takes several seconds or more time, the time span until the following package download starts is longer than 15 seconds.
A calculation of the difference between "Time Started" and "Time Finished" in AppCafe's "Pending" tab shows that the complete download process takes 13 minutes.

Internet browsers:
I tested the Internet browsers Iridium 58.0_12 (which is based on Chromium), Firefox 58.0.2,1, QupZilla 2.1.2 and Opera 12.16_6.
Surfing on news sites is especially well suited for testing because such sites cause a huge number of Internet server contacts; I chose the homepage of The New York Times for testing.
All browsers show the same behavior:
When I enter the homepage address and press the return key, for 15 seconds no homepage server contact occurs; only after these 15 seconds, homepage server contacts occur and the homepage is loaded bit by bit.
(Side note: With Firefox, QupZilla and Opera 12.16_6, the delay is even longer: After pressing return, these browsers contact a FASTLY server first, and only afterwards the desired homepage server; between the FASTLY server contact and the first homepage server contact a 15 seconds-interval occurs (35 seconds for Opera 12.16_6 because Opera calls the FASTLY server several times)).
Between the server contacts that occur, different intervals like 3, 4, 5, 10, 15, and 22 seconds are observed.
Often not only one but up to 12 (or even more) server contacts occur simultaneously.

Observations in case the IP address of the DNS server of my Internet service provider is chosen as DNS server address in Network Manager's DNS field:
In this case, no abnormal delays between consecutive data transfers occur; instead, most of the Internet server contact sequences described in the paragraphs above occur within 1 to 3 seconds completely.
Only if a file that is being downloaded has a size of several megabytes, its download itself takes some time so that there is a normal delay until the following Internet server contact starts.
A normal delay can also occur if a program needs some time to process received data internally:
for example, in case the update check Update Manager performs on booting of TrueOS finds a new TrueOS update, its first 12 Internet server contacts occur within 3 seconds, but then there's a time span of about 20 seconds in that Update Manager processes the info about the new update so that only afterwards the last 4 Internet server contacts are established by Update Manager (within 1 second).

AppCafe under TrueOS 18.03:
Download of LibreOffice via AppCafe:
A calculation of the difference between "Time Started" and "Time Finished" in AppCafe's "Pending" tab shows that the complete download process takes only 3 minutes 17 seconds.

Internet browsers:
When I enter a homepage address and press the return key, the homepage is loaded immediately without delay.

Historical background and comparisons with other operating systems:
The 15 seconds-delay-problem is very old:
A decade ago, I tried the Linux distributions Ubuntu 8.04 and openSUSE 11.2: both Linux distributions had this problem (which I could solve by entering the IP address of the DNS server of my Internet service provider in Network Manager's DNS field).
Also older versions of TrueOS (when it was called PC-BSD) already had this problem.
In the end, I suppose that from the first day Network Manager came into existence (for Linux and BSD), the 15 seconds-delay-problem existed.

I also tried a current Linux distribution (openSUSE 42.3):
Here, Firefox also has the 15 seconds-delay-problem and shows a behavior like Firefox under TrueOS.
The openSUSE Update Manager and Software Manager show the 15 seconds-delay-problem when they contact download.opensuse.org and ftp.opensuse.org; though, contacts to other mirror servers and ftp servers often occur without delay.

Comparison with Apple operating system OSX 10.7:
Browsing the Internet with Opera Browser under OSX 10.7 was always unproblematic - even if the local IP address of my router was entered in Network Manager's DNS field.
Though, from Opera Browser version 11.50 (which was my first Opera version for OSX 10.7), the 15 seconds-delay-problem occurred when I sent an e-mail via the mail module of Opera Browser: my mouse cursor became a spinning rainbow wheel for 45 seconds - only after that delay, the e-mail was sent successfully. (I read in forums that this problem was known since Opera version 9).
I solved this problem by entering the IP address of the DNS server of my Internet service provider in Network Manager's DNS field.
Later, when Opera 11.64 was released, this problem was solved in Opera: from that version, I could enter the local IP address of my router in Network Manager's DNS field, and every e-mail could be sent without delay.

Comparison with Windows XP:
Under Windows XP, the 15 seconds-delay-problem never occurred. (Also Opera for Windows never had the 15 seconds-delay-problem).
(I never bought newer versions of Windows).

Summary:
Entering the IP address of the DNS server of the Internet service provider in Network Manager's DNS field solves the 15 seconds-delay-problem.

However, it would be nice if one could change the software so that no problems arise if the router's local IP address is entered in Network Manager's DNS field. I hope that my analysis above can help to find the necessary software adjustments.

As it can be seen above - even if my router's local IP address is entered in Network Manager's DNS field - Internet server contacts of independent programs like Update Manager and BSDstats don't have to wait for each other.
Programs like AppCafe, openSUSE's Update Manager and Internet browsers can initiate at least partially many Internet server contacts simultaneously; so it could be worthwhile to check which binary functions these programs use to achieve this.
Possibly programs like AppCafe, openSUSE's Update Manager and Internet browsers can initiate many Internet server contacts simultaneously because these programs start a separate subprocess for each new Internet server contact so that Network Manager thinks that each Internet server contact originates from a different program and therefore doesn't put these Internet server contacts in a kind of waiting list.

Well, in the end, it would be nice if it were sufficient to change only Network Manager to solve the 15 seconds-delay-problem:
Maybe Network Manager can be altered so that it basically thinks that every Internet server connection it mediates originated from a different program.
As it can be seen above, the Network Manager of Apple's OSX 10.7 is capable of mediating Internet server connections without 15 seconds-delays, even if my router's local IP address is entered in Network Manager's DNS field.
Provided that the operating system Darwin contains the same Network Manager as OSX / macOS, one could take a look in the open source code of Darwin in order to study the binary functions of Network Manager, which probably have the 15 seconds-delay-problem already solved.