Autor: Paul Cobbaut
Data publicării: 24 mai 2015
Traducere: A. Panin
Data transferului: 11 iulie 2015

Capitolul 4. Introducere în serverele DNS

4.3. Servere de cache DNS

Un server DNS care nu servește zona DNS, dar este conectat la alte servere de nume pentru a stoca interogări în cache se numește server DNS de stocare în cache. Serverele de stocare în cache DNS nu funcționează cu bazele de date din zonele DNS care conțin înregistrări de resurse. În schimb, se conectează la alte servere de nume și memorează în cache informațiile legate.

Există două tipuri de servere DNS de stocare în cache. Acestea sunt servere DNS care folosesc servere de redirecționare DNS și servere DNS care folosesc servere rădăcină DNS.

4.3.1. Un server DNS de stocare în cache care nu utilizează un server de redirecționare

Un server DNS de stocare în cache care nu utilizează un server de redirecționare trebuie să obțină informațiile în altă parte. În momentul primirii unei cereri de la un client, acesta contactează unul dintre serverele rădăcină. Serverul rădăcină trimite informații despre serverul de stocare în cache despre serverul care deservește domeniul țintă de nivel superior, care, la rândul său, îl va direcționa către un alt server DNS. Cel din urmă server poate avea fie informații pentru a răspunde cererii, fie poate transmite informații despre un alt server DNS care poate avea aceste informații. În cele din urmă, serverul nostru DNS va primi informațiile de care are nevoie pentru a răspunde cererii și le va trimite înapoi clientului.

Ilustrația de mai jos arată procesul prin care un client trimite o solicitare pentru informații despre adresa IP pentru numele de domeniu linux-training.be. Serverul nostru de stocare în cache se va conecta la serverul rădăcină și va fi redirecționat către serverul care deservește domeniul de nivel superior .be. Apoi se va conecta la serverul care deservește domeniul de nivel superior .be și va fi redirecționat către unul dintre serverele de nume din organizația Openminds. Unul dintre aceste servere de nume (în acest caz, nsq.openminds.be) va răspunde solicitării cu adresa IP a serverului cu numele de domeniu linux-training.be. După ce serverul nostru de stocare în cache trimite aceste informații către client, acesta se poate conecta la site-ul web în cauză.

Când utilizați tcpdump sniffer pentru a rezolva un anumit nume de domeniu, obțineți următoarea ieșire (primele 20 de caractere din fiecare rând au fost eliminate).

192.168.1.103.41251> M.ROOT-SERVERS.NET.domain: 37279% A? linux-tr \ aining.be. (46) M.ROOT-SERVERS.NET.domain> 192.168.1.103.41251: 37279- 0/11/13 (740) 192.168.1.103.65268> d.ns.dns.be.domain: 38555% linux-training.\ fi. (46) d.ns.dns.be.domain> 192.168.1.103.65268: 38555- 0/7/5 (737) 192.168.1.103.7514> ns2.openminds.be.domain: 60888% A? linux-train \ ing.be. (46) ns2.openminds.be.domain> 192.168.1.103.7514: 60888 * - 1/0/1 A 188.93.155. \ 87 (62)

4.3.2. Server de stocare în cache DNS folosind un server de redirecționare

Un server DNS de stocare în cache care utilizează un server de redirecționare este un server DNS care primește toate informațiile de care are nevoie de la serverul de redirecționare (forwarder). De exemplu, serverul DNS al unui furnizor de servicii Internet poate acționa ca un server DNS de redirecționare.

Ilustrația de mai sus arată un server DNS din rețeaua locală a unei companii care utilizează un server DNS furnizat de ISP ca server DNS de redirecționare. Dacă adresa IP a serverului DNS furnizată de ISP este 212.71.8.10, următoarele linii ar trebui să fie prezente în fișierul de configurare named.conf al serverului DNS al companiei:

Expeditori (212.71.8.10;);

În plus, vă puteți configura și serverul DNS să funcționeze cu redirecționări condiționate. Descrierea serverului DNS cu redirecționare condiționată din fișierul de configurare arată astfel:

Zona „someotherdomain.local” (tip forward; forward only; forwarders (10.104.42.1;););

4.3.3. Interogare iterativă sau recursivă

