From owner-freebsd-questions@FreeBSD.ORG Thu Jun 23 14:45:54 2011 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (unknown [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B2281065674 for ; Thu, 23 Jun 2011 14:45:54 +0000 (UTC) (envelope-from eosterweil@verisign.com) Received: from exprod6og115.obsmtp.com (exprod6og115.obsmtp.com [64.18.1.35]) by mx1.freebsd.org (Postfix) with ESMTP id 4CAD28FC1C for ; Thu, 23 Jun 2011 14:45:39 +0000 (UTC) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob115.postini.com ([64.18.5.12]) with SMTP ID DSNKTgNRko3LXT0Qnz/8XPQjypt99K9Mzo7V@postini.com; Thu, 23 Jun 2011 07:45:53 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id p5NEjcS6002582; Thu, 23 Jun 2011 10:45:38 -0400 Received: from DUL1WNEXMB11.vcorp.ad.vrsn.com ([10.170.13.11]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 23 Jun 2011 10:45:37 -0400 Received: from 10.131.30.110 ([10.131.30.110]) by DUL1WNEXMB11.vcorp.ad.vrsn.com ([10.170.13.11]) with Microsoft Exchange Server HTTP-DAV ; Thu, 23 Jun 2011 14:45:27 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Thu, 23 Jun 2011 10:45:26 -0400 From: "Osterweil, Eric" To: Matthew Seaman , Message-ID: Thread-Topic: dnssec with freebsd's resolver(3) Thread-Index: AcwxKocisMB+ChKkSrOyXFsWV7ByEwAiakaX In-Reply-To: <4E026568.4020206@infracaninophile.co.uk> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 23 Jun 2011 14:45:37.0959 (UTC) FILETIME=[375C9370:01CC31B4] Cc: Subject: Re: dnssec with freebsd's resolver(3) X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 14:45:54 -0000 On 6/22/11 5:58 PM, "Matthew Seaman" wrote: > On 22/06/2011 20:02, Osterweil, Eric wrote: >>=20 >>=20 >>=20 >> On 6/22/11 2:56 PM, "Leon Me=DFner" wrote: >>=20 >>> On Mon, Jun 20, 2011 at 06:17:23AM +0100, Matthew Seaman wrote: >>>> On 20/06/2011 01:37, Leon Me=DFner wrote: >>>=20 >>> Ok, my recursive resolver does DO processing. How do i tell ssh to set >>> the bit ? Doesn't ssh use my base system stub resolveer to query my in >>> resolv.conf configured DNS ? >>=20 >> I'm not sure what you mean by "DO processing," but validation requires a >> little more than issuing queries w/ the DO bit set (that has been the >> default in BIND for a while). You need to have the root (or some other) >> trust-anchor configured, and you need to enable DNSSEC validation in you= r >> named.conf. >>=20 >> Only after that will you see the AD bit at the stub. >=20 > Actually, typically with a correctly configured validating resolver, as > an end user issuing queries from the system's stub resolver, you'll only > see responses with data that is either: >=20 > -- completely unsigned And this will _not_ have the AD bit. >=20 > -- signed, and that validates correctly This will have the AD bit, but only if there is a verifiable chain of trust leading from a configured trust-anchor. >=20 > Data that doesn't validate correctly is discarded. Better make sure > your DNSSEC setup is correctly maintained and updated, or your domains > may effectively disappear from the net. This actually depends on exactly what you mean by "doesn't validate," and how the resolver is configured: If the chain of trust does not lead to thi= s zone, then the resolver can be configured to return data without setting th= e AD bit (this is the default for most early movers on DNSSEC). If there IS = a valid chain of trust, and the crypto doesn't verify, then you are right, data is not returned (unless the CD bit is set). >=20 > "validates correctly" is a function of how your recursive resolver is > configured: for instance, you will probably want to trust DLV secured > data until authentication paths up to the root become more prevalent in > all corners of the DNS. I strongly disagree! Now that the root, .com, .net, .edu, .gov, .org, etc. are signed (over 65 TLDs), the few _debatable_ reasons to use DLV are reall= y gone. Today, if there is no chain to a zone, then you (as the resolver operator) can decide if you want to configure the TA manually, or wait unti= l the zone operator gets their DS in their parent zone. In either case, the typical DNSSEC validating resolver configuration will return data for these zones, just not setting the AD bit. Don't forget (also), that using DLV exposes the privacy of exactly what zones you are querying to the external party running the DLV. You will essentially tell that party what zones you= r are querying by asking for those zones' DLV records. Eric