inconsistent forward-zone behavior between config files, unbound-control

Unbound
1

It is quite possible I am just clueless and doing things all wrong, so please
forgive me if this is a waste of your time. I've Googled and experimented for
hours, and am no closer to understanding what's going wrong here.

I'm just trying to get Unbound configured on FreeBSD 10.2-STABLE such that:

* the DHCP-assigned nameserver (10.0.1.1, my router) is ignored, even after
lease renewals

* by default, queries go to my ISP's resolvers (Comcast: 75.75.75.75 &
75.75.76.76)

* DNSBL zone queries bypass the ISP's resolvers - e.g., *.multi.uribl.com
needs to be resolved starting from the root servers, such that a TXT lookup of
test.uribl.com.multi.uribl.com will return the descriptive text "permanent
testpoint" rather than "127.0.0.1 -> Query Refused. See
http://uribl.com/refused.shtml for more information [Your DNS IP: 76.x.x.x]"

At the bottom of this post you can see my config files.

The reason I'm bypassing the DHCP-assigned nameserver is because I only get
SERVFAIL for any lookup with it, even though it just forwards to my ISP. It's
a current-model Apple AirPort Time Capsule, so you'd think it would be
DNSSEC-friendly, but I guess not, and of course there's no advanced settings
available in the AirPort Utility.

The main thing I'm trying to diagnose at this point is not the DHCP stuff,
rather just the DNSBL forwards.

When using my config files, lookups for most domains work, but the DNSBL test
only ever gives me SERVFAIL.

tcpdump is not very helpful; nothing is going out over the wire for those
lookups, even on first try:

17:06:36.553477 IP (tos 0x0, ttl 64, id 46664, offset 0, flags [none], proto UDP (17), length 76, bad cksum 0 (->c656)!)
    127.0.0.1.52659 > 127.0.0.1.53: [bad udp cksum 0xfe4b -> 0xede4!] 60714+ TXT? test.uribl.com.multi.uribl.com. (48)
17:06:36.561421 IP (tos 0x0, ttl 64, id 46675, offset 0, flags [none], proto UDP (17), length 76, bad cksum 0 (->c64b)!)
    127.0.0.1.53 > 127.0.0.1.52659: [bad udp cksum 0xfe4b -> 0x6d62!] 60714 ServFail q: TXT? test.uribl.com.multi.uribl.com. 0/0/0 (48)

And here's the unbound -ddvvv output: http://pastebin.com/raw.php?i=dcRP67yZ
It includes the startup messages and the messages resulting from these 4
commands (and I realize I may be a bit paranoid with the flushes):

# unbound-control -c /var/unbound/unbound.conf list_forwards
. IN forward 75.75.75.75 75.75.76.76
multi.uribl.com. IN forward multi.uribl.com.
# unbound-control -c /var/unbound/unbound.conf flush_zone multi.uribl.com
ok removed 0 rrsets, 0 messages and 0 key entries
# unbound-control -c /var/unbound/unbound.conf flush_zone uribl.com
ok removed 0 rrsets, 0 messages and 0 key entries
# host -tTXT test.uribl.com.multi.uribl.com
Host test.uribl.com.multi.uribl.com not found: 2(SERVFAIL)

OK, bear with me here. If I remove the "." forward at this point, I still get
SERVFAIL:

# unbound-control -c /var/unbound/unbound.conf forward_remove .
ok
# unbound-control -c /var/unbound/unbound.conf list_forwards
multi.uribl.com. IN forward multi.uribl.com.
# unbound-control -c /var/unbound/unbound.conf flush_zone multi.uribl.com
ok removed 0 rrsets, 0 messages and 0 key entries
# unbound-control -c /var/unbound/unbound.conf flush_zone uribl.com
ok removed 0 rrsets, 0 messages and 0 key entries
# host -tTXT test.uribl.com.multi.uribl.com
Host test.uribl.com.multi.uribl.com not found: 2(SERVFAIL)

...And everything works fine if I remove both forwards:

