En VPN-domæneregel holder op med at virke, når et CDN skifter adresser

Du kopierer adressen fra et opslag ind i din ruteringsregel, siden virker, og en uge senere gør den ikke. Intet ved reglen er ændret. Tjenesten er flyttet til en anden kantadresse, klienten har slået et andet værtsnavn op, eller sessionen er skiftet til IPv6. Beslutningen foran dig er, om en navnebaseret regel eller et eksplicit interval er det rigtige værktøj til denne tjeneste, og tre betingelser afgør det. Det følgende adskiller navnet fra adressen, fordi kun én af dem er stabil.

Hvorfor et opslag ikke er en fortegnelse

Et indholdsleveringsnetværk svarer med en adresse, der er valgt til resolveren, regionen og øjeblikket. Spørg to gange fra forskellige netværk, og du kan få forskellige svar. Spørg én gang og behandle svaret som tjenestens adresseliste, og den regel, du skriver, er et øjebliksbillede og ikke en regel. Det er hele problemet med at behandle et DNS-svar som konfiguration.

Der er et andet hul. Et synligt værtsnavn dækker sjældent hele applikationen, fordi login, medier og API-trafik ofte bruger separate navne. En regel bygget på værtsnavnet i adresselinjen kan dække siden og misse videoen, hvilket læses som en delvis fejl og ikke som en ruteringsfejl.

Det tredje hul er adressefamilien. En regel kun for v4 siger intet om den AAAA-post, som klienten måske foretrækker.

Tre betingelser, der afgør domæneregel eller intervaller

For det første, offentliggør tjenesten et stabilt sæt præfikser, som du kan eje og dokumentere? Hvis ja, er eksplicitte intervaller ærlige og billige. Hvis ikke, er en domæneregel den eneste mekanisme, der kan følge tjenesten.

For det andet, opdateres din klients domænemekanisme? En regel, der slår op én gang ved forbindelse og aldrig igen, er et øjebliksbillede med bedre branding. For det tredje, dækker mekanismen underdomæner og begge adressefamilier, eller kun de navne, du skrev?

Svar på de tre, og valget er som regel indlysende. Gætteri giver en regel, der virker i test og fejler i produktion.

Test en session, ikke en side

Indlæs siden, og udfør derefter den handling, der betyder noget: log ind, start afspilning, upload en fil. Hver af dem kan nå en anden vært, og den, der fejler, er den, din regel missede.

List op, hvad sessionen faktisk kontakter, i stedet for hvad siden viser:

dig +short example.com A
dig +short example.com AAAA
curl -sI https://example.com | head -5

Hold resolveren synlig under sammenligningen, fordi en regel, der virker fra én resolver og fejler fra en anden, fortæller dig om CDN'ets svar, ikke om tunnelen. En kort TTL betyder også, at det svar, du noterede, har en holdbarhedsdato.

Hvad hver mekanisme faktisk dækker

De to mekanismer ser udskiftelige ud på en indstillingsside og opfører sig forskelligt under overfladen.

En kernel-adruterute matcher præfikser. Den aner ikke, hvad et værtsnavn er, så den kan ikke følge en tjeneste, der skifter adresser. En domæneregel slår navne op og ruter resultatet; den følger tjenesten, men afhænger af resolveren, opdateringsadfærden og klientens håndtering af underdomæner, så en regel, der følger navne, skal testes med den resolver, klienten faktisk bruger.

Ingen af dem er en overmængde af den anden, og derfor skaber blanding uden en note forvirring senere.

Tjek igen, når tjenesten ændrer sig

Efter en klientopdatering eller en tjenesteændring skal du køre den samme sessionstest igen. En adresseliste, der tidligere virkede, er bevis om den periode, ikke en permanent fortegnelse over tjenestens infrastruktur.

Skriv ned, hvilken mekanisme der dækker hvilket værtsnavn, og datoen for din seneste verifikation.

Den note er forskellen mellem en regel, du kan forsvare, og en regel, som ingen tør røre. Hvis tjenesten offentliggør sin egen præfiksliste, brug den og angiv datoen. Hvis ikke, så sig det, og hold domæneregelen med dens opdateringsadfærd skrevet ved siden af.