Postfix probe to find out id DNSSEC works

[Wietse Venema]

Earlier this year there was a thread about Postfix failing to notice
that some TLSA record was corrupted, because

- Postfix was configured to use opportunistic DANE, which ignores
  TLSA records when they aren't DNSSEC validated.

- Some system library API did not indicate whether responses were
  DNSSEC validated, therefore Postfix ignored all TLSA records.

This happened with libc-musl, and with glibc.

Of course Postfix would refuse to deliver to destinations that are
configured to use "mandatory DANE", because that requires DNSSEC
validated TLSA records.

I am implementing code where Postfix will try to find out if DNSSEC
validation is available. This may explain why "mandatory DANE"
does not work, and why opportunistic DANE will be a NOOP.

A draft manpage is below.

        Wietse

dnssec_probe (default: ns:.)
       The DNS query type (default: "ns") and DNS query  name  (default:  ".")
       that Postfix may use to determine whether DNSSEC is available.

       When  DNSSEC  validation  is  unavailable, mail deliveries using oppor-
       tunistic DANE will not be protected by TLSA records, and mail  deliver-
       ies using mandatory DANE will fail.

       Postfix  will  use  the  DNSSEC  probe  when a Postfix program requests
       DNSSEC validation, and the Postfix program did  not  receive  a  DNSSEC
       validated response to this query, or to an earlier query. Possible rea-
       sons for an insecure reply are:

       o      The query name is in a DNS zone that has no DNSSEC signatures.

       o      The local resolv.conf file points to a DNS  resolver  that  does
              not validate DNSSEC signatures.

       o      Some  intermediate  DNS resolver does not validate DNSSEC signa-
              tures.

       o      The system library does not pass on the  "DNSSEC  is  validated"
              bit to Postfix, perhaps because Postfix does not know how to ask
              the library to do that.

       By default, the DNSSEC probe asks for the DNS root zone NS records.  If
       Postfix  runs  on  a  network where the DNS root zone is not reachable,
       specify a different probe, or specify an empty probe value  to  disable
       this feature.

       When  the  DNSSEC probe fails, or when Postfix receives a reply that is
       not DNSSEC validated, Postfix logs a warning that DNSSEC validation may
       be unavailable.

       This feature is available in Postfix 3.6 and later.

[Viktor Dukhovni]

On Sun, Sep 27, 2020 at 05:56:52PM -0400, Wietse Venema wrote:

> A draft manpage is below.
>

It looks very reasonable.  The news might not reach the folks who
only search for particular queue ids in the logs, but shoehorning
a (say the MX lookup) DNSSEC status into each smtp delivery log
entry is likely too invasive.

Perhaps if we had an option to switch logging to JSON (nice job on
"postqueue -j", by the way, very useful that), then the JSON variant
might be able to report additional non-essential to most, but useful
to some, details.

> dnssec_probe (default: ns:.)
>        The DNS query type (default: "ns") and DNS query  name  (default:  ".")
>        that Postfix may use to determine whether DNSSEC is available.
>
>        When  DNSSEC  validation  is  unavailable, mail deliveries using oppor-
>        tunistic DANE will not be protected by TLSA records, and mail  deliver-
>        ies using mandatory DANE will fail.
>
>        Postfix  will  use  the  DNSSEC  probe  when a Postfix program requests
>        DNSSEC validation, and the Postfix program did  not  receive  a  DNSSEC
>        validated response to this query, or to an earlier query. Possible rea-
>        sons for an insecure reply are:
>
>        o      The query name is in a DNS zone that has no DNSSEC signatures.
>
>        o      The local resolv.conf file points to a DNS  resolver  that  does
>               not validate DNSSEC signatures.
>
>        o      Some  intermediate  DNS resolver does not validate DNSSEC signa-
>               tures.
>
>        o      The system library does not pass on the  "DNSSEC  is  validated"
>               bit to Postfix, perhaps because Postfix does not know how to ask
>               the library to do that.
>
>        By default, the DNSSEC probe asks for the DNS root zone NS records.  If
>        Postfix  runs  on  a  network where the DNS root zone is not reachable,
>        specify a different probe, or specify an empty probe value  to  disable
>        this feature.
>
>        When  the  DNSSEC probe fails, or when Postfix receives a reply that is
>        not DNSSEC validated, Postfix logs a warning that DNSSEC validation may
>        be unavailable.
>
>        This feature is available in Postfix 3.6 and later.