# unbound-control -c /var/unbound/unbound.conf forward_remove .
ok
# unbound-control -c /var/unbound/unbound.conf forward_remove multi.uribl.com
ok
# unbound-control -c /var/unbound/unbound.conf flush_zone multi.uribl.com
ok removed 0 rrsets, 0 messages and 0 key entries
# unbound-control -c /var/unbound/unbound.conf flush_zone uribl.com
ok removed 0 rrsets, 0 messages and 0 key entries
# host -tTXT test.uribl.com.multi.uribl.com
test.uribl.com.multi.uribl.com descriptive text "permanent testpoint"

Now here's the really weird part: I can add the forwards back in with
unbound-control, and the behavior is different. Now the DNSBL forward is still
not working, but instead of SERVFAIL, it is going through the default forward!

# unbound-control -c /var/unbound/unbound.conf forward_add . 75.75.75.75 75.75.76.76
ok
# unbound-control -c /var/unbound/unbound.conf forward_add multi.uribl.com multi.uribl.com
ok
# unbound-control -c /var/unbound/unbound.conf list_forwards
. IN forward 75.75.76.76 75.75.75.75
multi.uribl.com. IN forward multi.uribl.com.
# unbound-control -c /var/unbound/unbound.conf flush_zone uribl.com
ok removed 11 rrsets, 4 messages and 0 key entries
# unbound-control -c /var/unbound/unbound.conf flush_zone multi.uribl.com
ok removed 0 rrsets, 0 messages and 0 key entries
# host -tTXT test.uribl.com.multi.uribl.com
test.uribl.com.multi.uribl.com descriptive text "127.0.0.1 -> Query Refused. See http://uribl.com/refused.shtml for more information [Your DNS IP: 76.96.107.199]"

(I do note one small difference: the default resolvers I specified on the
command line apparently got added in reverse order for some reason. It doesn't
seem to matter, though; I tried putting them reversed on the command line and
the result was the same.)

And as if that wasn't strange enough, remove the "." forward now, leaving just
the one for the DNSBL zone, et voila:

# unbound-control -c /var/unbound/unbound.conf forward_remove .
ok
# unbound-control -c /var/unbound/unbound.conf flush_zone uribl.com
ok removed 1 rrsets, 2 messages and 0 key entries
# unbound-control -c /var/unbound/unbound.conf flush_zone multi.uribl.com
ok removed 0 rrsets, 0 messages and 0 key entries
# unbound-control -c /var/unbound/unbound.conf list_forwards
multi.uribl.com. IN forward multi.uribl.com.
# host -tTXT test.uribl.com.multi.uribl.com
test.uribl.com.multi.uribl.com descriptive text "permanent testpoint"

*boggle*

