Har afstemt en DNS‑zone med 20 poster deklarativt

Situation. Virksomhedens DNS havde omkring tyve poster fordelt på et website, et git‑underdomæne, to personlige omdirigeringer, mailrouting gennem en hostet postkasseudbyder, et afsenderdomæne til transaktionsmails og autentificeringsposterne for begge. Det hele lå i en udbyders webkonsol, så den aktuelle tilstand var det, den seneste person, der klikkede, havde efterladt.

Opgave. Zonen skulle gøres til en erklæring i repositoryet, med en måde at sammenligne den erklæring med det, udbyderen reelt svarer med.

Handling. Zonen er skrevet som data — aktive poster, applikationsposter, transportpolitikposter og en særskilt liste over poster, der afventer fjernelse, hvilket er den ærlige måde at registrere en sletning, der endnu ikke er sket. Ét play afstemmer den mod udbyderens API. To yderligere indgange ligger bag tags, der eksplicit skal vælges til: en gennemgang, der rapporterer forskellen uden at ændre noget, og en eksport, der skriver zonen ud i det standardiserede zonefilformat, så den kan læses af noget, der ikke er dette repository. Den mest interessante beslutning var en omvending. En løsning, der sendte de to websites gennem udbyderens indholdsnetværk, blev bygget, virkede og blev derefter slået fra igen — for den koster netop den sætning, som virksomhedens privatlivsside handler om. Med en proxy foran håndterer en anden virksomhed hver besøgendes adresse og hver URL, den besøgende beder om, før vi gør, og under deres politik i stedet for vores. For en forretning, der skiller sig ud ved at love, at ingen kigger med, er det en dårligere byttehandel end de angreb, den beskytter imod.

Resultat. Zonen er versioneret, kan sammenlignes og kan eksporteres, og den ene beslutning, der gik imod det oplagte standardvalg, er skrevet ned med sin begrundelse, så ingen tager sagen op igen ved et uheld. Gennemgangen er den del, der bruges mest, for man vil oftere kende forskellen end lukke den.