Milline on DNS-i struktuur? DNS-protokoll. Peamised DNS-i funktsioonid

Teisele sõlmele juurdepääsul (näiteks brauseris lehe avamisel helistatakse veebiserverisse ja avamisel postiprogramm- juurdepääs meiliserverile), saab kasutaja määrata sõlme aadressi otse või kaudselt, mis omakorda sunnib kasutaja sõlme edastama paketti teisele sõlmele. Kuid hostid ei saa saata pakette, mis määravad sihtkoha hostinime, mistõttu enamik võrke kasutab DNS-protokolli hostinimede lahendamiseks oma IP-aadressidele.

Sõlm toimib DNS-kliendina, saates DNS-serverisse sõnumeid oma IP-aadressil, mis näitab nõutav nimi sõlm, millele server vastab vajaliku sõlme IP-aadressiga. Kui saatev host on teada saanud, et hostinimi vastab selle IP-aadressile, saab selle teabe vahemällu salvestada, et vältida DNS-päringu uuesti käivitamist sellele hostile juurdepääsul.

DNS-süsteem hoiab hierarhiat, mis vastab tsoonihierarhiale. Iga tsoon on kaardistatud vähemalt ühe autoriteetse DNS-serveriga, kus domeeniteave asub. Samuti on 13 juur-DNS-serverit. Need on DNS-serverid, mis sisaldavad teavet domeenide kohta kõrgeim tase, osutades DNS-serveritele, mis toetavad kõiki neid domeene. Juurservereid haldavad erinevad professionaalsed organisatsioonid, paljudel neist serveritest on peeglid, seega on DNS-süsteemi peaaegu võimatu keelata.

DNS-kirjed on erinevad tüübid ja sisaldavad mitmesugust teavet. Peamised märkimist vajavad kirjed on toodud tabelis 1.

Tüüp Dekodeerimine Kirjeldus
A Aadress Aadressikirje, nime ja IP-aadressi vastavus
CNAME Kanooniline nimi Pseudonüümi kanooniline nimi (ühetasandiline edastamine)
N.S. Autoriteetne nimeserver Domeenitsooni eest vastutava sõlme aadress. Kriitiline domeeninimesüsteemi enda toimimise jaoks
PTR Domeeninime osuti Rakendab ümbersuunamismehhanismi
SOA Autoriteedi algus Teabe volituse märge, mida kasutatakse uue tsooni tähistamiseks

Tabel 1. Põhiline ressursside kirjed DNS

A kirje sisaldab IP-aadressi vastavust domeeninimele. Kasutatakse hostinime lahendamisel, näiteks kui brauser peab avama veebilehe (domeeninime järgi). Päring määrab hostinime ja DNS-server vastab selle hosti IP-aadressiga, mis on võetud A-kirjest. Kirje sisaldab IP-aadressi.

CNAME kirjed võimaldavad teil määrata hostile "aliase" või "kanoonilise nime", et siduda see mitte konkreetse IP-aadressiga, vaid viidata teisele hostile. Näiteks kui sõlmel on mitu domeeninime, siis piisab ühe A-kirje määramisest ja selle linkimisest. Kirje sisaldab domeeninime.

N.S. kirjeid kasutatakse antud tsooni ja tsoone teenindavate NS-serverite tähistamiseks järgmine tase. Kirje sisaldab vastutava DNS-serveri aadressi.

PTR kirje seob hosti IP selle kanoonilise nimega. See kirje on oluline kirjade edastamisel. Rämpsposti mahu vähendamiseks on paljud vastuvõtvad serverid Meil saab kontrollida PTR-kirje olemasolu hosti jaoks, kust saatmine toimub. Sel juhul PTR rekord IP-aadress peab ühtima saatja nimega meiliserver, millega ta ennast selle käigus tutvustab SMTP seansid. Sageli loovad Interneti-teenuse pakkujad automaatselt genereeritud PTR-kirjed oma abonentide IP-aadresside jaoks, kasutades konkreetset malli. Seetõttu peate ühel neist aadressidest meiliserveri seadistamisel koos domeeni registreerimisega domeeninime registripidaja juures muutma teenusepakkuja DNS-serveris PTR-kirjet.

SOA kirje sisaldab teavet DNS-tsooni kohta (tsooni esmase DNS-serveri nimi, tsoonifaili vastutava administraatori kontaktaadress, erinevate ajavahemike seaded).

Mis on juhtunudDNS

DNS (domeeninimesüsteem) on süsteem, mis tagab tuttavate veebilehtede domeeninimede toimimise. Seadmetevaheline suhtlus Internetis toimub IP-aadresside abil, näiteks: “192.64.147.209”. IP-aadresside meeldejätmine on aga keeruline, seetõttu leiutati inimsõbralikud domeeninimed, näiteks: “google.com”.

Arvuti/server ei salvesta domeenide ja nende IP-aadresside vahelist vastavustabelit. Täpsemalt, see ei salvesta kogu tabelit, vaid salvestab ajutiselt sageli kasutatavate domeenide andmed. Kui saidi domeen sisestatakse brauserisse, tuvastab arvuti automaatselt selle IP-aadressi ja saadab sellele päringu. Seda protsessi nimetatakse domeenide lahendamiseks.

Mõelgem välja, millest DNS-süsteem koosneb ja kuidas see töötab.

Kuidas see töötabDNS

Domeeninimesüsteem koosneb järgmistest komponentidest:

