Talk:Unbound

From ArchWiki

"better to wait another month than this terrible script"

I assume this thread is about Special:Diff/505851, which is from January 2018. Regid (talk) 23:31, 25 May 2019 (UTC)Reply[reply]

User:Lahwaacz Please explain how the script is "terrible". It builds upon the one already suggested and is the only thing that works in a setup where one starts their network configuration manually when they want to connect to the internet, not automatically at boot.

—This unsigned comment is by Wincraft71 (talk) 07:21, 4 January 2018‎. Please sign your posts with ~~~~!

To begin with, systemctl is-active dhcpcd@eth0.service returns active even if the ethernet cable is not connected. Second, the service should run once and then be done, not ping-pong with systemd every 2 minutes if the system is offline. Third, longish scripts belong to separate files instead of the ExecStart line. Finally, if it still builds upon the one already suggested, you should just describe the differences instead of copy-pasting the timer etc. -- Lahwaacz (talk) 18:10, 4 January 2018 (UTC)Reply[reply]
In the scenario where the dhcpcd service is not enabled at boot and stays disabled for the user to manually start it, that would not be a problem. The service only repeats until it succeeds then it's done, otherwise it would always fail at boot because the system is offline. The script helps with delayed manual network configurations and is far from "terrible". Aside from the first two points, if the script was placed in a file and the differences placed in the article as an edit to be made to the original roothints.service, would it be acceptable? -- Wincraft71 (talk) 18:39, 4 January 2018 (UTC)Reply[reply]
If the dhcpcd service is not enabled and only started manually, one can also update the root hints manually. And note that for each restart of a service systemd writes several lines into its log so if the system is offline for 2 hours and the service restarts every 2 minutes, that's 60 log events, which is too much for a "normal" operation. Since you're devising such solution, surely 2 hours offline are not unusual - otherwise you could simply let the timer trigger at the time of the day which is always online. Let's continue when you deal with these. -- Lahwaacz (talk) 19:17, 4 January 2018 (UTC)Reply[reply]
Updating the root hints manually defeats the entire purpose of it being automatic. The time can be upped to 15 minutes which would make it only 8 log events which should be fine. Letting the timer trigger at a certain time of day is not dynamic, schedules can change and it should not be a fixed time. -- Wincraft71 (talk) 19:46, 4 January 2018 (UTC)Reply[reply]
There is no maximum offline time for a system, so it doesn't matter how large the restart timeout is - the service should start and wait on its own instead of returning to systemd. In any case, you need a better way to detect active internet connection. -- Lahwaacz (talk) 20:09, 4 January 2018 (UTC)Reply[reply]
Services running only when the system is up is additionally exactly the point of the network-online.target target, which this service should require and be ordered after, and then just run the update script without the restart or connectivity checking. @kyriastalk 00:25, 7 January 2018 (UTC)Reply[reply]
I am seeing from journalctl --list-boots and systemctl status network-online.target that network-online.target is reached shortly after boot, but my network was not up until 15 minutes later -- Wincraft71 (talk) 02:28, 8 January 2018 (UTC)Reply[reply]
Then it is misconfigured. See [1]. -- Lahwaacz (talk) 08:51, 8 January 2018 (UTC)Reply[reply]

Two DNS servers are not inherently more secure than one

There is a template:accuracy at unbound#Adding an authoritative DNS server. Not put by me. I think it is arguable if running two DNS servers, one which will act as a resolver and the other as authoritative, is inherently more secure than running one providing all features. What I think is less arguable is that using diverse solutions across the internet as a whole is inherently more secure then using one prominent solution. Which is why lowering the share of BIND usage across the internet did made the internet more secure. Perhaps also making OpenBSD 5.7, which uses nsd + unbound in its base and offers BIND only via ports, more secure then 5.6. Regid (talk) 06:50, 26 May 2019 (UTC)Reply[reply]

"...if the package is updated regularly, no manual intervention is required. "

The sentence "Therefore, if the package is updated regularly, no manual intervention is required." suggests that there is no need in maintaining an up-to-date root.hints file. Just by keeping unbound up-to-date will keep the root hints current enough.

Current unbound version 1.19.0 dates 8 November, 2023. Arch package is carrying the same date. 2 months and 13 days later the unbound internal stubs list is already out of date for B.ROOT-SERVERS.NET both ipv4 and ipv6 addresses. At least the addresses at https://www.internic.net/domain/named.cache (last updated: December 20, 2023) do differ. Although the internal stub for the old B.ROOT-SERVER ipv4 199.9.14.201 does still answer queries.

On the other hand https://kb.isc.org/docs/aa-01309 states: It doesn't matter if the root hint zone is a little out of date - this is because root priming takes care of any recent changes... As long as at least one of the servers listed in the root hint zone is still correct, named will be able to prime itself.

Does unbound operate similar to bind (only 1 responding dns root-server is enough) in priming the root hint zone? Probackup-nl (talk) 14:44, 21 January 2024 (UTC)Reply[reply]