DNS je dio kritične putanje pri svakom učitavanju stranice, ali arhitekturu je lakše razumjeti kada se jasno odvoje uloge. Stub razrješivač na prijenosnom računalu ili telefonu šalje upit rekurzivnom razrješivaču. Taj razrješivač slijedi delegiranja od korijena, TLD-ova i mjerodavnih poslužitelja, zatim predmemorira odgovor. Mjerodavni poslužitelj imena ne pretražuje internet u potrazi za odgovorom; on objavljuje zapise za svoju zonu. Negativno predmemoriranje također može pamtiti da naziv ne postoji, što objašnjava zašto dodavanje zapisa možda neće odmah postati vidljivo.
TTL je odluka o upravljanju predmemorijom, a ne prekidač brzine. TTL od 300 sekundi može pomoći tijekom planirane migracije, ali povećava broj upita za osvježavanje i skraćuje razdoblje u kojem razrješivači mogu posluživati odgovor iz predmemorije. TTL od 3600 sekundi smanjuje uzvodne upite za stabilne zapise. Smanjite TTL barem jedan interval predmemorije prije planiranog premještanja, pričekajte da stara vrijednost istekne, promijenite zapis i vratite dulju vrijednost nakon provjere. Ne očekujte da će niži TTL ukloniti iz predmemorije odgovore spremljene uz prethodnu vrijednost.
U praksi, sloj razrješivača može izgledati ovako:
client stub -> office/VPC resolver -> shared recursive resolver -> authoritative DNSPrvi sloj držite u blizini klijenata radi ponovne upotrebe veza i lokalne politike. Koristite zajednički rekurzivni sloj za predmemoriranje, DNSSEC validaciju, bilježenje i uzvodni failover. Mjerite omjer pogotka predmemorije, latenciju upita po razrješivaču, stopu SERVFAIL-a i prekide zbog isteka vremena zasebno. Brza mjerodavna usluga ne može nadoknaditi pogrešno konfigurirani lokalni razrješivač koji ponavlja upite preko spore ili nedostupne putanje.
Na mjerodavnom i CDN rubu, anycast oglašava istu adresu usluge s više mrežnih lokacija. Usmjeravanje obično šalje upit obližnjem mrežnom čvorištu, dok se oglašavanje neispravnog čvorišta može povući. Anycast ne jamči geografski najbliži poslužitelj, a promjene ruta mogu premjestiti razrješivač između lokacija. EDNS Client Subnet (RFC 7871) daje mjerodavnoj usluzi skraćeni dio klijentske podmreže kako bi mogla odabrati regionalnu adresu. To može poboljšati CDN smještaj, ali smanjuje privatnost i fragmentira zajedničke predmemorije. Omogućite ga samo kada mjerenja pokažu stvarnu korist za usmjeravanje prometa.
CNAME flattening razrješava pseudonim na vrhu zone i vraća konačnu adresu, čime korijenski zapis ostaje kompatibilan s davateljima koji zahtijevaju alias. Provjerite ponašanje osvježavanja davatelja prije oslanjanja na njega za brzi failover. Za prijenos koji štiti privatnost, DoT koristi TLS na portu 853, DoH prenosi DNS preko HTTPS-a, a DoQ koristi QUIC. Ti protokoli štite promet između klijentskog i rekurzivnog razrješivača, ali ne čine mjerodavni zapis privatnim. DoQ može smanjiti head-of-line blocking na prijenosnom sloju, no kriptirana veza s razrješivačem ipak zahtijeva razumno postavljene vremenske pragove i pouzdan prijelaz na rezervnu opciju.
Izvori: RFC 8499, RFC 2308, RFC 7871, Cloudflare CNAME flattening, RFC 7858, RFC 8484 i RFC 9250.
Povezana područja
Savjetodavna područja vezana uz ovu temu
Ova su područja rada usklađena s temom članka i daju čišći prijelaz od edukativnog sadržaja do konkretne implementacije.
Nastavite čitati
Povezani članci
Prvo po zajedničkim kategorijama, a zatim po najjačem preklapanju u tagovima.