Domeeninimede hierarhiline struktuur:

  • Tipptaseme domeenitsoonid (esimene tase) – näiteks "ru", "com" või "org". Need hõlmavad kõiki sellesse tsooni kuuluvaid domeeninimesid. Iga domeeni tsoon võib sisaldada piiramatul arvul domeene.
  • Domeeninimed (teise taseme domeenitsoonid)- näiteks: "google.com" või "yandex.ru". Sest Domeeninimede süsteem on hierarhiline, siis võib "yandex.ru" nimetada ka vanematsooni "ru" alamdomeeniks. Seetõttu on õigem näidata domeeni taset. Kuid praktikas nimetatakse mis tahes taseme domeenitsooni lihtsalt "domeeniks".
  • Alamdomeenid (kolmanda taseme domeenitsoonid)- näiteks: "api.google.com" või "mail.yandex.ru". Võib olla 4, 5 tasemega domeenitsoone ja nii edasi.

Pange tähele, et "www.google.com" ja "google.com" on tegelikult erinevad domeenid. Me ei tohi unustada märkida igale neist A-kirjeid.

DNS-server või NS-server (nimeserver).– toetab (teenitab) domeenitsoone, mis on talle delegeeritud. See salvestab otse tsooni ressursikirje andmed. Näiteks serveril, millel asub sait “example.ru”, on IP-aadress “1.1.1.1”. DNS-server vastab kõigile nende domeenitsoonide päringutele. Kui ta saab päringu domeeni kohta, mida pole talle delegeeritud, siis ta küsib vastust teistelt DNS-serverid.

DNS-kirjed (ressursikirjed)– see on NS-serveri domeenitsooni kirjete kogum, mis salvestab selle jaoks vajalikke andmeid DNS töö. Nendes kirjetes olevate andmete põhjal vastab DNS-server domeeni päringutele. Kirjete loendi ja nende tähenduse leiate allpool.

DNS juurserverid(peal Sel hetkel maailmas on neid 13) salvestavad andmed selle kohta, millised DNS-serverid teenindavad tipptaseme tsoone.

DNS-serverid tippdomeeni tsoonide jaoks- salvestada teavet selle kohta, millised NS-serverid teatud domeeni teenindavad.

IP-aadressi väljaselgitamiseks võtab domeeniarvuti/server ühendust selles määratud DNS-serveriga võrgusätted. Tavaliselt on see Interneti-teenuse pakkuja DNS-server. DNS-server kontrollib, kas domeen on talle delegeeritud või mitte. Kui jah, vastab ta kohe päringule. Kui ei, siis küsib see teavet DNS-serveri kohta, mis seda domeeni teenindab juurserver ja seejärel ülataseme domeenitsooni serveris. Pärast seda teeb see päringu otse seda domeeni teenindavale NS-serverile ja saadab vastuse teie arvutisse/serverisse.

Andmete vahemällu salvestamine kasutatakse kõikides seadmetes (arvutid, serverid, DNS-serverid). See tähendab, et nad mäletavad vastuseid viimastele neile esitatud päringutele. Ja kui tuleb sarnane palve, siis nad lihtsalt vastavad samaga, mis eelmisel korral. Näiteks kui avasite veebilehe google.com oma brauseris esimest korda pärast selle sisselülitamist, siis arvuti DNS-päring, ja järgmistel päringutel võtab see andmeid, mille DNS-server talle esimest korda saatis. Seega jaoks populaarsed päringud pole vaja iga kord kogu ahelat läbida ja päringuid NS-serveritele genereerida. See vähendab oluliselt nende koormust ja suurendab töö kiirust. Kuid selle tulemusena värskendatakse andmeid DNS-süsteem ei juhtu kohe. Domeeni IP-aadressi muutmisel levitatakse selle kohta teavet Interneti kaudu 1-24 tunni jooksul.

Domeenide registreerimine/eraldamine

Iga domeeni tsoon Esimesel tasemel on oma organisatsioon, mis määrab domeenide eraldamise reeglid ja tagab selle tsooni toimimise. Näiteks domeenitsoonide RU, SU ja RF jaoks on see koordineerimiskeskus riiklik domeen Internet https://cctld.ru. Need organisatsioonid kehtestavad tööreeglid ja tehnilised nõuded domeenide registripidajatele.

Domeeniregistripidajad– need on ettevõtted, kes registreerivad uusi domeene otse lõppklientide esmatasandi domeenitsoonis. Korraldage tehniline suhtlus domeeninimede registriga. Nendes isiklik konto Domeeni omanik konfigureerib, milline DNS-server domeeni toetab.

Domeeni administraator (omanik)– isik, kellele domeeninime õigused otseselt kuuluvad. Ta saab domeeni hallata ja registripidaja võtab temalt vastu muudatusi.

Domeeni delegeerimine– selle DNS-serverite märge, mis seda teenindavad.

PõhilineDNS-kirjed

On olemas järgmised DNS-i (ressursi) põhikirjed:

A – sisaldab teavet domeeni hosti (serveri) IPv4-aadressi kohta. Näiteks 1.1.1.1.

AAA – sisaldab teavet domeeni hosti (serveri) IPv6-aadressi kohta. Näiteks 2001:0db8:11a3:09d7:1f34:8a2e:07a0:765d.

MX – sisaldab andmeid domeeni meiliserveri kohta. Sel juhul näidatakse meiliserveri nimi, näiteks mail.example.com. Sest Domeenil võib olla mitu meiliserverit, siis näitab igaüks neist prioriteeti. Prioriteet määratakse numbriga 0 kuni 65535. Sel juhul on “0” kõrgeim prioriteet. Esimesele meiliserverile on tavaks määrata prioriteet “10”.

TXT – lisainfo domeeni kohta vabatekstina. Maksimaalne pikkus 255 tähemärki.

