Unbound is primarily a caching server, and even though it does support local zones, that is not its main purpose. Bind (and other dns servers) allows a server to be both recursive and authoritative, but it is not really a clean way of operating (IMHO).
If you want a public server, it should only expose public authoritative information. Internally, you should separate recursive and authoritative services, using unbound only as a recursive server, using a stub zone to refer to internal authoritative information, which could be in an internal view on the same server as the public authoritative information. If you only have a handful of RRs for the internal zone, you could use unbound's local zone, but I think it would be more convenient to manage all the authoritative data in one location, rather than two.
If you have to run them on the same server, you should make unbound only respond to an internal interface; the authoritative server should only respond to an external interface, using the internal view if a request comes from the server host itself.
Offlist, Bruce found a solution, it was do turn off do-ip6 in the
unbound.conf. Ip6 was turned off in RHEL as well. For some reason the
ipv6 sockets took an inordinate amount of effort.
(I would like people to run with ipv6 enabled of course, but this seems
interesting when you deploy on kernels with ipv6 disabled).
Offlist, Bruce found a solution, it was do turn off do-ip6 in the
unbound.conf. Ip6 was turned off in RHEL as well. For some reason the
ipv6 sockets took an inordinate amount of effort.
Are you going to investigate this further?
(I would like people to run with ipv6 enabled of course, but this seems
interesting when you deploy on kernels with ipv6 disabled).
Can we pass an option to unbound to override the config setting? And perhaps
only pass it when we find NETWORKING_IPV6=yes in /etc/sysconfig/network via
the init script?
Worst case, we could check for the option and warn on bootup. But ideally it
should run fast either way.
I had added the following lines to /etc/modprobe.conf:
alias net-pf-10 off
options ipv6 disable=1
I also changed /etc/sysconfig/network to read:
NETWORKING_IPV6=no
To disable ipv6 when installing RHEL 5.5 (on a Dell 2970)
In the unbound.conf file I left the 'do-ip6: yes' commented out <which yes is the default>
We also run an anycast model - which is running two virtual (static) IPs of off eth1. These IPs are the same IPs as are used in servers in several cities - so your lookups are geo based with the same IPs.
Hence I have 'interface-automatic: yes' set to yes.
And the interfaces are explicitely set (all of them - the loopback, the physical and the two virtuals) as opposed to using 0.0.0.0 - seems to be what works.
This configs ended up dropping QPS to 160 - 2000 at a high end.
Setting 'do-ip6: no' changed the QPS to between 45,000 and 60,000 pending the cache.
We will be going to IPV6 shortly, but not just now.
Bruce
Bruce Hayward, MTS Allstream Inc., (p) 204-958-1983 (e) bruce.hayward@mtsallstream.com
Bruce, could it be that you have ip6tables turned on? The IPv6 and ip6tables implementations in the kernel shipped with RHEL 5 are riddled with bugs. One of these bugs is that if you enable ip6tables, even without any firewall rules, the MTU size drops dramatically and the kernel mucks up IPv6 fragmentation.
I've written down some of the problems we ran into on our resolvers (running unbound on both IPv4 as well as IPv6) in this blogpost (it also contains some info on compiling a newer BIND on RHEL 5.x, but you can ignore that):
The tool that I have on the RHEL servers is iptables (not something that we normally use)
I have figured out enough to know that I cannot use port forwarding as this is to localhost. But must use thee port redirect option E.g.
iptables -t nat -A PREROUTING -p tcp -d 142.161.130.xxx --dport 53 -j REDIRECT --to-ports 49152
iptables -t nat -A PREROUTING -p udp -d 142.161.130.xxx --dport 53 -j REDIRECT --to-ports 49152
Means if 142.161.130.xxx will connect at port 53 of this server then it will actually connected to 49152
And in the unbound.conf file I have setup
interface: 142.161.130.xxy@49152
interface: 142.161.130.xxx@49152
interface: 127.0.0.1@53
interface: 127.0.0.1@49152
When I do a netstat -na|grep -i listen - I do not see the port 49152 listening.
What am I missing?
Bruce
Bruce Hayward, MTS Allstream Inc., (p) 204-958-1983 (e) bruce.hayward@mtsallstream.com
The tool that I have on the RHEL servers is iptables (not something that we normally use)
I have figured out enough to know that I cannot use port forwarding as this is to localhost. But must use thee port redirect option E.g.
iptables -t nat -A PREROUTING -p tcp -d 142.161.130.xxx --dport 53 -j REDIRECT --to-ports 49152
iptables -t nat -A PREROUTING -p udp -d 142.161.130.xxx --dport 53 -j REDIRECT --to-ports 49152
Means if 142.161.130.xxx will connect at port 53 of this server then it will actually connected to 49152
I think you need -s 142... and not -d 142... here. -s is source
address, -d is destination address.
And in the unbound.conf file I have setup
interface: 142.161.130.xxy@49152
interface: 142.161.130.xxx@49152
interface: 127.0.0.1@53
interface: 127.0.0.1@49152
When I do a netstat -na|grep -i listen - I do not see the port 49152 listening.
I think so, but it's a long time since I had to use iptables.
regardless of IP address direct any ip hitting port 53 to redirect to port 49152?
Also do not see the port showing up with the netstat regardless of options - does unbound not open that port when configured?
Try: netstat -tnlp and -unlp and if the port doesn't show up then
check the logs. (Well check the log file anyway as a first thing when
something doesn't work as expected...)
If you enable:
interface-automatic: yes
then any interface ports other than 53 disappear (when using interface: <ip address[@port]> as per the documentation).
We have interface-automatic: yes enabled as suggested as we run in an anycast model (same virtuals regardless of geo).
Thoughts on how to accomplish both (views and anycast) given the behaviour of ports on the <ip address[@port]> line teamed with interface-automatic.
Much Thanks
Bruce
Bruce Hayward, MTS Allstream Inc., (p) 204-958-1983 (e) bruce.hayward@mtsallstream.com
I have setup some virtual interfaces, using private (192.168..) IPs and using IPTables to forward the incoming traffic to them.
Likewise these private interfaces do not show when configured in the unbound.conf on the interface line (netstat -tnlp | grep unbound) if we turn on Interface-automatic: yes.
I rebuilt the 'Public' virtual IPs to dangle off of the physical interface (eth1), instead of the loopback.
Testing is going well with 'Interface-automatic: yes' turned off, with the new virtual interfaces running private IPs, and the Public Virtuals moved from the loopback to an ethx virtual.
The next phase will be creating another instance of unbound running at the same time (just will create another config directory, and use the same binary), and get it to discriminate between the two versions running, based upon the private IP listened to.
If all of this works, then we have 'views'.
Bruce
Bruce Hayward, MTS Allstream Inc., (p) 204-958-1983 (e) bruce.hayward@mtsallstream.com
