Ce sunt un server DNS, un rezolvator și un rezolvator stub? (Unix, Dns, Terminologie, Systemd Rezolvat)

Tim a intrebat.

https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html#Description spune

În plus, systemd-resolved oferă un ascultător DNS stub local la adresa IP 127.0.0.53 pe interfața locală loopback. Programele care emit cereri DNS direct, ocolind orice API locală, pot fi direcționate către acest stub, pentru a le conecta la systemd-resolved.

Cum trebuie să înțeleg formatul `/etc/resolv.conf`? spune

serverul DNS și rezolvatorul („stub resolver”) pot fi diferite, puteți transmite cereri DNS către 127.0.0.53, care le transmite routerului dumneavoastră pentru DNS real (de exemplu, acesta poate gestiona gazdele locale, dar poate transmite cererile pentru gazde la distanță pentru DNS complet).

Ce sunt un server DNS, un rezolvator și un rezolvator stub?

Am auzit, de asemenea, de două tipuri de servere DNS (unul se numește „resolver”, iar pe celălalt l-am uitat). Ce înseamnă cele două tipuri?

Comentarii

  • Cred că asta ați uitat. –  > Por Stephen Kitt.
2 răspunsuri
JdeBP

Nume confuze pe care oamenii le greșesc adesea.

În terminologia de RFC 1034, , există „rezolvatori” și există „servere de nume”. „resolver” descrie întregul subsistem pe care programele de utilizator îl utilizează pentru a accesa „serverele de nume”, fără a ține cont de o anumită arhitectură. Este subsistemul care interoghează unul sau mai multe „servere de nume” pentru datele pe care acestea le publică și care compune din aceste date un răspuns final pentru aplicația care face interogarea, în modul descris în RFC 1034 § 5.3.3.. Un „rezolvator” este general subsistem care efectuează interogarea rezoluție.

RFC permite, teoretic, deoarece nu este menit să fie centrat pe Unix, , sisteme în care tot mecanismul de rezolvare a interogărilor se află într-o formă de subsistem partajat care rulează în cadrul fiecărui program de aplicații individuale.

În terminologia RFC 1034, un „stub resolver” este ceea ce se folosește în general în lumea Unix și Linux: o bibliotecă client DNS destul de proastă care rulează în procesele de aplicație, care vorbește aceleași protocoale DNS/UDP și DNS/TCP cu un program extern care rulează ca un alt proces, care face de fapt munca grea de rezolvare a interogărilor, efectuând tranzacții back-end și construind răspunsul front-end din acestea.

„rezolvator” este un termen atât de confuz și atât de des folosit contrar RFC-urilor, încât, cu ani în urmă, am început să explic DNS oamenilor folosind terminologia împrumutată din HTTP: servere proxy, , servere de conținut, , și biblioteci client legate în aplicații.

  • Site-ul bibliotecă client DNS din aplicațiile dumneavoastră este aproape va fi întotdeauna biblioteca client BIND DNS de la ISC. Majoritatea bibliotecilor C de pe sistemele Unix și Linux încorporează biblioteca client BIND DNS. Totuși, există și alte biblioteci client DNS, iar o minoritate de aplicații le utilizează în schimb.

    Biblioteca client DNS face calificarea numelui și află cu ce server(e) proxy DNS trebuie să vorbească, în modurile descrise în continuare.

  • Aplicația inițială server proxy DNS este, în această configurație particulară, systemd-resolved ascultă la 127.0.0.53.

    Alte programe Unix și Linux care îndeplinesc acest rol includ Daniel J. Bernstein’s dnscache, , unbound, , dnsmasq, , PowerDNS Recursor, MaraDNS Recursor („Deadwood”) și așa mai departe.

    Eu personal am o instanță locală a programului modificat dnscache (care poate moșteni socket-urile sale de ascultare) pe fiecare mașină care ascultă pe 127.0.0.1, care este, de asemenea, locul implicit în care biblioteca client BIND DNS se așteaptă ca un server DNS proxy să fie, în absența unei configurări explicite.

  • systemd-resolved vorbește cu alte servere DNS proxy, care pot vorbi cu alte servere proxy, redirecționează interogarea de-a lungul unui lanț până când interogarea ajunge la un de rezolvare de rezolvare.
    • În mod implicit, așa cum cei de la systemd livrează lucrurile și cu excepția cazului în care persoana care a creat pachetul binar sau administratorul de sistem local îl modifică, serverul DNS proxy de rezolvare va fi un server administrat de Google ca parte a Google Public DNS, și va exista un lanț de servere DNS proxy de redirecționare de lungime 1.
    • În cazul în care administratorul de sistem a configurat systemd-resolved pentru a utiliza alte servere DNS proxy în locul celor de la Google, lanțul va fi mai lung. Exemple de astfel de configurări includ (într-o ordine aproximativă de la cel mai bun la cel mai rău) utilizarea unui server DNS proxy de rezolvare locală în LAN, utilizarea unui server DNS proxy care rulează într-un router/pasarelă la marginea LAN sau utilizarea unui server DNS proxy terț care se află pe Internet în general.
  • Site-ul server DNS proxy de rezolvare de la capătul îndepărtat al lanțului face munca grea de rezolvare a interogărilor, interogând serverele DNS de conținut din întreaga lume, după cum este necesar, pentru date pe care le combină pentru a forma răspunsul final, care este apoi returnat de-a lungul lanțului de servere DNS proxy, inclusiv systemd-resolved la capătul apropiat al acestui lanț, către biblioteca de clienți DNS din aplicații.

