inconsistent forward-zone behavior between config files, unbound-control
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
Re: inconsistent forward-zone behavior between config files, unbound-control
Am 22.09.2015 um 19:02 schrieb Mike Brown via Unbound-users:
* by default, queries go to my ISP's resolvers (Comcast: 75.75.75.75 &
75.75.76.76)
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'"
:
}
Re: inconsistent forward-zone behavior between config files, unbound-control
A. Schulze via Unbound-users wrote: > Am 22.09.2015 um 19:02 schrieb Mike Brown via Unbound-users: > >* 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. -- Robert Edmonds edmo...@debian.org
Re: inconsistent forward-zone behavior between config files, unbound-control
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Mike, On 09/22/2015 07:02 PM, Mike Brown via Unbound-users wrote: > 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJWAnUzAAoJEJ9vHC1+BF+NrNMQAKomkrICyWOtW3e6icefjDIr 0Po9MhUjUNJvngSriUk8rO0keved8wERUcrVnIxq93Ulnl4NJHdiT97NuSUI+hzC aXZncrJeTmEG+JvgHrwkHJDkErs4DpokItnVj1YrzUV18tuC05f2U4yCaeV1kVem 5yjQ+iTkmPpmJHohE+QpTtfWyIfZrr6ZK3ZROzcURBWQ1t70+iGHDbtQqDdxADXi D30teF28Qy6AquK+uoG72TDcnSfbfSYcKdNjl8evnNS16tq8rrvGlcKuu+Sk4vi+ 4i7h1U7fwq0/C/ZgtPprMWvr1uemjNH7eE6OOw/KBbq6NNiUfWj8IoVGJ697OJib VzLOGFXoN/YI/gVnhXq7XM0y/S/ifyErd5vGWzGe/EJH7teOm8VNdtzCSun1IPr4 w2HNUZmu5ch/W5kpyxJq+/33hDlS6g9xK9coUXLOlwUE1WEZinZxr8/jg/GmRRLG CUSnMkZktw9Lxy58LnPm/dwmVSj1wv2R+vhH5+gBI4cJFXvRtzOziiQnE3jdtNGc VtOmehRLHpti3Lqovi9r29AqDAXsx5rStIVs1IeYIqWq5649kdCKSYQ2sZpUFun9 ug4pzyclOhBuwFzJGwAV0yZ+bADyOP4pfdYfoBKPoaZ8qpKfT+j5YS3mtOdGh9kV K6xEVsbtkl2RrYCqM7wA =Fwii -END PGP SIGNATURE-
Re: inconsistent forward-zone behavior between config files, unbound-control
On Wed, Sep 23, 2015 at 11:47:31AM +0200, W.C.A. Wijngaards via Unbound-users
wrote:
> 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.
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?
