DNSSEC validation via AD bit?

[Tony Finch]

Gregory Shapiro via bind-users <bind-users at lists.isc.org> wrote:
>
> Two questions:

Slightly expanding on Mark's answers...

> 1. Is there a reason when BIND is running as both a recursive server and
> an authoritative server for a domain, it doesn't set the AD bit when
> answering resolver queries for one of its authoritative domains?

AD means "I validated this" and AA means "I am authoritative for this".
In almost all cases, authoritative servers don't validate the zones they
serve - as Mark said, it's unnecessary. Because they don't validate it
would be wrong to set AD. (But note that BIND's "mirror" zones do validate
authoritative zones and the AD/AA bits change accordingly.)

> 2. Should sendmail not be trusting the AD bit in replies from the admin
> configured (i.e., trusted by admin) resolvers?

It's dangerous territory. Sendmail isn't alone: for example, OpenSSH also
relies on the AD bit to validate SSHFP records. But using AD is only safe
if the validating resolver is running on localhost. Unfortunately the
portable subset of the resolver API doesn't allow programs to check their
recursive server addresses, so they just have to hope that they have been
configured by a careful person. (On a mail server there are also
performance reasons for running a local resolver, so I guess you are OK in
this respect.)

As Mark says, ideally these programs would do their own validation, but to
get good performance the program should ideally be able to make concurrent
queries for the chain of trust, and once again the standard resolver makes
it difficult. Or the program can hope the recursive server is running on
localhost so it doesn't matter too much if the queries are serialized.

There are workarounds for your AA problem. You might try using mirror
zones instead of secondary zones. Or you can ensure that queries for your
secondary zones go through a validating resolver. This is a bit like the
common pairing of NSD and Unbound on the same server, but with BIND you
can do it in one process. The trick is to use two views: one is
authoritative-only, and has your secondary zone configurations. The other
is recursive-only, but it has static-stub zone configurations for all your
secondary zones, pointing at localhost. Then you arrange for these
self-queries to be handled by the authoritative view. I have used this
setup for a while on my workstation for testing / experimental purposes,
but I never put it into serious production because it's too far along the
mad science spectrum.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  https://dotat.at/
Thames: Northwest 7 to severe gale 9, backing west 5 to 7. Slight or
moderate in southwest, otherwise rough or very rough, becoming
moderate. Rain. Good, occasionally moderate.