În termenii RFC 1034, pentru a contrasta, „rezolvatorul” este de fapt o imensă cutie neagră care cuprinde biblioteca BIND DNS Client, systemd-resolved, , și Google Public DNS, deoarece este definit de RFC ca având pe de o parte „programe de utilizator” și pe de altă parte servere DNS de conținut (care furnizează „direct” referințe și informații din baza de date). Adesea, oamenii vor folosi termenul în mod greșit, uneori pentru că înțeleg greșit conceptul neutru din punct de vedere al arhitecturii din RFC 1034 de „resolver” ca fiind același lucru cu un singur program server Unix sau Linux, ceea ce nu este cazul. Terminologia HTTP nu are această imensă cutie neagră.

Lecturi suplimentare

Comentarii

  • Văd un pericol în analogia cu „proxy”. În lumea HTTP, un proxy nu face decât să redirecționeze traficul către un anumit server, în timp ce un server de nume recursiv DNS are mult mai mult de lucru, deoarece contactează mai multe servere de nume. Este posibil chiar să fie nevoit să efectueze calcule DNSSEC. –  > Por Patrick Mevzek.
  • De asemenea, în ceea ce privește denumirea lucrurilor, grupul de lucru IETF DNSOP a produs acest RFC care oferă vocabularul care poate fi utilizat atunci când se lucrează la probleme DNS: tools.ietf.org/html/rfc8499. A se vedea în special secțiunea 6: „stub resolver”, „recursive nameserver”, „authoritative server” și „forwarder”. –  > Por Patrick Mevzek.
  • Deci, un „stub resolver” ar fi de tipul dig, nslookup, ?  > Por Timothy Pulliam.
  • Sunt puțin curios ce se întâmplă la nivel de rețea atunci când rezolvatorul/proxy-ul redirecționează cererea. Limbajul din descrieri este ambiguu. La un moment dat, am avut impresia că rezolvatorul R1 îl întreabă pe R2, care la rândul său îl întreabă pe R3 etc. La un alt moment dat, aveam impresia că R1 îl întreabă pe R2, R2 răspunde spunând „du-te și întreabă-l pe R3”, R1 îl întreabă pe R3 etc. I cred că că aceasta din urmă este corectă, dar nu am văzut nimic care să precizeze explicit acest lucru. –  > Por Steven J Owens.
  • Ambele sunt corecte. Unul este un proxy de redirecționare, iar celălalt este un proxy de rezolvare. –  > Por JdeBP.
Tejas Sarade

În ceea ce privește systemd-resolved, ‘stub-resolver’ nu face toată rezoluția DNS pe cont propriu (adică nu se conectează la serverele DNS rădăcină -> serverele de nume tld/gtld -> serverele de nume autoritare). În schimb, se conectează la alte rezolvatoare (de obicei configurate prin configurarea interfeței de rețea. de exemplu, 8.8.8.8.8 sau 1.1.1.1.1 sau furnizate de ISP) pentru rezolvarea numelor.

Scopul este că, în loc ca fiecare program/client să interogheze direct rezolvatoarele, acesta poate interoga rezolvatorul de tip stub, care poate stoca în memoria cache rezultatele pentru a accelera procesul general de rezolvare a numelui. Există, de asemenea, câteva beneficii suplimentare.

Motivul pentru care se numește „stub” este acela că se comportă ca un fel de rezolvare, dar, din punct de vedere tehnic, nu este o rezolvare, deoarece nu are toate funcționalitățile acesteia.