And I can go back to the initial SERVFAIL state with a reload (this
is with Dag-Erling's patch applied):

# unbound-control -c /var/unbound/unbound.conf reload
ok
# unbound-control -c /var/unbound/unbound.conf flush_zone uribl.com
ok removed 0 rrsets, 0 messages and 0 key entries
# unbound-control -c /var/unbound/unbound.conf flush_zone multi.uribl.com
ok removed 0 rrsets, 0 messages and 0 key entries
# host -tTXT test.uribl.com.multi.uribl.com
Host test.uribl.com.multi.uribl.com not found: 2(SERVFAIL)

Clearly I must be doing something wrong in my configuration, but I can't
figure out what. Any help appreciated, and let me know if more info is needed.

My configs:

# cat /etc/resolvconf.conf
# This file was generated by local-unbound-setup.
# Modifications will be overwritten.
resolv_conf="/dev/null" # prevent updating /etc/resolv.conf
# Static DNS configuration

# cat /etc/resolv.conf
# Generated by resolvconf
# search hsd1.co.comcast.net.
# nameserver 10.0.1.1
nameserver 127.0.0.1
options edns0

# cat /var/unbound/unbound.conf
# This file was generated by local-unbound-setup.
# Modifications will be overwritten.
server:
        username: unbound
        directory: /var/unbound
        chroot: /var/unbound
        pidfile: /var/run/local_unbound.pid
        auto-trust-anchor-file: /var/unbound/root.key

include: /var/unbound/forward.conf
include: /var/unbound/lan-zones.conf
include: /var/unbound/control.conf
include: /var/unbound/conf.d/*.conf

# cat /var/unbound/forward.conf
# This file was generated by local-unbound-setup.
# Modifications will be overwritten.
forward-zone:
        name: .
        forward-addr: 75.75.75.75
        forward-addr: 75.75.76.76

# cat /var/unbound/conf.d/uribl.conf
forward-zone:
  name: multi.uribl.com
  forward-host: multi.uribl.com

2

why would you do that?

I expect Comcast not to block other DNS queries? Assuming that I would suggest
to run unbound simply in default configuration -> resolving direct via root nameservers.
No default forwarding -> no need to configure exceptions for DNSBL zones.

Also I'm not aware any unbound configuration is modified in any way by a DHCP client.
I use to ignore any resolver announced by a DHCP server:

$ stat --printf "%a\n" /etc/dhcp/dhclient-enter-hooks.d/do_not_touch_resolv_conf
755

$ cat /etc/dhcp/dhclient-enter-hooks.d/do_not_touch_resolv_conf
#!/bin/sh
make_resolv_conf() {
  logger -p daemon.info -t /etc/dhcp/dhclient-enter-hooks.d/do_not_touch_resolv_conf "ignore DHCP suggestion 'nameserver $new_domain_name_servers'"
  :
}

3

>* by default, queries go to my ISP's resolvers (Comcast: 75.75.75.75 &
>75.75.76.76)
why would you do that?

Comcast's 75.75.75.75 and 75.75.76.76 nameservers are anycasted.
75.75.75.75 in particular should (probably) be routed to a nearby
Comcast data center.

For instance, on my home Comcast connection, 75.75.75.75, F-Root, and
L-Root all have anycast instances located in a local Comcast facility,
so the RTT to these three servers are identical (~10 ms) for me.

Comcast's servers perform DNSSEC validation and it should in theory be
possible to have a validating DNS server like Unbound forward to those
servers and re-validate the answers, so for a lightly loaded server it
may actually result in *better* performance (latency wise) to forward to
the nearby Comcast cache rather than directly contacting authoritative
nameservers that may be much farther than ~10 ms away.

Also I'm not aware any unbound configuration is modified in any way by a DHCP client.
I use to ignore any resolver announced by a DHCP server:

The stock upstream Unbound distribution does not have any DHCP client
integration, true. However, some OSes (e.g. Debian) have optional
resolvconf integration, which can be used to automatically configure
nameservers learned via DHCP as forwarders for Unbound. Other OSes may
have similar functionality. This only works well if those nameservers
perform DNSSEC validation, however.

4

Hi Mike,

It is quite possible I am just clueless and doing things all wrong,
so please forgive me if this is a waste of your time. I've Googled
and experimented for hours, and am no closer to understanding
what's going wrong here.

Not a clue about comcast or uribl, but your unbound.conf looks weird:

# cat /var/unbound/conf.d/uribl.conf forward-zone: name:
multi.uribl.com forward-host: multi.uribl.com

This entry creates a loop, where unbound has to lookup multi.uribl.com
to lookup multi.uribl.com, and to do that it has to lookup
multi.uribl.com ... And that causes it to fail.

Also multi.uribl.com is a website, and unbound wants nameservers (the
right hand side of the dig multi.uribl.com NS lookup).

To remove the endless loop you can type IP adresses (with
forward-addr: ip), but in this case, uribl has nameservers that do not
cause a loop:
forward-host: aa.uribl.com.
forward-host: bb.uribl.com.
..
forward-host: hh.uribl.com.

Another point, it should be a stub-zone, because those are
authoritative servers that you are listing in the config. Use
stub-zone: and stub-host: in the uribl.conf file.

Best regards, Wouter

5

Thanks, W.C.A.

For BIND, I was advised to handle DNSBL zones simply like this, and I even put
this advice in the Spamassassin wiki, since it worked for me:

  zone "multi.uribl.com" { type forward; forward first; forwarders {}; };

Presumably, and correct me if I'm wrong, for any lookup in the multi.uribl.com
domain, BIND just bypasses the default forward and instead forwards to the
root nameservers and recursively resolves from there, along the way learning
about and temporarily caching the current list of aa,bb,..,hh.uribl.com
servers and their probably randomized order.

To instead be hard-coding a certain list of those nameservers in a certain
order feels risky, given that they seem to intend for some flexibility in what
servers are available and what order they should be in.

Is it not possible to do something similar in Unbound?