Néha a számítógép újraindítása után, vagy minden nyilvánvaló ok nélkül a kedvenc webhely főoldala helyett a „DNS-kiszolgáló címe nem található” ijesztő üzenet jelenik meg (néha az üzenet még tömörebb: „DNS-szerver hiba ”).

Ebben a cikkben megvizsgáljuk, miért nem válaszol a DNS-kiszolgáló, és mit kell tenni, ha a Windows operációs rendszer nem találja a kiszolgáló DNS-címét.

A szerver DNS-címe nem található: a probléma lehetséges okai

A DNS-kiszolgáló hibáinak leggyakoribb okai a következők:

1. Technikai munka magán a webhelyen vagy az internet-forrást „hosztoló” internetszolgáltató oldalán.

2. Technikai munka az internetszolgáltató oldalán.

3. A számítógép hálózati beállításai hibásak.

Ha egy DNS-szerver hiba csak egy webhelyen „felbukkan” (és a többi weboldal probléma nélkül „betöltődik”, akkor a probléma valószínűleg ennek a webes erőforrásnak az oldalán van, és itt nincs mit tenni: Az biztos, hogy a webhely rendszergazdái tudnak a problémákról, és a lehető leghamarabb megoldják a problémát.

Ha a DNS-szerver több helyen nem elérhető, akkor érdemes ellenőrizni ezeknek az erőforrásoknak a betöltését más számítógépekről/mobileszközökről: ha a szerencsétlen hiba minden PC-n megjelenik, akkor ez vagy a szolgáltatóval, vagy a hálózati eszköz (például útválasztó).

Ebben az esetben megbíznia kell a komplex hálózati varázslatban az automatikus hangolás segítségével, és:

1. Kapcsolja ki az útválasztót, várjon 30 másodpercet, majd kapcsolja be újra.

2. Húzza ki a hálózati kábelt a számítógép LAN-portjából, és csatlakoztassa újra a csatlakozót a hálózati kártya csatlakozójához.

3. Indítsa újra a számítógépet.

A legtöbb esetben az ilyen „műveletek” után a Windows képes megtalálni a szerver DNS-címét, és a kedvenc webhelyei problémamentesen működnek.

Ha a böngésző továbbra is azt írja, hogy a DNS-kiszolgáló nem válaszol, akkor „fel kell tárnia a nehéztüzérséget”.

Ennek a hibának számos egyéb oka is lehet:

1. Vírusok, amelyek automatikusan módosítják a Windows 7 hálózati beállításait.

2. Egy szerencsétlen varázsló, aki manuálisan beállította a .

3. A rendszer-/hálózati programok eltávolítása vagy a DNS-szolgáltatás automatikus indításával kapcsolatos problémák meghibásodott DNS-beállítások.

Hogyan lehet javítani a „DNS-kiszolgáló nem elérhető” hibát?

1. A DNS-gyorsítótár egy olyan adattároló a számítógépen, amelybe a webhelyek neveit rögzítik - ez szükséges a kívánt erőforráshoz való kapcsolódás felgyorsításához. Talán a gyorsítótár törlése segít - ehhez nyomja meg a „Win” + „R” gombot, futtassa az „ipconfig /flushdns” parancsot a terminálon, és próbálja meg újra elérni a webhelyet.

2. Ha a gyorsítótár frissítése nem segített, manuálisan kell regisztrálnia a DNS-kiszolgálókat - valószínűleg ezek a problémák a szolgáltató oldalán. Ehhez nyissa meg újra a parancssori terminált a „Win” + „R” gombbal, és futtassa az „ncpa.cpl” parancsot - megnyílik a „Hálózati kapcsolatok” menü.

2.1. Válassza ki a hálózat eléréséhez használtat -> Properties -> Internet Protocol Version 4 -> Properties.

2.2. Ha valami megjelenik az „Elsődleges” és az „Alternatív” szervereken, próbálja meg bejelölni a „DNS-adatok automatikus fogadása” négyzetet, alkalmazza a módosításokat, és indítsa újra.

2.3. Ha kezdetben volt egy jelölőnégyzet az automatikus visszakereséshez, akkor a „Preferált DNS-kiszolgáló címe” mezőben jelölje be a „8.8.8.8”, az „Alternatív” mezőben pedig a „8.8.4.4” értéket.

Tehát olyan Google nyilvános DNS-szervereket adott meg, amelyek hibátlanul működnek. Alkalmazza a beállításokat, indítsa újra a számítógépet, és próbáljon meg újra csatlakozni a kívánt webhelyhez.

Ha a számítógép nem találja a DNS-kiszolgáló címét, amikor útválasztón keresztül csatlakozik (és nem közvetlenül), meg kell találnia azt a DNS-kiszolgálók lapon, és meg kell adnia ugyanazt a két címet. Ha több címmező van, vagy más címek vannak megadva, ne ijedjen meg, csak adjon meg két címet, és mentse el a beállításokat.

3. Ha ez nem segít, lehet, hogy a hiba vírus miatt jelenik meg.

Ebben az esetben egy teljes rendszerellenőrzés víruskereső szoftverrel, például Dr.Web, Avira, Avast vagy Kaspersky segít.

4. Ellenőrizze, hogy a DNS-szolgáltatás automatikus indítása megfelelően működik-e. Ehhez lépjen a Vezérlőpult -> Adminisztráció -> Szolgáltatások menüpontra,

Keresse meg a DNS-szolgáltatást a listában, és ellenőrizze, hogy az „Automatikus” szerepel-e az „Indítási típus” oszlopban.

5. Ha a fenti intézkedések elvégzése után a „nem található a kiszolgáló DNS-címe” probléma nem oldódik meg, vissza kell állítania a TCP/IP-beállításokat a számítógépen. Itt talál egy ingyenes Microsoft segédprogramot és használati utasítást - https://support.microsoft.com/ru-ru/kb/299357

Folytatva a honlapkészítés témáját, beszéljünk egy olyan fontos szempontról, mint a domain névrendszer - DNS - működése. A kezdeti elhelyezéssel, valamint a helyek különböző szerverek és tárhelyek közötti átvitelével kapcsolatos számos probléma a DNS-zóna beállításával és helyével kapcsolatos. A domain névrendszer működésének megértése megkönnyíti a saját domainek, a kapcsolódó webhelyek és egyéb szolgáltatások kezelését.

Mi az a domain név? Sokak számára ez egyet jelent a webhely címével, például www.site. Ha beírja ezt a címet, szilárdan biztos abban, hogy erre az oldalra kerül, és nem valahol máshol. Ugyanakkor egy tartománynév nemcsak webhelyet, hanem e-mail szervert, rövid üzenetküldő szervert vagy egyéb internetes és hálózati szolgáltatást is jelölhet. A tartománynevek tartomány zónákban szerepelnek, amelyek hierarchikus sorrendben helyezkednek el egymáson belül.

Általános értelemben a domain egy szimbolikus név, amely lehetővé teszi egy autonóm névtér egyedi megcímzését az interneten. És nem csak címet ad, hanem azt is lehetővé teszi, hogy bármely ügyfél gyorsan megtalálja a kívánt csomópontot anélkül, hogy a legcsekélyebb fogalma is lenne a helyéről. Nem túlzás azt állítani, hogy a DNS-rendszer a modern internet alapja abban a formában, ahogyan azt mindannyian ismerjük és megszoktuk.

A DNS-rendszer globális és szigorú hierarchiával rendelkezik. Tekintsük a következő diagramot:

A hierarchia legfelső szintje a ponttal jelölt gyökértartomány, amely az első szintű tartományokról tartalmaz információkat, pl. ru, com, org stb. A gyökérzóna munkáját 13, világszerte elhelyezett, adataikat egymás között folyamatosan replikáló root szerver biztosítja. Valójában több gyökérszerver is létezik, de a protokollszolgáltatások csak 13 legfelső szintű csomópont megadását teszik lehetővé, így a rendszer skálázhatóságát és hibatűrését az egyes gyökérszerverek tükrei biztosítják.

Az első szintű tartományok számunkra jól ismert domain zónák, amelyeket nemzeti és nemzetközi szervezetek is kezelhetnek, és saját felhasználási feltételekkel rendelkeznek. Minden egyes első szintű tartomány zóna lehetővé teszi korlátlan számú másodszintű tartomány elhelyezését, amelyek webhelycímként minden internetfelhasználó számára ismerősek.

A második szintű tartományok viszont egyben tartományi zónák is, és lehetővé teszik harmadik szintű tartományok elhelyezését, amelyekbe, mint egy fészkelő babába, negyedik, ötödik stb. szinteket. Annak érdekében, hogy a különböző zónákban elhelyezkedő csomópontokat egyértelműen azonosítani lehessen, a koncepció teljesen minősített domain név (FQDN, Teljesen minősített domain név), amely tartalmazza a DNS-hierarchiában lévő összes szülőtartománynevet. Például webhelyünk esetében az FQDN a következő lesz: weboldal. Pontosan így, a gyökérzónát jelző ponttal végződve.

Ez egy nagyon fontos szempont. A mindennapi használat során a zárópont elvetése megszokott, de a DNS rekordokban a zárópont hiánya azt jelzi, hogy a domain név az aktuális tartományzónához tartozik, pl. A DNS-kiszolgáló ehhez a névhez hozzáadja a saját tartományzónáját és az összes magasabb szintű zónát a gyökérig.

Például a szerverünkön a zónában weboldal hozzáadunk egy CNAME típusú rekordot, amely egy harmadik fél szerverére mutat, mondjuk a Yandex leveleire. A helyes bejegyzésnek így kell kinéznie:

MailIN CNAMEdomain.mail.yandex.net.

Ebben az esetben az e-mail név nem teljes tartománynév, és a következőre bővül mail.site., ha elfelejtünk pontot tenni a Yandex domain név végére, akkor ez a név szintén nem lesz FQDN, és a teljes domain névvel kell kiegészíteni. A következő hibás bejegyzés:

Levelezés: CNAME domain.mail.yandex.net

Tapasztalatlan szemmel nehéz észrevenni a különbséget, de a Yandex mail webes felülete helyett ez a design egy nem létező címre küld minket: domain.mail.yandex.net.site.

Még egy dolog. A tartományi zónához tartozó összes rekordot a zóna adminisztrátorai írják be saját DNS-kiszolgálójukon. Hogyan válnak ezek a rekordok ismertté a DNS-rendszer számára? Végül is nem értesítjük a magasabb szintű DNS-kiszolgálókat, ha bármilyen rekordot megváltoztattunk.

Bármely DNS-zóna csak a tagcsomópontjairól és a gyermekzónáiról tartalmaz rekordokat. A lefelé irányuló zónák csomópontjaira vonatkozó információkat a rendszer saját szerverein tárolja. Ezt delegálásnak nevezik, és lehetővé teszi a gyökérkiszolgálók terhelésének csökkentését, valamint a szükséges autonómiát a gyermektartományi zónák tulajdonosainak.

Tehát mondjuk vásárolt egy domaint example.org, utána delegálnia kell, pl. adja meg a névszervereket (DNS-kiszolgálókat), amelyek a fájlzónához tartozó rekordokat tartalmazzák. Ezek lehetnek saját szerverei vagy nyilvános szolgáltatásai, például a Yandex DNS.

Ebben az esetben a tartományi zónában org egy bejegyzés kerül hozzáadásra:

Példa IN NS dns1.yandex.net.

Ez azt jelzi, hogy a zóna összes rekordja a szerveren található dns1.yandex.net. A szabályok szerint minden tartományzónának legalább két NS-kiszolgálóval kell rendelkeznie, amelyek különböző alhálózatokban helyezkednek el. A gyakorlatban gyakran beérik egy szerverrel, és két IP-címet vásárolnak hozzá különböző tartományokból.

Most pedig nézzük meg, hogyan történik a szükséges DNS-rekord keresése, és miért teszi lehetővé a szerveren készített rekord a látogatók számára, hogy a világ bármely pontjáról eljuthassanak webhelyére.

Tegyük fel, hogy egy felhasználó meg akarja látogatni a népszerű Yandex Market erőforrást, beírja a megfelelő webhely nevét a böngésző címsorába, és megnyomja az Enter gombot. Ahhoz, hogy egy oldal tartalma a felhasználó számára megjelenjen, a böngészőnek kérést kell küldenie az oldalt kiszolgáló webszervernek, ehhez ismernie kell annak IP címét. Ezért a böngésző felveszi a kapcsolatot a DNS-klienssel, hogy megtudja, melyik cím egyezik a felhasználó által megadott tartománynévvel.

A DNS-kliens viszont ellenőrzi a bejegyzéseket a hosts fájlban, majd a helyi gyorsítótárban, és ott nem találva a szükséges bejegyzéseket, továbbítja a kérést a hálózati beállításokban megadott DNS-kiszolgálónak. Ez valószínűleg egy helyi gyorsítótárazó DNS-proxy, például a dnsmasq vagy egy helyi vállalati DNS-kiszolgáló. Ezek a megoldások általában nem a globális DNS rendszer teljes értékű szerverei, és nem részei annak, csak a helyi zónát szolgálják ki és gyorsítótárazza a DNS kéréseket, így az ilyen kérés, ha az adatok nincsenek a gyorsítótárban, egy magasabb szintre kerül átvitelre. -szintű DNS-kiszolgáló, általában a szolgáltató szervere.

A kérés beérkezése után a szolgáltató szervere ellenőrzi a saját rekordjait, majd a saját gyorsítótárát, és ha az eredményt megtalálja, jelenti azt a kliensnek, ellenkező esetben a szerver kénytelen lesz igénybe venni. rekurzió- keresés a globális DNS rendszerben. A folyamat mechanizmusának jobb megértése érdekében elkészítettük a következő diagramot:

Tehát az ügyfél DNS-kérést küld a szolgáltató szerverének, hogy megtudja a domain címét market.yandex.ru, a szolgáltató szervere nem rendelkezik ilyen információval, ezért felveszi a kapcsolatot az egyik gyökérszerverrel, átadva neki a kérést. A gyökérszerver szintén nem rendelkezik a szükséges rekordokkal, de azt válaszolja, hogy ismeri a zónáért felelős szervert ru - a.dns.ripn.net. Ezzel a névvel együtt a gyökérszerver azonnal jelentheti az IP-címét (és a legtöbb esetben meg is teszi), de lehet, hogy ezt nem teszi meg, ha nem rendelkezik ilyen információval. Ebben az esetben, mielőtt kapcsolatba lépne ezzel a szerverrel, meg kell tennie végezzen még egy rekurzív lekérdezést, csak a nevének meghatározásához.

Miután megtudta a ru zónáért felelős szerver címét, a szolgáltató szervere elküldi neki a kérést, de ez a szerver sem rendelkezik a szükséges rekordokkal, hanem jelenti, hogy mi a zóna yandex a szerver válaszol ns1.yandex.ruÉs Szükségszerűen megadja a címét. Ellenkező esetben a rekurzió nem fejezhető be, mivel a zóna yandex a zónában található szerver válaszol yandex. Ehhez a magasabb zónában a zónát kiszolgáló névszerverekről szóló NS rekord mellett egy "linkelt" A-rekord, amely lehetővé teszi egy ilyen szerver címének megtudását.

Végül egy kérés elküldésével a zónát kiszolgáló szervernek yandex, a szolgáltató szervere megkapja a kívánt tartomány címét és jelenti azt a kliensnek. Az eredményt a gyorsítótárban is elhelyezi a tartomány SOA rekordjában megadott TTL-érték által meghatározott ideig. A gyakorlatban, mivel a rekurzív lekérdezések nagyon drágák, a szolgáltatók rekordgyorsítótárazási ideje figyelmen kívül hagyhatja a tartományi TTL értékeket, és két-négy órától több napig vagy akár egy hétig is elérheti az értékeket.

Most nézzünk még egy pontot. A lekérdezések lehetnek rekurzívak vagy nem rekurzívak. A rekurzív kérés kész választ kap, pl. IP-címek vagy üzenetek arról, hogy a tartomány nem létezik, nincs delegálva stb. A nem rekurzív kérés csak arra a zónára ad választ, amelyért az adott szerver felelős, vagy hibát ad vissza.

Mivel a rekurzív lekérdezések meglehetősen erőforrásigényesek, a legtöbb DNS-kiszolgáló a rekurzív lekérdezéseket nem rekurzív módon dolgozza fel. Vagy ezt szelektíven is megtehetik, például a szolgáltató DNS-kiszolgálói csak a klienseik számára hajtanak végre rekurzív lekérdezéseket, a többi pedig nem rekurzív módon.

Esetünkben a kliens rekurzív kérést küldött a szolgáltató szerverére, amely viszont egymás után nem rekurzív kéréseket küldött, amíg meg nem találta a kívánt szervert, amely a kívánt választ adta. Ugyanakkor nemcsak a felhasználói kérések eredményei, hanem a közbenső kérések eredményei is a szolgáltató szerverének gyorsítótárába kerülnek, ami lehetővé teszi az alábbi ilyen kérések nem rekurzív vagy minimális számú kéréssel történő végrehajtását .

Például, ha egy felhasználó a Yandex Market felkeresése után úgy dönt, hogy használja a levelezési szolgáltatást, a szerver azonnal kérést küld a ns1.yandex.ru, mivel már tudja, hogy melyik szerver tartalmaz rekordokat a zónához yandex.

Elmélettől gyakorlatig

Amikor egy regisztrátortól vásárol domaint, a rendszer felkéri, hogy delegálja azt, pl. adja meg azokat a DNS-kiszolgálókat, amelyeken a tartományzóna elhelyezkedni fog. Ezek lehetnek regisztrátor szerverek (általában ingyenesek), hoszter szerverek, nyilvános DNS szolgáltatások vagy saját névszerverek; ha ugyanabban a domain zónában található, akkor IP-címeket is meg kell adni. Például így néz ki a domain delegálási ablaka egy jól ismert regisztrátornál:

Pontosan mit tegyek oda? Ez attól függ, hogy hol és hogyan tárolja webhelyét. Ha megosztott tárhelyet használ, akkor az összes szükséges rekordot a tárhely automatikusan létrehozza, amikor hozzáadja webhelyét a tárhely vezérlőpultjához, csak delegálnia kell a tartományt a tárhely NS szerverére, pl. jelezze őket ebben az ablakban. Ez a módszer egyszerűsége miatt kiválóan alkalmas kezdőknek, de van egy hátránya is: a DNS-zóna vezérlésének lehetősége a felhasználó részéről hiányzik vagy minimális. Ráadásul megosztott tárhelyen az oldal IP-címét a rendszergazdák megváltoztathatják a felhasználó értesítése nélkül, így ha nem kívánja használni a tárhely NS szerverét, akkor ezt a kérdést mindenképpen meg kell beszélni a technikai támogatással.

Ha egy webhelyet egy másik tárhelyre visz át, akkor át kell vinnie a webhelyet, és a regisztrátornál módosítania kell a régi tárhely névszervereit az új szerverére. De ne feledje, hogy a DNS-kiszolgálók gyorsítótárában lévő információk nem frissülnek azonnal, hanem legalább a TTL tartományérték lejárta után, így egy ideig webhelye továbbra is elérhető a régi címen. Ha sürgősen dolgoznia kell vele, anélkül, hogy megvárná a szolgáltató DNS-gyorsítótárának frissítését, hozzáadhatja a fájlhoz. otthont ad bejegyzés a következő tartalommal:

1.2.3.4 example.com

Ahol 1.2.3.4 És example.com ennek megfelelően az új IP-címet és a domain nevet.

Ha saját VPS-je van, vagy teljes mértékben szeretné irányítani a domain zónát, akkor használja a regisztrátor szervereit vagy nyilvános szolgáltatásokat. Saját névszerver létrehozása véleményünk szerint nem érdemes ötlet, hacsak nem saját tárhelyet csinálsz.

Ebben az esetben létre kell hoznia legalább két A rekordot, amelyek a webhelyet ebben a tartományban kiszolgáló webszerverre mutatnak:

@ IN A 1.2.3.4
www IN A 1.2.3.4

A DNS-rekordok kutya karaktere magát a tartományt jelöli, és létre kell hoznia egy rekordot a www aldomainhez is, hogy azok a felhasználók is hozzáférhessenek, akik a webhely címét www-vel írják be.

Nem vesszük fontolóra bejegyzések hozzáadását e-mailekhez, erről cikkünkben olvashat:

Egy webhely áthelyezésekor csak az A rekordokban lévő IP-címeket kell módosítania, és meg kell várnia a DNS-információk frissítését. Általában ez a legkellemetlenebb pillanat - úgy tűnik, hogy minden megtörtént, de nem változtathatsz semmit, csak várhatsz. De ha követ néhány ajánlást, ez a folyamat a lehető legfájdalommentesebben és a látogatók számára észrevétlenül hajtható végre.

Először is módosítsa a TTL értéket a SOA rekordban. Alapértelmezés szerint ez több óra, és ennyi ideig kell várnia, amíg a DNS-kiszolgáló gyorsítótárában lévő bejegyzés frissül. Az aktuális TTL érték meghatározásához futtassa a parancsot a kívánt tartománynév megadásával:

Nslookup -typr=soa webhely

Esetünkben 4 óra:

Ezért legalább 4 órával (régi TTL érték) a tervezett átvitel előtt módosítsa a TTL értéket alacsonyabb értékre, például 900-ra (15 perc). Ezután állítsa a webhelyet írásvédett módba, és helyezze át az új szerverre. A webhelyet nem szabad kikapcsolni vagy átvinni karbantartásra; hozzáférhető lehet és kell is maradnia. De meg kell akadályoznia, hogy a felhasználók módosítsák és hozzáadják az információkat, pl. megtiltani a regisztrációt, kommentálást, rendelés leadását stb. Ezenkívül ügyeljen arra, hogy jól láthatóan tegyen közzé egy üzenetet a műszaki munkáról és a hozzávetőleges befejezési dátumról.

Annak érdekében, hogy a DNS-rekordok megváltoztatása nélkül dolgozhasson az új kiszolgálóval, adja hozzá a szükséges sort a hosts fájlhoz. Miután elhelyezte a webhelyet az új webhelyen, és megbizonyosodott arról, hogy megfelelően működik, módosítsa a DNS-rekordokat, és most 15 percen belül az első felhasználók elkezdik látogatni webhelyét az új szerveren. A régi szerver funkcionalitását még egy ideig fenn kell tartani, ideális esetben akár egy hétig is, mivel nem minden szolgáltató használja a SOA rekord TTL értékét a gyorsítótár frissítéséhez; a saját beállításai segítségével csökkentheti a terhelést. felszerelés.

Sikeres migráció után a TTL értéket a korábbi értékekre kell növelni, hogy ne keletkezzen szükségtelen terhelés a névszervereken.

Mi a legegyszerűbb sémát vettük figyelembe, de a gyakorlatban a honlapon kívül általában létezik egy irodai hálózat, amelynek sok erőforrása kívülről is elérhető legyen. Tekintsük a következő diagramot:

Nyilvános szervereink vannak a weboldalhoz és az e-mailekhez, valamint egy irodai hálózatunk, amelyhez aldomaint jelöltünk ki hivatal. Ha nincs különösebb probléma a levelezővel és a webszerverrel, akkor az irodaterülettel is vannak lehetőségek. Általában egy helyi zónát saját DNS szolgál ki, és nincs kapcsolata az anyazónával. Globális DNS rendszerzónához iroda.example.com nem létezik, de az azonos nevű gazdagép létezik. Ez akkor indokolt, ha a vállalati hálózat a NAT mögött van, és csomópontjai csak szürke címekkel rendelkeznek, és a külső hozzáférés csak arra az átjáróra történik, amelyre a belső csomópontok megfelelő portjai továbbítva vannak.

Ebben az esetben a zóna DNS-rekordjai example.comígy nézhet ki:

@ IN A 1.2.3.4
www IN A 1.2.3.4
levél A 1.2.3.5
iroda IN A 5.6.7.8

De felmerül némi bonyolultság: a hálózaton belül az ügyfelek belső nevek használatával érik el a hálózati szolgáltatásokat: corp.office.example.com vagy rdp.office.example.com, amelyek a belső „szürke” címekre mutatnak." A helyi hálózaton kívül azonban nem lehet feloldani az ilyen nevek IP-címét, mivel a globális DNS-rendszer számára nincs zóna, amely ezeket tartalmazza. A Split-DNS nevű mechanizmus lehetővé teszi, hogy kikerüljön ebből a helyzetből.amely lehetővé teszi, hogy az ügyfél pozíciójától függően eltérő eredményeket adjon.

A helyi hálózaton az ügyfelek DNS-kérelmeit egy helyi szerver szolgálja ki, amely rendelkezik a megfelelő rekordokkal; a hálózaton kívül a kérések a zónát kiszolgáló szerverhez küldik el. example.com. Ugyanakkor az összes vállalati erőforrás, amelyet a helyi hálózat különböző szerverei képviselnek, kívülről egyetlen címen érhetők el: iroda.example.com. Ezért ideje megjegyezni a becenevet vagy a CNAME rekordot. Ez a bejegyzés lehetővé teszi további mnemonikus nevek vagy álnevek társítását a valódi gazdagépnévhez. Kérjük, vegye figyelembe, hogy az álnevek használata más bejegyzésekben elfogadhatatlan. Esetünkben a következő bejegyzéseket kell hozzáadnunk:

Corp.office IN CNAME iroda.example.com.
rdp.office A CNAME-ben office.example.com.

Mostantól egy kliens, függetlenül a helyétől, ugyanazt a nevet használhatja az erőforrásokhoz való hozzáféréshez, de az eredmények eltérőek lesznek. A helyi hálózaton megkapja a valódi szervercímet és közvetlenül csatlakozik, azon kívül pedig a hálózati átjáróhoz kerül.

A CNAME típusú rekordok a támogatott tartományzónán kívülre történő átirányításra is használhatók. A fő feltétel az, hogy a CNAME rekordnak valódi névre kell mutatnia FQDN formátumban.

Az álnevek másik felhasználási módja a cím lerövidítése. Tegyük fel, hogy a teljes tartomány levelezőszervere example.com olyan szervert szeretnénk használni, amely a moszkvai irodában található, és rendelkezik a címmel mail.iroda.msk.example.com, el kell ismernie, nem tűnik túl vonzónak. Sokkal kényelmesebb lenne egy ilyen cím mail.example.com, nincs ennél egyszerűbb, adja hozzá a következő bejegyzést:

Levelezés CNAME-ben mail.office.msk.example.com.

De ne feledje, hogy más erőforrásrekordokban csak valódi neveket használjon, így ez a rekord helytelen lesz:

example.com. MX 10 levélben

A helyes út a következő lenne:

example.com. IN MX 10 mail.office.msk

Végül beszéljünk a tartományi zónák delegálásáról. A fenti példában azt a helyzetet vizsgáltuk, amikor egy tartományon belül a különböző részlegekhez saját aldomain tartozik, mivel minden részleg saját infrastruktúrával rendelkezik, ezért célszerű delegálni rájuk a saját tartományzónáik kezelését. Erre a célra a zónában example.com minden zónához el kell helyezni egy NS-t és a hozzá tartozó A rekordot. Például:

Msk IN NS ns1.msk.example.com.
msk IN NS ns2.msk.example.com.

ns1.msk IN A 1.2.3.4
ns2.msk IN A 5.6.7.8

Most, amikor hozzáférünk egy címhez, mondjuk mail.iroda.msk.example.com zóna névszerverek example.com megjeleníti a zónát kiszolgáló szerver nevét és címét msk.example.com. Ez lehetővé teszi a zóna adminisztrátorai számára, hogy maguk hajtsák végre a szükséges változtatásokat anélkül, hogy ez befolyásolná a szülőzóna működését, vagy felvenné a kapcsolatot a rendszergazdákkal bármilyen olyan probléma esetén, amely rekordok módosítását igényli.

A DNS-kiszolgálók (angol tartománynévrendszer) állandó elérhetetlenségének problémája sajnos továbbra is fennáll a világháló fehérorosz szegmensében.

Hogyan jelenik meg a DNS-szolgáltatás meghibásodása számítógépen vagy laptopon?

A tálcán (értesítési terület az óra közelében): hálózat ikon felkiáltójellel. Ugyanakkor van pénz a szolgáltató mérlegében; A számítógép (laptop) jól működik.

Ez a probléma a népszerű HUAWEI HG532e ADSL modemnél is előfordul. Néha egy adott eszköz csak az újraindítás után kezd el megfelelően működni.

Amikor a ping parancsot a parancssori értelmezőn keresztül futtatja: csak egy villogó kurzor látható.

A DNS-problémák elhárításának lépései

DNS-probléma megoldása:

1. ellenőrizze, hogy a DNS-kliens szolgáltatás fut-e a számítógépen;
2. Nyilvános DNS-re váltunk a Google-tól.

A DNS szolgáltatás működésének ellenőrzése a Windows rendszerben

A számítógépen nyomja meg a WIN+R billentyűkombinációt (Windows ikon a billentyűzeten).

A megjelenő ablakban írja be a services.msc parancsot. Megjelenik a szolgáltatások teljes listája, keresse meg a DNS-klienst. Ellenőrizzük az indítás típusát – Automatikus, Állapot – futás. RENDBEN. Ha ez a helyzet, menjünk tovább….nem? Javítsuk ki.

Ezután a Google nyilvános DNS-ére váltunk

A következő DNS-kiszolgálócímek használata lapon adja meg az értékeket:

• az első mezőben (preferált DNS szerver) – 8.8.8.8
• a másodikra ​​(alternatív DNS szerver) – 8.8.4.4

Kattintson az OK gombra, és zárja be. A számítógépünk most úgy van beállítva, hogy DNS-címeket fogadjon a Google nyilvános DNS-szolgáltatásától. Egyes esetekben jobb, ha a DNS-kiszolgálót közvetlenül az útválasztó felületén konfigurálják, mint ahogy az a helyzet.

Ezzel befejeződik a számítógép manuális beállítása a Google nyilvános DNS szolgáltatással való együttműködéshez.

A „DNS-szerver nem válaszol” hiba kijavításához általában elegendő a számítógép hálózati kártyájának beállítása, hogy nyilvános Google-szervereken keresztül működjön.

Ugyanakkor a webhelyek megnyitásának sebessége kissé megnőhet - a Google nagy teljesítményű szerverek kiterjedt hálózatával rendelkezik szerte a világon.

Lehetőség van a DNS automatikus konfigurálására speciális szoftver segítségével. A program ebből a szempontból elég érdekes.

Egy gombnyomással módosíthatja a DNS-beállításokat. A funkcionalitás azt is lehetővé teszi, hogy a leggyorsabbat ajánlja.

A globális internethez való csatlakozásunkat nem csak zsinórok és vezetékek biztosítják, hanem szoftveres beállítások is. A legtöbb felhasználó teljes mértékben a szolgáltatójára támaszkodik, és ez elvileg helyes, mert ott nem dolgoznak hülyék. De néha ők is tévednek. Annak érdekében, hogy kevésbé függjünk szolgáltatónk hibáitól, próbáljuk meg kicsit elszakadni az övétől. Természetesen a berendezéseken, vezetékeken, kábeleken, antennákon - ezen nem változtatunk, ebben teljesen a szolgáltatótól függünk, de a szoftveres kapcsolaton - ebben jobban bízom a Google szakembereiben, mint a helyi technikusokban.

Mi történt

DNS (egyszerű magyarázat)?

Az internet egy technikai struktúra. A hálózaton egy felhasználó vagy bármely szolgáltatás minden számítógépének saját digitális IP-címe van, például 24.198.15.6 A hálózat szerverein, amint tudjuk, webhelyeket tárolnak. A hálózati számítógépek közötti kommunikáció a digitális értékek felhasználásával történik. De az emberek könnyebben megjegyzik a szavakat (pl. google.com), mint a hely digitális IP-címét (24.198.15.6). Pontosan azért hozták létre a DNS (Domain Name Service) szolgáltatást, hogy az emberek ne memorizáljanak egy koherens számkészletet, de szavakkal. Feladata, hogy megmondja a hálózati számítógépeknek, hogy melyik digitális IP-cím felel meg egy betűcímnek.

Hogyan ellenőrizhető, hogy a DNS működik-e?

A DNS működését akár a helyi számítógépünkön is tesztelhetjük. Az ellenőrzéshez számítógépünknek csatlakoznia kell az internethez. A start menüben válassza ki a "Futtatás" opciót, írja be a parancsot cmdés nyomja meg az Entert. Megnyílik egy fekete ablak. Egyszerűen fogalmazva, a parancssorba ment. Belép:

és nyomja meg az Entert. Ha csomagokat cserélnek (mint a képen), akkor a DNS működik. Felhívjuk figyelmét, hogy a csomagok cseréje pontosan a 74.125.136.113-as oldal digitális címével, annak IP-címével történik. Az Ön DNS-szolgáltatása a felügyeleti DNS-kiszolgálóktól kapott adatok alapján kérést kapott Öntől a google.com webhely pingelésére, és ennek szó szerinti értékét numerikussá konvertálta.

Honnan tudod, hogy a DNS nem működik?

Ha számítógépe csatlakozik az internethez, de nem nyit meg webhelyeket, előfordulhat, hogy a DNS nem működik. A DNS működésének ellenőrzése meglehetősen egyszerű. Nyissa meg újra a parancssort (fekete képernyő), és pingálja a google.com webhelyet. Ne legyen válasz (a webhelyek nem nyílnak meg), ezért a DNS működésének ellenőrzéséhez nem alfabetikus címeket kell pingelni, hanem numerikus címeket. A parancssorban

Így ellenőrizheti a Google DNS-szerverének elérhetőségét. Felhívjuk figyelmét, hogy a DNS működőképességének ellenőrzéséhez pingelni kell a digitális IP-címet. Ha IP-címmel csomagok cseréje (ping) történik, és a webhelyek nem nyílnak meg a számítógépről, akkor Önnek vagy szolgáltatójának problémái vannak a DNS-sel. Ha a ping nem következik, akkor keresse az internet-hozzáférés problémáját valami másban.

Hogyan lehet DNS-szolgáltatót váltani?

Az internetszolgáltató által alapértelmezés szerint biztosított DNS-kiszolgálók módosításához manuálisan kell beállítania a DNS-értékeket azon az eszközön, amelyen keresztül eléri a hálózatot. Windows-felhasználók számára ki kell választania az adaptert, amelyen keresztül a hálózathoz csatlakozik a hálózati kapcsolatokban, meg kell nyitnia a kapcsolat tulajdonságait, és be kell állítania a DNS-t az „Internet Protocol” beállításokban, vagy a modernebb eszközök esetében az „IP4 Protocol” beállításban. A 8.8.8.8 és 8.8.4.4 értékek nyilvános DNS-kiszolgálók a modern internet vezetőjétől, a Google-tól.

Érdemes megérteni, hogy milyen IP-címeket nem lehet beállítani. A DNS szolgáltatás meghatározott IP-címeken található. Ezenkívül ne használjon bármilyen DNS-t. A DNS egy édes pont a számítógépes csalók számára. Például internetes banki szolgáltatást használ, ha a támadók meghamisítják a DNS-kiszolgálót, és arra kényszerítik Önt, hogy átmenjen a DNS-ükön, akkor átirányíthatják a csaló webhelyeikre. Például megnyitja a https://bank.com webhelyet, de a hamis DNS szolgáltatás nem a valódi internetes bankoláshoz, hanem egy átverő oldalra irányítja. A böngészőben látni fogja, hogy megnyitja a kívánt címet, de valójában gyanútlanul a bűnözők webhelyén lesz.

Miért kell DNS-szolgáltatót váltani?

A DNS segítségével a szolgáltató szabályokat hozhat létre, vagy korlátozásokat írhat elő ügyfelei számára bármely webhely elérésére. Ezenkívül a szolgáltató helytelen beállításai megbéníthatják az ügyfelek munkáját. Minden tisztelettel a helyi internetszolgáltatók iránt, jobban bízom a Google szakembereiben. Persze valószínűleg az amerikai titkosszolgálatokkal dolgoznak együtt, de mi sem vagyunk terroristák.

Vannak más módok is a hálózati hozzáférési beállítások megváltoztatására, mint például a VPN, de ezek technikailag bonyolultabbak, gyakran pénzügyi megoldásokat igényelnek, de természetesen megbízhatóbbak, mint a szokásos DNS-váltás, hiszen változtatással teljes függetlenséget biztosítanak a szolgáltatótól. IP, DNS, hálózati hozzáférési pont, forgalom titkosítása.