Date: Mon, 15 Jun 2020 06:58:50 -0700 (PDT) From: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> To: Andriy Gapon <avg@freebsd.org> Cc: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net>, Ryan Steinmetz <zi@freebsd.org>, jaap@NLnetLabs.nl, net@freebsd.org Subject: Re: unbound and (isc) dhcpd startup order Message-ID: <202006151358.05FDwo7X076921@gndrsh.dnsmgr.net> In-Reply-To: <a0656ff4-6f02-ad4e-174b-ffdfe115156d@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 15/06/2020 15:57, Rodney W. Grimes wrote:
> >>
> >> 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 192.168.0.222"
> >> 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.
> >>
> >> For the moment I modified rc.d/unbound to add this line:
> >> # BEFORE: dhcpd
> >
> >>From looking at /etc/rc.d/local_unbound we see:
> > # PROVIDE: local_unbound
> > # REQUIRE: FILESYSTEMS defaultroute netwait resolv
> > # BEFORE: NETWORKING
> > # KEYWORD: shutdown
> >
> > What makes it work for that case is the BEFORE: NETWORKING is that
> > line missing for the port version?
>
> Yes, it is:
> # PROVIDE: unbound
> # REQUIRE: SERVERS cleanvar
> # KEYWORD: shutdown
>
> If we add BEFORE: NETWORKING then REQUIRE will also have to be adjusted as it's
> impossible to be before NETWORKING and after SERVERS.
Um, yea, I guess the bigger question is why is the port different
than the base system in this respect?
I would expect unbound to be the same, as unbound_local in almost
every respect, especially with respect to its startup sequencing,
providers and requires.
> >> I am not sure if this is the best solution and it's something that can be
> >> included into the port.
> >
> > I think that DNS needs to be started before more than just dhcpd,
> > so this is just 1 of many possible cases. This can also be issues
> > with almost any network stuff that wants to do stuff by DNS value,
> > including the networkself. DNS creates a chicken/egg problem in
> > that you may, or may not need the network to resolve names, I have
> > always hated that aspect of it. Modern tooling can help, you use
> > stuff to build your /etc/rc config files that can me run while the
> > network is up and functional so that this entering IP addresses in
> > N places is less painful.
> >
> > I seen no problem in adding a BEFORE: NETWORKING to the port, covering
> > a larger number of casses than your narrow BEFORE: dhcpd.
>
> I agree.
> I hope it doesn't break any currently working configurations too.
I have no idea how to hunt through ports looking for this. I
suppose find all ports that need unbound and see what there startup
scripts look like.
> >> On a related note, unbound rc script provides "unbound" service.
> >> I think that maybe it should provide something more generic such as "nameserver"
> >> or "dns-server" (not sure if there is an established name for that).
> >> The reason I am saying this is that, IMO, if unbound is replaced with some other
> >> name server implementation the rc dependency chains should stay the same.
> >
> > I do not see anything in the base system that uses unbound or local_unbound
> > service name, so this looks like it could be straightforward, though there
> > may be some ports that have use of this token.
> >
> > For the blue bikeshed I find that "server" is just noise in the token
> > and that "dns" already has "s" for system, so just "dns" is good with me :-)
>
> That's a good point.
> I've just checked bind ports and they use PROVIDE: named
> Not sure if "named" here is a bind specific name or a generic one.
named is specifically the name of the binary included in the bind
product, which included the resolver stub, named, and some other
support utilities like rndc and nslookup.
It would make since to unify these, though that is going to take
some cafeful thought and co-ordination as to not break peoples
running systems. I suspect the ports conflict stuff is keeping
one from installing unbound, and bind at the same time, arguable
wrong as one should be able to install both, but only run one
at a time, or even run both on different ports.
> --
> Andriy Gapon
--
Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202006151358.05FDwo7X076921>