NTACurrent en:DNS Setup

Aus Cryptshare Documentation
Wechseln zu:Navigation, Suche

Overview

To be able to receive emails according to the technical agreements made in the context of NTA 7516, the DNS configuration of the receiving domain has to meet some requirements, which are described here.

NTA 7516 TXT Record

A special TXT resource record identifies your domain as NTA 7516 compliant. The record's data also contains additional information for the sending side for validation and delivery.

Create a TXT RR with the following data: 

v=NTA7516-1;startdate=<start date>;enddate=<end date>;provider=<provider>;ntamx=<priority> <mail server>;ntamx=<priority> <mail server>...
  • <startdate>: Start of the validity period as year and month (YYYY-MM) according to the NTA 7516 certification of your organization. The first day of the specified month is the first day the record takes effect.
  • <enddate>: End of the validity period as year and month (YYYY-MM) according to the NTA 7516 certification of your organization. The last day of the specified month is the last day the record takes effect.
  • <provider>: Name of the communication service. For Cryptshare for NTA 7516, use "Cryptshare".
  • ntamx=<priority> <mail server>: Zero or more references to the mail server(s) which are capable of receiving emails compliant with NTA 7516. Each reference consists of ";ntamx:", followed by a number that specifies the preference and a hostname (divided by spaces). The preference defines the order in which the mail servers are used for delivery attempts (lowest first). If no "ntamx" references are specified, the default MX host(s) for the domain are used. For Cryptshare for NTA 7516, specify the fully qualified domain name of the Cryptshare Mail Gateway host.

Example: 

myorganisation.nl.    86400    IN    TXT    v=NTA7516-1;startdate=2019-06;enddate=2023-07;provider=Cryptshare;ntamx=10 nta7516-mx.myorganisation.nl

In addition, please adhere to the following rules of validity:

  • The end date must not be earlier than the start date.
  • There may be 2 records as specified above, e.g. to setup a new validity period declaration in advance. However, their dates must not overlap.
  • The record must not contain a " character (ASCII 32).
  • The TTL value of each record must not exceed 86400 (1 day).

DANE

DNS-based Authentication of Named Entities (DANE) can be used in the context of email transport to give the sending party proof of the receiving server's authenticity. Therefore, the recipients domain has a special (TLSA) resource record for each mail server with certificate data that can be used to verify the TLS certificate data of the server.

In addition, DANE requires DNSSEC (see the corresponding section below).

In general, TLSA records are structured as follows: Name: 

_<port>._<transport protocol>.<host>
  • <port>: The port number of the service.
  • <transport protocol>: The transport protocol of the service, for example TCP.
  • <host>: The FQDN of the host. For Cryptshare for NTA 7516, this is the FQDN of the Cryptshare Mail Gateway host.

Data: 

<usage> <selector> <matching-type> <certificate association data>
  • <usage>: Specifies how to verify the certificate. Possible values:
    • 0: PKIX-TA
    • 1: PKIX-EE
    • 2: DANE-TA
    • 3: DANE-EE A TLSA record that can be used for SMTP should specify 2 or 3 as usage.
  • <selector>: Specifies which part of the server's certificate are checked. Possible values:
    • 0: The entire certificate.
    • 1: The public key.
  • <matching-type>: Specifies which data is presented as <certificate association data>:
    • 0: The entire information (e.g. the whole certificate).
    • 1: SHA-256 hash of the selected data.
    • 2: SHA-512 hash of the selected data.

See https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities#RR_data_fields for more details. There are several online tools to create TLSA records for DANE, for example https://www.huque.com/bin/gen_tlsa or https://ssl-tools.net/tlsa-generator.

To follow the technical agreements for NTA 7516, use 3 (DANE-EE) as usage, 1 (public key) as selector, and 1 (SHA-256) as matching type.

Example: 

_25._tcp.nta7516-mx.myorganisation.nl.    3600    IN    TLSA    3 1 1 AB9BEB9919729F3239AF08214C1EF6CCA52D2DBAE788BB5BE834C13911292ED9

SPF

The Sender Policy Framework (SPF) is a method used in combination with DMARC for verifying that email sent from an originating domain only comes from authorised mail servers. With SPF, the receiving MTA is able to check if the sending MTA is allowed to send emails from a certain domain, by looking up SPF records (TXT records) of that sending domain.

