What to use as replacement for named after 10.2 upgrade

K

KdeBruin

I'm currently upgrading my 9.3-RELEASE system to 10.2-RELEASE using the steps outlined in this article:
https://dan.langille.org/2015/03/13...-freebsd-10-1-using-beadm-and-freebsd-update/

The upgrade will remove the named configuration I'm using now for a simple local nameserver. What would be the best way to continue:
What the nameserver needs to do is provide a mapping between IP addresses and local system names and act as a cache for external queries. IP addresses are assigned by my router based on MAC addresses so DHCP is not required.
 
In my lab consisting of about 85 machines and over 60 active users we use Unbound (3 instances for DMZ and 3 for LAN) exactly for that.
 
Another vote for dns/unbound. It's very flexible and can do almost anything except a master/slave setup for an authoritative DNS server (it lacks zone transfers, use dns/nsd for that). It has a good security track record and is the default caching DNS resolver in OpenBSD base starting with version 5.7.
 
If all else fails, you can always install one of the BIND ports and use the configuration you have now. The only difference is that BIND is installed from a port or package. But for a basic caching only server unbound should suffice.
 
KdeBruin said:
Oko, thanks for your input. I will search for some how-to to do this.
Click to expand...

Code: 
# uname -a
OpenBSD apollo.autonlab.org 5.7 GENERIC.MP#0 amd64

Run /usr/sbin/unbound-control-setup

Edit /var/unbound/etc/unbound.conf
Code: 
# $OpenBSD: unbound.conf,v 1.4 2014/04/02 21:43:30 millert Exp $

server:
  interface: 127.0.0.1
  interface: ::1
  interface: 192.168.6.254
  do-ip6: no
  do-tcp: no

  access-control: 0.0.0.0/0 refuse
  access-control: 127.0.0.0/8 allow
  access-control: ::0/0 refuse
  access-control: ::1 allow
  access-control: 192.168.6.0/24 allow


  hide-identity: yes
  hide-version: yes

  # Uncomment to enable DNSSEC validation.
  #
  auto-trust-anchor-file: "/var/unbound/db/root.key"

  # Serve zones authoritatively from Unbound to resolver clients.
  # Not for external service.
  #
  include: "/var/unbound/etc/autonlab/*"

Code: 
# pwd
/var/unbound/etc/autonlab
# ls *
6.168.192.in-addr.arpa  int.autonlab.org

Code: 
# more 6.168.192.in-addr.arpa
  local-zone: "6.168.192.in-addr.arpa." static
  local-data-ptr: "192.168.6.1 titan.int.autonlab.org"
  local-data-ptr: "192.168.6.2 svnhub.int.autonlab.org"

Code: 
# more int.autonlab.org
  local-zone: "int.autonlab.org" static
  local-data: "titan.int.autonlab.org IN A 192.168.6.1"
  local-data: "svnhub.int.autonlab.org IN A 192.168.6.2"
# echo 'unbound_flags="-c /var/unbound/etc/unbound.conf"'> /etc/rc.conf.local
# rcctl start unbound

Make sure that interface on which Unbound listens is up and make sure you edit firewall accordingly to allow port domain on UDP from 192.168.6.0/24 network.
 
Oko said:
Code: 
# uname -a
OpenBSD apollo.autonlab.org 5.7 GENERIC.MP#0 amd64

Run /usr/sbin/unbound-control-setup

Edit /var/unbound/etc/unbound.conf
Code: 
# $OpenBSD: unbound.conf,v 1.4 2014/04/02 21:43:30 millert Exp $

server:
  interface: 127.0.0.1
  interface: ::1
  interface: 192.168.6.254
  do-ip6: no
  do-tcp: no

  access-control: 0.0.0.0/0 refuse
  access-control: 127.0.0.0/8 allow
  access-control: ::0/0 refuse
  access-control: ::1 allow
  access-control: 192.168.6.0/24 allow


  hide-identity: yes
  hide-version: yes

  # Uncomment to enable DNSSEC validation.
  #
  auto-trust-anchor-file: "/var/unbound/db/root.key"

  # Serve zones authoritatively from Unbound to resolver clients.
  # Not for external service.
  #
  include: "/var/unbound/etc/autonlab/*"

