Setting up DNS in 2017 - A record to TLSA

Posted 03-23-2017 at 02:28 PM by serafean
Updated 03-23-2017 at 03:14 PM by serafean

I set off on the journey to set up DNS as correctly as I could. After reading through a lot of stuff, here are my findings:
This example server will have on IP, and will run a web server, and an email server.
This is more of a setup dump than tutorial, but might point someone in the right direction...

Prequisites:

First, create an A (AAAA for ipv6 ) record for the domain :

Code:

example.net. 1800 IN A 127.0.0.1

Basic explanation of the entry

example.net. - the domain name (not the dot at the end)
1800 - TTL - time DNS clients will keep this address before querying the address again
IN - DNS class. (Will always be IN)
A - Type of record
127.0.0.1 - IP address the server will be running on. This field carries the data of the record, and will be referred to as "data" further in the text.

Web server

Code:

www.example.net. 1800 IN CNAME example.net.

Here we reuse the main A record through this CNAME record. This will enable us to only change the IP address only in one place when necessary.

Email

This will run SMTP and IMAP.
Note: Do respect RFC 6409 and enable submission on port 587 (with authentication enabled), and leave port 25 for MTA-MTA connections.

Basic setup :

Code:

example.net. 1800 IN MX 1 mail.example.net.
mail.example.net. 1800 IN A 127.0.0.1

The MX record specifies where to find the email server for this domain. It can only reference an A (AAAA) record (in this case mail.example.net).

Help MUAs

RFC 6186 defines how to help MUAs find your server. This is done using SRV record.

Code:

_imap._tcp.example.net. 1800 IN SRV 0 0 143 mail.example.net.
_imaps._tcp.example.net. 1800 IN SRV 0 0 993 mail.example.net.
_submission._tcp.example.net. 1800 IN SRV 0 0 587 mail.example.net.

The data of an SRV record contains (in order) :

Priority - lower value is prefered. An entry with a higher value is selected only if no lower values were available.
weight - higher value is prefered. This allows distribution of load among services with the same priority
port - the port on which the service is listening
name - address where to contact the service. As with the MX record, this MUST point to an A or AAAA record.

SPF record

This record allows the receiving side to apply basic checks to a received email as specified by the sending domain.

Code:

example.net 1800 IN TXT v=spf1 mx ~ptr -all

v=spf1 defines the version of the spf.
The rest of the data contains the definition of the checks. Here the checks performed are:

mx - match if the domain name of sender's address matches the MX record of the domain. Accept such mail.
~ptr - check the PTR record. ~ specifies to accept even emails that fail, but tag them.
-all - Match everything. "-" specifies to fail.

This policy accepts only email where the MX record matches. For small servers, that's enough.
For the rest, I shall refer you to wikipedia or other documentation.

DKIM record
You should DKIM sign your outgoing email, and publish your public key in the DNS.

Code:

default._domainkey.example.net. 1800 IN TXT v=DKIM1;k=rsa;p=.....

DKIM is pretty complicated, too complicated for this post. I'll refer you to a tutorial and a record generator.

DMARC

Code:

_dmarc.example.net. 1800 IN TXT v=DMARC1; p=none; rua=mailto:dmarc@example.net;

Data section:

v - DMARC version used
p - Policy to implement. Unless you want to break mailing lists, leave this on 'none'
rua - where to send aggretate reports. Very useful for debugging.

There are a few more flags, it might even be possible to make a policy work with mailing lists. If anyone knows of one, please comment.

With these DNS record, most freemail providers accept emails from my server (including GMail).

DNSSEC & TLSA

TLSA records allow you to put hashes of TLS certificates into the DNS records of your domain. This creates a system resembling 2 factor authentication. For TLSA to be effective, your DNS should support DNSSEC. I'll give two examples of TLSA records.

LetsEncrypt

Lets Encrypt requires you to change certificates about every 3 months. This would require updating the TLSA records at the same time, which is non practical. Fortunately, We can specify the Certificate Authority that our certificate will be signed with. In this case the server MUST send the complete certificate chain.
Such a record looks as follows:

Code:

letsencrypt._dane.example.net 1800 IN TLSA 2 0 2 0ff0ebee2e9be02487662a6caa238f9c329344a9c0e146dccc74b1bbb84a51e6f762fa9e33ba6d6acd86581184f97c18ca885b753a6bb42f918ff6b6a17801e1
_443._tcp.www.example.net 1800 IN CNAME letsencrypt._dane.example.net

The CNAME redirection should be respected if both the CNAME record and the TLSA records are signed with DNSSEC.
Description of the data section:

2 - Usage field. Here specifiyng to check the certificate's CA.
0 - Use the full certificate to check
2 - Hash is SHA512 ( I recommend to use SHA256 (1), as it is the only one that MUST be implemented.
0ff.. - The hash itself

Letsencrypt TLSA info.
The Usage field currently allows 4 values :

0 - PKIX-TA: Certificate Authority Constraint - check signing CA, using the PKI infrastructure.
1 - PKIX-EE: Service Certificate Constraint - Check the certificate, using the PKI infrastructure.
2 - DANE-TA: Trust Anchor Assertion - check the signing CA, trusting this DNS record.
3 - DANE-EE: Domain Issued Certificate - check the certificate, trusting this DNS record.

A TLSA record generator. A good read about TLSA/DANE.
Currently almost nothing supports DANE validation, but there exists a plugin compatible with most browsers!

Setting up DNS in 2017 - A record to TLSA

Comments