Web Admin: Krystal: DNS Records

From U3A Support
Jump to navigation Jump to search

Introduction

A Domain Name System (DNS) record is a set of instructions used to connect domain names with internet protocol (IP) addresses within DNS servers. DNS records makes it possible for users to browse the internet using customizable domain names and URLs rather than complex numerical IP addresses. They are important because DNS records play a crucial role in translating human-readable domain names (like “shrewsburyu3a.org.uk”) into the corresponding IP addresses (such as “192.168.1.1”).

DNS records also provide other vital information for internet communication, ensuring seamless connectivity and efficient routing. There are a number of types of DNS records but some of the important ones that stand out for us are the:

MX records: MX records specifies which mail exchange servers route emails to the correct destinations.

Txt Records: Txt Records serve a purpose to allow other connectivity and confirmation of protocols between our website and client computers.

Many DNS records are created automatically as the website and basic email functions are set up. However, to enhance our security and email deliverability we have added a number of DNS records ourselves.

Additional DNS Records (Explanation)

SPF Records

An SPF (Sender Policy Framework) record is a TXT record published in the DNS (Domain Name System) by the domain owner. It serves as a whitelist of authorized IP addresses allowed to send emails on behalf of the domain. Some records are added automatically, we have for instance SPF records for shrewsburyu3a.org.uk, staging.shrewsburyu3a.org.uk & support.shrewsburyu3a.org.uk. Some have to be added manually. We had to manually add one for the Mailgun sever.

The key value for SPF records always start with "v=spf1".

DKIM Records

DKIM (DomainKeys Identified Mail) is an email authentication method that helps prevent spammers and malicious parties from impersonating legitimate domains. It ensures that emails are genuinely sent from authorized servers associated with a domain. Along with SPF and DMARC, DKIM strengthens email security. It works by using public key cryptography to authenticate the email's origin. It does this with a public-private key pair.

  • The Public Key is made available in a DNS Record (the DKIM record)
  • When an email is sent, included within the header is a section of the Private key - this is a "Digital Signature"
  • The receiving email server checks the DKIM DNS Record, retrieves the public key and verifies the digital signature.
  • If they match then the email hasn't been altered in transit and is allowed through to the destination.

The key value for DKIM records always start with "v=DKIM1".

DMARC Records

A DMARC (Domain-based Message Authentication Reporting and Conformance) record is a DNS TXT record that plays a crucial role in email authentication. DMARC is all about ensuring the authenticity of email messages to prevent email spoofing and unauthorized use of domains. It works alongside other email authentication methods like SPF and DKIM and specifies what happens after such checks - whether they fail or pass. Typically messages that fail are quarantined - sent to the spam or junk email folder, although you can select a policy of "none" used for testing and takes no action or "reject" which bins failures outright. Two reports are generated that are sent to a selected email address/es; an aggregate report (rua) and forensic reports for individual failures (ruf).

DMARC records primarily focus on outbound email and the key value always starts with "v=DMARC1"

Google Site Verification

