exim and dnssec

[Mark Elkins-2]

Is anyone looking at having Exim become DNSSEC aware - look at the AD
bit - stuff like that. Perhaps add the DNS Status as a mail header? - or
as a variable so that tests can be done?

The root gets signed by the end of the year.

just thinking out aloud in key strokes.
--
  .  .     ___. .__      Posix Systems - Sth Africa.  e.164 VOIP ready
 /| /|       / /__       mje@...  -  Mark J Elkins, Cisco CCIE
/ |/ |ARK \_/ /__ LKINS  Tel: [phone]  Cell: [phone]


--
## List details at http://lists.exim.org/mailman/listinfo/exim-users 
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On Tue, 2009-07-14 at 21:48 +0200, Mark Elkins wrote:
> Is anyone looking at having Exim become DNSSEC aware - look at the AD
> bit - stuff like that. Perhaps add the DNS Status as a mail header? - or
> as a variable so that tests can be done?
>
> The root gets signed by the end of the year.
>
> just thinking out aloud in key strokes.

DNSSEC just makes sure that the answers received in DNS lookups are
valid and came from the right place. Doesn't it?

My understanding of DNSSEC is fairly basic at this time as I haven't had
the time to attempt to deploy it on my zones or resolver yet.

I would have thought the responsibility for doing DNS lookups and
validating them would fall to the resolver library. In the event there
is a DNSSEC failure, the resolver simply returns SERVFAIL or lookup
fail. The normal Exim behaviour when this happens is dependant on where
it was called.

Say it was when doing a "verify = recipient" - in this case the default
Exim config (and I would have thought everyones) would defer the RCPT TO
temporarily and stick a message in the log file. A DNSSEC failure and a
complete DNS lookup failure would be identical in the present. You
wouldn't want to accept mail from a domain that was NXDOMAIN or SERVFAIL
at that point.

Am I looking this the wrong way, or have I missed the point of DNSSEC?

Could you be more specific as to what you think should change in Exim to
support DNSSEC and where you would use it?

--
The Exim manual - http://docs.exim.org


--
## List details at http://lists.exim.org/mailman/listinfo/exim-users 
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

[Mark Elkins-2]

On Wed, 2009-07-15 at 13:09 +1000, Ted Cooper wrote:

> On Tue, 2009-07-14 at 21:48 +0200, Mark Elkins wrote:
> > Is anyone looking at having Exim become DNSSEC aware - look at the AD
> > bit - stuff like that. Perhaps add the DNS Status as a mail header? - or
> > as a variable so that tests can be done?
> >
> > The root gets signed by the end of the year.
> >
> > just thinking out aloud in key strokes.
>
> DNSSEC just makes sure that the answers received in DNS lookups are
> valid and came from the right place. Doesn't it?

