What can we learn from obvious mistakes in DNS configurations? For near 20 years, I have been reviewing and auditing DNS configurations and zone files for numerous customers and students. I added many DNS diagnostics to and extended test cases for the reference implementation to DNS, participated in development of a new iterative resolver and authoritative server, and designed and ran an portable system resource and performance suite analyzing five different DNS server implementations on 19 different architecture, operating system, and compiler combinations. I have automated DNS and DNSSEC research for years.
Over several years, we developed an extensive audit suite analyzing over 90 configuration choices based on best practices, IETF/RFC requirements and guidelines, government mandates, registry requirements, and more, including for TCP and IPv6. (As far as we know, it is the most comprehensive DNS test suite.) These checks are ran against thousands of domains owned by the US government, Fortune 500 companies, and S&P Global 100 Banks. We have detected and documented many anomalies, such as expired or soon to expire DNSSEC signatures, domains with AAAA records but no IPv6 servers, non-recommended DNSSEC algorithms, NS targets that don't have addresses — and other lameness, no TCP nameservers, stale data from different secondaries, dangling DNS targets, and more.
Often we see the same problems again and again. This article focuses on two example types due to technical mistakes caused with a missing trailing dot in zone files and for a trailing period appended when not meant to (for some nameservers). This article doesn't give percentages versus valid or correct equivalents of the hundreds to thousands of mistakes we have recorded (which are also via domains in recent Tranco one million top websites lists), but simply shares a few examples.
In research this past year, we have detected around 2500 examples of unknown (NXDOMAIN) names that appear to have been caused by neglecting to include a period at the end of a name in a DNS zone file configuration. The 1987 Internet Standard, RFC 1035 DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION (5.1) says
"Domain names which do not end in a dot are called relative; the actual domain name is the concatenation of the relative part with an origin specified ...And the 1996 Informational RFC 1912 Common DNS Operational and Configuration Errors (3.2) highlights this common misconfiguration:
"If you don't put a `.' at the end of an FQDN, ... then the nameserver will append $ORIGIN to the name."
Our testing detects this in some cases, as often a repeated domain implies that the source zone file didn't have the name ending with a trailing period so the zone name gets appended. Additional non-automated checks use public suffix lists and ICANN domain lists to find other possible mistakes. This may result in many false-positives due to several new generic top-level domains match against normal hostname labels. Verifying NXDOMAINs for these helps narrow this down.
Here are few of our many, many detected examples. We didn't verify all of these, but we do have some commentary below.
SOA dns.eastbay.com.footlocker.com. dns_info.eastbay.com. 2016063151 3600 3600 1209600 86400Maybe the SOA MNAME was taken from the eastbay.com DNS and used for this zone but a trailing period was forgotten.
SOA ns3.level3.net. dnsteam.level3.com.aksteel.com 2019093000 86400 3600 604800 300
SOA ns3.ajgco.com. dns_admins.ajg.com.smartbizsavings.com. 2020042301 10800 3600 604800 900
SOA dns101.comcast.net. hostmaster.comcast.com.watchable.com. 112 7200 900 1209600 7200
SOA hpcwb2p.shinhan.com.shinhanglobal.com. root.shinhan.com.shinhanglobal.com. 2019053001 1800 3600 604800 600Two examples in this SOA record
MX 10 4next.net.4next.net.
MX 100 ms63743316.msv1.invalid.outlook.com.flysaa.com.
MX 0 aaspmx.l.google.com.l.economycandy.com.More than just a missing period, but maybe a copy and paste mistake.
MX 10 agromax.pro.agromax.pro.
(This is just a small example of thousands and doesn't include SRV and NS examples too.)
If forgetting to add the final period in a name causes naming problems, the opposite of this can be shown to also cause problems. In particular, the origin or zone name was meant to be appended to the name, but a trailing dot was specifically added to the original zone file which finalized the name.
MX 10 mail1. MX 20 mail2.
MX 10 mail. MX 20 mail2.
MX 10 m1. MX 20 m2.
SOA ns1. root.photoinf.com.photoinf.com. 1179370362 10800 3600 604800 38400This example appears to have both mistakes: added period and missing period.
SOA ns1. admin. 2013080752 1200 600 1209600 3600 NS ns1.Both SOA and NS records.
MX 35 mail5.bancoripley.
We found many more of those too, but, at least for SOA, they are hard to know if are on purpose or not. We looked at a few to see if corresponding records were there that maybe made sense.
Upcoming articles will share examples of non-technical typing, spelling, copy-and-pasting, and other typographical mistakes; and insane values and garbage inserted into DNS due to likely lack of knowledge or missing testing.
Note we frequently try to contact organizations about their DNS problems like these. Often SOA responsible person (RNAME) emails don't work, the organizations may not have other easily-found contact methods, or may not respond to Twitter direct (and public) messages, LinkedIn correspondence, or other communication attempts. For security issues, we also have tried using third-party companies that assist with disclosing issues to companies. It is likely that "someone" sees the report and doesn't understand it and doesn't handle it.
Gab
Twitter