DNS security is important and there’s a lot of information available talking about how to secure your DNS infrastructure.There are fewer articles talking about how to protect your reputation and domains from abuse by deploying DNS records.
As I generate a report talking about the deployment of DNS security records, it seems only fair to talk about those records and how they should be deployed. Which records you need and how they should be deployed depends on how you are using your domain and what other services you are running. One thing to keep in mind with these records is that their primary function is to make it harder for the bad guys to impersonate you; protecting your reputation and people you communicate with. The foundation of all of any DNS based security measure is to ensure that your DNS is secure, so pick a good registrar and DNS provider and make sure that you’ve enabled DNSSEC.
When you first register a domain the first thing you should do is to protect it so that it can’t be abused by other people whilst you’re not using it. The NCSC have some excellent advice on how to do this. For a parked domain you want to publish negative records telling people that the domain isn’t used and that anything they see from it is bogus. Following the NCSC advice you should be publishing the following records:
@ TXT “v=spf1 -all” @ MX 10 . @ CAA 0 issue ";" _dmarc TXT “v=DMARC1;p=reject;" * MX 10 . * TXT “v=spf1 -all” *._domainkey TXT “v=DKIM1; p=”
Unfortunately most DNS providers don’t allow a MX record with a value of “.” so unless you run your own DNS that one’s probably not possible. At this point you’re really just saying in many ways that the domain isn’t used for email, and that no certificate authority should issue a certificate for anything associated with it. If you are using a DMARC reporting service then the “_dmarc” record should obviously represent that e.g.
_dmarc TXT “v=DMARC1;p=reject;rua=mailto:firstname.lastname@example.org"
All of the above is well and good if you’re not using the domain, but sooner or later you’ll probably want to actually do something with it. If you’re just standing up a website or non-email service then nothing much changes. You’ll probably want to get a certificate for your website so just change:
@ CAA 0 issue ";"
To the Certificate authority of your choice:
@ CAA 0 issue "letsencrypt.org"
If you want to be thorough then as the M3AAWG explain, you should also set up a specific null MX and negative SPF record. So the domain might become:
@ A 192.0.2.1 @ AAAA 2001:db8::21 @ TXT “v=spf1 -all” @ MX 10 . @ CAA 0 issue "letsencrypt.org" _dmarc TXT “v=DMARC1;p=reject;" * MX 10 . * TXT “v=spf1 -all” *._domainkey TXT “v=DKIM1; p=” www CNAME @ www MX 10 . www TXT “v=spf1 -all”
At this point in theory you should also consider publishing a DANE/TLSA record. However, this can be problematic as you will need to update your TLSA records every time you renew your certificate, which if you’re using Let’s Encrypt would be every 90 days which is a bit much. There are some ways round this problem
Flipping Binary has a solution; or if you are prepared to let someone else handle part of your DNS security then TLSA.is have a CNAME based solution.
If you do publish a DANE record then it would be something like:
_443._tcp.www TLSA 3 1 1 0C72AC70B745AC19998811B131D662C9AC69DBDBE7CB23E5B514B56664C5D3D6
There are also tools available to assist in the generation of suitable records.
If you want to use your domain to send e-mail then things get a little more complicated, as you need to know the details of what servers will be sending e-mail on your behalf. Many providers make this easier by providing records that they maintain that you can include in your own records, both for SPF and DKIM purposes. Ideally you want to keep your DMARC record at reject then you will really want to have a service to monitor incoming DMARC reports to make sure nothing is misconfigured. Fortunately there are an increasing number of people offering such services to suit most budgets. If your domains is already sending email then moving to a strong DKIM/DMARC/SPF posture requires a bit of work and isn’t something I can cover here. However, assuming that you know what your mail servers are and want to follow best practices then putting it all together would give something like:
@ A 192.0.2.1 @ AAAA 2001:db8::21 @ TXT “v=spf1 ip4:192.0.2.2 include:spf.example.org -all” @ MX 10 mail.example.com @ CAA 0 issue "letsencrypt.org" _443._tcp.www TLSA 3 1 1 0C72AC70B745AC19998811B131D662C9AC69DBDBE7CB23E5B514B56664C5D3D6 _35._tcp.mail TLSA 3 1 1 0C72AC70B745A1D662C9AC69DBDBE7CB23E5B514B56664C5D3D6C19998811B13 _dmarc TXT “v=DMARC1;p=reject;rua=mailto:email@example.com" * MX 10 . * TXT “v=spf1 -all” *._domainkey TXT “v=DKIM1; p=” mail A 192.0.2.2 mail TXT "v=spf1 ip4:192.0.2.2 -all" mail1._domainkey TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ.....CTwIDAQAB" vendor._domainkey CNAME dkim1.example.org www CNAME @ www MX 10 . www TXT “v=spf1 -all”
The actual records required can very tremendously depending on your infrastructure and how many services you’re running. Whilst publishing explicit negative SPF and NULL MX records for every record that actually exists is the ideal for most people this doesn’t sale and the management overhead is far too high. A reasonable compromise would be to make sure suitable records are published for everything that does send email and for any records which are an obvious risk of impersonation. For example if there was a website “jobs.example.com” even if no email is ever sent as “firstname.lastname@example.org” it would be worth publishing explicit records to protect it, whilst “host-192-0-5-5.example.com” could most likely be considered a lower risk.
One final note only the initial template for parked/defensive domains can be deployed as is to give the expected results. All of the subsequent examples would need to be modified to actually work in a real world deployment.