In VPN-domeinregel brekt as in CDN syn adressen feroaret

Jo kopiearje it adres út ien syktocht yn jo rûte-regel, de side wurket, en in wike letter net mear. Der is neat oan de regel feroare. De tsjinst is nei in oar râne-adres ferhuze, de klant hat in oare hostnamme oplost, of de sesje is oergongen nei IPv6. De beslissing foar jo is oft in namme-basearre regel of in eksplisyt berik it goede ynstrumint foar dizze tsjinst is, en trije betingsten bepale dat. Wat folget skiedt de namme fan it adres, om't mar ien fan beide stabyl is.

Wêrom ien syktocht gjin ynventaris is

In ynhâldsleveringsnetwurk antwurdet mei in adres dat keazen is foar de oplosser, de regio en it momint. Freegje twa kear út ferskate netwurken en jo kinne ferskate antwurden krije. Freegje ien kear en behannelje it antwurd as de adreslist fan de tsjinst, en de regel dy't jo skriuwe is in momintopname, net in regel. Dat is it hiele probleem mei it behanneljen fan in DNS-antwurd as konfiguraasje.

Der is in twadde gat. Ien sichtbere hostnamme dekt selden de hiele applikaasje, om't oanmelding, media en API-ferkear faak aparte nammen brûke. In regel boud út de hostnamme fan de adresbalke kin de side dekke en de fideo misse, wat lêzen wurdt as in dielútfal, net as in rûteflater.

It tredde gat is de adresfamylje. In regel allinnich foar v4 seit neat oer de AAAA-opname dy't de klant miskien leaver hat.

Trije betingsten dy't domeinregel of berikken bepale

Earst, publisearret de tsjinst in stabile set foarheaksels dy't jo besitte en dokumintearje kinne? As dat sa is, binne eksplisite berikken earlik en goedkeap. As dat net sa is, is in domeinregel it iennige meganisme dat de tsjinst folgje kin.

Twadde, fernijt it domeinmeganisme fan jo klant? In regel dy't ien kear by ferbining oplost en nea wer is in momintopname mei bettere branding. Tredde, dekt it meganisme subdomeinen en beide adresfamyljes, of allinnich de nammen dy't jo typt hawwe?

Beäntwurdzje dy trije en de kar is meastentiids dúdlik. Rieden jout in regel dy't yn testen wurket en yn produksje mislearret.

Test in sesje, net in side

Laad de side, doch dan de bewurking dy't der ta docht: oanmelde, ôfspylje begjinne, in bestân uploade. Elk fan dy kin in oare host berikke, en dejinge dy't mislearret is dejinge dy't jo regel mist hat.

List op wat de sesje echt kontaktet, ynstee fan wat de side toant:

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

Hâld de oplosser sichtber by de ferliking, om't in regel dy't fan ien oplosser wurket en fan in oare mislearret jo oer it antwurd fan de CDN fertelt, net oer de tunnel. In koarte TTL betsjut ek dat it antwurd dat jo fêstlein hawwe in hâldberensdatum hat.

Wat elk meganisme eins dekt

De twa meganismen lykje yn in ynstellingsside útwikselber en gedrage har derûnder oars.

In kernel-adresrûte past foarheaksels oan. It hat gjin idee wat in hostnamme is, dus it kin in tsjinst dy't adressen feroaret net folgje. In domeinregel lost nammen op en rûtelet it resultaat; it folget de tsjinst, mar hinget ôf fan de oplosser, it fernijingsgedrach en de behanneling fan subdomeinen troch de klant, dus in regel dy't nammen folget moat teste wurde mei de oplosser dy't de klant echt brûkt.

Gjinien is in oermêns fan de oare, en dêrom soarget it mingjen sûnder notysje letter foar betizing.

Kontrolearje opnij nei't de tsjinst feroare is

Nei in klantfernijing of in tsjinstferoaring, fier deselde sesjetest opnij út. In adreslist dy't earder wurke is bewiis oer dy perioade, net in permaninte ynventaris fan de ynfrastruktuer fan de tsjinst.

Skriuw op hokker meganisme hokker hostnamme dekt, en de datum fan jo lêste kontrôle.

Dy notysje is it ferskil tusken in regel dy't jo ferdigenje kinne en in regel dy't nimmen oan doar te kommen. As de tsjinst syn eigen foarheaksel-list publisearret, brûk dy en neam de datum. As net, sis dat, en hâld de domeinregel mei syn fernijingsgedrach derby skreaun.