SRV – sisaldab konkreetsete teenuste/protokollide hostinime ja pordi numbriteavet vastavalt standardile RFC 2782 http://www.rfc-editor.org/rfc/rfc2782.txt. Sisaldab järgmisi välju:

  • _Service._Proto.Name (näide: _jabber._tcp.jabber), kus:
    • Teenus: teenuse nimi (näide: ldap, kerberos, gc ja teised).
    • Proto: protokoll, millega kliendid saavad antud teenusega ühenduse luua (näide: tcp, udp).
    • Nimi: seda teenust hostiva domeeni nimi.
  • Prioriteet – täpselt nagu MX-kirje puhul, näitab prioriteetsust sellest serverist. Määrake numbriga 0 kuni 65535. Sel juhul on “0” kõrgeim prioriteet.
  • Kaal – suhteline kaal koormuse jaotamiseks sama prioriteediga serverite vahel. Määratud täisarvuna.
  • Port – pordi number, millel teenus selles serveris asub.
  • Sihtkoht – seda teenust pakkuva serveri domeeninimi.

NS – seda domeeni toetava DNS-serveri nimi.

CNAME (kanooniline hostinimi) – kasutatakse ümbersuunamiseks teisele domeeninimele. Näiteks serveri nimi example.com muudeti nimeks new.com. Sel juhul väljale „Tulised”. cname kirjed peate määrama example.com ja väljale "Kanooniline nimi" - new.com. Nii suunatakse kõik aadressile example.com olevad päringud automaatselt ümber saidile new.com.

SOA on domeeni põhikirje. See salvestab domeeninime enda ja domeeniandmete eluea - TTL. TTL (time-to-live) määrab, millise aja jooksul DNS-server pärast tsooni kohta teabe saamist selle oma mällu (vahemällu) salvestab. Soovitatav väärtus 86400 – 1 päev. Väärtust näidatakse sekundites.

DNS-protokoll täidab kahte põhifunktsiooni. See võimaldab klientarvutitel pärida DNS-serverilt mis tahes võrgus oleva hosti IP-aadressi või nime ning samuti võimaldab vahetada teavet DNS-serveri andmebaaside vahel. See protokoll kasutab standardset päringu-vastuse vormingut, kus klient saadab päringupaketi ja server vastab kas andmebaasist hangitud teavet sisaldava paketi või veateate abil, mis näitab, miks päringut ei saanud töödelda. Oma töös kasutab see protokoll porti 53 ja tuntud protokolle - TCP või UDP. Veelgi enam, viimasel ajal on UDP muutunud levinumaks meetodiks pakettide transportimiseks Interneti kaudu. DNS-pakett koosneb viiest väljast: päis, küsimus, vastus, volitus ja lisateabe väli. Joonisel fig. 4.5 näidatud üldine struktuur DNS pakett.


Riis.

4.5.

Pealkirja väli Päise väli sisaldab teavet paketi ja selle eesmärgi kohta. See annabüldkirjeldus pakett (päringupakett või vastusepakett) ja näitab paketi igas andmeväljas sisalduvat andmemahtu. Päise kirjeldus

on toodud tabelis. 4.3.
Tabel 4.3. DNS-i paketi päise väli Natuke
0-15 Kirjeldus
16 ID
17-20 QR
21 OPCODE
22 A.A.
23 TC
24 R.D.
25-27 R.A.
28-31 Z
32-47 RCODE
48-63 QDCOUNT
64-79 ANCOUNT
80-95 NSCOUNT

ARCOUNT QR ID-bitid on päringupaketi unikaalne 16-bitine identifitseerimisnumber. Seda identifitseerimisnumbrit kasutab ka serveri genereeritud vastusepakett, et klient saaks serveri vastuse oma päringule sobitada. QR-bitt näitab paketi tüüpi (päringupakett - 0, vastusepakett - 1). Väli

Järgmised neli bitti määravad paketi erinevad parameetrid. AA-bitt määratakse siis, kui vastus on autoriteetne (andmed tulevad otse tsooni eest vastutavalt DNS-serverilt). Mitteautoriteetsed vastused võivad pärineda DNS-serveritelt, millel on vahemällu salvestatud teave eelmiste päringute algsete kirjete kohta. Seda teavet peetakse mitteautoriteetseks, kuna on võimalik, et teavet on pärast viimast serverile juurdepääsu korda muudetud. TC-bitt määratakse siis, kui on vaja kärpida paketis olevaid andmeid võrgu kaudu edastamiseks mugavaks vormiks. See on täiesti võimalik, kui kasutatakse UDP-protokolli, mille kohaselt ei tohiks paketi suurus ületada 512 baiti. RD-bitt lülitatakse sisse, kui klient soovib DNS-serveri poole jooksvalt rekursiivselt päringuid teha. Kui see bitt on määratud, küsib DNS-server teisi DNS-servereid, kuni saab vastuse. Kui seda bitti pole määratud, tagastab DNS-server päringule mis tahes teabe, mis tal on. RA-bitt on seatud teavitama klienti võimalusest rekursiivne päring sellele serverile. Z-bitid on praegu kasutamata ja reserveeritud tuleviku jaoks.

RCODE-bitte kasutatakse ainult vastusepakettides. Need kuvavad vastuse olekut - vigu pole (0), tõrkeid päringupaketis (1), sisemised vead takistasid serveril päringut töödelda (2), päringus määratud nime pole olemas (3), seda tüüpi server ei toeta päringut (4) ja server keeldus päringut töötlemast (5).

Ülejäänud neli päise parameetrit on 16-bitised numbrid ja neid kasutatakse loenduritena. Need aitavad jälgida partiina tagastatud lähtekirjete arvu. QDCOUNT kuvab taotluste arvu (pakki saab lisada rohkem kui ühe päringu). ANCOUNT – vastuses sisalduvate originaalkirjete arv. NSCOUNT tähistab originaalsete autoriteetsete nimeserveri kirjete arvu ja ARCOUNT lisateabe väljal olevate kirjete arvu.

Küsimuste väli

