DEV Community: Mike Pultz

TLS Is Easy to Enable and Hard to Get Right

Mike Pultz — Wed, 27 May 2026 16:15:34 +0000

Enabling TLS is a solved problem. Get a certificate from Let's Encrypt, point your server at it, done. What's not solved is the configuration that comes after: cipher suites, protocol versions, session settings, OCSP stapling. The decisions that determine whether your TLS implementation is actually secure, or just technically present.

The problem is that a misconfigured TLS setup looks identical to a correct one. Both show the padlock. Both say HTTPS. The difference only surfaces when someone runs a scan, or when an auditor asks why you're still accepting TLS 1.1, or when a CVE lands and you're not sure if you're exposed.

Why it's hard

Every application handles TLS differently. The correct cipher string for Nginx is not the correct cipher string for Postfix. PostgreSQL's ssl_min_protocol_version setting doesn't exist in MySQL, which uses tls_version instead. RabbitMQ uses an Erlang term file. IIS uses registry keys. Kafka uses Java KeyStore files and properties that differ between brokers and clients.

The underlying security requirements are identical across all of them: TLS 1.2 minimum, ECDHE for key exchange, AEAD for encryption. But applying those requirements to a specific piece of software means learning its configuration model, finding documentation that reflects current best practices, and figuring out which version introduced the settings you need.

Most developers aren't TLS specialists. They're configuring TLS for a database or a message broker or a mail server that happens to be one component of a larger system, and they need a correct answer quickly, not a cryptography education.

The documentation gap

Vendor documentation tends toward completeness, not correctness. A reference page will show every available TLS option without telling you which combinations are safe. Example configurations show what's possible, not what's recommended. Defaults often favor compatibility over security, which in this context means accepting protocol versions that RFC 8996 deprecated in 2021 and cipher suites that haven't been recommended since before that.

AI assistants have the same problem at higher velocity: their training data includes every TLS guide ever written, including the outdated ones, and they'll confidently reproduce decade-old cipher strings without flagging that they've been superseded.

The result is that the most natural paths to a TLS configuration produce configs that work but may not be secure.

What GoodTLS does

GoodTLS is a configuration reference for 48 applications across 8 categories: web servers, databases, message brokers, mail servers, DNS resolvers, VPN software, and more. Each guide gives you the specific configuration for that application, based on current standards, with no deprecated options and no hedging.

The cipher suites are the same across every OpenSSL-based application on the site:

ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-CHACHA20-POLY1305
ECDHE-RSA-CHACHA20-POLY1305

Every suite uses ECDHE for forward secrecy. Every suite uses AEAD encryption. None use CBC mode. None use static RSA key exchange. The list is the same whether you're configuring Nginx, HAProxy, Postfix, or OpenVPN, because the security requirements are the same.

TLS 1.2 minimum, TLS 1.3 alongside it, everywhere. No exceptions for "legacy compatibility." There is no legacy client that justifies enabling a protocol deprecated three years ago.

Consistency across your stack

A typical production environment has TLS configured in a lot of places: web server at the edge, database, cache, message broker, mail server. Each configured at different times, by different people, from different sources. The result is usually a patchwork: Nginx hardened because someone ran an SSL Labs scan, PostgreSQL running with defaults, Redis with a cipher string from five years ago.

GoodTLS covers all of them from the same standard. If you use it as the reference for your stack, you get consistent security posture across every application, not because the syntax is the same, but because the underlying decisions are.

The attacks it prevents

These aren't hypothetical. The recommendations map directly to real vulnerabilities.

Excluding CBC ciphers eliminates the Lucky13 attack surface. Excluding 3DES closes Sweet32. Requiring ECDHE key exchange prevents ROBOT. Disabling TLS 1.0 and 1.1 rules out BEAST and POODLE. Excluding EXPORT ciphers removes FREAK and LOGJAM. Each item in the cipher list has a reason; each exclusion has a CVE behind it.

The goal is a configuration where the answer to "are you vulnerable to X" is no by construction, because the class of cipher or protocol that enables X isn't present.