To setup SPF, create  TXT resource records for each MTA that is authorized to send emails. Data format: 

v=<version> <directives>

To follow the technical agreements for NTA 7516, SPF has to be applied to all relevant domain names (including domains that are not used for emailing), as well as to all receiving email servers (more precisely: on every domain with an A-record or an MX-record). This includes the host of the Cryptshare Mail Gateway. The SPF record must contain the IP address(es) of the sending server(s) and the string "-all".

Example (22.33.44.55 is the IP address of the Cryptshare Mail Gateway host): 

myorganisation.nl.    3600    IN    TXT    v=spf1 ip4:22.33.44.55 -all

DKIM

DKIM allows the receiving MTA to check that an email that claimed to have come from a specific domain was indeed authorised by the owner of that domain. To achieve this, the sender adds a digital signature, linked to a domain name, to each outgoing email message. The recipient system can verify this by looking up the sender's public key published in TXT resource records. A TXT record name has the following format: 

<selector>._domainkey.<domain name>
  • <selector>: A selector string, as specified during the setup of Cryptshare Mail Gateway. This selector should change every time the keys change, so it's recommended to include a date reference, like "feb2021".
  • <domain name>: The domain name that is used for emails.

The record data is structured as tag-value pairs, and consist at least of the tag "p" which specifies the public key (Base64-encoded). The version tag "v" is recommended and has currently only "DKIM1" as valid value. 

v=DKIM1; p=<public key>
  • <public key>: The public key of the key pair that is used to add the DKIM signature to the message, and that has been created during the installation of Cryptshare Mail Gateway.

Example: 

nta7516feb2021._domainkey.myorganisation.nl.    3600    IN    TXT    v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDDmzRmJRQxLEuyYiyMg4suA2SyMwR5MGHpP9diNT1hRiwUd/mZp1ro7kIDTKS8ttkI6z6eTRW9e9dDOxzSxNuXmume60Cjbu08gOyhPG3GfWdg7QkdN6kR4V75MFlw624VY35DaXBvnlTJTgRg/EW72O1DiYVThkyCgpSYS8nmEQIDAQAB

DMARC

DMARC (Domain-based Message Authentication, Reporting and Conformance) makes it possible to publish policies on how an email provider should handle email that cannot be identified as originating from the specified sender domain. This allows organisations to prevent others from sending emails on behalf of the organisation's email domain.

A DMARC policy allows a sender to indicate that messages are protected by SPF or DKIM and informs the recipient what to do if both of these authentication methods fail. DMARC policies are published in the DNS as TXT resource records.

Name: 

_dmarc.<domain name>
  • <domain name>: The domain name that is used for emails.

The record data is structured as tag-value pairs, whereby at least "v" and "p" tags are required: 

v=DMARC1; p=<policy>
  • <policy>: The policy that is applied if both SPF and DKIM checks fail. Possible values:
    • none: The domain owner requests no specific action be taken regarding delivery of messages.
    • reject: The domain owner wishes for mail receivers to reject email that fails the DMARC mechanism check. Rejection should occur during the SMTP transaction.
    • quarantine: The domain owner wishes to have email that fails the DMARC check to be treated by mail recipient's SMTP server as suspicious. Depending on the capabilities of the mail recipient's SMTP server, this can mean "place into spam folder", "scrutinise with additional intensity", and/or "flag as suspicious".

For more details, see https://dmarc.org//draft-dmarc-base-00-01.htm.

To follow the technical agreements for NTA 7516, DMARC is applied to all relevant domain names (including domains that are not used for emailing), as well as to all receiving email servers. The DMARC record must specify the "reject" or "quarantine" policy.

Example: 

_dmarc.myorganisation.nl.    3600    IN    TXT    v=DMARC1; p=reject

DNSSEC

In order to make it possible for the communication partner to check the integrity and authenticity of the DNS records described above, the technical agreements for NTA 7516 require DNSSEC (Domain Name System Security Extensions) for your organisation's domain.

Please consult your DNS provider to setup DNSSEC properly.

Abgerufen von „https://documentation.cryptshare.com/w/index.php?title=NTACurrent_en:DNS_Setup&oldid=18927“