O interogare recursivă este o interogare DNS după care clientul așteaptă un răspuns final de la serverul DNS (în ilustrația de mai sus, este descrisă de săgeata roșie aldine care indică de la MacBook către serverul DNS). O interogare iterativă este o interogare DNS, după care clientul nu se așteaptă să primească un răspuns final de la serverul DNS (în ilustrația de mai sus, este descrisă folosind trei săgeți negre care indică de la serverul DNS). Interogările iterative se fac cel mai adesea între serverele de nume. Serverele de nume rădăcină nu răspund la interogările recursive.

Serverul DNS care gestionează o zonă DNS este numit server DNS autorizat pentru acea zonă. Amintiți-vă că o zonă DNS este doar o colecție de înregistrări de resurse.

Primul server DNS autorizat pentru o zonă DNS este numit server DNS primar. Acest server va funcționa cu o copie de citire și scriere a bazei de date a zonei DNS. Dacă trebuie să îmbunătățiți integritatea datelor în cazul unor defecțiuni, să îmbunătățiți performanța serverului sau să echilibrați încărcarea, puteți instala un alt server DNS care va gestiona și această zonă DNS. Acest server va fi denumit server DNS secundar.

Serverul secundar obține o copie a bazei de date a zonei DNS de la serverul primar în timpul unui transfer de zonă. Solicitările de transfer de zonă DNS sunt trimise de servere secundare la anumite intervale de timp. Durata acestor intervale de timp este setată ca parte a înregistrării resursei SOA.

Puteți iniția o actualizare forțată a datelor zonei DNS folosind utilitarul rndc. Exemplul de mai jos inițiază un transfer de date pentru zona DNS fred.local și tipărește porțiunea corespunzătoare din fișierul jurnal / var / log / syslog.

[email protected]: / etc / bind # rndc refresh fred.local [email protected]: / etc / bind # grep fred / var / log / syslog | coada -7 | tăiat -c38- zone fred.local / IN: trimiterea notificărilor (serial 1) primit comanda canal de control "refresh fred.local" zona fred.local / IN: Transferul a început. transfer de „fred.local / IN” de la 10.104.109.1 # 53: conectat folosind 10.104.33.30 # 57367 zona fred.local / IN: transfer serial 2 transferat de „fred.local / IN” de la 10.104.109.1 # 53: Transfer finalizat: 1 mesaje, 10 înregistrări, 264 octeți, 0,001 secunde (264000 octeți / sec) zona fred.local / IN: trimitere notificări (serie 2) [email protected]: / etc / bind #

Când adăugați un server DNS secundar la o zonă DNS, puteți configura acel server să fie un server DNS slave în raport cu serverul principal. Serverul DNS primar va fi serverul DNS principal în raport cu serverul secundar.

Cel mai adesea, serverul DNS primar este serverul master, care lucrează cu toate serverele slave. Uneori, un server slave poate acționa și ca un server master pentru serverele slave de nivel următor. În ilustrația de mai jos, serverul numit ns1 este serverul principal, iar serverele numite ns2, ns3 și ns4 sunt servere secundare. Deși ns1 este master pentru ns2 și ns3, ns2 este master pentru ns4.

Înregistrarea resursei SOA conține rata de reîmprospătare pentru zona DNS numită reîmprospătare. Dacă această valoare este setată la 30 de minute, serverul slave va trimite solicitări de a transfera o copie a datelor zonei DNS la fiecare 30 de minute. Această intrare conține, de asemenea, o valoare pentru durata perioadei de expirare numită retry. Această valoare este utilizată atunci când serverul principal nu a răspuns la ultima cerere de transfer de date din zona DNS. Valoarea numită expiry time setează perioada de timp în care serverul slave poate răspunde la solicitările clienților fără a actualiza datele zonei DNS.

Următorul este un exemplu de utilizare a utilitarului nslookup pentru a citi datele de înregistrare a resurselor SOA pentru o zonă DNS (linux-training.be).

[email protected]:~# nslookup > tip set = SOA > server ns1.openminds.be > linux-training.be Server: ns1.openminds.be Adresă: 195.47.215.14 # 53 linux-training.be origine = ns1.openminds.be adresă de e-mail = hostmaster.openminds.be serial = 2321001133 reîmprospătare = 14400 minim = 0 reîncercare = 800360 reîncercare = 800360