Who it's for

Developers who need to configure TLS for an application they don't work with every day. Security engineers auditing configurations against a known baseline. Organizations writing internal TLS standards who want something they can link to.

goodtls.com — free, no account required.

DMARC Is Now a Proper Internet Standard: What Changed in RFC 9989/9990/9991

Mike Pultz — Fri, 22 May 2026 21:46:45 +0000

DMARC has been an Informational RFC since 2015. That changed this month.

RFC 9989 replaces RFC 7489 and elevates DMARC to Standards Track, reflecting over a decade of deployment experience and near-universal adoption across the email ecosystem. The spec was also split into three separate documents:

RFC 9989 — core DMARC protocol
RFC 9990 — aggregate reporting (RUA)
RFC 9991 — failure reporting (RUF)

Splitting them allows each component to evolve independently. Here's what changed.

The DNS Tree Walk Replaces the Public Suffix List

This is the most significant architectural change.

RFC 7489 used the Public Suffix List to determine organizational domain boundaries. To find the org domain for mail.example.co.uk, you'd look up co.uk in the PSL, then take one label to the left. It works, but the problems are real: external dependency, manual maintenance, potential staleness, no support for non-obvious namespace boundaries.

RFC 9989 introduces the DNS Tree Walk as the alternative. The algorithm walks up the DNS tree looking for _dmarc TXT records, starting from the sending domain and moving toward the root. It caps at eight queries to prevent DoS amplification.

For most domains this changes nothing operationally. For complex organizations with deep subdomain hierarchies, or operators running public suffix domains that want their own DMARC policies, it's a meaningful improvement.

The new psd tag lets a domain declare itself as a Public Suffix Domain, enabling DMARC policy coverage at that level.

New Tags

`t` — Test Mode

Replaces the behavioral role of pct. Where pct=0 meant "apply policy to 0% of failing messages," t=y explicitly signals that the policy is in test mode and shouldn't be enforced.

The distinction between "policy exists but is being staged" and "policy is active against a subset of traffic" is now unambiguous.

v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com

`np` — Non-Existent Subdomain Policy

Allows separate policy handling for subdomains that have no DNS records at all. Previously, sp applied to all subdomains. Now you can distinguish between legitimate configured subdomains (sp) and mail claiming to originate from subdomains that don't exist in DNS (np).

Non-existent subdomains sending mail are almost always spoofing, so np=reject is often the right default.

`psd` — Public Suffix Domain

Marks the domain as a Public Suffix Domain for the DNS Tree Walk algorithm.

Removed Tags

`pct` — Gone

Percentage-based partial enforcement has been removed. Use t=y for test mode instead.

`rf` — Report Format

Removed. Only AFRF format was ever widely implemented. The tag was vestigial.

`ri` — Report Interval

Removed. Aggregate reports are daily. The tag existed, receivers rarely honored it, and the spec now reflects reality.

Aggregate Reporting Changes (RFC 9990)

The aggregate reporting spec was extracted from RFC 7489 into its own document. The format remains XML with several refinements.

DKIM selector is now mandatory in reports. Previously optional, it's required for understanding which DKIM key configuration is producing results — which matters for key rotation debugging.

New discovery method field indicates whether the receiver used psl or treewalk to find the organizational domain. Useful for diagnosing alignment issues during the transition period.

Extension framework allows future XML schema additions within defined namespaces without breaking existing parsers.

The schema changes are backward-compatible. Well-formed RFC 7489 reports will still parse. If you're running your own DMARC report parser, the new fields are additive.

Failure Reporting Changes (RFC 9991)

The changes here are more significant for implementors.

Identity-Alignment is now a mandatory ARF header. Failure reports must include this field listing which authentication mechanisms failed to produce an aligned pass, or none if all passed. This was absent from the original spec, leading to inconsistent implementations.

Rate limiting is now required. RFC 9991 explicitly mandates that report generators implement rate limits. This closes a known gap: failure reports can be triggered by an attacker sending large volumes of spoofed mail, making an unrated reporting system a DoS amplification vector.

