dnssec with freebsd's resolver(3)

[Osterweil, Eric]

On 6/22/11 5:58 PM, "Matthew Seaman" <m.seaman at infracaninophile.co.uk>
wrote:

> On 22/06/2011 20:02, Osterweil, Eric wrote:
>> 
>> 
>> 
>> On 6/22/11 2:56 PM, "Leon Meßner" <l.messner at physik.tu-berlin.de> wrote:
>> 
>>> On Mon, Jun 20, 2011 at 06:17:23AM +0100, Matthew Seaman wrote:
>>>> On 20/06/2011 01:37, Leon Meßner wrote:
>>> 
>>> 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 ?
>> 
>> 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 your
>> named.conf.
>> 
>> Only after that will you see the AD bit at the stub.
> 
> 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:
> 
>     -- completely unsigned

And this will _not_ have the AD bit.

> 
>     -- 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.

> 
> 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 this
zone, then the resolver can be configured to return data without setting the
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).

> 
> "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 really
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 until
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 your
are querying by asking for those zones' DLV records.

Eric