Küsimuste väli sisaldab päringuid, millele klient soovib, et DNS-server vastaks. Üks DNS-pakett võib sisaldada mitut päringut. Päringute arv paketis määratakse QDCOUNT parameetriga päiseväljalt. Küsimuste väli koosneb kolmest osast: teisendatavate domeeninimede loend; kirjetüüpide väljad, mida klient vastuses saada soovib, ja päringu klassi parameeter. Lahendatavate domeeninimede loend on nimede loend, mille jaoks klient soovib saada IP-aadresse. Nimeloendi loomiseks kasutatakse spetsiaalset vormingut. Iga nime ees on ühebaidine väärtus, mis määrab nime pikkuse. Loendi lõppu tähistab nullpikkusega nimi. Tekstiosale järgneb kahebaidine QTYPE kirje. See määrab, millisel kujul soovib klient saadaolevate domeenide kohta teavet saada. Need väärtused on täpselt samad, mis algsed DNS-kirjetüübid. Näiteks konkreetse domeeni meiliserveri leidmiseks peaksite kasutama MX-kirjetüüpi. Ja lõpuks on küsimusevälja viimane parameeter QCLASS. See määratleb päringuklassi, mis meie puhul on mõeldud Interneti-võrgud jääb alati IN .

Aadresside vastendamine nimedele

IP-aadress salvestatakse dot-decimal notation. Domeeninimede otsimiseks IP-aadresside järgi kasutatakse domeeni in-addr.arpa. Selle alamdomeenid on lihtsate nimedega domeenid vahemikus 0 kuni 255, mis vastavad IP-aadressi kõige olulisemale oktetile. Nende alamdomeenid on lihtsate nimedega domeenid vahemikus 0 kuni 255, mis vastavad IP-aadressi teisele oktetile jne. kuni 4. oktetini. Seega kirjutatakse IP-aadress domeeninimesse vastupidises järjekorras. Näiteks aadress 195.161.72.28 vastab domeeninimele 28.72.161.195.in-addr.arpa. (ja PTR väärtus – deol.deol.ru). Kirjuta tagasi vajalik tsoonide lihtsamaks delegeerimiseks vastavalt IP-aadresside eraldamisele.

Tipptaseme tsoonid domeenis in-addr.arpa. IANA delegeeritud piirkondlikele registripidajatele (RIR-id, piirkondlikud Interneti-registraatorid) koos IP-aadresside plokkidega.

RIPE nõuab, et LIR sisestaks alamtsooni delegeerimiseks teabe RIPE andmebaasi. Kui esindate LIR-i, peate olema läbinud erikursused ja kui mitte, siis ei anta teile õigust RIPE andmebaasi teavet sisestada ja peate küsima oma LIR-i. Andmebaas peab sisaldama nii võrku (whois [e-postiga kaitstud]) ja tsoon (whois [e-postiga kaitstud])

Aadresside nimedeks vastendamine võib olla mõne Interneti-teenuse kasutamiseks kohustuslik: kaardistamine puudub – teenus puudub.

Ressursikirjed (RR, Ressursikirjed)

Ressursikirjeid saab esitada tekstivormingus tsooni andmefailis ja binaarvormingus DNS-protokolli sõnumsides. Teksti formaat tsoonid võivad erinevate DNS-serveri rakenduste puhul erineda, see kirjeldab standardis (RFC 1035) mainitud vormingut, mida kasutatakse BIND 4/8/9. Tsoonifail peab sisaldama ainult ühe klassi kirjeid.

Iga kirje asub eraldi real. Tühjad read ignoreeritakse. Reapiire ei tuvastata sulgudes ja tsiteeritud tekstiliteraalides. Väljade eraldajad on tühikud ja tabeldusmärgid. Kommentaarid algavad semikooloniga kõikjal real ja jätkuvad kuni rea lõpuni. Lisaks ressursikirjetele võib tsoonifail sisaldada käskkirju $ORIGIN, $INCLUDE ja $TTL (alates versioonist BIND 8.2). Sümbolit „@” kasutatakse suhteliste domeeninimede praeguse vaikeliite tähistamiseks. Kaldkriips väldib järgmise tegelase eritähendust. Vormis on võimalik määrata suvalisi oktette kaheksandarvud(\012). Otsingu ajal kirjatähte ei arvestata, vaid see tagastatakse vastuses.

Direktiiv $ ORIGIN määrab suhteliste domeeninimede praeguse vaikeliite. Käsk $INCLUDE lisab määratud faili tsoonifaili ja määrab (ainult sisestatud faili kirjete puhul) suhteliste domeeninimede praeguse järelliide (sufiksi võib ära jätta). BIND-i ja selle tuletiste vanemates versioonides (näiteks in.named Solaris 2.5-s) sufiksi muutmine ei toimi (kuigi veateadet pole!) ja selleks tuleb käsk $INCLUDE “raamida” muutmise direktiividega. $ORIGIN ja selle taastamine. Direktiiv $TTL määrab vaike-TTL (RFC 2308).

Ressursikirje koosneb domeeninimest (väljajätmisel eeldatakse eelmise ressursikirje väärtust), klassi nimest (võib ära jätta ja võtta eelmisest kirjest), TTL-ist (sekundite arv, võib ära jätta ja võtta $TTL käsk BIND 8.2 ja uuemate või SOA väljast MINIMUMTTL on soovitatav väärtus üks päev - 1 tund kuni nädal peab olema sama; ), kirje tüüp ja kirje andmed (vormingu määrab klass ja tüüp). Uutes versioonides (BIND?) saab kellaaegu määrata nii sekundites kui minutites (liide m), tundides (sufiks h), päevades (sufiks d), nädalates (liide w). Ainult hostinimed peavad ühtima domeeninime süntaksiga (tähed, numbrid ja miinus), ülejäänud (nt esimene silt) postiaadress SOA-kirjes) võivad koosneda suvalistest ASCII-märkidest.

