On Wed, Jan 07, 2015 at 12:45:53AM +0100, Jean Bruenn wrote:
> What happens if I send an email to your Mailserver if there is
> no DS-record for my domain in eu (which is why I use dlv - I added
> the dnskey of a .eu testdomain there) the same as explained
> below (no mail loss)?
DANE plays no role in inbound mail. The receiving server does not
do any DANE lookups. DANE TLSA is a client-side technology.
The .eu TLD is signed, there are many .eu DNSSEC domains.
For example: debian.eu
debian.eu. IN MX 10 mailly.debian.org. ; NOERROR AD=1
debian.eu. IN MX 10 muffat.debian.org. ; NOERROR AD=1
The TLSA records of the (shared with debian.org) MX hosts are also
present and DNSSEC validated.
> >> What happens if they don't?
> >
> > They'll send email to your domain without DNSSEC or DANE.
> >
> >> Verification will fail and the mail is rejected?
> >
> > Of course not. All that happens is that email transmission to your
> > domain is more vulnerable to MiTM attacks.
> >
> >> Basically I want to know if it is safe to implement DANE with
> >> DLV.
> >
> > Safe, but largely pointless. By the time enough domains enable
> > client-side DANE support for this to matter to you, the ISC DLV
> > may be substantially obsolete.
>
> I see. If I understand correctly it does help in cases like mine if
> the registrar for example has no dnssec support yet?
There is no pressing need to run out and implement DANE for your
domain, certainly not as a fashion statement or out of concern that
mail delivery will suffer if you don't.
At this stage, I'd like to see DANE implemented *only* by people
who know what exactly what they're getting into.
* DO NOT enable DNSSEC if you've not reliably automated timely
resigning of your zone files. Too many sites neglect this
and disappear from the Internet for days until someone notices
that validating resolvers are dropping all responses for the domain.
* DO NOT publish DANE TLSA records for SMTP unless you've understood
that you should only publish records of one the forms:
; Use "3 1 1", the other three are OK, but "3 1 1" is better.
_25._tcp.mx.example.com. IN TLSA 3 1 1 <sha2-256 digest of DER leaf
public key in X.509 SPKI format>
_25._tcp.mx.example.com. IN TLSA 3 0 1 <sha2-256 digest of DER leaf
cert>
_25._tcp.mx.example.com. IN TLSA 3 1 2 <sha2-512 digest of DER leaf
public key in X.509 SPKI format>
_25._tcp.mx.example.com. IN TLSA 3 0 2 <sha2-512 digest of DER leaf
cert>
; Use "2 0 1", the other three are OK, but "2 0 1" is better.
_25._tcp.mx.example.com. IN TLSA 2 0 1 <sha2-256 digest of DER CA
certificate>
_25._tcp.mx.example.com. IN TLSA 2 1 1 <sha2-256 digest of DER CA
public key in X.509 SPKI format>
_25._tcp.mx.example.com. IN TLSA 2 0 2 <sha2-512 digest of DER CA
certificate>
_25._tcp.mx.example.com. IN TLSA 2 1 2 <sha2-512 digest of DER CA
public key in X.509 SPKI format>
The use of SHA2-512 just bloats the DNS packet sizes with
no tangible security benefit, the 2nd-preimage resistance
of SHA2-256, let alone SHA2-512 dwarfs the security level
of the typical RSA-1024 zone signing keys at the root and
TLD domains.
The DANE-TA(2) certificate usage REQUIRES that the trust-anchor
certificate be part of the server's certificate chain file.
Too many people get this wrong from time to time. Stick
to DANE-EE(3) unless you have the attention to detail of
a clinically diagnosed OCD patient who never makes mistakes.
With DANE-EE(3) you are also not subject to "unplanned"
certificate expiration outages, or hostname mismatch issues.
* Deploy a "3 1 1" separate certificate for each server, avoid
the temptation to "share". With "shared" certificates, a
mistake in key rotation takes out all the servers.
* Do understand how to coordinate DANE TLSA record updates with
key rotation, and never forget to update DANE TLSA records
as part of that process.
* Do monitor your DANE deployment, and promptly fix any problems.
Have a working "postmaster" mailbox that is read by human.
Publish an working "hostmaster" address in the "RNAME"
field of the domain's SOA record that is also read by a human.
From RFC 1035, Section 3.3.13:
RNAME A <domain-name> which specifies the mailbox of the
person responsible for this zone.
Know how to encode email addresses with dots in the localpart as
SOA RNAMEs (see SOA of disa.mil for example).
I am hoping at present to discourage the use of DANE either as a
fashion statement or by inexperienced server operators.
I am also trying to encourage the use of DANE by seasoned administrators
who know what they are getting into, and how to make it work
reliably.
Of the approximately 800 domains that I found to have published
DANE TLSA records for SMTP to date, too many had various problems.
We'll announce a testing site soon that will help detect problems
early, but it won't prevent them if the site's administrator is
not sufficiently disciplined about ongoing operational requirements.
If you understand DNS and email well, are ready to implement DNSSEC
and are good at not losing track of details, please implement DANE,
otherwise, please wait, or use a professionally operated hosting
service that will do it for you.
--
Viktor.
