Bug 247305 - dns/unbound: start earlier because it can provide local name service
Summary: dns/unbound: start earlier because it can provide local name service
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-ports-bugs (Nobody)
Keywords: patch
Depends on:
Reported: 2020-06-16 11:26 UTC by Andriy Gapon
Modified: 2020-07-27 10:52 UTC (History)
3 users (show)

See Also:
bugzilla: maintainer-feedback? (jaap)

proposed patch (1.82 KB, patch)
2020-06-16 11:26 UTC, Andriy Gapon
no flags Details | Diff
alternative patch (358 bytes, patch)
2020-06-16 11:29 UTC, Andriy Gapon
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Andriy Gapon freebsd_committer 2020-06-16 11:26:36 UTC
Created attachment 215610 [details]
proposed patch


I am configuring a small LAN -- mostly a gateway / router for it -- and I am
using unbound for a local DNS and isc-dhcp44-server for DHCP.
I have a few hosts with static IP addresses (for various reasons).
So, in unbound.conf I have an entry like
  local-data: "hipster.home.arpa. IN A"

and in dhcpd.conf  have:
  host hipster {
    hardware ethernet 40:74:e0:xx:xx:xx;
    fixed-address hipster.home.arpa;

I am using a DNS name to avoid hardcoding the same IP address twice.
But obviously this depends on the local DNS server starting before the HDCP
server if they are on the same host / router.
It seems that at the moment there is nothing to ensure that order.

It's been pointed out that both local_unbound and bind (in the default configuration) start earlier.  local_ubound start even before NETWORKING while bind starts before SERVERS.

I am proposing to change unbound port to do the same thing as bind ports.
START_LATE port option is provided for those who would need to start unbound at its traditional stage.
Comment 1 Andriy Gapon freebsd_committer 2020-06-16 11:29:27 UTC
Created attachment 215611 [details]
alternative patch

I have written an alternative patch.
It changes the startup order less drastically, so that unbind starts between SERVERS and DAEMON.  That's enough for my use case.
Comment 2 Rodney W. Grimes freebsd_committer 2020-06-16 14:50:55 UTC
(In reply to Andriy Gapon from comment #1)
I am ok with this, but I think it is fixing to narrow a set of cases, specifically only a subset of cases, ie DAEMONs that want to use dns in the configurations.  That set is large enough that this is a productive change.

I still wonder about the base system vs ports being different.  That just rubs me the wrong way.
Comment 3 Fernando Apesteguía freebsd_committer 2020-06-17 12:28:48 UTC
^Triage: Reporter is committer, assign accordingly.
Comment 4 Andriy Gapon freebsd_committer 2020-06-17 12:37:57 UTC
(In reply to Fernando Apesteguía from comment #3)
I am an src committer and never commit to ports.
Comment 5 Fernando Apesteguía freebsd_committer 2020-06-17 13:00:44 UTC
(In reply to Andriy Gapon from comment #4)

Hi Andriy

Any committer may commit to any repository with an accepted review from any committer with existing access to that repository.

Committers may obtain review via a Differential in Phabricator, adding the "Contributor Reviewers ($Repository)" group as a Reviewer, reaching out to other committers; directly or via mailing lists, or setting the attachment flag to: maintainer-approval ? <person-youd-like-to-review>
Comment 6 Andriy Gapon freebsd_committer 2020-06-17 13:27:48 UTC
(In reply to Fernando Apesteguía from comment #5)
I am aware that I *can* do it.  I am just letting you know that I am not doing it.
There is the maintainer who makes a decision if the proposed change is good.
There are port committers who are fluent with committing to ports.
I am just a reporter.
Comment 7 Fernando Apesteguía freebsd_committer 2020-06-17 13:48:28 UTC
(In reply to Andriy Gapon from comment #6)

Sure, thing. It was not my intention to annoy or lecture you :-)

Back to the pool.
Comment 8 Jaap Akkerhuis 2020-07-27 10:52:06 UTC
(In reply to Andriy Gapon from comment #0)
Given the discussion I'm actually leaning towards using the same ordering as the default in the base (local_unbound).

That has the benefit of the least surprise (I think).