Kirjeklassid (ainult IN elas raske evolutsioonilise võitluse üle), sulgudes on DNS-protokolli sõnumite kood:

  • IN (1) – Internet
  • CS (2) – CSNET
  • CH (3) – KAOS
  • HS (4) – Hesiodos

Kirjete tüübid, sulgudes – DNS-protokolli sõnumite kood:

BIND versioon? võimaldab lisaks kasutada käsku $GENERATE, et luua RR-ide jada, mis erinevad ainult parameetri poolest:

$GENERATE intervall vasak-osa kirje-tüüp parem-osa

Numbriintervall määratakse kas algus-lõpuna või alguse-lõpuna/sammuna. Vaikimisi on samm 1. Vasak pool määrab reegli domeeninimede moodustamiseks kirjete jada jaoks, mille indeks jookseb algusest lõpuni sammude kaupa. Parem osa määrab kirjeandmete genereerimise reegli (praegu on lubatud ainult tüübid PTR, CNAME, DNAME, A, AAAA ja NS). Reeglites asendatakse üksik $ märk praeguse indeksi väärtusega. Indeksi väärtust saab muuta, määrates nihke (lahutatakse indeksist), välja laiuse (kasutatakse tulemuse vormindamiseks) ja numbrisüsteemi (d, o, x, X) lokkis traksid komadega eraldatud. Kui saadakse suhteline nimi, siis täiendatakse seda kehtiva sufiksiga. Kasutatakse peamiselt automaatne genereerimine tagasituleku tsoonid:

$ ORIGIN 0.0.192.IN-ADDR.ARPA.
$GENERATE 1-127 $CNAME $.0

teisendatud

1.0.0.192.IN-ADDR.ARPA CNAME 1.0.0.0.192.IN-ADDR.ARPA
2.0.0.192.IN-ADDR.ARPA CNAME 2.0.0.0.192.IN-ADDR.ARPA
...
127.0.0.192.IN-ADDR.ARPA CNAME 127.0.0.0.192.IN-ADDR.ARPA

DNS-protokoll

Tavaliselt kasutavad DNS-päringud ja vastused UDP protokoll (port 53, domeen), kuid nad saavad kasutada ka TCP-protokolli (port 53, domeen). Iga sõnum mahub täielikult ühte UDP-paketti, seega ei tohi see olla suurem kui 64 KB. Tegelikkuses on paljudel rakendustel mittefragmenteeritava UDP-paketi suuruse piirang 576 baiti. Selline pakett sisaldab üldjuhul teavet 10 NS-tüüpi kirje kohta. Interneti juurserverite domeeninimed paigutati ühte domeeni, mis võimaldas linkide abil infot pakendada (vt allpool) umbes 13 serveri kohta. Kui vastus ei mahu ühte UDP fragmenti, määratakse päises TC (kärbitud) bitt, mis viib korduva päringuni, kasutades TCP protokoll. TCP-protokolli kasutamisel lisatakse igale sõnumile, mis sisaldab sõnumi pikkust, eesliide (2 baiti) ilma eesliidet arvestamata. Esimene edastatav bitt on vasakpoolne bitt (null), mis on kõige olulisem bitt.

Päringute ja vastuste vorming on sama ( vt üksikasju RFC 1035)

TSIG protokolli laiendus

RFC 2845 laieneb DNS-protokoll võimalus kontrollida päringute ja vastuste terviklikkust (QUERY), tsooniülekandeid, samuti dünaamiliste muudatuste autentimist (UPDATE, RFC 2136), kasutades krüptograafiliselt tugevat kontrollsummad– TSIG (tehingute allkirjad). Räsi genereerimisel kasutatakse HMAC-MD5 algoritmi ja kahe osaleja vahel jagatud saladust ( sümmeetriline võti). Võtme jaotusmehhanism ei ole määratletud. Tehingus osalejad võivad jagada mitut võtit, nii et konkreetse võtme tuvastamiseks kasutatakse selle nime domeeninime vormingus. Rünnakute vältimiseks kordusmäng kirje sisaldab allkirja aega (vajalik on aja sünkroonimine näiteks NTP abil). Kaitstud päringule vastates saadab server vastuse, mis on kaitstud sama algoritmi ja võtmega. Võtmetena on soovitatav kasutada vähemalt 128 biti pikkuseid juhuslikke jadasid.

See mehhanism nõuab vähem protsessori koormust ja väiksemaid infrastruktuuri loomise kulusid väikese arvu sõlmedega võrreldes DNSSEC-iga, millel on asümmeetrilised krüptimismehhanismid ja avalikud võtmed(RFC 2535, RFC 2137). Teisest küljest võimaldab DNSSEC installitud võtmete levitamise infrastruktuuri hõlpsalt skaleerida ja pakkuda digitaalne allkiri(TSIG, vaatamata oma nimele, ei võimalda võtme sümmeetria tõttu päringute autorsust kontrollida).

RFC 2845 tutvustab uut TSIG (250) kirjetüüpi ja mitmeid uusi vastusekoode. TSIG-kirje on virtuaalne, st. arvutatakse tehingu käigus, see ei sisaldu tsooni andmefailis ega salvestata vahemällu. Kirje lisatakse lisaandmete sektsiooni; sisaldab jagatud võtme nime, klassi (ANY), TTL (0), algoritmi nime (nüüd alati HMAC-MD5), allkirja aega, ajahälbe intervalli, räsi, algse sõnumi ID (kasutatakse dünaamiliste muudatuste edastamisel), veakoodi, lisaandmeid vea kohta (näiteks lahknevus osalejate tundides). Räsi genereerimiseks kasutatakse algset sõnumit, võtme nime, klassi, TTL-i, algoritmi nime, allkirja aega, ajahälbe intervalli. Vastuse räsi genereerimisel kaasatakse lähteandmete hulka ka päringu räsi.

Dünaamilised tsoonide muudatused