dmarc is now a formal ARF authentication failure type. The Authentication-Failure ARF header now includes dmarc as a valid type value alongside the existing dkim and spf types.

Privacy guidance is significantly expanded. The document adds detailed guidance on PII redaction, URI validation, and secure transport for failure reports. If you're forwarding RUF reports to a third-party reporting service, the privacy section of RFC 9991 is worth reading before you do.

What You Actually Need to Do

For most domain owners, nothing changes immediately. RFC 9989 is backward-compatible with RFC 7489 and your existing DMARC record continues to work.

The practical checklist:

Remove pct tags from your DMARC records. Receiver behavior around deprecated tags will vary as implementations update.
If you're using pct=0 for staged rollouts, move to t=y to signal test mode explicitly.
If you're operating mail infrastructure (MTAs, DMARC reporting tools, monitoring systems), the Identity-Alignment requirement in RFC 9991 and the psd/treewalk changes in RFC 9989 require implementation updates.
Public Suffix Domain operators should evaluate adding psd=y once receiver support is established.

The Standards Track designation matters for enterprise and government procurement environments where "Informational RFC" raised compliance questions. DMARC is now a proper internet standard, not a proposal.

We've Normalized AI Outages, and That Should Bother You

Mike Pultz — Sun, 17 May 2026 00:38:48 +0000

I've been writing software and running production infrastructure for over 20 years. I've been on call at 3am, written post-mortems, and had the kind of conversations with clients about downtime that you don't forget. The baseline expectation, baked into every product I've ever built or supported, is that reliability is non-negotiable. You don't ship something people depend on and then shrug when it falls over.

So it's strange to find myself in a world where the tools so many people depend on daily go down with a frequency that would have cost me client confidence ten years ago, and somehow nobody seems particularly bothered.

The Claude status page is showing another incident as I write this. It's not unusual. Anthropic, OpenAI, GitHub Copilot, Gemini, these services have outages constantly. Not rarely. Not occasionally. Constantly. Multiple times a week, sometimes daily. The status pages are almost always showing something yellow or red.

And the response from the industry, and from us as users, has been a collective shrug.

I get why. The technology is genuinely impressive and the productivity gains are real. We've built workflows around these tools and quietly adjusted our expectations to match what vendors actually deliver rather than what we'd normally demand. We've done it so smoothly that most people haven't noticed the adjustment.

But think about what we've actually accepted. If any other piece of critical infrastructure in your stack had this track record, you would have replaced it. Your database going down twice a week is not a beta-era quirk, it's a fire. Your payment processor "partially degraded" on a Monday afternoon is a crisis.

AI services? That's just Tuesday.

The thing that concerns me most is not the outages themselves. It's the normalization. When you stop expecting reliability from a system you depend on, you've made a quiet decision about your own standards. That decision has a way of spreading.

Twenty years of engineering taught me that reliability is a culture, not a feature. Right now, as an industry, we're not building it in, we're hoping nobody notices.

I Built a Free DNS & Network Tools Site - Here's What I Learned

Mike Pultz — Wed, 15 Apr 2026 16:31:30 +0000

For years I kept reaching for the same handful of online tools when debugging email deliverability issues, checking DNS propagation, or diagnosing network problems. Most of the popular ones are fine but ad-heavy, paywalled above basic usage, or just showing their age. So I did what developers do: I built my own and put it at mrdns.com.

It's free, no account required, and covers a fairly wide range of DNS, network, and email tools. Here's what's in it and some of the more interesting technical bits along the way.

What's in the toolbox

DNS

DNS Lookup is the core feature - query any record type (A, AAAA, MX, TXT, NS, SOA, CNAME, PTR, CAA, SRV, TLSA, HTTPS, SVCB, MTA-STS, BIMI, and more) against authoritative resolvers. Results include country flag icons for A/AAAA records using GeoLite2.

DNS Propagation Checker queries 8 global resolvers simultaneously and shows whether your change has propagated. This one was fun to build - more on that below.

DNSSEC Checker walks the chain of trust: checks for DS records, validates DNSKEY digests, and verifies RRSIG records aren't expired.