Google Postmaster Tools is a free service offered by Google that provides email senders with valuable insights into their email deliverability and performance on Gmail. It’s designed to help marketers and organizations improve their email practices by tracking various metrics like spam reports, domain reputation, and delivery errors. Due to our relatively low volume of emails sent, we only register for the Spam report that indicates how many of our users have marked u3a email as spam. TBH, this was a service that we signed up for (it's free) that gives us very little.

The key value for Google Site Verification always starts with "google-site-verification".

NCSC Site Verification

Unlike Google Postmaster Tools (above), the NCSC (National Cyber Security Centre) gives us a lot more detail about the state or our email services and website. To link our website to the NCSC a validation Txt record has been added. It has a unique code.

The key value for the NCSC verification record starts with "asvdns_".

TLS-RPT Records

TLS Reporting is a protocol that allows a domain to advertise a destination for sending email services to report the success or failure of encryption in transit. TLS-RPT complements other protocols that enforce TLS, such as Mail Transfer Agent Strict Transport Security (MTA-STS) and DNS-based Authentication of Named Entities (DANE). It focuses on inbound email traffic, unlike DMARC reporting, which primarily deals with outbound email.

Reports are aggregated, so you receive one report per day from each sending service.

TLS-RPT reports highlight issues related to TLS negotiation with mail servers. Common errors include:

  • Failure to negotiate TLS with the mail servers.
  • Invalid certificate problems.
  • Issues related to MTA-STS or DANE.

MTA-STS Interaction:

When an MTA-STS policy (either “testing” or “enforce”) is present, you’ll receive reports from services attempting to send you email.

During testing, reports simulate how your email service handles inbound traffic before enforcing the policy, without risking email loss.In summary, TLS-RPT provides insights into encryption failures, helping you enhance your email security and ensure successful email delivery

The key value for TLS-RPT records always starts with "v=TLSRPTv1".

MTA-STS Records

MTA-STS (Mail Transfer Agent Strict Transport Security) is an essential email standard that enhances the security of inbound email. MTA-STS secures inbound email by preventing attackers from exploiting weaknesses in standard SMTP security. The main features:

  • It ensures that only TLS-encrypted messages are delivered to your domain.
  • Messages can only be delivered to email servers published by the MTA-STS policy.
  • Similar to DMARC, MTA-STS provides inbound protection for your domain.

There are two modes of use; testing and enforce. As you would expect, setup the policy with testing to start with, then update to enforce when you are happy with the results and you understand what is happening.

MTA-STS DNS records should have an associated MTA-STS policy that is published to a hidden well-known folder to a MTA-STS subdomain of shrewsburyu3a.org.uk.

The key value for MTA-STS records always start with "v=STSv1"

Summary

Having a full set of DNS Records, increases the Domain Holders email reputation and enhances the deliverability of email to the recipients. A useful tool to check various DNS records can be found at MXToolBox.com.

DNS Check
DNS Checks

DNS Records are managed in the "Zone Editor", part of the "Domains" section of cPanel.

DNS Record details

All these records here are available for anyone to see online with a suitable reporting tool.

SPF

  • The SPF record for the shrewsburu3a.org.uk domain can be explained thus:
    • The name of the SPF record is just the domain name: shrewsburyu3a.org.uk.
    • v=spf1: This indicates that the TXT record contains an SPF policy and should be interpreted as such by email servers.
    • +mx: This mechanism allows the domain to send emails from its mail exchange (MX) servers. In other words, it authorizes the domain’s mail servers to send emails on behalf of the domain.
    • +a: This mechanism permits the domain to send emails from its A records (IP addresses associated with the domain). It allows the domain’s web server (A record) to be an authorized sender.
    • include:relay.k.io: The include mechanism specifies that the SPF check should also include the SPF records of the domain specified (in this case, relay.k.io). If the SPF check passes for that domain, it contributes to the overall SPF authorization.
    • +ip4:77.72.1.17: This allows the specific IP address 77.72.1.17 to send emails on behalf of the domain. It explicitly authorizes this IP address.
    • include:mailgun.org: Similar to the previous include mechanism, this one includes the SPF records of the domain mailgun.org in the SPF check. If the SPF check passes for Mailgun, it contributes to the overall authorization.
    • ~all: The soft fail (~all) indicates that if the SPF check fails, the email should still be accepted but marked as potentially suspicious. It doesn’t result in a strict rejection. In summary, this SPF record allows emails from the domain to be sent by its MX servers, its A records, the specified IP address, and also considers SPF records from relay.k.io and mailgun.org. The soft fail at the end ensures that even if the SPF check fails, emails are not outright rejected but may be flagged as suspicious.
  • And the SPF record for the Mailgun server
    • The name of the SPF record is just the sub domain name: mg.shrewsburyu3a.org.uk.
    • v=spf1: This indicates that the TXT record contains an SPF policy and should be interpreted as such by email servers.
    • include:eu.mailgun.org: The include mechanism specifies that the SPF check should also include the SPF records of the domain specified. In this case, it includes the SPF records from the domain eu.mailgun.org. If the SPF check passes for that domain, it contributes to the overall SPF authorization.
    • ~all: The soft fail (~all) indicates that if the SPF check fails, the email should still be accepted but marked as potentially suspicious. It doesn’t result in a strict rejection. In summary, this SPF record allows emails from the domain to be sent by its authorized sources (including those specified in the eu.mailgun.org SPF records), and the soft fail ensures that even if the SPF check fails, emails are not outright rejected but may be flagged as suspicious123.

DKIM

The DKIM record for support.shrewsburyu3a.org.uk can be explained as follows

  • default._domainkey.shrewsburyu3a.org.uk. The name of the DNS Record.
  • v=DKIM1: This tag specifies the version of DKIM being used. In this case, it’s DKIM1, indicating the first version of DKIM.
  • k=rsa: The key type used for DKIM. Most commonly, it is set to RSA (Rivest–Shamir–Adleman), which is a widely used asymmetric encryption algorithm. However, RFC 8032 introduced support for ed25519 as an alternative key type.
  • p=MIIBIjANBgkqhkiG9w0BAQEFAAOC: This tag contains the public key data in base64 format. The public key is used by receiving mail servers to validate the authenticity of email messages signed by the sending domain. The value you provided is a snippet of the actual public key. In summary, DKIM ensures the integrity of email messages by digitally signing them using the private key of the sending domain. Receiving mail servers then use the public key from the DKIM record to verify that the email has not been altered during transit.

DMARC

DMARC Policy: Our actual DMARC Policy is explained thus:

  • _dmarc.shrewsburyu3a.org.uk. The name of the DNS record.
  • v=DMARC1: This indicates that the TXT record contains a DMARC policy and should be interpreted as such by email servers.
  • p=quarantine: The DMARC policy specifies what happens to an email after it is checked against SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) records. In this case, p=quarantinemeans that email servers will monitor emails coming from the domain and block any messages that might be fraudulent by sending them to the junk or spam folder of the recipient. It’s a way to start monitoring for fraud without taking strict action1.
  • sp=none: This part refers to the subdomain policy. Since it’s set to none, it means that the policy for subdomains is the same as the main domain (i.e., no strict actions are taken). In practice this means that we do not need a DMARC record for mg.shrewsburyu3a.org.uk nor staging.shrewsburyu3a.org.uk.
  • adkim=r: The alignment mode for DKIM checks. Here, r stands for relaxed alignment. It means that DKIM checks are not strict; they allow some flexibility in the alignment of the DKIM signature.
  • aspf=r: Similar to adkim, this specifies the alignment mode for SPF checks. Again, r indicates relaxed alignment for SPF.
  • pct=100: This sets the percentage of emails to which the DMARC policy applies. In this case, it’s set to 100%, meaning that the policy applies to all emails.
  • fo=1: The failure reporting options. Here, 0 means that no forensic reports are requested if both SPF and DKIM fail and fo=1 generates a report if either SPF and DKIM fail. Forensic reports contain information about individual email messages that fail authentication.
  • rf=afrf: The format for forensic reports. afrf stands for Authenticated Failure Reporting Format, which is a standardized format for reporting failures.
  • ri=86400: The interval for sending aggregate reports (in seconds). In this case, it’s set to 86,400 seconds (which is 24 hours).
  • rua=mailto:validemailaddress@somewhere.org.uk : This specifies the email address where aggregate reports should be sent. Aggregate reports provide summarized information about email authentication results. Emails are sent to our Webmanager.
  • ruf=mailto:validemailaddress@somewhere.org.uk: Similarly, this specifies the email address where forensic reports should be sent. Forensic reports contain detailed information about individual email failures. Emails are sent to our Webmanager. In summary, this DMARC record instructs email servers to monitor emails from the domain, use relaxed alignment for both DKIM and SPF checks, and send aggregate and forensic reports to the specified email address.