RFC 2136 laiendab DNS-protokolli, et võimaldada kliendi nõudmisel tsooni sisu dünaamiliselt muuta. See välistab vajaduse sagedaste muutmiste järele (nt. DHCP töö) muuda tekstifail koos tsooni kirjeldusega ja taaskäivitage server. Kasutades sellest laiendist Selle esmase autoriteetse serveri hallatavas tsoonis saate teha ühe partii jooksul mitu muudatust (kõik domeeninimed peavad olema tsoonis):

  • lisada ressursikirje (RR) ressursikirjete komplekti (RRset); SOA ja CNAME tüüpi kirjeid ei lisata, vaid need asendatakse; kui SOA-d ei olnud või selle seerianumber oli suurem, siis lisamist ignoreeritakse; katset asendada tavaline kirjekomplekt CNAME-ga või CNAME tavalise kirjekomplektiga ignoreeritakse; duplikaatkirje lisamise katset ignoreeritakse
  • eemaldada antud väärtusega ressursikirje (RR) ressursikirjete komplektist (RRset); tsooni enda viimast NS-kirjet ja SOA-d ei kustutata; katset kustutada olematut kirjet ignoreeritakse
  • kustutada ressursi kirjekomplekt (RRset); Tsooni enda NS- ja SOA-kirjeid ei kustutata; katset kustutada olematut komplekti ignoreeritakse
  • kustutada kõik määratud domeeninimega seotud ressursikomplektid; Tsooni enda NS- ja SOA-kirjeid ei kustutata; katset kustutada olematut komplekti ignoreeritakse

Muudatuste komplektile võib eelneda järgmist tüüpi tingimuste kogum (kõik domeeninimed peavad olema tsoonis):

  • määratud domeeninimes on vähemalt üks määratud tüüpi ressursikirje
  • määratud domeeninimes on määratud tüüpi ressursikirjeid antud väärtused(TTL väärtust ei võeta arvesse; nimede võrdlemisel suurtähti ja väiketähtedega ei eristata, malle ei töödelda, sünonüüme (CNAME) ei töödelda)
  • määratud domeeninimes ei ole ühtegi määratud tüüpi ressursikirjet
  • määratud domeeninimel on vähemalt üks ressursikirje
  • määratud domeeninimel pole ressursikirjeid

Kogu see tingimuste ja muudatuste pakett on aatomiline, s.t. töödeldakse ühtse jagamatu tervikuna (nagu tehing DBMS-is). Sel juhul peab server enne kliendile vastamist muudatused kettale kirjutama. bind kirjutab ajutiselt muudatused logisse ja liidab selle hiljem tsoonifailiga. Kui muudatused SOA-d ei mõjuta, peaks server seerianumbrit automaatselt suurendama. Meetod ei ole standardiga ette nähtud. Kui automaatne suurenemine seerianumber teostatakse viivitusega, kuid see ei tohiks olla pikem kui 300 sekundit või 1/3 tsooni värskendamise ajast.

RFC 2136 tutvustab uus klass PUUDUB (254) ja mitu uut vastusekoodi. Päringute ja vastuste vorming on sama, mis tavapärastel päringutel ja vastustel, kuid sellel on päringu kood – UPDATE (5). Päringu jaotis sisaldab muudetava tsooni nime (täpselt üks SOA tüüpi ressursikirje), vastuse sektsioon – tingimuste kogum, autoriteetsete serverite lingi jaotis – lisatavad või kustutatavad kirjed, lisateabe jaotis – kirjete linkimine domeeninimedest väljaspool tsooni (server võib neid ignoreerida).

Klient saab potentsiaalsete serverite loendi hankida SOA-kirjetest, NS-kirjetest või väliste vahenditega.

Server saab kontrollida kliendi õigust tsooni muuta oma IP-aadressi järgi (ei ole soovitatav) või kasutades TSIG mehhanismi.

Teisene autoriteetne server, mis sai päringu dünaamiline muutus tsooni, saab selle enda nimel ümber suunata esmasesse serverisse (muutes päringu identifikaatorit) ja pärast vastuse saamist kliendile tagastada. See omakorda võib seda edasi saata jne. Kasutatavate serverite loend langeb kokku nende serverite loendiga, millele edastatakse tsoonide ülekandmise taotlused. Kui klient kasutas päringu jaoks TCP-d (soovitatav, kui on tulemuste töötlemine), peaks sekundaarne server kasutama päringu edastamiseks ka TCP-d.

Veenduge, et muudatused rakendatakse õiges järjekorras (nii et vanemad muudatused, mis on "transiidi ajal", ei kattuks uuemate muudatustega), on mittetriviaalne ülesanne TCP/IP keskkonnas, eriti kui on mitu taotlevat klienti ja mitu ümbersuunajat sekundaarsed serverid. Serveri vastus võib samuti viibida või kaduda. RFC autorid soovitavad sünkroonimise tagamiseks kasutada “token” ressursikirjeid (selline luba võib näiteks sisaldada päringu väljastamise aega).

DNS-klient (lahendaja)

DNS-kliendid rakendatakse tavaliselt rutiinide teegina, mis on lisatud igale domeeninimeteenust vajavale programmile (staatiliselt või dünaamiliselt). Lihtne (jälg)klient pääseb määratud kliendile juurde, kui DNS-i seaded server(id), tõlgendab vastust ja tagastab tulemuse päringu esitavale programmile. Kliendi juurutamine Solarises (Solaris 2.5.1 ja varasemad versioonid vastavad BIND 4.8.3-le; paikadega - BIND 4.9.3; Solaris 2.6, 7 ja 8 - BIND 4.9.4-P1) ja Linuxis (DNS-klient on glibc-s sidumise asemel) võimaldab hankida teavet ka muudest allikatest ( kohalik fail, NIS, NIS+ jne) olenevalt Name Service Switchi sättest. Mõned kliendid võimaldavad teil teavet ise vahemällu salvestada või nscd-d kasutades.

