VPN-i domeenireegel läheb katki, kui CDN oma aadresse muudab

Kopeerid aadressi ühest päringust oma marsruutimisreeglisse, sait töötab ja nädal hiljem enam mitte. Reeglis ei muutunud midagi. Teenus kolis teisele servaaadressile, klient lahendas teise hostinime või sessioon läks üle IPv6-le. Sinu ees olev otsus on, kas nimepõhine reegel või selgesõnaline vahemik on selle teenuse jaoks õige vahend, ja kolm tingimust otsustavad selle. Järgnev eraldab nime aadressist, sest ainult üks neist on stabiilne.

Miks üks päring ei ole inventuur

Sisu tarnimise võrk vastab aadressiga, mis on valitud lahendaja, piirkonna ja hetke jaoks. Küsi kaks korda erinevatest võrkudest ja võid saada erinevaid vastuseid. Küsi üks kord ja käsitle vastust teenuse aadressiloendina, ja reegel, mille kirjutad, on hetktõmmis, mitte reegel. See on kogu probleem DNS-vastuse käsitlemisel konfiguratsioonina.

On teine lünk. Üks nähtav hostinimi katab harva kogu rakenduse, sest sisselogimine, meedia ja API-liiklus kasutavad sageli eraldi nimesid. Aadressiriba hostinimest ehitatud reegel võib katta lehe ja jätta video vahele, mida loetakse osaliseks tõrkeks, mitte marsruutimisveaks.

Kolmas lünk on aadresside perekond. Ainult v4 jaoks mõeldud reegel ei ütle midagi AAAA-kirje kohta, mida klient võib eelistada.

Kolm tingimust, mis otsustavad domeenireegli või vahemikud

Esiteks, kas teenus avaldab stabiilse prefiksite komplekti, mille saad omada ja dokumenteerida? Kui jah, on selgesõnalised vahemikud ausad ja odavad. Kui ei, on domeenireegel ainus mehhanism, mis suudab teenust järgida.

Teiseks, kas sinu kliendi domeenimehhanism värskendub? Reegel, mis lahendatakse üks kord ühendamisel ja mitte kunagi hiljem, on parema brändinguga hetktõmmis. Kolmandaks, kas mehhanism katab alamdomeenid ja mõlemad aadresside perekonnad või ainult nimed, mille sisestasid?

Vasta neile kolmele ja valik on tavaliselt ilmne. Oletamine annab reegli, mis töötab testimisel ja ebaõnnestub tootmises.

Testi sessiooni, mitte lehte

Laadi leht ja soorita seejärel oluline toiming: logi sisse, alusta esitamist, laadi fail üles. Igaüks neist võib jõuda erinevasse hosti, ja see, mis ebaõnnestub, on see, mille sinu reegel vahele jättis.

Loetle, millega sessioon tegelikult ühendust võtab, mitte mida leht kuvab:

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

Hoia lahendaja võrdluse ajal nähtav, sest reegel, mis töötab ühest lahendajast ja ebaõnnestub teisest, räägib sulle CDN-i vastusest, mitte tunnelist. Lühike TTL tähendab ka seda, et salvestatud vastusel on säilivusaeg.

Mida iga mehhanism tegelikult katab

Kaks mehhanismi näivad seadete lehel vahetatavad ja käituvad seestpoolt erinevalt.

Kerneli aadressimarsruut sobib prefikseid. Sellel pole aimugi, mis on hostinimi, seega ei saa see järgida teenust, mis aadresse muudab. Domeenireegel lahendab nimesid ja marsruudib tulemuse; see järgib teenust, kuid sõltub lahendajast, värskenduskäitumisest ja kliendi alamdomeenide käsitlemisest, seega tuleb nimesid järgivat reeglit testida lahendajaga, mida klient tegelikult kasutab.

Kumbki ei ole teise ülemhulk, mistõttu nende segamine ilma märkmeta tekitab hiljem segadust.

Kontrolli uuesti, kui teenus muutub

Pärast kliendi uuendust või teenuse muutust käivita sama sessioonitest uuesti. Varem töötanud aadressiloend on tõend selle perioodi kohta, mitte teenuse infrastruktuuri püsiv inventuur.

Kirjuta üles, milline mehhanism katab millist hostinime, ja viimase kontrolli kuupäev.

See märge on vahe reeglil, mida saad kaitsta, ja reeglil, mida keegi ei julge puutuda. Kui teenus avaldab oma prefiksiloendi, kasuta seda ja viita kuupäevale. Kui ei, ütle seda ja hoia domeenireegel koos selle värskenduskäitumisega kõrval kirjas.