# What to use as replacement for named after 10.2 upgrade



## KdeBruin (Sep 9, 2015)

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:

Install one of the dns/bind ports
Switch to using unbound(8)
Switch to using dns/dnsmasq
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.


----------



## Oko (Sep 9, 2015)

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.


----------



## KdeBruin (Sep 9, 2015)

Oko, thanks for your input. I will search for some how-to to do this.


----------



## kpa (Sep 9, 2015)

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.


----------



## SirDice (Sep 9, 2015)

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.


----------



## Oko (Sep 10, 2015)

KdeBruin said:


> Oko, thanks for your input. I will search for some how-to to do this.




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

Run `/usr/sbin/unbound-control-setup`

Edit  /var/unbound/etc/unbound.conf 

```
# $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/*"
```


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


```
# 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"
```


```
# 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.


----------



## protocelt (Sep 10, 2015)

Oko said:


> ```
> # uname -a
> OpenBSD apollo.autonlab.org 5.7 GENERIC.MP#0 amd64
> ```
> ...


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 
	
	



```
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.


----------



## kpa (Sep 10, 2015)

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.


----------



## KdeBruin (Sep 10, 2015)

Thanks all. I have hit a snatch with some development I have to do so I will look at it this weekend.


----------



## Oko (Sep 10, 2015)

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
> 
> 
> 
> ...


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.


----------



## protocelt (Sep 10, 2015)

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.


----------



## KdeBruin (Sep 13, 2015)

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...


----------



## kpa (Sep 13, 2015)

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:


```
option domain-name "example.com";
```


----------



## ds_aim (Sep 13, 2015)

```
pkg install bind99
```
Bind99 is the newest version of named from FreeBSD 9.3


----------



## KdeBruin (Sep 16, 2015)

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.


----------



## kpa (Sep 16, 2015)

Are you using +search with dig(1)?  


```
+[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.
```


----------



## KdeBruin (Sep 16, 2015)

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.


----------



## Oko (Sep 17, 2015)

KdeBruin said:


> 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.


What about drill(1)?


----------

