En VPN-domänregel går sönder när ett CDN byter sina adresser

Du kopierar adressen från en uppslagning till din routingregel, webbplatsen fungerar och en vecka senare gör den det inte. Inget i regeln har ändrats. Tjänsten flyttade till en annan kantadress, klienten löste upp ett annat värdnamn, eller sessionen bytte till IPv6. Beslutet framför dig är om en namnebaserad regel eller ett explicit intervall är rätt verktyg för den här tjänsten, och tre villkor avgör det. Det följande skiljer namnet från adressen, eftersom bara en av dem är stabil.

Varför en uppslagning inte är en förteckning

Ett innehållsleveransnätverk svarar med en adress som valts för resolvern, regionen och ögonblicket. Fråga två gånger från olika nätverk och du kan få olika svar. Fråga en gång och behandla svaret som tjänstens adresslista, och regeln du skriver är en ögonblicksbild, inte en regel. Det är hela problemet med att behandla ett DNS-svar som konfiguration.

Det finns en andra lucka. Ett synligt värdnamn täcker sällan hela applikationen, eftersom inloggning, media och API-trafik ofta använder separata namn. En regel byggd från värdnamnet i adressfältet kan täcka sidan och missa videon, vilket läses som ett delvis fel och inte som ett routingfel.

Den tredje luckan är adressfamiljen. En regel bara för v4 säger ingenting om AAAA-posten som klienten kanske föredrar.

Tre villkor som avgör domänregel eller intervall

För det första, publicerar tjänsten en stabil uppsättning prefix som du kan äga och dokumentera? Om ja, är explicita intervall ärliga och billiga. Om inte, är en domänregel den enda mekanismen som kan följa tjänsten.

För det andra, uppdateras din klients domänmekanism? En regel som löses en gång vid anslutning och aldrig igen är en ögonblicksbild med bättre varumärke. För det tredje, täcker mekanismen subdomäner och båda adressfamiljerna, eller bara namnen du skrev?

Svara på de tre och valet är oftast självklart. Gissningar ger en regel som fungerar i test och misslyckas i produktion.

Testa en session, inte en sida

Ladda sidan och utför sedan operationen som betyder något: logga in, starta uppspelning, ladda upp en fil. Var och en av dem kan nå en annan värd, och den som misslyckas är den din regel missade.

Lista vad sessionen faktiskt kontaktar i stället för vad sidan visar:

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

Håll resolvern synlig under jämförelsen, eftersom en regel som fungerar från en resolver och misslyckas från en annan berättar om CDN:ets svar, inte om tunneln. En kort TTL betyder också att svaret du noterade har en hållbarhetstid.

Vad varje mekanism faktiskt täcker

De två mekanismerna ser utbytbara ut på en inställningssida och beter sig olika under ytan.

En kärnadressrutt matchar prefix. Den har ingen aning om vad ett värdnamn är, så den kan inte följa en tjänst som byter adresser. En domänregel löser namn och routar resultatet; den följer tjänsten men beror på resolvern, uppdateringsbeteendet och klientens hantering av subdomäner, så en regel som följer namn måste testas med den resolver som klienten faktiskt använder.

Ingen av dem är en övermängd av den andra, och därför skapar blandning utan en anteckning förvirring senare.

Kontrollera igen när tjänsten ändras

Efter en klientuppdatering eller en tjänsteändring, kör samma sessionstest igen. En adresslista som tidigare fungerade är bevis om den perioden, inte en permanent förteckning över tjänstens infrastruktur.

Skriv ned vilken mekanism som täcker vilket värdnamn, och datumet du senast verifierade det.

Den anteckningen är skillnaden mellan en regel du kan försvara och en regel som ingen vågar röra. Om tjänsten publicerar sin egen prefixlista, använd den och ange datumet. Om inte, säg det, och håll domänregeln med sitt uppdateringsbeteende skrivet bredvid.