Transferurile de date din zona DNS sunt efectuate numai în cazurile de modificări ale datelor în bazele de date din zona DNS (adică atunci când una sau mai multe înregistrări de resurse sunt adăugate, șterse sau modificate pe partea serverului principal). Serverul slave compară numărul de serie al propriei copii a înregistrării resursei SOA cu numărul versiunii înregistrării resursei SOA a serverului principal corespunzător. Dacă numerele de versiune sunt aceleași, nu este necesară nicio actualizare a datelor (deoarece nu au fost adăugate, eliminate sau modificate alte înregistrări de resurse). În același caz, dacă numărul versiunii înregistrării resursei SOA pe partea serverului slave este mai mic decât numărul versiunii aceleiași înregistrări pe partea serverului master corespunzătoare, se va face o cerere de transfer DNS.

Mai jos este un instantaneu al ferestrei sniffer Wireshark cu date capturate în timpul transferului de date din zona DNS.

4.9. Transferuri totale sau parțiale ale zonelor DNS

Transferurile de date din zona DNS pot fi fie complete, fie parțiale. Decizia de a utiliza un mod sau altul depinde de cantitatea de date care trebuie transferată pentru a actualiza complet baza de date a zonei DNS de pe serverul slave. Transferul parțial al datelor de zonă este de preferat atunci când cantitatea totală de date modificate este mai mică decât dimensiunea întregii baze de date. Transferurile complete ale zonei DNS se fac folosind protocolul AXFR, iar transferurile parțiale ale zonei DNS se fac folosind protocolul IXFR.

Lansarea WordPress 5.3 îmbunătățește și extinde editorul de blocuri introdus în WordPress 5.0 cu un bloc nou, interacțiuni mai intuitive și accesibilitate îmbunătățită. Caracteristici noi în editor [...]

