Când un rezolutor DNS caută un domeniu/zonă pentru un server de nume autorizat, preia toate cele 6 înregistrări și le parcurge?
Da, un server de nume recursiv adecvat ia în considerare toate serverele de nume și va încerca să interogă de fiecare dată mai târziu pe cel mai rapid.
Un algoritm brut este un fel de:
- de la o pornire la rece (fără cache), încercați-le pe toate aleatoriu, înregistrați cât de repede răspund (ar putea fi necesar să separați cazul UDP de cazul TCP acolo)
- după ceva timp, începeți să îl utilizați mai frecvent pe cel mai rapid pe baza răspunsurilor anterioare
- dar rețineți că trebuie să vă asigurați că nu rămâneți la infinit cu niciun server de nume dat, trebuie să încercați „din când în când” și pe celelalte. De ce? Deoarece topologia rețelei se poate modifica, precum și serverele de nume în sine.
ns3 ar putea fi cea mai rapidă astăzi pentru punctul tău de vedere specific, dar poate mâine va fi ns5 in schimb; așa că trebuie să-l folosești pe cel mai rapid, dar nu întotdeauna, doar pentru a te asigura că poți descoperi automat orice altul mai rapid decât cel pe care îl crezi că este cel mai rapid acum.
Dacă un resolver folosește primul server NS
Opreste aici. Recordurile vin într-un set, nu o listă. Adică, nu există o ordine inerentă în DNS. Bineînțeles că există o ordine în reprezentarea firului sau a afișajului, dar nu provine din protocol.
Seturile de recorduri sunt pungi: primești recorduri, fără comenzi. De fapt, puteți vedea că multe servere de nume, pentru exact aceeași interogare, dacă există mai multe înregistrări în răspuns, vor ordona înregistrările diferit de fiecare dată când interogați, exact pentru a combate sistemele client care ar lua în considerare doar primul articol și nesocotiți pe ceilalți.
când acel server de nume autorizat nu răspunde
Vezi algoritmul de mai sus: dacă unul dintre serverele de nume din NS set nu răspunde, puteți considera că este același cu „răspunsul cel mai lent de la oricare altul”. DNS-ul clientului are timeout-uri, așa că nu va aștepta infinit, dar marcați că acest server de nume este prea lent și va trece la altele.
Așa că la prima dată întâmpinați o penalizare pentru că sistemul trebuie să încerce să contacteze acel server de nume, să aștepte puțin (câteva secunde), să reîncerce și la un moment dat să nu mai folosească acel server de nume. După acea rampă, va folosi celelalte servere de nume și lucrurile vor fi rapide. Dar prima dată când trebuie să descoperiți un anumit server de nume este lent/nu răspunde încercând cu adevărat să-l contactați, nu puteți deduce problema fără a încerca.
Asta înseamnă că trebuie să setez TTL scurt pentru înregistrările NS?
Poate, dar în mare parte este irelevant. De ce? Pentru că dvs NS înregistrările sunt publicate în zona părinte a domeniului dumneavoastră, pentru a asigura delegarea DNS. Ele sunt publicate acolo cu un TTL desigur, deoarece toate înregistrările au un TTL atașat, dar sunt publicate într-o zonă pe care nu o controlați, deci NU puteți alege valorile lor TTL!
(Există aici o discuție complicată/nu complet terminată despre acele înregistrări, cum ar fi NS care există în două părți: părintele și copilul, cu întrebarea „care este cu adevărat autoritar”? Dacă părintele are un TTL de 1 săptămână NS înregistrează și tu în zona ta la fel NS înregistrările au un TTL de 1 secundă, ce ar trebui să facă serverul de nume recursiv? S-ar putea ajunge la concluzia că, în mod normal, partea copil a delegației ESTE autoritară, deci 1 secundă câștigă aici; în practică, mai multe implementări DNS sunt „centrate pe părinți”, adică folosesc datele din partea părinte, deci 1 săptămână câștigă acolo)
TTL-urile sunt întotdeauna un compromis. Odată cunoscuți, unii oameni ajung imediat la concluzia că lucrurile funcționează mai bine cu TTL-uri foarte scăzute... ceea ce este adevărat pentru unele cazuri și nu atât de mult pentru altele. Cache-urile sunt bune, dacă nu ar fi acolo (aka: nu folosiți TTL-uri suficient de mari) nu sunteți rezistent la orice probleme mici, asta ar face totul să dispară, deoarece cache-urile ar fi expirat deja numele.
De asemenea, valoarea TTL nu are (sau puțin) impact pentru algoritmul de mai sus în parcurgerea pe toate serverele de nume, încercând cu timeout și convergând spre cel mai rapid.
Deci, dacă vă uitați la ce se întâmplă în serverele de nume TLD (acea gazdă NS înregistrări pentru toate domeniile sub acel TLD) sau în diferite recomandări, veți vedea adesea NS înregistrări cu un TTL de 1 sau 2 zile.
Vreo sfat despre cum funcționează DNS-ul rezolutorului cu NS care nu răspunde și TTL-ul său?
Fiecare resolver isi face propriul :-) Acest lucru nu este chiar specificat de protocol, este un detaliu de implementare. Puteți studia codul sursă pentru cel pe care îl puteți instala, dar probabil nu veți putea aduna detalii despre acesta de la furnizorii DNS recursivi publici mari.
Mai multe detalii poti gasi totusi aici:
RFC 1034 §5.3.3 oferă și unele informații (rețineți, de asemenea, că ia în considerare un caz pe care l-ați uitat: un anumit server de nume poate avea mai multe adrese IP - chiar și astăzi ar trebui să fie întotdeauna cazul, cu un IPv4 și unul IPv6 - și nu există nicio garanție că obțineți rezultate în aceeași perioadă de timp cu fiecare):
Pe lângă numele și adresele serverelor, datele SLIST
structura poate fi sortată pentru a utiliza mai întâi cele mai bune servere și pentru a asigura
că toate adresele tuturor serverelor sunt utilizate într-o manieră round-robin. The
sortarea poate fi o simplă funcție de preferință a adreselor pe local
rețea peste alții sau poate implica statistici din evenimentele trecute, cum ar fi
timpii de răspuns anterior și mediile de bataie.
Pasul 3 trimite întrebări până când se primește un răspuns. Strategia este
pentru a parcurge toate adresele pentru toate serverele cu a
timeout între fiecare transmisie. În practică, este important să se folosească
toate adresele unei gazde multihomed și o retransmisie prea agresivă
politica încetinește de fapt răspunsul atunci când este folosită de mai mulți soluționari
luptă pentru același server de nume și chiar ocazional pentru unul singur
rezolutor. SLIST conține de obicei valori de date pentru a controla intervalele de timp
și urmăriți transmisiile anterioare.
RFC 1035 §7.2 are de spus:
Pentru a finaliza inițializarea SLIST, rezolutorul atașează orice
informațiile istorice pe care le are la fiecare adresă din SLIST. Asta va
de obicei constau dintr-un fel de medii ponderate pentru timpul de răspuns
a adresei și media batting a adresei (adică cât de des
adresa a răspuns deloc la cerere). Rețineți că aceasta
informațiile ar trebui păstrate pe bază de adresă, mai degrabă decât pe bază de per
pe baza serverului de nume, deoarece timpul de răspuns și media de bataie de a
un anumit server poate varia considerabil de la o adresă la alta. Notă
de asemenea, că această informație este de fapt specifică unei adrese de resolver /
pereche de adrese de server, așa că un solutor cu mai multe adrese poate dori
păstrați istorice separate pentru fiecare dintre adresele sale. O parte a acestui pas
trebuie să se ocupe de adrese care nu au un astfel de istoric; în acest caz an
timpul estimat dus-întors de 5-10 secunde ar trebui să fie cel mai rău caz, cu
estimări mai mici pentru aceeași rețea locală etc.
Rețineți că ori de câte ori este urmată o delegare, algoritmul de rezolvare
reinițializează SLIST.
Informațiile stabilesc o clasare parțială a numelui disponibil
adresele serverului. De fiecare dată când se alege o adresă și statul ar trebui
să fie modificată pentru a preveni selecția sa din nou până când toate celelalte adrese au
fost încercat. Timpul de expirare pentru fiecare transmisie ar trebui să fie cu 50-100% mai mare
decât valoarea medie prevăzută pentru a permite variația răspunsului.
De asemenea, pentru a termina și mai precis despre asta:
După cum este ilustrat în acest articol de la imperva
Acest articol la care faceți referire vorbește despre problema care s-a întâmplat pentru persoanele care folosesc serverele de nume Dyn, când a avut loc o întrerupere.
Atunci, da, dacă folosești numai servere de nume Dyn, ai o problemă. Deoarece chiar dacă vă schimbați zona pentru a folosi altele, NS înregistrează TTL înseamnă că modificarea dvs. nu va fi văzută imediat. Dar asta, în realitate, nu spune multe despre TTL-uri, ci doar spune multe despre managementul DNS: dacă vrei să fii rezistent, pentru zonele importante, nu folosește un singur furnizor DNS, ci mai mulți (care desigur impune o oarecare coordonare între le puteți amesteca și potriviți în mod arbitrar furnizorii X și Y, și este și mai complicat dacă prin DNSSEC în amestec, dar este posibil).
În acest fel, tocmai din cauza algoritmului rapid redactat mai sus, chiar dacă 2 din 5 să spunem că serverul de nume nu reușește să răspundă complet, deoarece acest furnizor specific are o problemă, celălalt va prelua sarcina și va face domeniul dumneavoastră să funcționeze.S-ar putea să existe o întârziere suplimentară la fiecare interogare nouă pentru vizitatori (deoarece toate serverele de nume recursive nu pot înțelege imediat că trebuie să treacă la anumite servere de nume, deoarece 2 din 5 sunt nefuncționale) și, de asemenea, mai multe întârzieri, deoarece celelalte 3 sunt copleșite cu mai multe. interogări decât în mod normal (DNS-ul echilibrează sarcina în mod implicit, astfel încât, în teorie, fiecare server de nume primește aproximativ același volum de interogări), dar totuși va fi dat un răspuns.
PS: nu este cerut, dar deoarece uneori nu este clar, toate înregistrările dintr-un anumit set de înregistrări trebuie să aibă același TTL. TTL este pe înregistrare, dar trebuie să fie același într-un set de înregistrări dat, ceea ce înseamnă că pentru un anumit tuplu de (nume, tip de înregistrare) [și clasă, dar nimeni nu folosește nimic în afară de ÎN ca clasa]
