VPN domeinu-araua apurtu egiten da CDN batek helbideak aldatzen dituenean
DNS erantzun bat argazki bat da, ez inbentario bat. Hiru baldintzek erabakitzen dute izenetan oinarritutako araua edo aurrizki esplizitua egokiak diren CDN baten gaineko zerbitzu baterako.
Konsulta batetik helbidea zure bideratze-araurara kopiatzen duzu, gunea funtzionatzen du, eta astebete geroago ez. Arauan ezer ez da aldatu. Zerbitzua beste ertz-helbide batera mugitu da, bezeroak beste ostalari-izen bat ebatzi du, edo saioa IPv6-ra aldatu da. Zure aurrean duzun erabakia da izenetan oinarritutako araua edo barruti esplizitua den tresna egokia zerbitzu honetarako, eta hiru baldintzek erabakitzen dute. Hurrengoak izena helbidetik bereizten du, bietako bat bakarrik delako egonkorra.
Zergatik ez den kontsulta bat inbentario bat
Eduki-banaketa sare batek ebazlearentzat, eskualdearentzat eta unerako hautatutako helbide batekin erantzuten du. Galdegin bitan sare desberdinetatik eta erantzun desberdinak jaso ditzakezu. Galdegin behin eta tratatu erantzuna zerbitzuaren helbide-zerrenda gisa, eta idazten duzun araua argazki bat izango da, ez arau bat. Hori da DNS erantzun bat konfigurazio gisa tratatzearen arazo osoa.
Bigarren hutsune bat dago. Ostalari-izen ikusgai batek gutxitan hartzen du aplikazio osoa, sarbidea, multimedia eta API trafikoak askotan izen bereiziak erabiltzen dituztelako. Helbide-barran agertzen den ostalari-izenetik eraikitako arau batek orria har dezake eta bideoa galdu, eta hori huts partzial gisa irakurtzen da, ez bideratze-errore gisa.
Hirugarren hutsunea helbide-familia da. v4-rako bakarrik den arau batek ez du ezer esaten bezeroak hobets dezakeen AAAA erregistroaz.
Domeinu-araua edo barrutiak erabakitzen dituzten hiru baldintza
Lehenik, argitaratzen al du zerbitzuak jabetu eta dokumentatu ditzakezun aurrizki-multzo egonkor bat? Bai bada, barruti esplizituak zintzoak eta merkeak dira. Ez bada, domeinu-araua da zerbitzuari jarrai diezaiokeen mekanismo bakarra.
Bigarrenik, zure bezeroaren domeinu-mekanismoa freskatzen al da? Konektatzean behin ebazten den eta inoiz gehiago ez den araua branding hobea duen argazki bat da. Hirugarrenik, mekanismoak azpidomeinuak eta bi helbide-familiak hartzen al ditu, edo idatzi dituzun izenak bakarrik?
Erantzun hiru horiei eta aukera normalean begi-bistakoa izaten da. Asmatzeak proban funtzionatzen duen eta ekoizpenean huts egiten duen arau bat sortzen du.
Proba ezazu saio bat, ez orri bat
Kargatu orria, eta gero egin garrantzitsua den eragiketa: hasi saioa, hasi erreprodukzioa, igo fitxategi bat. Horietako bakoitzak ostalari desberdin batera irits daiteke, eta huts egiten duena zure arauak galdu duena da.
Zerrendatu saioak benetan zer kontaktatzen duen, orriak zer erakusten duen ordez:
dig +short example.com A
dig +short example.com AAAA
curl -sI https://example.com | head -5Eduki ebazlea ikusgai konparaketan zehar, ebazle batetik funtzionatzen duen eta bestetik huts egiten duen arau batek CDN-ren erantzunaz hitz egiten dizulako, ez tunelaz. TTL labur batek ere esan nahi du erregistratu duzun erantzunak iraungitze-data duela.
Zer hartzen duen mekanismo bakoitzak benetan
Bi mekanismoak trukagarriak dirudite ezarpenen orri batean, eta barrutik desberdin jokatzen dute.
| Mechanism | What it matches | How it fails |
|---|---|---|
| Domain rule | Names the client resolves, then their addresses | Misses subdomains, or goes stale when refresh is off |
| Address route | A prefix you wrote down | Keeps matching an address the service has left |
Kernelaren helbide-bideak aurrizkiak parekatzen ditu. Ez du ideiarik zer den ostalari-izen bat, beraz ezin du helbideak aldatzen dituen zerbitzu bat jarraitu. Domeinu-arau batek izenak ebazten ditu eta emaitza bideratzen du; zerbitzuari jarraitzen dio, baina ebazlearen, freskatze-portaeraren eta bezeroak azpidomeinuekin duen tratamenduaren mende dago, beraz izenei jarraitzen dien araua bezeroak benetan erabiltzen duen ebazlearekin probatu behar da.
Bat ere ez da bestearen gainmultzo, eta horregatik haiek oharrik gabe nahasteak nahasmena sortzen du geroago.
Egiaztatu berriro zerbitzua aldatu ondoren
Bezeroaren eguneraketa edo zerbitzu-aldaketa baten ondoren, exekutatu berriro saio-proba bera. Lehen funtzionatzen zuen helbide-zerrenda garai hartako froga da, ez zerbitzuaren azpiegituraren inbentario iraunkorra.
Idatzi zein mekanismok hartzen duen zein ostalari-izen, eta azken egiaztapenaren data.
Ohar hori da defenda dezakezun arau baten eta inork ukitzera ausartzen ez den arau baten arteko aldea. Zerbitzuak bere aurrizki-zerrenda argitaratzen badu, erabili eta aipatu data. Ez badu, esan, eta eduki domeinu-araua bere freskatze-portaerarekin ondoan idatzita.