propgate / course

Anyone can verify a domain in two weeks. The last 20% takes two years.

Every product that asks a customer to add DNS records builds the same system, and most of them build the easy 80%: query the name, compare the string, show a green tick. Then the tickets start. The record is there but the provider appended the zone name to it. The tick is green because a wildcard answers every query. The customer deleted the key on Tuesday and nobody noticed until Friday.

This course is about that 20%. It works through a real implementation — 78 diagnosis codes, 74 catalogued requirements across 14 RFCs, of which 5 are openly recorded as not done — and every query you run goes to 35 real zones on a real authoritative server, because a mocked resolver agrees with whatever you believed when you wrote the mock.

Start — The last 20%

Nine units

  1. 00The last 20%Why every SaaS that asks customers to edit DNS rebuilds the same system badly, and why 'record not found' is the bug rather than the answer.
  2. 01DNS does not tell the truthThe failure modes that make naive verification wrong: NODATA against NXDOMAIN, negative caching, wildcard synthesis, flattened aliases, appended zone names, split strings, and truncation.
  3. 02A resolver with no dependenciesBuilding a resolver from Node built-ins: the wire format byte by byte, name compression, EDNS0, following a delegation from the root, and why a nameserver's port is a field.
  4. 03SPF the way an MTA reads itRFC 7208 as a program rather than a pattern: the ten-lookup limit and exactly where it is counted, the two-void limit, macro expansion, and the difference between redirect and all.
  5. 04Keys, policies, and treesThe other four evaluators: DKIM key parsing and what an empty p= means, DMARC at the organizational domain, the null MX, and climbing the CAA tree.
  6. 05Asking the right questionWhy a checker needs to be told what a domain is for: profiles as shape, expectations as values, four verdicts instead of a boolean, and why a skipped check is not a passing one.
  7. 06Believing a failureThe highest-stakes correctness property in the product: consensus across vantage points, consecutive-failure thresholds, and a schedule that adapts to what state a domain is in.
  8. 07The parts that cost moneyWhere the architecture and the invoice are the same decision: storing changes instead of observations, adaptive scheduling, and why a polling loop can never be serverless.
  9. 08Publishing a contractWhat it takes to publish a diagnosis code as an API: coverage guards, an RFC ledger with no percentage in it, signed webhooks with a delivery ledger, and the parts deliberately left unbuilt.

What you need

A terminal, Docker, and dig. The units read fine without them; the exercises do not work without them, and the exercises are the part that sticks.

How it is gated

Each unit ends in questions, and every one has to be right before the next unit opens. No score, no percentage, unlimited retries. If you already know a unit, there is a button that says so.

Where progress goes

Your browser, under one key, sent nowhere. There is nothing to sign up for. Export it if you care about keeping it.