--
    Viktor.

[Wietse Venema]

Viktor Dukhovni:

> On Sun, Sep 27, 2020 at 05:56:52PM -0400, Wietse Venema wrote:
>
> > A draft manpage is below.
> >
>
> It looks very reasonable.  The news might not reach the folks who
> only search for particular queue ids in the logs, but shoehorning
> a (say the MX lookup) DNSSEC status into each smtp delivery log
> entry is likely too invasive.
>
> Perhaps if we had an option to switch logging to JSON (nice job on
> "postqueue -j", by the way, very useful that), then the JSON variant
> might be able to report additional non-essential to most, but useful
> to some, details.

We could log the DNSSEC status only if DNS was 'secure', like we
log the connection reuse counter only when a connection was used
more than once.

        Wietse

[Viktor Dukhovni]

> On Sep 28, 2020, at 7:09 PM, Wietse Venema <[hidden email]> wrote:
>
> We could log the DNSSEC status only if DNS was 'secure', like we
> log the connection reuse counter only when a connection was used
> more than once.

Makes sense I think, and would probably do the job.  The key
question is what to signal, there are three relevant bits to
log (similar to delays=a/b/c/d perhaps):

        * Was the MX RRset signed
        * Was the MX host address RRset signed
        * Were DANE TLSA RRs found for the MX host.

If all are false, log nothing, if at least one is true, then
log the triple as some subset of

        dnssec=mx,addr,tlsa

How does that sound?

--
        Viktor.

[Wietse Venema]

Viktor Dukhovni:

> > On Sep 28, 2020, at 7:09 PM, Wietse Venema <[hidden email]> wrote:
> >
> > We could log the DNSSEC status only if DNS was 'secure', like we
> > log the connection reuse counter only when a connection was used
> > more than once.
>
> Makes sense I think, and would probably do the job.  The key
> question is what to signal, there are three relevant bits to
> log (similar to delays=a/b/c/d perhaps):
>
> * Was the MX RRset signed
> * Was the MX host address RRset signed
> * Were DANE TLSA RRs found for the MX host.
>
> If all are false, log nothing, if at least one is true, then
> log the triple as some subset of
>
> dnssec=mx,addr,tlsa
>
> How does that sound?

If an SMTP connection is reused, the Postfix SMTP client would get
the DNSSEC status from the connection cache daemon. Otherwise, the
Postfix SMTP client will have to pass that info to the connection
cache daemon. This could represent the DNSSEC status as a bit mask.

The Postfix SMTP client's DNSSEC status is scattered over multiple
data structures, sometimes explicit in the form of DNS resource
records, and sometimes implicit in the form of derived information.

Just like the connection reuse count, the bounce/defer/etc. protocols
could internally propagate the DNSSEC status bitmask vis the msg_stats
structure.

Below is a quick 30-minute analysis of what is where.

        Wietse

All Postfix SMTP client state is kept in an SMTP_STATE object which
owns the SMTP_ITERATOR, SMTP_TLS_POLICY, and SMTP_SESSION.

The SMTP_ITERATOR maintains DNS resource records as the SMTP client
iterates over mail server IP addresses. These records give us two
of the three items that we want to log:

typedef struct SMTP_ITERATOR {
    ...
    struct DNS_RR *rr;                  /* current A or AAAA record or null */
    struct DNS_RR *mx;                  /* MX resource record(s) or null */
    ...
    struct SMTP_STATE *parent;          /* parent linkage */
} SMTP_ITERATOR;

TLSA information exists only in the form of derived information.
One has to assume that DNSSEC was validated, otherwise the TLS_DANE
field should be null. I don't think that there will be a need for
a parent link to find the SMTP_ITERATOR or SMTP_SESSION objects.

typedef struct SMTP_TLS_POLICY {
    ...
    TLS_DANE *dane;                     /* DANE TLSA digests or null */
    ...
    /* No parent linkage */
} SMTP_TLS_POLICY;

Depending on the usage context, sometimes only SMTP_SESSION state
is avaiable, but this has a parent link, so no problem finding the
rest of what is needed to log the DNSSEC status.

typedef struct SMTP_SESSION {
    ...
    SMTP_STATE *state;                  /* back link */
} SMTP_SESSION;