Üldine päringu algoritm on järgmine: rakendusprogramm, mis vajab näiteks hostiaadressi saamiseks oma nime järgi, kutsub välja gethostbyname(3) alamprogrammi vms. Programmi koostamisel lingitakse sellega alamprogrammid libc teegist (glibc), mis kontrollivad vajaliku info olemasolu nscd vahemälus (kui muidugi nscd server töötab). Kui vahemälust teavet ei saa hankida, kasutatakse NSS-i nimeteenuse(te) määramiseks, mida kasutatakse aadressi nime järgi otsimiseks. Eelkõige saavad NSS-i sätted määrata domeeninimede otsimise nimeteenuseks DNS-i. Sel juhul kasutatakse solver(3)-s määratud funktsioone, mis on “päris” DNS-klient (moodustavad DNS-protokolli järgi päringu serverile ja töötlevad vastust).

Töö seadistamine DNS-klient toodetud faili abil /etc/resolv.conf või keskkonnamuutujad, kui protsess algab.

Iga rida /etc/resolv.conf sisaldab ühte lauset, kommentaarid algavad semikooloniga või märgiga # (ettevaatust: klient ei pruugi selles failis vigadest teatada!):

  • nimeserveri teenindava serveri IP-aadress(serveri aadressidega saab määrata kuni 3 rida; vaikimisi kasutatakse samas hostis asuvat serverit (saab määrata ka selle IP-aadressi või aadressi 0.0.0.0 või loopback-aadressi 127.0.0.1 abil); klient küsitleb määratud serverid nende loendi järjekorras, kui te ei oodanud loendist eelmise serveri vastust või saite veateate (serveri port, serveri host või kogu võrk pole saadaval); loendis olevat küsitlust korratakse mitu korda sõltuvalt kliendi versioonist (2 kuni 4); esialgne ooteintervall sõltub versioonist (2 kuni 5 sekundit) ja loendis olevate serverite arvust; iga järgneva loendi läbimisega ooteintervall kahekordistub; kogu ooteaeg ulatub kuni 8.2 versioonide puhul 80 sekundini ja uuemate versioonide puhul 24 sekundini)
  • domeen kohalik-domeeni-nimi(lisatakse suhtelistele domeeninimedele enne otsimist; punkt nime lõpus pole vajalik; vaikimisi tuletatakse hosti domeeninimest (vt hostinimi(1)); nimi kohalik domeen määrab ka vaikeotsingu loendi (bind 4.8.3 jaoks: kohaliku domeeninimi ja selle esivanemate loend, millel on vähemalt kaks lihtsat nime; sidumise uute versioonide puhul: ainult kohaliku domeeni nimi))
  • otsige tühikuga eraldatud domeeninimede loendit(kuni 6 domeeninime eelistuse järjekorras; eesnimi loendis määrab kohaliku domeeninime; domeen ja otsingulaused on üksteist välistavad (käitatakse viimane); otsinguloendit kasutatakse suhteliste domeeninimede lahendamiseks; sidumise 4.8.3 puhul tehakse suhtelise nime lahutus esmalt otsinguloendi järgi (otsimisloendi domeeninimed määratakse omakorda enne DNS-serveri päringut suhtelisest nimest paremale), kui see ei õnnestu, loetakse nimi absoluutseks ja esitatakse veel üks taotlus sidumise uutele versioonidele, esmalt lahendatakse suhteline nimi, mis sisaldab vähemalt ühte punkti, tehakse nii, nagu see oleks absoluutne, kui see ebaõnnestub, kasutatakse otsinguloendit)
  • sortimisloend IP-võrgu aadress/mask...(versioon 4.9 ja uuem; võimaldab kliendil eelistada määratud võrgud mitut aadressi sisaldavate vastuste saamisel paneb ta need nimekirja algusesse, ülejäänud lõppu; Saate määrata kuni 10 võrku)
  • valikuvõimalus...(versioon 4.9 ja uuem; võimaldab teil muuta kliendi seadeid
    • silumine(stdout)
    • ndots:punktide arv(minimaalne punktide arv argumendis, mis põhjustab nimeotsingu enne otsinguloendi kasutamist; vaikimisi on 1)
    • katsed: serveriloendi küsitluste arv(vaikimisi – 2; maksimaalne – 5)
    • timeout:initial-wait-interval(vaikimisi – 5 sekundit; maksimaalne – 30 sekundit)
    • pöörata(iga kõne puhul kasutage koormuse jaotamiseks erinevat serverite järjekorda; levitamine toimub ainult ühe protsessi jooksul - järgmisel programmi käivitamisel on loendis esimene server taas esimene, mida kasutatakse)
    • no-check-nimed(keela lihtsate nimede leksikaalne kontroll, mis sisaldub versioonides 4.9.4 ja vanemates)

Konkreetsel lahendaja(3) juurutamisel võivad olla erinevad parameetrite vaikeväärtused – vt /usr/include/resolv.h. Erinevad programmid saab koostada erinevate DNS-kliendi versioonidega. Õnneks jätab DNS-klient failist /etc/resolv.conf vahele read, millest ta aru ei saa. DNS-kliendi vanemaid versioone (resolv+) võib juhtida /etc/host.conf, sel juhul vaadake host.conf(5). Mõned programmid määravad lähtestamise ajal iseseisvalt DNS-kliendi parameetrite mittestandardsed väärtused.

Keskkonna muutuja LOCALDOMAIN alistab domeeni ja otsingujuhised. Keskkonnamuutuja RES_OPTIONS alistab suvandite lause. Keskkonnamuutuja HOSTALIASES võimaldab määrata domeeninimede sünonüümide loendit (ükshaaval) sisaldava faili nime (nt /etc/host.aliases). lihtne nimi ja selle domeeni sünonüüm ilma tühikuga eraldatud real lõpupunktita).

