Date: Thu, 23 Jun 2011 10:45:26 -0400 From: "Osterweil, Eric" <eosterweil@verisign.com> To: Matthew Seaman <m.seaman@infracaninophile.co.uk>, <freebsd-questions@freebsd.org> Subject: Re: dnssec with freebsd's resolver(3) Message-ID: <CA28C9C6.C8F0%eosterweil@verisign.com> In-Reply-To: <4E026568.4020206@infracaninophile.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On 6/22/11 5:58 PM, "Matthew Seaman" <m.seaman@infracaninophile.co.uk> wrote: > On 22/06/2011 20:02, Osterweil, Eric wrote: >>=20 >>=20 >>=20 >> On 6/22/11 2:56 PM, "Leon Me=DFner" <l.messner@physik.tu-berlin.de> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA28C9C6.C8F0%eosterweil>