From owner-freebsd-stable@FreeBSD.ORG Sun Jun 29 23:43:30 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D30CBFAA for ; Sun, 29 Jun 2014 23:43:30 +0000 (UTC) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.isc.org", Issuer "RapidSSL CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B2B6A2492 for ; Sun, 29 Jun 2014 23:43:30 +0000 (UTC) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id CD36C3493D1; Sun, 29 Jun 2014 23:43:22 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 84338160055; Sun, 29 Jun 2014 23:50:25 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 1CF5816004A; Sun, 29 Jun 2014 23:50:25 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id EA4D419753E2; Mon, 30 Jun 2014 09:42:48 +1000 (EST) To: Peter Wemm From: Mark Andrews References: <4052053.k3ny9DzFll@overcee.wemm.org> Subject: Re: stable/10: unbound refuses to forward some DNS queries In-reply-to: Your message of "Sun, 29 Jun 2014 14:56:58 -0700." <4052053.k3ny9DzFll@overcee.wemm.org> Date: Mon, 30 Jun 2014 09:42:48 +1000 Message-Id: <20140629234248.EA4D419753E2@rock.dv.isc.org> X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mx.pao1.isc.org Cc: Konstantin Belousov , freebsd-stable@freebsd.org, Dmitry Morozovsky X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 23:43:30 -0000 In message <4052053.k3ny9DzFll@overcee.wemm.org>, Peter Wemm writes: > On Sunday 29 June 2014 20:04:29 Dmitry Morozovsky wrote: > > On Sun, 29 Jun 2014, Dmitry Morozovsky wrote: > > > Thank you so much, it works like a charm. > > > > > > I do not have special TLD for forward resolving, and for me the > following > > > > > > subset seems to be enough: > > > #suggested by kib@ > > > domain-insecure: "168.192.in-addr.arpa." > > > local-zone: "168.192.in-addr.arpa." transparent > > > > ... and it turned out that even the last line is optional. > > > > To clarify: ALL queries for my case should be forwarded. > > > > It's on FreeBSD 10.0-STABLE #4 r267602: Wed Jun 18 11:15:36 MSK 2014 > > I use 'nodefault' instead of 'transparent' for these. > > I'm pretty sure you do need it because unbound has the RFC1918 and other > "fake" addresses stubbed out. If you only did a 'reload' after changing > it, the stubs would have been replaced with a live address. I'd expect a > full kill/restart to not work without it. > > You need the domain-insecure for 168.192.in-addr.arpa because there is a > NSEC3 hash on 192.in-addr.arpa that has a 'proof of non existence' for the > 192.168 node underneath. 168.192.in-addr.arpa is insecurely delegated to the AS112 servers. This breaks the secure delegation chain. RFC 6303 requires this insecure delegations for all the zones it lists so that serving local content doesn't fail due to DNSSEC validation. I believe all the RFC 6303 zones now have insecure delegations. I had to complain to IANA that some didn't exist initially. The RFC 1918 subset definitely do have insecure delegations. No nameserver from any vendor should require validation to be explicitly disabled for 168.192.in-addr.arpa or any of the rest of the RFC 1918 / RFC 6303 zones. If unbound requires such a setting it is broken. > For what its worth, this is the general gist of what we do on the > freebsd.org cluster with some use of RFC1918 addresses: > > Individual machines: > server: > ... > domain-insecure: "10.in-addr.arpa" > local-zone: "10.in-addr.arpa." nodefault > ... > forward-zone: > # Forward to the cluster caching hub > name: . > forward-addr: 2001:4f8:3:ffe0:4064:0:35:1 > forward-addr: 2001:4f8:3:ffe0:4064:0:35:2 > forward-addr: 149.20.53.9 > forward-addr: 149.20.53.10 > > And one of the corresponding cache hubs: > server: > ... > domain-insecure: "10.in-addr.arpa" > local-zone: "10.in-addr.arpa." nodefault > ... > stub-zone: > name: "10.in-addr.arpa" > stub-addr: 149.20.53.9@5301 # local authoritive-only zone server > stub-addr: 149.20.53.10@5301 # local authoritive-only zone server > ... > > Obviously this would need to be adjusted for whatever RFC1918 addresses > you're using locally. But that's how we use the built-in local_unbound > resolver for dogfood in the freebsd.org cluster. If you forward the entire namespace then the forwarder should be serving the RFC 6303 zones not the local recursive resolver. Forwarding ("forward only" in named terms) is equivalent to serving the zone locally. Note named takes forwarding (existance and forwarding mode) into consideration when deciding whether to enable a RFC 6303 zone or not. Mark > -- > Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; > KI6FJV > UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org