(I'm very green at DNSSEC but...)
There are three (four?) possible states...
1 - The DNS query is not signed.
2 - The DNS query is signed and the answer is verified correct
3.1 - The DNS query is signed and the answer is verified incorrect
      because someone is injecting a Cache server with bad information.
3.2 - The DNS query is signed and the answer is verified incorrect
      because someone has broken something (very lightly to happen!).


I have no idea if the standard DNS lookup calls even give this bit back
(getaddrinfo() - etc). I do know that there are various patches (or
clues) available at http://www.dnssec-deployment.org/tracker/

> My understanding of DNSSEC is fairly basic at this time as I haven't had
> the time to attempt to deploy it on my zones or resolver yet.
>
> I would have thought the responsibility for doing DNS lookups and
> validating them would fall to the resolver library. In the event there
> is a DNSSEC failure, the resolver simply returns SERVFAIL or lookup
> fail. The normal Exim behaviour when this happens is dependant on where
> it was called.

I think the resolver just sets the flags and allows the application to make
up its own mind as to what to do. That is how it was explained to me.

> Say it was when doing a "verify = recipient" - in this case the default
> Exim config (and I would have thought everyones) would defer the RCPT TO
> temporarily and stick a message in the log file. A DNSSEC failure and a
> complete DNS lookup failure would be identical in the present. You
> wouldn't want to accept mail from a domain that was NXDOMAIN or SERVFAIL
> at that point.
>
> Am I looking this the wrong way, or have I missed the point of DNSSEC?
>
> Could you be more specific as to what you think should change in Exim to
> support DNSSEC and where you would use it?

I was thinking along the lines of making the info available - and allowing
people to make up their own minds.

ie - if the DNS is signed but has failed validation - then defer anything
to do with that e-mail. Failure could mean either someone injecting bad
records or someone has broken something.

DNSSEC also means that its possible to insert 'Security Key' info into the
DNS that is reasonably tamper proof (assuming the zone is signed).
ie - it would be a simple way to add trust. ie for PGP signatures, dkim or
domainkeys....

I'm only trying to explore ideas.

> --
> The Exim manual - http://docs.exim.org
>
>
--
  .  .     ___. .__      Posix Systems - Sth Africa
 /| /|       / /__       mje@...  -  Mark J Elkins, SCO ACE,
Cisco CCIE
/ |/ |ARK \_/ /__ LKINS  Tel: [phone]  Cell: [phone]


--
## List details at http://lists.exim.org/mailman/listinfo/exim-users 
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On Wed, 2009-07-15 at 10:45 +0200, Mark Elkins wrote:

> On Wed, 2009-07-15 at 13:09 +1000, Ted Cooper wrote:
> > On Tue, 2009-07-14 at 21:48 +0200, Mark Elkins wrote:
> > > Is anyone looking at having Exim become DNSSEC aware - look at the AD
> > > bit - stuff like that. Perhaps add the DNS Status as a mail header? - or
> > > as a variable so that tests can be done?
> > >
> > > The root gets signed by the end of the year.
> > >
> > > just thinking out aloud in key strokes.
> >
> > DNSSEC just makes sure that the answers received in DNS lookups are
> > valid and came from the right place. Doesn't it?
>
> (I'm very green at DNSSEC but...)
> There are three (four?) possible states...
> 1 - The DNS query is not signed.
> 2 - The DNS query is signed and the answer is verified correct
> 3.1 - The DNS query is signed and the answer is verified incorrect
>       because someone is injecting a Cache server with bad information.
> 3.2 - The DNS query is signed and the answer is verified incorrect
>       because someone has broken something (very lightly to happen!).
>
>
> I have no idea if the standard DNS lookup calls even give this bit back
> (getaddrinfo() - etc). I do know that there are various patches (or
> clues) available at http://www.dnssec-deployment.org/tracker/

So I had a little bit of a browse around and it seems that Postfix and
Sendmail have DNSSEC support where they wont deliver outbound email to
fraudulently signed MX records which specify verification is required.

This is rather puzzling since I was under the impression that DNSSEC was
meant to be completely transparent, at the resolver layer and simply
wouldn't return results if they were invalid. ie SERVFAIL or similar.

At this point I'm hoping that someone else here might know more about
the specifics of how DNSSEC is supposed to work at the application
level.

The Sendmail and Postfix patches seem to use libval, a DNSSEC validation
library. If it was to be added as a dependency to Exim, we'd have to
make it a conditional build inclusion.

Support should probably be added to "sender = verify" type lookups,
"dnsdb" lookups, routers and transports.

libspf2 has a patch/update to it as well, but I don't know if anything
changes with that interface or if additional calls are required to get
the DNSSEC status of the SPF result - I don't think it would change but
it probably needs to be checked.

I'll open up a bugzilla entry for it, but before I have a half arsed
look at it, is there anyone willing to program it up?

--
The Exim manual - http://docs.exim.org


--
## List details at http://lists.exim.org/mailman/listinfo/exim-users 
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

[Andre Grueneberg-2]

Ted Cooper wrote:
> So I had a little bit of a browse around and it seems that Postfix and
> Sendmail have DNSSEC support where they wont deliver outbound email to
> fraudulently signed MX records which specify verification is required.
>
> This is rather puzzling since I was under the impression that DNSSEC was
> meant to be completely transparent, at the resolver layer and simply
> wouldn't return results if they were invalid. ie SERVFAIL or similar.

Basically both is correct.
In case you have a DNSSec enabled resolver, it will verify the
responses. If it fails it will return a SERVFAIL to the stub resolver.
Exception: You set the CD (checking disabled) flag in the request. In
that case the querier will get the information no matter what.

Additionally you may explicitly set the DO (DNSSec okay) flag in your
(EDNS0 enabled) request to get the RRSIG RRs for the returned RRs.

In principle the stub resolver could also do the verification. So far I
haven't seen any stub resolver doing that.

In case neither your resolver nor your stub resolver verify the DNS
responses, you may do so in the application. Additionally in case you
don't own the resolver, you might not want to trust it.

Problem is you don't want to maintain the trust anchor in all your
applications.

One option is to do all queries with DO and check the AD (authentic
data) flag and indicate that. Only I don't know where.

Andre
--
If you are feeling good, don't worry; you'll get over it.


--
## List details at http://lists.exim.org/mailman/listinfo/exim-users 
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

[Florian Weimer-2]

* Ted Cooper:

> DNSSEC just makes sure that the answers received in DNS lookups are
> valid

Yes.

> and came from the right place. Doesn't it?

No.  The transport isn't secured at all.  That's why the protocol is
so complex, and somewhat operationally challenging with current
software.

> I would have thought the responsibility for doing DNS lookups and
> validating them would fall to the resolver library. In the event there
> is a DNSSEC failure, the resolver simply returns SERVFAIL or lookup
> fail. The normal Exim behaviour when this happens is dependant on where
> it was called.

Client-side validation in short-lived processes does not work that
well because you'd have to walk back the chain of delegation to a
trust anchor, fetching DS and DNSKEY RRs at each point and performing
an RSA operation.  You have to repeat the process for each MX host, so
for domains like exim.org (domain and all MXs in different TLDs), this
can be quite a bit of work.  Usually, the costs are reduced by
caching, but if you use a process-specific validator in a short-lived
process, the efficiency of the cache is greatly reduced.

(I can't find the Postfix and Sendmail patches, BTW, so I don't know
what they are doing.)

--
Florian Weimer                <fweimer@...>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: [phone]
D-76133 Karlsruhe             fax: [phone]

--
## List details at http://lists.exim.org/mailman/listinfo/exim-users 
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/