NCSC

The NCSC DNS Validation key has a value of asvdns_+32+random characters.

TLS-RPT

Our TLS-RPT record can be explained as follows:

  • _smtp._tls.shrewsburyu3a.org.uk. The name of the DNS Record.
  • v=TLSRPTv1 Indicates that this DNS record is for TLS-RPT version 1.
  • rua=mailto:tls-rua@mailcheck.service.ncsc.gov.uk: The rua tag stands for “Report URI Aggregate”. It defines the email address where aggregated TLS-RPT reports should be sent. In this case, reports are directed to tls-rua@mailcheck.service.ncsc.gov.uk.

These reports provide information about TLS connection failures encountered by email-sending services.

MTS-STS

The DNS record:
  • _mta-sts.shrewsburyu3a.org.uk The name of the DNS record.
  • v=STSv1 Indicates that this DNS record is for MTA-STS version 1
  • id=20240414T143000Z It is recommended to use a datetime format here. This must be updated it the corresponding policy is changed. In this example the ID indicates 14 Apr 2014 at 14:30 hrs.
The MTA-STS Policy
  • version: STSv1 Indicates that this is version 1 of the STS Policy
  • mode: testing Testing or Enforce as required
  • mx: mx1.krystal.uk The mail server/s. A separate line for each mail server
  • mx: mx2.krystal.uk
  • mx: mxa.eu.mailgun.org
  • mx: mxb.eu.mailgun.org
  • max_age: 86400 TTL in seconds, 86400 seconds is 24 hours.

The policy should be published as a txt file to a secure webpage in the format: mta-sts/domain name/.well-known/mta-sts.txt

Navigate to the previous or next article