DANE for Email Security Appliance

Available Languages

Updated:August 26, 2019
Document ID:214794

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

    Introduction

    This document describes DANE implementation for ESA outbound mail flow.

    Prerequisites

    General knowledge of ESA concepts and configuration.

    Requirements to implement DANE:

    • DNSSEC capable DNS Resolver
    • ESA with AsyncOS 12.0 or newer

    Background Information

    DANE has been introduced to ESA 12 for outbound mail validation.

    DNS-based Authentication of Named Entities (DANE).

    • DANE is an internet security protocol to allow X.509 digital certificates, to be bound to domain names using DNSSEC. (RFC 6698)
    • DNSSEC is a collection of IETF specifications for securing DNS records through the use of public-key cryptography. (Very elementary explanation. RFC 4033, RFC 4034, and RFC 4035)

    Considerations for Implementation

    Verify the ESA utilizes a dnssec capable DNS Resolver.

    DNS capability to perform dnssec/DANE queries is required to implement DANE.

    To test the ESA DNS DANE capability a simple test can be performed from the ESA CLI login.

    The CLI command 'daneverify' will perform the complex queries to verify whether a domain is capable of passing DANE verification.

    The same command can be used with a known good domain to confirm the ESA ability to resolve dnssec queries.

    'ietf.org' is a globally known source. Performing the cli command 'daneverify' will verify whether the DNS Resolver is DANE capable or not.

    VALID PASS: DANE CAPABLE DNS SERVER "DANE SUCCESS" RESULTS FOR ietf.org

    > daneverify ietf.org

    SECURE MX record(mail.ietf.org) found for ietf.org
    SECURE A record (4.31.198.44) found for MX(mail.ietf.org) in ietf.org
    Connecting to 4.31.198.44 on port 25.
    Connected to 4.31.198.44 from interface 216.71.133.161.
    SECURE TLSA record found for MX(mail.ietf.org) in ietf.org
    Checking TLS connection.
    TLS connection established: protocol TLSv1.2, cipher ECDHE-RSA-AES256-GCM-SHA384.
    Certificate verification successful
    TLS connection succeeded ietf.org.
    DANE SUCCESS for ietf.org
    DANE verification completed.

    INVALID FAIL: NON-DANE CAPABLE DNS SERVER  "BOGUS" RESULTS FOR ietf.org

    > daneverify ietf.org

    BOGUS MX record found for ietf.org
    DANE FAILED for ietf.org
    DANE verification completed.

    VALID FAIL: daneverify cisco.com > cisco has not implemented DANE. This is the expected result from a dnssec capable resolver.

    > daneverify cisco.com

    INSECURE MX record(alln-mx-01.cisco.com) found for cisco.com
    INSECURE MX record(alln-mx-01.cisco.com) found. The command will still proceed.
    INSECURE A record (173.37.147.230) found for MX(alln-mx-01.cisco.com) in cisco.com
    Trying next MX record in cisco.com
    INSECURE MX record(rcdn-mx-01.cisco.com) found for cisco.com
    INSECURE MX record(rcdn-mx-01.cisco.com) found. The command will still proceed.
    INSECURE A record (72.163.7.166) found for MX(rcdn-mx-01.cisco.com) in cisco.com
    Trying next MX record in cisco.com
    INSECURE MX record(aer-mx-01.cisco.com) found for cisco.com
    INSECURE MX record(aer-mx-01.cisco.com) found. The command will still proceed.
    INSECURE A record (173.38.212.150) found for MX(aer-mx-01.cisco.com) in cisco.com
    DANE FAILED for cisco.com
    DANE verification completed.

    If the above tests "VALID" work:

    • A cautious approach would be to test each domain prior to adding a profile for the domain.
    • A more aggressive approach would be to configure DANE on the Default Destination Controls Profile and see who passes/fails.

    Mail Direction determines if DANE will verify.

    Sender Group/Mail Flow Policies which have the "RELAY" action configured will peform DANE verification.

    Sender Group/Mail Flow Policies which have the "ACCEPT" action configured will NOT pefor DANE verification.

    Caution: If the ESA has the Desination Controls "DANE" enabled on the Default Policy, there is a risk of failed delivery.  If an internally owned domain such as the ones listed in the RAT, pass through both RELAY and ACCEPT mail flow policies, combined with the presence of an SMTP Route for the domain.

    SMTP Routes

    DANE will Fail on SMTP Routes unless the "Destination Host" is configured to "USEDNS."

    DANE Opportunistic will not deliver the messages, containing them in the Delivery Queue until the bounce profile timer expires.

    Why? DANE Verification gets skipped since an SMTP Route would be a modification of the true destination and may not properly use DNS.

    Solution: Create Destination Control Profiles to explicitly disable  DANE Verification for domains containing SMTP Routes

    DANE Opportunistic or DANE Mandatory

    The following lookups are performed during DANE verification.

    Each verification feeds content to perform the subsequent verification.

    • MX Record lookup verifies if >>> Secure, Insecure, Bogus
    • A record lookup verifies if >>> Secure Insecure > Bogus
    • TLSA record lookup verifies if >>> Secure, Insecure, Bogus, NXDOMAIN
    • Certificate verify >> Success, Failed

    Secure:

    • DNS verified the presence of a secure record containing an RRSIG  validated signed RRSIG DS and DNSKEY, up the chain of trust.

    Insecure:

    • DNS determines the domain has no dnssec enabled records present. 

    Bogus:

    • Incomplete, but present dnssec entries may fail verification.
    • Invalid records due to an expired key.
    • Missing record or key in the chain of trust.

    NXDOMAIN

    • No record found in DNS.

    A combination of the above record check and the verification results will determine "DANE Success | DANE Fail | DANE fallback to TLS."

    Eg: if there is no RRSIG sent for example.com’s MX record, the parent zone (.com) is checked to see whether example.com has a DNSKEY record, indicating that example.com should be signing its records. This validation continues up the chain of trust finishing with the root zone (.) key verification.is reached, and the root zone’s keys match what the ESA expects (hard-coded values on the ESA, which gets auto-updated based on RFC5011).

    DANE MANDATORY

    DANE MANDATORY

    Note: DANE OPPORTUNISTIC DOES NOT BEHAVE LIKE TLS PREFERRED. The ACTION portion of the below chart results DANE FAIL, will not deliver for either Mandatory or Opportunistic. The messages will remain in the delivery queue until the timer expires, then delivery terminates.

    DANE OPPORTUNISTIC

    DANE OPPORTUNISTIC

    Enable DANE on Multiple Appliance Environment

    The following figure illustrates the workflow when you enable DANE in a multiple appliance environment.

    If the environment has multiple layers of ESA appliances, one for scanning and another for delivering messages Ensure DANE only gets configured on the appliance that directly connects to the outside destinations.

    Multi-ESA Design. DANE configured on the Delivery ESA

    Managing Multiple DNS Resolvers

    If an ESA has multiple DNS resolvers configured, a few that support DNSSEC a few that do not support DNSSEC, Cisco recommends configuring the DNSSEC capable resolvers with a higher priority (Lower Numeric Value), to prevent inconsistencies.

    This prevents the Non-DNSSEC capable resolver to classify the destination domain supporting DANE as 'Bogus'.

    Managing Secondary DNS Server

    When the DNS resolver is not reachable, the DNS falls back to the secondary DNS Server. If you do not configure DNSSEC on the secondary DNS server, the MX Records for DANE capable destination domains are classified as ‘Bogus.’ This impacts the message delivery irrespective of the DANE settings (Opportunistic or Mandatory). Cisco recommends you to use a secondary DNSSEC capable resolver.

    Configuration

    Configure DANE for outbound mail flow.

    1. Webui Navigate to > Mail Policies > Destination Controls > Add Destination
    2. Complete the top portion of the profile to your preference.
    3. TLS Support: is required to be set to "TLS Preferred | Preferred - Verify | Required | Required - Verify| Required - Verify Hosted Domain."
    4. Once TLS Support has been enabled, DANE Support: the dropdown menu will become active.
    5. DANE Support: options include "None | Opportunistic | Mandatory.
    6. Once the DANE Support option has been completed, submit and commit changes.

    Destination Control Profile - DANE Verify

    Verify DANE Success

    Delivery Status

    Monitor the WebUI "Delivery Status" Report for any unintended build-up of destination domains, potentially due to DANE Failure.

    Perform this prior to enabling the service, then periodically for several days to ensure continued success.

    ESA WebUI > Monitor > Delivery Status > check the "Active Recipients" column.

    Mail Logs

    Default Mail Logs at informational level for log level.

    The mail logs show very subtle indicators for DANE successfully negotiated messages.

    The final TLS negotiation outbound will include a slightly modified output to include the domain at the end of the log entry.

    The log entry will include "TLS success protocol" followed by TLS version/cipher "for domain.com".

    The magic is in the "for":

    myesa.local> grep "TLS success.*for" mail_logs

    Tue Feb  5 13:20:03 2019 Info: DCID 2322371 TLS success protocol TLSv1.2 cipher DHE-RSA-AES256-GCM-SHA384 for karakun.com

    Mail Logs debug

    Custom Mail Logs at Debug Level will display complete DANE and dnssec lookups, negotiation expected, portions of the check which pass/fail and a success indicator.

    Note: Mail logs configured for Debug Level logging may consume excessive resources on an ESA depending on the system load and configuration.

    Mail logs configured for Debug Level logging may consume excessive resources on an ESA depending on the system load and configuration.

    Mail logs are usually NOT maintained at Debug Level for extended periods of time.

    The Debug Level logs may generate a tremendous volume of mail logs in a short period of time.

    A frequent practice is to create an additional log subscription for mail_logs_d and set the logging for DEBUG.

    The action prevents impact to the existing mail_logs and allows manipulation to the volume of logs maintained for the subscription.

    To control the volume of logs created, restrict the number of files to maintain to a smaller number such as 2-4 files.

    When the monitoring, trial period or troubleshooting has completed, disable the log.

    Mail logs set for debug level show very detailed DANE output:

    Success sample daneverify
    daneverify ietf.org

    SECURE MX record(mail.ietf.org) found for ietf.org
    SECURE A record (4.31.198.44) found for MX(mail.ietf.org) in ietf.org
    Connecting to 4.31.198.44 on port 25.
    Connected to 4.31.198.44 from interface 194.191.40.74.
    SECURE TLSA record found for MX(mail.ietf.org) in ietf.org
    Checking TLS connection.
    TLS connection established: protocol TLSv1.2, cipher DHE-RSA-AES256-GCM-SHA384.
    Certificate verification successful
    TLS connection succeeded ietf.org.
    DANE SUCCESS for ietf.org
    DANE verification completed.


    debug level mail logs during the above 'daneverify' exeuction.
    Sample output from the execution of the daneverify ietf.org will populate the dns lookups within the mail logs
    Mon Feb  4 20:08:47 2019 Debug: DNS query: Q('ietf.org', 'MX')
    Mon Feb  4 20:08:47 2019 Debug: DNS query: QN('ietf.org', 'MX', 'recursive_nameserver0.parent')
    Mon Feb  4 20:08:47 2019 Debug: DNS query: QIP  ('ietf.org','MX','194.191.40.84',60)
    Mon Feb  4 20:08:47 2019 Debug: DNS query: Q  ('ietf.org', 'MX', '194.191.40.84')
    Mon Feb  4 20:08:48 2019 Debug: DNSSEC Response data([(0, 'mail.ietf.org.')], secure, 0, 1800)
    Mon Feb  4 20:08:48 2019 Debug: DNS encache (ietf.org, MX, [(8496573380345476L, 0, 'SECURE', (0, 'mail.ietf.org'))])
    Mon Feb  4 20:08:48 2019 Debug: DNS query: Q('mail.ietf.org', 'A')
    Mon Feb  4 20:08:48 2019 Debug: DNS query: QN('mail.ietf.org', 'A', 'recursive_nameserver0.parent')
    Mon Feb  4 20:08:48 2019 Debug: DNS query: QIP  ('mail.ietf.org','A','194.191.40.84',60)
    Mon Feb  4 20:08:48 2019 Debug: DNS query: Q  ('mail.ietf.org', 'A', '194.191.40.84')
    Mon Feb  4 20:08:48 2019 Debug: DNSSEC Response data(['4.31.198.44'], secure, 0, 1800)
    Mon Feb  4 20:08:48 2019 Debug: DNS encache (mail.ietf.org, A, [(8496573380345476L, 0, 'SECURE', '4.31.198.44')])
    Mon Feb  4 20:08:48 2019 Debug: DNS query: Q('mail.ietf.org', 'AAAA')
    Mon Feb  4 20:08:48 2019 Debug: DNS query: QN('mail.ietf.org', 'AAAA', 'recursive_nameserver0.parent')
    Mon Feb  4 20:08:48 2019 Debug: DNS query: QIP  ('mail.ietf.org','AAAA','194.191.40.84',60)
    Mon Feb  4 20:08:48 2019 Debug: DNS query: Q  ('mail.ietf.org', 'AAAA', '194.191.40.84')
    Mon Feb  4 20:08:48 2019 Warning: Received an invalid DNSSEC Response: DNSSEC_Error('mail.ietf.org', 'AAAA', '194.191.40.84', 'DNSSEC Error for hostname mail.ietf.org (AAAA) while asking 194.191.40.84. Error was: Unsupported qtype') of qtype AAAA looking up mail.ietf.org
    Mon Feb  4 20:08:48 2019 Debug: DNS query: Q('mail.ietf.org', 'CNAME')
    Mon Feb  4 20:08:48 2019 Debug: DNS query: QN('mail.ietf.org', 'CNAME', 'recursive_nameserver0.parent')
    Mon Feb  4 20:08:48 2019 Debug: DNS query: QIP  ('mail.ietf.org','CNAME','194.191.40.83',60)
    Mon Feb  4 20:08:48 2019 Debug: DNS query: Q  ('mail.ietf.org', 'CNAME', '194.191.40.83')
    Mon Feb  4 20:08:48 2019 Debug: DNSSEC Response data([], , 0, 1800)
    Mon Feb  4 20:08:48 2019 Debug: Received NODATA for domain mail.ietf.org type CNAME
    Mon Feb  4 20:08:48 2019 Debug: No CNAME record(NoError) found for domain(mail.ietf.org)

    Mon Feb  4 20:08:49 2019 Debug: DNS query: Q('_25._tcp.mail.ietf.org', 'TLSA')
    Mon Feb  4 20:08:49 2019 Debug: DNS query: QN('_25._tcp.mail.ietf.org', 'TLSA', 'recursive_nameserver0.parent')
    Mon Feb  4 20:08:49 2019 Debug: DNS query: QIP  ('_25._tcp.mail.ietf.org','TLSA','194.191.40.83',60)
    Mon Feb  4 20:08:49 2019 Debug: DNS query: Q  ('_25._tcp.mail.ietf.org', 'TLSA', '194.191.40.83')
    Mon Feb  4 20:08:49 2019 Debug: DNSSEC Response data(['0301010c72ac70b745ac19998811b131d662c9ac69dbdbe7cb23e5b514b56664c5d3d6'], secure, 0, 1800)
    Mon Feb  4 20:08:49 2019 Debug: DNS encache (_25._tcp.mail.ietf.org, TLSA, [(8496577312207991L, 0, 'SECURE', '0301010c72ac70b745ac19998811b131d662c9ac69dbdbe7cb23e5b514b56664c5d3d6')])
    fail sample daneverify

    []> thinkbeyond.ch

    INSECURE MX record(thinkbeyond-ch.mail.protection.outlook.com) found for thinkbeyond.ch
    INSECURE MX record(thinkbeyond-ch.mail.protection.outlook.com) found. The command will still proceed.
    INSECURE A record (104.47.9.36) found for MX(thinkbeyond-ch.mail.protection.outlook.com) in thinkbeyond.ch
    Trying next A record (104.47.10.36) for MX(thinkbeyond-ch.mail.protection.outlook.com) in thinkbeyond.ch
    INSECURE A record (104.47.10.36) found for MX(thinkbeyond-ch.mail.protection.outlook.com) in thinkbeyond.ch
    DANE FAILED for thinkbeyond.ch
    DANE verification completed.

    mail_logs
    Sample output from the execution of he danverify thinkbeyond.ch will populate the dns lookups within the mail logs
    Mon Feb  4 20:15:52 2019 Debug: DNS query: Q('thinkbeyond.ch', 'MX')
    Mon Feb  4 20:15:52 2019 Debug: DNS query: QN('thinkbeyond.ch', 'MX', 'recursive_nameserver0.parent')
    Mon Feb  4 20:15:52 2019 Debug: DNS query: QIP  ('thinkbeyond.ch','MX','194.191.40.84',60)
    Mon Feb  4 20:15:52 2019 Debug: DNS query: Q  ('thinkbeyond.ch', 'MX', '194.191.40.84')
    Mon Feb  4 20:15:52 2019 Debug: DNSSEC Response data([(10, 'thinkbeyond-ch.mail.protection.outlook.com.')], insecure, 0, 3600)
    Mon Feb  4 20:15:52 2019 Debug: DNS encache (thinkbeyond.ch, MX, [(8502120882844461L, 0, 'INSECURE', (10, 'thinkbeyond-ch.mail.protection.outlook.com'))])
    Mon Feb  4 20:15:52 2019 Debug: DNS query: Q('thinkbeyond-ch.mail.protection.outlook.com', 'A')
    Mon Feb  4 20:15:52 2019 Debug: DNS query: QN('thinkbeyond-ch.mail.protection.outlook.com', 'A', 'recursive_nameserver0.parent')
    Mon Feb  4 20:15:52 2019 Debug: DNS query: QIP  ('thinkbeyond-ch.mail.protection.outlook.com','A','194.191.40.83',60)
    Mon Feb  4 20:15:52 2019 Debug: DNS query: Q  ('thinkbeyond-ch.mail.protection.outlook.com', 'A', '194.191.40.83')
    Mon Feb  4 20:15:52 2019 Debug: DNSSEC Response data(['104.47.9.36', '104.47.10.36'], insecure, 0, 10)
    Mon Feb  4 20:15:52 2019 Debug: DNS encache (thinkbeyond-ch.mail.protection.outlook.com, A, [(8497631700844461L, 0, 'INSECURE', '104.47.9.36'), (8497631700844461L, 0, 'INSECURE', '104.47.10.36')])
    Mon Feb  4 20:15:52 2019 Debug: DNS query: Q('thinkbeyond-ch.mail.protection.outlook.com', 'AAAA')
    Mon Feb  4 20:15:52 2019 Debug: DNS query: QN('thinkbeyond-ch.mail.protection.outlook.com', 'AAAA', 'recursive_nameserver0.parent')
    Mon Feb  4 20:15:52 2019 Debug: DNS query: QIP  ('thinkbeyond-ch.mail.protection.outlook.com','AAAA','194.191.40.84',60)
    Mon Feb  4 20:15:52 2019 Debug: DNS query: Q  ('thinkbeyond-ch.mail.protection.outlook.com', 'AAAA', '194.191.40.84')
    Mon Feb  4 20:15:52 2019 Debug: DNSSEC Response data([], , 0, 32768)
    Mon Feb  4 20:15:52 2019 Debug: Received NODATA for domain thinkbeyond-ch.mail.protection.outlook.com type AAAA
    Mon Feb  4 20:15:52 2019 Debug: DNS query: Q('thinkbeyond-ch.mail.protection.outlook.com', 'CNAME')
    Mon Feb  4 20:15:52 2019 Debug: DNS query: QN('thinkbeyond-ch.mail.protection.outlook.com', 'CNAME', 'recursive_nameserver0.parent')
    Mon Feb  4 20:15:52 2019 Debug: DNS query: QIP  ('thinkbeyond-ch.mail.protection.outlook.com','CNAME','194.191.40.83',60)
    Mon Feb  4 20:15:52 2019 Debug: DNS query: Q  ('thinkbeyond-ch.mail.protection.outlook.com', 'CNAME', '194.191.40.83')
    Mon Feb  4 20:15:53 2019 Warning: Received an invalid DNS Response: SERVER FAILED to IP 194.191.40.83 looking up thinkbeyond-ch.mail.protection.outlook.com
    Mon Feb  4 20:15:53 2019 Debug: DNS query: QIP  ('thinkbeyond-ch.mail.protection.outlook.com','CNAME','194.191.40.84',60)
    Mon Feb  4 20:15:53 2019 Debug: DNS query: Q  ('thinkbeyond-ch.mail.protection.outlook.com', 'CNAME', '194.191.40.84')
    Mon Feb  4 20:15:54 2019 Warning: Received an invalid DNS Response: SERVER FAILED to IP 194.191.40.84 looking up thinkbeyond-ch.mail.protection.outlook.com
    Mon Feb  4 20:15:54 2019 Debug: No CNAME record() found for domain(thinkbeyond-ch.mail.protection.outlook.com)

    Related Information

    Revision History

    Revision Publish Date Comments
    1.0
    26-Aug-2019
    Initial Release
    TAC Authored

    Contributed by Cisco Engineers

    • Guru Narala
      Cisco TAC Engineer
    • Chris Arellano
      Cisco Tac Engineer

    Was this Document Helpful?

    FeedbackFeedback

    Contact Cisco

    This Document Applies to These Products