Box is enabling DNSSEC on its DNS domains. This article covers how to test that Box DNSSEC validation is working properly through your enterprise’s local DNS servers using Box’s DNSSEC-enabled box-test.com domain and the Comcast-maintained dnssec-failed.org domain as an example domain with invalid DNSSEC.
Background
Some recommended reading on how DNSSEC works and other tooling can be found here:
The DNSSEC protocol requires clients to explicitly perform DNSSEC validation of domain records. Most operating systems and devices only support “stub resolvers” that don’t support direct DNSSEC validation and hand off DNS recursive lookup functions to an enterprise-maintained recursive DNS server, and most enterprises choosing to enable DNSSEC validation of domain records will implement validation at that first DNS server. This may be a BIND DNS server managed by your IT team, a DNS server managed by your cloud infrastructure providers, an enterprise security suite like Cisco Umbrella or Palo Alto Networks’s DNS Security, or public DNS servers like Cloudflare, OpenDNS, or Google Public DNS.
Troubleshooting approach
If you have overridden DNS for Box domains locally in your environment on your own domain name servers, there is risk that DNSSEC validation rejects your override domains. DNSSEC validation issues may show up as some clients not being able to lookup DNS records for Box domains. The general approach we’re recommending to diagnose inconsistent DNS resolution issues that arise after Box’s DNSSEC rollout are:
-
Use third party sites to verify DNSSEC keys are valid for a given problematic domain name, irrespective of your own enterprise configurations.
-
Check DNSSEC validation from your client or server instance using “delv”.
-
Check logs on any DNS servers where you have DNSSEC validation implemented.
Third Party DNSSEC validation sites
Box uses the following third party sites during DNSSEC enablement to verify cryptographic trusts at top-level domains updated by our domain registrar with keys generated by our external DNS provider.
Examples showing successful DNSSEC validation:
Examples finding issues:
Using the “delv” tool as provided by ISC BIND on Linux distributions
The “delv” command is available in most Linux distributions. On Red Hat distributions it is part of the “bind-utils” RPM. Ensuring DNSSEC validation is working properly from your Linux server instance through your DNS servers is quick and simple:
$ delv www.box-test.com
; fully validated
www.box-test.com. 300 IN A 107.152.24.234
www.box-test.com. 300 IN RRSIG A 13 3 300 20240105002433 20240103002433 44688 box-test.com. eZFkt/oTe0+xO55ti3BFR64ObkMG55wttbYYqOLjxAQnnfdWPXw/wUos y+ZH2fNaHYI7PgVYF4MzOQ20yP40GA==If for any reason that doesn’t return “fully validated”, you should get a message explaining why. If you request assistance from Box Support on a suspected DNSSEC problem, please provide information in your case similar to below:
$ delv dnssec-failed.org
;; validating dnssec-failed.org/DNSKEY: no valid signature found (DS)
;; no valid RRSIG resolving 'dnssec-failed.org/DNSKEY/IN': 169.254.169.254#53
;; broken trust chain resolving 'dnssec-failed.org/A/IN': 169.254.169.254#53
;; resolution failed: broken trust chain
Please note that there are additional useful tracing options for delv like “+multi +vtrace”. You can see examples at https://kb.isc.org/docs/aa-01152
Caveats
Please note that “delv” as provided on MacOS doesn’t work correctly without additional configuration. However, “delv” as provided via the “bind” package on Homebrew for MacOS does operate as expected above.
Checking DNSSEC validation failures in DNS server logs
Checking DNS server logs will be specific to your DNS server vendor. Some troubleshooting descriptions for BIND can be found at https://dnsinstitute.com/documentation/dnssec-guide/ch05s03.html#troubleshooting-logging-debug