După nouă luni de dezvoltare, este disponibil pachetul multimedia FFmpeg 4.2, care include un set de aplicații și o colecție de biblioteci pentru operațiuni pe diverse formate multimedia (înregistrare, conversie și [...]

Caracteristici noi în Linux Mint 19.2 Cinnamon

Linux Mint 19.2 este o versiune de asistență pe termen lung care va fi acceptată până în 2023. Vine cu software actualizat și conține îmbunătățiri și multe noi [...]

Distribuția Linux Mint 19.2 a fost lansată

Este prezentată lansarea kitului de distribuție Linux Mint 19.2, a doua actualizare a ramurii Linux Mint 19.x, formată pe baza pachetului Ubuntu 18.04 LTS și suportată până în 2023. Distribuția este pe deplin compatibilă [...]

Sunt disponibile noi versiuni de serviciu BIND care includ remedieri de erori și îmbunătățiri ale caracteristicilor. Noile versiuni pot fi descărcate de pe pagina de descărcări de pe site-ul dezvoltatorului: [...]

Exim este un agent de transfer de mesaje (MTA) dezvoltat la Universitatea din Cambridge pentru a fi utilizat pe sisteme Unix conectate la Internet. Este disponibil gratuit în conformitate cu [...]

După aproape doi ani de dezvoltare, a fost lansat ZFS pe Linux 0.8.0, o implementare a sistemului de fișiere ZFS ambalat ca modul pentru nucleul Linux. Modulul a fost testat cu nucleele Linux 2.6.32 până la [...]

WordPress 5.1.1 remediază vulnerabilitatea de control al site-ului

Internet Engineering Task Force (IETF), care dezvoltă protocoale și arhitectură Internet, a finalizat formarea unui RFC pentru protocolul ACME (Automatic Certificate Management Environment) [...]

Centrul de certificare non-profit Let’s Encrypt, controlat de comunitate și care oferă certificate gratuit tuturor, a rezumat rezultatele anului trecut și a vorbit despre planurile pentru 2019. […]

A fost lansată o nouă versiune de Libreoffice - Libreoffice 6.2

DNS (Domain Name System) este o componentă importantă și destul de greu de configurat necesară pentru funcționarea site-urilor web și a serverelor. Mulți utilizatori apelează la serverele DNS furnizate de furnizorul lor de găzduire, cu toate acestea, deținerea de servere DNS are unele avantaje.

În acest tutorial, veți învăța cum să instalați Bind9 și să-l configurați ca server DNS de cache sau de redirecționare pe un server Ubuntu 14.04.

Cerințe

• Înțelegerea tipurilor de bază de servere DNS. Pentru detalii, vezi.
• Două mașini, dintre care cel puțin una rulează Ubuntu 14.04. Prima mașină va fi configurată ca client (adresa IP 192.0.2.100), iar a doua ca server DNS (192.0.2.1).

Veți învăța cum să configurați o mașină client pentru a trimite interogări printr-un server DNS.

Memorarea în cache a serverului DNS

Serverele de acest tip sunt numite și calificative deoarece procesează interogări recursive și, în general, pot efectua căutări DNS pe alte servere.

Când un server DNS de cache monitorizează răspunsul la cererea unui client, acesta returnează răspunsul clientului și, de asemenea, îl stochează în cache pentru timpul permis de TTL-ul înregistrărilor DNS corespunzătoare. Cache-ul poate fi apoi folosit ca sursă de răspunsuri la solicitările ulterioare pentru a accelera timpul general de procesare a cererii.

Aproape toate serverele DNS din configurația dvs. de rețea vor fi stocate în cache. Un server DNS de stocare în cache este o alegere bună pentru multe situații. Dacă nu doriți să vă bazați pe serverele DNS ale furnizorului dvs. de găzduire sau pe alte servere DNS publice, configurați-vă propriul server DNS de stocare în cache. Cu cât distanța de la serverul DNS la mașinile client este mai mică, cu atât este nevoie de mai puțin timp pentru a deservi interogările DNS.

Redirecționarea serverului DNS

Din perspectiva clientului, un server DNS de redirecționare va arăta aproape identic cu un server de cache, dar mecanismele și volumul de lucru sunt complet diferite.

Un server DNS de redirecționare are aceleași beneficii ca un server de cache. Cu toate acestea, nu execută de fapt nicio interogare recursivă. În schimb, redirecționează toate cererile către un server de autorizare extern și apoi memorează în cache rezultatele pentru cererile ulterioare.

Acest lucru permite serverului de redirecționare să servească cereri din memoria cache fără a procesa cereri recursive. Astfel, acest server se ocupă doar de cereri individuale (cereri client redirecționate) și nu de întreaga procedură de recursivitate. Acest lucru poate fi avantajos în mediile în care lățimea de bandă externă este limitată, în care serverele de cache trebuie schimbate frecvent și în situațiile în care solicitările locale trebuie redirecționate către un server și cererile externe către altul.

Pasul 1 - Instalarea Bind pe un server DNS

Pachetul Bind poate fi găsit în depozitul oficial Ubuntu. Actualizați indexul pachetului și instalați Bind folosind apt manager. De asemenea, trebuie să instalați câteva dependențe.

sudo apt-get update
sudo apt-get install bind9 bind9utils bind9-doc

După aceea, puteți începe configurarea serverului. Puteți utiliza configurația serverului de cache ca șablon pentru configurarea unui server de redirecționare, așa că trebuie să configurați mai întâi un server DNS de stocare în cache.

Pasul 2 - configurarea unui server DNS de cache

Mai întâi, trebuie să configurați Bind ca server DNS de cache. Această configurație va face ca serverul să caute recursiv răspunsuri la întrebările clienților pe alte servere DNS. Acesta va sonda secvenţial toate serverele DNS relevante până când va găsi un răspuns.

Fișierele de configurare Bind sunt stocate în directorul / etc / bind.

Majoritatea fișierelor nu trebuie editate. Fișierul principal de configurare este named.conf (named și bind sunt două nume pentru o aplicație). Acest fișier se referă la fișierele named.conf.options, named.conf.local și named.conf.default-zones.

Pentru a configura un server DNS de stocare în cache, trebuie doar să editați named.conf.options.

sudo nano named.conf.options

Acest fișier arată astfel (comentariile au fost omise pentru simplitate):

Opțiuni (
directorul „/ var / cache / bind”;
dnssec-validare auto;

listen-on-v6 (orice;);
};

Pentru a configura un server de stocare în cache, trebuie să creați o listă de control al accesului sau ACL.

Trebuie să protejați serverul DNS care procesează interogări recursive de la atacatori. Atacurile de amplificare DNS sunt deosebit de periculoase deoarece pot implica serverul în atacuri distribuite de denial of service.

Atacurile de amplificare DNS sunt o modalitate de a închide serverele și site-urile. Pentru a face acest lucru, atacatorii încearcă să găsească servere DNS publice care procesează interogări recursive. Ei falsifică adresa IP a victimei și trimit o solicitare care va returna un răspuns foarte voluminos serverului DNS. În acest caz, serverul DNS returnează prea multe date către serverul victimei ca răspuns la o solicitare mică, crescând lățimea de bandă disponibilă a atacatorului.

Găzduirea unui server DNS recursiv public necesită o configurare și o administrare atentă. Pentru a preveni compromiterea serverului, configurați o listă de adrese IP sau intervale de rețea în care serverul poate avea încredere.

Înainte de blocarea opțiunilor, adăugați un bloc acl. Creați o etichetă pentru grupul ACL (în acest tutorial, grupul se numește goodclients).

acl goodclients (
};
Opțiuni (
. . .

În acest bloc, enumerați adresele IP sau rețelele care vor avea acces la acest server DNS. Deoarece serverul și clientul rulează pe o subrețea / 24, puteți restricționa accesul la acea subrețea. De asemenea, trebuie să deblocați localhost și localnets, care se conectează automat.

acl goodclients (
192.0.2.0/24;
gazdă locală;
rețele locale;
};
Opțiuni (
. . .

Acum aveți un ACL client securizat. Puteți începe configurarea rezoluției cererilor în blocul de opțiuni. Adăugați următoarele rânduri la acesta:

Opțiuni (
directorul „/ var / cache / bind”;
recursivitate da;

. . .

Blocul de opțiuni activează în mod explicit recursiunea și apoi configurează parametrul de interogare allow-query pentru a utiliza ACL. De asemenea, puteți utiliza un alt parametru pentru a face referire la un grup ACL, cum ar fi allow-recursion. Cu recursiunea activată, allow-recursion va defini o listă de clienți care pot folosi servicii recursive.

Cu toate acestea, dacă parametrul allow-recursion nu este setat, Bind se întoarce la lista allow-query-cache, apoi la liste allow-query și, în final, la rețelele locale implicite și la listele localhost. Deoarece configurăm doar serverul de cache (nu are propriile sale zone și nu transmite cereri), lista de interogări permise se va aplica întotdeauna numai recursiunii. Acesta este cel mai comun mod de a defini ACL-uri.

Salvați și închideți fișierul.

Acestea sunt toate setările care trebuie adăugate la fișierul de configurare a serverului DNS de stocare în cache.

Notă: Dacă doriți să utilizați doar acest tip de DNS, mergeți să verificați configurațiile, reporniți serviciul și configurați-vă clientul.

Pasul 3 - Configurarea unui server DNS direct

Dacă un server de redirecționare DNS este mai potrivit pentru infrastructura dvs., puteți modifica ușor setarea.

În acest moment, fișierul named.conf.options arată astfel:

acl goodclients (
192.0.2.0/24;
gazdă locală;
rețele locale;
};
Opțiuni (
directorul „/ var / cache / bind”;
recursivitate da;
allow-query (clienți buni;);
dnssec-validare auto;
auth-nxdomain nr; # conform cu RFC1035
listen-on-v6 (orice;);
};

Puteți utiliza același ACL pentru a restricționa serverul DNS la o anumită listă de clienți. Cu toate acestea, acest lucru necesită unele modificări de configurare, astfel încât serverul să nu mai încerce să execute interogări recursive.

Nu schimba recursiunea la nr. Serverul de redirecționare acceptă servicii recursive. Pentru a configura un server de redirecționare, trebuie să creați o listă de servere de stocare în cache către care va trimite cererile.

Acest lucru se face în blocul opțiuni (). În primul rând, trebuie să creați un nou bloc de expeditori în el, care va stoca adresele IP ale serverelor de nume recursive către care doriți să redirecționați cererile. În acest caz, acestea vor fi serverele DNS ale Google (8.8.8.8 și 8.8.4.4):

. . .
Opțiuni (
directorul „/ var / cache / bind”;
recursivitate da;
allow-query (clienți buni;);
expeditori (

8.8.8.8;

8.8.4.4;

};
. . .

Ca urmare, configurația arată astfel:

acl goodclients (
192.0.2.0/24;
gazdă locală;
rețele locale;
};
Opțiuni (
directorul „/ var / cache / bind”;
recursivitate da;
allow-query (clienți buni;);
expeditori (
8.8.8.8;
8.8.4.4;
};
numai înainte;
dnssec-validare auto;
auth-nxdomain nr; # conform cu RFC1035
listen-on-v6 (orice;);
};

Ultima modificare se referă la parametrul dnssec. Cu configurația curentă și în funcție de setările serverelor DNS către care sunt redirecționate cererile, în jurnale pot apărea următoarele erori:

25 iunie 15:03:29 cache numită: eroare (chase DS servers) rezolvarea „in-addr.arpa/DS/IN”: 8.8.8.8 # 53
25 iunie 15:03:29 cache numită: eroare (fără DS valid) la rezolvarea „111.111.111.111.in-addr.arpa/PTR/IN”: 8.8.4.4 # 53

Pentru a le evita, modificați parametrul de validare dnssec la yes și activați explicit dnssec.

. . .
numai înainte;
dnssec-activare da;
validare dnssec da;
auth-nxdomain nr; # conform cu RFC1035
. . .

Salvați și închideți fișierul. Serverul DNS de redirecționare este acum configurat.

Pasul 4: Verificarea setărilor și repornirea Bind

Acum trebuie să vă asigurați că setările funcționează conform așteptărilor.

Pentru a verifica sintaxa fișierelor de configurare, introduceți:

sudo named-checkconf

Dacă nu există erori în fișiere, linia de comandă nu va afișa nicio ieșire.

Dacă primiți o eroare, corectați-o și verificați din nou.

Puteți apoi reporni demonul Bind pentru a actualiza setările.

sudo service bind9 restart

Apoi trebuie să verificați jurnalele serverului. Rulați comanda pe server:

sudo tail -f / var / log / syslog

Acum deschideți un nou terminal și începeți să configurați mașina client.

5: configurarea clientului

Conectați-vă la computerul client. Asigurați-vă că clientul a fost listat în grupul ACL al serverului DNS configurat. În caz contrar, serverul DNS va refuza să servească solicitările acestui client.

Editați fișierul /etc/resolv.conf pentru a indica serverul către serverul de nume.

Modificările făcute aici vor persista doar până la repornire, ceea ce este excelent pentru testare. Dacă sunteți mulțumit de rezultatele setării testului, puteți face aceste setări permanente.

Deschideți fișierul cu sudo într-un editor de text:

sudo nano /etc/resolv.conf

Fișierul ar trebui să enumere serverele DNS care vor fi utilizate pentru a rezolva solicitările. Pentru a face acest lucru, utilizați directiva nameserver. Comentează toate intrările curente și adaugă o linie de server de nume care indică către serverul tău DNS:

serverul de nume 192.0.2.1
# server de nume 8.8.4.4
# server de nume 8.8.8.8
# server de nume 209.244.0.3

Salvați și închideți fișierul.

Acum puteți trimite o solicitare de testare pentru a verifica dacă se rezolvă corect.

Puteți folosi ping pentru a face acest lucru:

ping -c 1 google.com
PING google.com (173.194.33.1) 56 (84) octeți de date.
64 de octeți de la sea09s01-in-f1.1e100.net (173.194.33.1): icmp_seq = 1 ttl = 55 timp = 63,8 ms
--- statistici ping google.com ---
1 pachet transmis, 1 primit, 0% pierdere de pachete, timp 0 ms
rtt min / mediu / max / mdev = 63,807 / 63,807 / 63,807 / 0,000 ms

În fiecare an, viteza internetului - atât pe ultimul kilometru, cât și pe canalele principale - este din ce în ce mai mare. Un singur lucru este invariabil - latența s-a confruntat deja cu limitările fizice: viteza luminii în fibră este de aproximativ 200 de mii de kilometri pe secundă și, în consecință, mai repede de ~ 150 ms nu va fi primit un răspuns de la serverul de peste Oceanul Atlantic. în viitorul previzibil (deși, desigur, există delicii, cum ar fi fibră cu miez de aer sau comunicație prin releu radio, dar acest lucru este greu disponibil pentru simplii muritori).

Când încercăm, de exemplu, din Rusia să deschidem un site web situat în SUA (serverele sale NS sunt probabil în același loc), iar domeniul nu a fost găsit în memoria cache DNS al furnizorului dvs., atunci va trebui să așteptăm un mult timp chiar și pe un internet gigabit, poate chiar o secundă întreagă: în timp ce trecem peste ocean, vom primi numele serverelor NS ale domeniului, în timp ce le tăiem IP-ul, în timp ce vom trimite și primi cererea DNS propriu-zisă .. .

În urmă cu câțiva ani, Google și-a lansat propriile servere DNS publice și, pentru a agita tranziția către acestea, au dezvoltat utilitarul NameBench, care rulează teste DNS pe istoricul dvs. de navigare și arată cât de mult DNS Google este mai rapid decât serverul DNS al ISP-ului dumneavoastră.

Dar am reușit să-mi fac propriul server DNS, care funcționează mai rapid decât Google Public DNS, iar în această scurtă notă vreau să împărtășesc rezultatele.

PDNSD

pdnsd- cache proxy DNS. Pe lângă memorarea banală în cache a cererilor DNS (cu capacitatea de a seta rigid TTL minim - poate fi necesar pe un internet foarte prost), el este capabil să trimită o solicitare simultan către mai multe servere DNS „părinte” și să ofere clientul a primit primul răspuns.

Includerea sondajului paralel este cea care ne oferă principalul avantaj în viteză. de cand când rezultatul este găsit în memoria cache a oricărui furnizor, obținem rezultatul foarte repede și nu ne așteptăm la rezoluție completă și lentă dacă primul furnizor nu are un răspuns în cache.

Este instalat în Ubuntu - banalul apt-get.

Câteva puncte din config

global (perm_cache = 10240; // Dimensiunea maximă a memoriei cache în kilobytes. // Implicit a fost 1024, toate înregistrările nu au fost interferate cu mine. cache_dir = "/ var / cache / pdnsd"; [...] min_ttl = 60m; // Timp minim pentru salvarea unei intrări în cache. // Chiar dacă TTL-ul ajunge în mai puțin de 60 de minute, va fi de 60 de minute max_ttl = 1w; // Timpul maxim pentru salvarea unei intrări în cache neg_ttl = 5m; // Timp pentru stocarea în cache a răspunsurilor negative (adică dacă domeniul nu este găsit) [..] par_queries = 3; // Numărul de servere DNS „părinte” interogate simultan) server (etichetă = „principal”; ip = 85.21.192.5 // Există 4 servere, dacă primele 3 nu răspund, o solicitare va fi trimisă către 4 -th, 213.234.192.7 // Primele 2 servere sunt serverul ISP-ului dvs., iar unele învecinate, 8.8.4.4 // Acesta este Google Public DNS - au totul rare în cache și se rezolvă rapid, 8.8.8.8; [.. ])

În principiu, caching-ul poate fi mai puțin agresiv (min_ttl = 1m de exemplu), dar în timpul anului de lucru nu au existat probleme deosebite. În caz de probleme - dacă doriți, puteți șterge o intrare din cache:
sudo pdnsd-ctl record 3.14.by ștergere sau toate odată:
sudo pdnsd-ctl empty-cache

Rezultatele testului în NameBench

Vedem că pentru 50% dintre solicitări, primim un răspuns în mai puțin de 10 ms, cu 85% mai rapid decât Google Public DNS, iar apoi rezultatele coincid în mod firesc cu Google.

Pe baza rezultatelor testelor, NameBench ne informează cu bucurie:

8.8.8.8 Replica mai lentă a SYS-192.167.0.98 8.8.4.4 Replica mai lentă a SYS-192.167.0.98

Astfel, un proxy DNS de cache inteligent cu solicitări paralele poate accelera chiar și Internetul de 100 de megabiți. Iar pentru legăturile lente (radio) cu latență mare și pierderi de pachete, diferența poate fi ca între cer și pământ.