Kui vajate töötavat kohalik server DNS (tavaliselt domeeninimede määramise tõttu ifconfig-is või marsruudis), siis on soovitatav esitada varumeetod domeeninimede lahendamine NSS-i seadistamise ja faili /etc/hosts täitmisega, muul juhul klientarvutid on sunnitud ootama ühe DNS-serveri laadimist. Seda olulisem on varumeetodi pakkumine DNS-servereid töötavatele hostidele. Parem on alglaadimise ajal DNS-i mitte kasutada. Seal on ka salapärane fail /etc/ppp/resolv.conf.

DNS-i seadistamine MS Windowsis toimub kasutades GUI. Tootja kinnitab, et see on väga lihtne;). Ainus erinevus on DNS-kliendi juurutamine erinevad versioonid MS Windows on suurem kui Linuxi Unix (eriti on W2000 ja XP TCP/IP-pinn võetud FreeBSD-st (NetBSD?):

  • W95 – eraldi virnad jaoks kohalik võrk (Kontrollpaneel-> Võrk -> TCP/IP -> DNS) ja sissehelistamisühendused (My Computer -> Dial-up Networking -> paremklõps soovitud ühendusel -> Properties -> Server Types -> TCP/IP); Sissehelistamisühenduse kasutamisel on soovitatav lahkuda tühi nimekiri DNS-serverid põhipinusse ja valige sissehelistamisühenduste seadistamisel suvand "Serverile määratud nimeserveri aadressid".
  • W98 – visuaalselt ei erine seadistus; serveri tagastatud aadressid sorteeritakse marsruutimistabeli järgi; klient töötab samaaegselt nii põhipinu jaoks määratud serveritega kui ka selle sissehelistamisühenduse jaoks määratud serveritega
  • NT – visuaalselt väga sarnane W95-ga; põhipinu (Juhtpaneel -> Võrk -> Protokollid -> TCP/IP -> DNS) ja sissehelistamisühenduse sätted (Minu arvuti -> Sissehelistusvõrgud -> valige õige ühendus rippmenüüst -> More -> Edit Entry -> Modem Properies -> Server -> TCP/IP) kasutatakse õigel ajal; klient salvestab saadud tulemused vahemällu (protsessi sees); SP4-s hakkab klient pärast esimese serveri tõrget saatma päringuid paralleelselt kõigile talle teadaolevatele serveritele
  • W2000 (Start -> Setting -> Network and Dial-up -> paremklõpsake Kohalik alaÜhendus -> Atribuudid -> TCP/IP); kliendi käitumine on sarnane NT SP4-ga

DNS-serverid

Veidi hiljem avaldan artikli Bind 9 kohta

Artikkel on võetud Bog BOSi veebisaidilt, autor Sergei Jevgenievitš Bogomolov.

Pakkujana virtuaalne infrastruktuur, 1cloud firma on huvitatud võrgutehnoloogiad, millest me oma ajaveebis regulaarselt räägime. Täna oleme koostanud materjali domeeninimede teemal. Selles vaatleme DNS-i toimimise põhiaspekte ja DNS-serverite turvaprobleeme.

Samuti tasub öelda paar sõna vastupidise sobitamise protseduuri kohta - nime saamine esitatud IP-aadressi järgi. See juhtub näiteks meiliserveri kontrollimise ajal. Seal on spetsiaalne domeen in-addr.arpa, mille kirjeid kasutatakse IP-aadresside teisendamiseks sümboolseteks nimedeks. Näiteks aadressi 11.22.33.44 DNS-nime saamiseks võite DNS-serverist küsida kirje 44.33.22.11.in-addr.arpa ja see tagastab vastava sümboolse nime.

Kes haldab ja hooldab DNS-servereid?

Kui sisestate brauseri reale Interneti-ressursi aadressi, saadab see päringu juurtsooni eest vastutavale DNS-serverile. Selliseid servereid on 13 ja neid hallatakse erinevad operaatorid ja organisatsioonid. Näiteks a.root-servers.net IP-aadress on 198.41.0.4 ja seda haldab Verisign, samas kui e.root-servers.net (192.203.230.10) haldab NASA.

Kõik need operaatorid pakuvad seda teenust tasuta ja annab ka katkematu töö, sest kui mõni neist serveritest ebaõnnestub, muutuvad terved Interneti-piirkonnad kättesaamatuks. Varem juur-DNS-serverid, mis on kõigi taotluste töötlemise aluseks domeeninimed Internetis, mis asub Põhja-Ameerika. Alternatiivse adresseerimistehnoloogia kasutuselevõtuga "levisid" need aga kogu maailmas ja tegelikult kasvas nende arv 13-lt 123-le, mis võimaldas DNS-i sihtasutuse töökindlust suurendada.

Teine võimalus on kasutada IP Source Guard funktsiooni. See tugineb uRPF-tehnoloogiale ja DHCP-pakettide nuhkimisele, et filtreerida välja võltsitud liiklus üksikutes lülitiportides. IP Source Guard kontrollib DHCP-liiklust võrgus ja teeb kindlaks, millised IP-aadressid on võrguseadmetele määratud.

Kui see teave on kogutud ja DHCP nuhkimiskoondtabelisse salvestatud, saab IP Source Guard seda kasutada vastuvõetud IP-pakettide filtreerimiseks. võrguseade. Kui pakett võetakse vastu lähte-IP-aadressiga, mis ei ühti DHCP-pakettide nuhkimise liittabeliga, siis pakett visatakse kõrvale.

Märkimist väärib ka utiliit dns-validator, mis jälgib kõigi DNS-pakettide edastamist, sobitab iga päringu vastusega ning kui päised ei ühti, annab sellest kasutajale teada. detailne info saadaval



SEOTUD ARTIKLID