Code: 
# pwd
/var/unbound/etc/autonlab
# ls *
6.168.192.in-addr.arpa  int.autonlab.org

Code: 
# more 6.168.192.in-addr.arpa
  local-zone: "6.168.192.in-addr.arpa." static
  local-data-ptr: "192.168.6.1 titan.int.autonlab.org"
  local-data-ptr: "192.168.6.2 svnhub.int.autonlab.org"

Code: 
# more int.autonlab.org
  local-zone: "int.autonlab.org" static
  local-data: "titan.int.autonlab.org IN A 192.168.6.1"
  local-data: "svnhub.int.autonlab.org IN A 192.168.6.2"

# echo 'unbound_flags="-c /var/unbound/etc/unbound.conf"'> /etc/rc.conf.local
# rcctl start unbound


Make sure that interface on which Unbound listens is up and make sure you edit firewall accordingly to allow port domain on UDP from 192.168.6.0/24 network.
Click to expand...
You don't need to do all that for unbound(8) on FreeBSD 10.2-RELEASE. The configuration files will be automatically created by its rc(8) script. Just adding
Code: 
local_unbound_enable="YES"
to /etc/rc.conf will automatically create the necessary configuration files on reboot/service start if they don't already exist. You can of course configure Unbound further if needed.
 
The default configuration of local_unbound is very minimal and allows only local 127.0.0.1 connections. I also don't like the way the local_unbound rc(8) script mucks with /etc/resolv.conf, the dns/unbound port is a better choise if you have a LAN to serve.
 
Thanks all. I have hit a snatch with some development I have to do so I will look at it this weekend.
 
protocelt said:
You don't need to do all that for unbound(8) on FreeBSD 10.2-RELEASE. The configuration files will be automatically created by its rc(8) script. Just adding
Code: 
local_unbound_enable="YES"
to /etc/rc.conf will automatically create the necessary configuration files on reboot/service start if they don't already exist. You can of course configure Unbound further if needed.
Click to expand...
You don't need to do all of above on OpenBSD either. OP asked for little bit more complex set up then the one needed for DNS resolver which you typically run on your laptop. By the way I would second kpa statement. I would very strongly suggest reading vanilla unbound.conf file and understanding what every option does. After several iterations I am happy with OpenBSD defaults and what you see above is essentially diff to OpenBSD default configuration of Unbound resolver.

As much as I dislike FreeBSD firewalls (including its "fork" of PF) I like the idea of running Unbound as a Jail instance on the top of a ZFS pool (Hint: iocage rocks!). Highly recommended for FreeBSD only shops.
 
I've setup Unbound from both the ports and base system. Other than local_unbound's rc(8) script clobbering /etc/resolv.conf and the auto-configuration, both versions seemed functionally equivalent to me after being configured. Admittedly, I used a pretty simple configuration for both so there could be functional differences I'm not aware of.

Oko, I'm not familiar with how OpenBSD does it's configuration though I assume it's similar as on FreeBSD. I'll find out soon enough as I'll be setting up OpenBSD for my home network shortly as soon as I decide on the hardware to use so your post is helpful none the less. This is off topic however so is probably better discussed elsewhere. :)
 
I'm now using local_unbound and I can do normal and reversed lookups of both internal LAN and external addresses and hostnames. However, on my Mac I must use the full hostname including the domain name for a lookup. Need to figure out what that is all about as on my server I can use the hostname with or without the domain name part.

To be continued...
 
You need to provide the domain name in DHCP for the clients to be able to use the short names. For example with the standard ISC DHCP:

Code: 
option domain-name "example.com";
 
Code: 
pkg install bind99
Bind99 is the newest version of named from FreeBSD 9.3
 
I have everything up and running including name resolution for my local network. The strange thing is that with OS X I can just use a hostname for e.g. ssh but not for dig. The domain name was properly set by the DHCP server and also used in the OS X network settings.
 
Are you using +search with dig(1)?

Code: 
+[no]search
  Use [do not use] the search list defined by the searchlist or
  domain directive in resolv.conf (if any). The search list is not
  used by default.
 
I didn't use the +search argument but I must admit that I hadn't looked at the manual page either. Thanks for the info and I will add it to my list of tips and tricks.
 
You must log in or register to reply here.
Back
Top