Whois / RDAP looks up domain and IP registration info. It tries RDAP first (the modern structured replacement for whois) using IANA bootstrap files to find the authoritative server, and falls back to the classic whois binary if needed.

Network

Ping and Traceroute stream results in real-time using Server-Sent Events. Each traceroute hop gets city-level geolocation and is plotted on a Leaflet map.

What is My IP detects your IPv4 and IPv6 addresses separately - by pointing the browser at two different subdomains, one with only an A record and one with only an AAAA record. It's a clean technique that forces the browser down each protocol path without any JS tricks.

Blacklist / RBL Check tests an IP or domain against 15+ DNSBL blocklists in parallel. IPv6 addresses get the nibble-reversed treatment before the query.

SSL Certificate Checker connects directly with stream_socket_client, captures the full chain, and reports expiry, SANs, key type/bits, and SHA-256 fingerprint.

HTTP Headers follows redirects manually (up to 5 hops), shows each hop's status and headers, and flags missing security headers.

Port Checker does a TCP connect with a short timeout and grabs the first 512 bytes of banner if the port is open. Useful for quickly checking whether a service is actually listening.

Email

Email tooling is where the site arguably has the most depth:

Email Health Check - runs SPF and DMARC together and gives a combined grade
SPF Checker - recursively expands includes and validates mechanisms
DMARC Checker - parses and validates every tag
DKIM Checker - looks up the public key, checks key size (warns below 2048 bits, errors below 1024)
Email Header Analyzer - paste in raw headers and it reconstructs the relay chain with per-hop delays, authentication results (SPF/DKIM/DMARC), and spam scores
MTA-STS Checker - validates the DNS record, fetches and parses the policy file, and cross-checks against MX records
BIMI Checker - validates the DNS record, fetches the SVG logo for preview, and verifies the VMC certificate against known CAs

There's also an SPF Generator and DMARC Generator for building records from scratch with a live preview.

A few interesting implementation details

DNS Propagation: hybrid DoH + UDP

Not all public resolvers support application/dns-json (the DoH JSON API). Cloudflare, Google, Alibaba, NextDNS, and DNS.SB do. Quad9, OpenDNS, and AdGuard don't - at least not from my server. So the propagation checker runs the DoH resolvers in parallel via curl_multi, then queries Quad9/OpenDNS/AdGuard over plain UDP with NetDNS2. You get 8 resolver results, most of them arriving together.

Real-time ping and traceroute with SSE

Both tools use Server-Sent Events - the server opens a process with proc_open, reads output line by line, and streams data: <json>\n\n to the browser. Nginx needs X-Accel-Buffering: no to prevent it from buffering the response. The client uses EventSource and appends rows to a table as they arrive. Traceroute geo-locates each hop and rebuilds the map polyline after each update.

IPv4/IPv6 dual-stack detection

To separately detect both protocol addresses in the browser, I use two subdomains: ipv4.mrdns.com has only an A record, and ipv6.mrdns.com has only an AAAA record. The browser is forced onto the correct protocol purely by DNS - there's no JS protocol negotiation involved. Each returns a tiny JSON blob {"ip":"<remote_addr>"} directly from nginx.

RDAP over legacy whois

The Whois tool uses RDAP as the primary backend. It fetches the IANA bootstrap JSON files (which map IP CIDRs and TLDs to authoritative RDAP servers), caches them for 24 hours, and queries the right server directly. The parsed response gives you structured data - registrar, registrant, status, nameservers, dates - rather than a blob of text to regex apart. The raw whois fallback is there for the edge cases RDAP doesn't cover yet.

Stack

Nothing exotic - PHP 8.5, Bootstrap 5.3, vanilla JS with no framework. NetDNS2 for DNS resolution, GuzzleHTTP for outbound HTTP, and MaxMind GeoLite2 databases for geolocation. Deployed on nginx + PHP-FPM.

Try it

Everything is at mrdns.com - free, no sign-up. If something's broken or you have a tool you'd like to see added, let me know in the comments.