DNS-felbontás
- Regisztrálnia kell egy olyan weboldalt, mint a newdomain.com, newdomain.org, newdomain.biz, newdomain.tárhely stb. Manapság nagyon sok új TLD van .munka, .tárhely stb. bármelyik Domain-nyilvántartótól. A leggyakoribbak, mint az Istennap.com, Domain.com, NameCheap.com, Bluehost.com
- Miután megvásárolta a domain nevet a fenti regisztrátortól, most meg kell találnunk egy tárhelyfiókot (vagy lehet megosztott tárhely / viszonteladói tárhely, vagy VPS / dedikált szerver) . Ha megosztott / viszonteladói fiókkal rendelkezik, akkor többnyire egy pár névkiszolgálót adnak nekünk, amelyeket fel kell használniuk arra, hogy a tartományt a szervereikre mutassák. HA vps / dedikált szervereket vásárol, akkor előfordulhat, hogy a kiszolgálót olyan DNS-kiszolgálóval kell beállítanunk, amelyhez főleg elnevezett vagy kötelező csomagokat használunk.
- Ha magát a regisztrátor névszervereket használja, akkor az összes DNS-rekordot manuálisan kell létrehoznia a panelen. Ha cpanel / plesk megosztott tárhelyet használ, akkor többnyire az összes dns rekordot létrehozzák a fiók létrehozása során, és csak a regisztrátor végére kell mutatnia a tárhelyszolgáltató névszervereit.
- Miután rámutatott, akár 24 - 72 órába is beletelhet a változások terjedése az interneten.
A DNS-rekordok megértése
A DNS-rekordok olyan beállítások, amelyek segítenek abban, hogy egy tartományt és a szolgáltatások sokféleségét a megfelelő szerverekre vagy IP-címre irányítsuk. A DNS-rekordok oktatóként működnek, mint az a tartomány, amely az adott ip-re mutat, az az aldomain egy másik ip-re mutat stb. Megfelelő DNS-rekordok nélkül az embereknek emlékezniük kell az IP-címre, az ip-címre való emlékezés pedig fárasztó feladat lesz, és ez játszik szerepet a DNS jelentőségében.
Nem kell emlékeznünk egy IP-címre, mivel az emberek számára mindig az lesz a kérdés, hogy IP-címet használnak-e a weboldalra. Ezért regisztráljuk a domain nevet, és a DNS-t használjuk, hogy helyesen mutasson rá a tárhelyszerverre. A DNS-kiszolgálók vagy csomagok létrehozása előtt be kell írnia az IP-címet a böngészőbe, és emlékeznie kell ugyanarra. Az IPV6 bevezetésével szó szerint lehetetlen megjegyezni az IP-címet azok számára is, akik rendelkeznek a legjobb memória kapacitással.
Több mint 70 + dns rekord van, és elolvashatja az alábbi linket az összes lehetséges DNS-rekordhoz és annak részleteihez
https: // www.iana.org / hozzárendelések / dns-paraméterek / dns-paraméterek.xml
Az alábbi nyilvántartásokat tárgyalom, amelyek a laikusok számára a leginkább szükségesek ahhoz, hogy a webhelye tárolható és az e-mail zökkenőmentesen folyjon.
- SOA Record
- TTL érték
- Rekord
- AAAA rekord
- NS Record
- MX Record
- TXT Record
- SPF rekord
- DKIM Record
- DMARC rekord
- PTR rekord
- CNAME rekord
- SRV Record
- RP Record
- DNSKEY rekords
1. SOA (A HATÓSÁG ELKEZDÉSE) Felvétel
A SOA-lemez a legfontosabb és mégsem annyira népszerű lemez. A DNS zóna fájl működéséhez és eredményeinek megadásához kötelező rögzíteni. Ez a bejegyzés tartalmazza a zóna nevét, a domain zóna fájlját kezelő felelős személy e-mail címét, az aktuális sorszámot, a zóna elsődleges vagy fő névszerverét, valamint néhány időelemet, amelyet másodpercek alatt mérnek és jelenítenek meg.
Az alábbiakban bemutatunk egy minta SOA rekordot
tartomány.com. 86400 SOA ns1-ben.tartomány.com. tulajdonos e-mail.tartomány.com. (2017100505; sorozatszám
3600; frissítés
7200; próbálkozzon újra
1209600; lejár
86400)
Ennek pontos formátuma az alábbiakban található
@ IN SOA elsődleges-név-szerver hostmaster-email (
sorozatszám
frissítés ideje
újrapróbálkozás
time-to-expire
minimum-TTL)
Elsődleges név-kiszolgáló: Megmutatja a névszervert, amely az eredeti dns rekordokat tartalmazza.
Hostmaster-email: A domainért felelős tulajdonos e-mail címe. Időtartamra ".”A @ szimbólum helyébe lép. Az e-mail címekhez, amelyek.”Már ebben is meg fog menekülni egy„ / ”betűvel.
Sorozatszám : Ez a zóna verziószáma, és a zónafájl minden frissítésével növekszik.
Frissítés ideje: Ez az érték azt az időt mutatja, amelyig várni kell a sorszám-frissítés ellenőrzésére. Erre főleg akkor van szükség, ha van egy másodlagos dns vagy dns fürt, amelynek ellenőriznie kell a master fájl frissítését, és a legfrissebbet át kell másolni a fürt többi szerverére. Csak azokra vonatkozik, akik másodlagos DNS-ekkel vagy fürtbeállítással rendelkeznek.
Idő az újrapróbálkozáshoz: Meghatározza, hogy a névszervernek mennyi ideig kell várnia az újrapróbálkozásra, ha az utolsó kísérlet nem sikerült.Csak azokra vonatkozik, akik másodlagos DNS-ekkel vagy fürtbeállítással rendelkeznek.
Lejárati idő: ez határozza meg, hogy mennyi ideig kell várnunk, mielőtt érvénytelennek tekintenénk a másodlagos vagy más fürtnévszerverek adatait, és abbahagynánk a válaszolást az adott zóna kérdéseire.
minimum-TTL: Meddig kell a névszervernek vagy a felbontóknak gyorsítótáraznia a negatív választ.
2. TTL (Time to Live) érték
A TTL érték az az idő másodpercben, amikor egy dns rekordokat egy külső dns szerver vagy névszerver tárol, és ezt követően frissítenie kell a gyorsítótárat, és meg kell adnia a legújabb értéket . Ennek legfőbb jelentősége az áttelepítést tervezi, és a DNS-változtatásokra nincs szükség a leállási idő nélkül. A névszerverek megváltoztatása mindig leállást okozhat, mivel ezekre nincs lehetőségünk. Tehát az áttérés előtt általában megváltoztatjuk a TTL értékét 300 mp-re 1-2 nappal maga előtt, így az áttérés után megváltoztatjuk a névszerver IP-jét a regisztrátor végén, és a régi szerver összes zónafájljának IP-jét új IP-re is megváltoztatjuk. így mindkét esetben elkezdi az új szerverre történő feloldást, vagyis ha a dns régi szerverre kerül, akkor a tartományt az adott szerverről egy új kiszolgálóra irányítja, és ha az újonnan frissített névszervereket veszi át, akkor a új szerver.
Ha nincs megadva ttl érték, akkor ez lesz az összes dns rekord fő alapértelmezett értéke, hacsak nincs megadva egy másik érték a rekordokban.
Minta bejegyzésTTL 14400 USD
3. Rekord
A rekordokat más néven Address Records vagy Host Records néven is ismertek. Ezt főleg arra használják, hogy a tartomány / aldomain stb. A szerver ip címére mutasson. A rekord csak IP-címre oldódik fel, és más argumentum / változó nincs az A rekordban. A rekordokat csak arra használják, hogy IPV4-címre mutassanak.
Az A minta az alábbiakban találhatótartomány.com. 14400 IN A 192.168.1.1
Használhatunk helyettesítő dns rekordot is, amely az összes aldomaint egy ip-be tölti be
*.tartomány.com 14400 IN A 192.168.1.14. AAAA rekord
Az AAAA rekord megegyezik a fenti nyilvántartással, és a rekord célja és felhasználása egyaránt megegyezik. Az egyetlen különbség, hogy ezt arra használják, hogy a tartományt IPV6 IP-re mutassák, és ha a tartománynak is van IPv6 verziója, akkor ezt az A rekordot is jól meg kell mutatnunk .
Az AAAA rekordminta az alábbiakban található
tartomány.com 14400 IN AAAA 0133: 4237: 89bc: cddf: 0123: 4267: 89ab: cddf5. NS (névszerver) rekord
Ideális helyzet lesz mind a névszerver a regisztrátor szintjén, mind a DNS zóna fájlja megegyezik, és a nem egyező ns rekordok bizonyos problémákat okozhatnak egyes internetszolgáltatóknál, de általában nem ez a probléma. Tehát az Elsődleges névkiszolgáló rekordoknak mind a regisztrátorban, mind a DNS-zóna fájlban ott kell lenniük a szerveren, amelyet a regisztrátor említ.
Minta bejegyzéstartomány.com. 86400 IN NS ns1.maindomain.com.
tartomány.com. 86400 IN NS ns2.maindomain.com.
Ha ugyanannak a tartománynak van névszervere, akkor feltétlenül adjon hozzá A rekordokat ezekhez a névkiszolgálókhoz .A fenti példában néhány más registerd névszervert használ, például ns1.maindomain.com. De ha az ns1-et szeretné használni.tartomány.com, mint névszerver a regisztrátorban és a szerveren, be kell állítania a HOST rekordokat a regiszterbe (ami a RAGASZTÁSI rekord), és hozzá kell adnia az alábbi A rekordokat is
ns1 14400 IN A 192.168.1.1ns2 14400 IN A 192.168.1.1
6. MX (Mail Exchange) rekord
Ez egy másik fontos dns rekord, amely meghatározza a domainbe érkező levelek sorsát. Amikor valaki e-mailt küld egy domain alatti e-mail fiókba, a távoli kiszolgáló e-mailt küld az MX rekordokban említett szervernek és a legkisebb prioritású értéknek, amely valójában a legmagasabb prioritású
Minta MX rekordok
tartomány.com 14400 IN MX 10 mail_1.tartomány.comtartomány.com 14400 IN MX 20 mail_2.tartomány.com
tartomány.com 14400 IN MX 30 mail_3.tartomány.com
Ebben a példában, ha mail_1.tartomány.A com nem működik, a leveleket a mail_2 címre szállítjuk.tartomány.com. Ha mail_2.példa.com is leállt, a leveleket a mail_3-nak fogjuk kézbesíteni.tartomány.com.Ezt főleg akkor használják, ha a tartomány több szerveren van hozzáadva, és a levelek ezekben vannak konfigurálva. De ezek a levelek szétszóródnak ezekre a szerverekre, és lehet, hogy ezeket manuálisan kell ellenőriznie.
Ha ugyanazzal a domainnévvel rendelkező MX rekordokat használ, akkor hozzá kell adnia megfelelő dns A rekordokat. Mint az alábbiakban . De ha google alkalmazásokat, Outlookot stb. Használ, akkor nem kell további A rekordot hozzáadnia azok számára, akiknek nincs ellenőrzése ezek felett, és ezeket a szolgáltatóknak hozzá kell adniuk.
mail_1 14400 IN A 192.168.1.1mail_2 14400 IN A 192.168.1.2
mail_3 14400 IN A 192.168.1.3
7. TXT (szöveges) felvétel
A TXT rekordnak vagy a szöveges rekordnak valójában nincs szerepe a domainek funkcionalitásában, és általában valamilyen információ megjelenítésére vagy bizonyos ellenőrzésekre használják, például amikor regisztrál a Google-alkalmazásokba vagy az Outlook Mail szolgáltatásba, akkor megkérik, hogy adjon meg egy TXT rekord, amelyet kérnek (egyedi kód), hogy ellenőrizni tudják a tartomány tulajdonjogát. Az SPF / DKIM rekordok szintén a TXT-n alapulnak, de vannak olyan funkcióik, amelyeket végre lehet hajtani. Ezeket fel lehet használni a tulajdonjog hitelesítésének lehetőségeként, miközben hozzáadják a Google webmester-fiókjához és más, a Google-hoz kapcsolódó szolgáltatásokhoz is.
Az alábbiakban egy minta DNS bejegyzés található a Google ellenőrzéséhez
tartomány.com. 300 IN TXT google-site-verification = gBmnBtGTIz_esMKJBKT-PxLH50M8. SPF (Sender Policy Framework) rekord
Az SPF rekord alapvetően egy TXT rekord, amely rendszerint közzéteszi az összes kijelölt levelezési kiszolgálót egy tartományhoz vagy aldomainhez. A nyilvántartás fő célja a levelek jogszerűségének bizonyítása és a hamis levelek megakadályozása. A célpostaszerver elutasíthatja az e-maileket, ha azok nem a regisztrált vagy említett levélkiszolgálóktól származnak a rekord alapján.
Minta bejegyzéstartomány.com. TXT-ben "v = spf1 + a + mx + ip4: 192.168.1.5 -minden
Ez azt jelenti, hogy ez a tartomány csak az A rekordról, az MX rekordkiszolgálókról és az ip 192-ről is küld majd jogos leveleket.168.1.5 és minden más elutasítható . A fenti SPF rekord mellett a visszatérő szerver ellenőrzi az SPF-ben említett összes szervert és IP-címet. Ha az IP-cím megegyezik, akkor az ellenőrzés átkerül, és ha nem, akkor meghibásodik (az üzenet automatikusan elutasításra kerül), és ha „~ all” -t használunk, ami egy soft fail, amely az üzenet FAIL-ként jelenik meg, de nem lesz elutasította.
Erről a linkről további sytanx-okra hivatkozhat.
9. DKIM (DomainKeys Identified Mail) rekord
Ez egy TXT rekord is, amely e-mail hitelesítési protokoll, és egy kicsit bonyolultabb, mint az SPF. Ez a rekord egy aldomainhez készült, amelynek egyedi választója van a kulcshoz, majd egy „.Egy ilyen rekord hozzáadásával digitális aláírást ad az e-mail fejlécéhez. Ezt az aláírást a közzétett DKIM rekord nyilvános kulcsával ellenőrizzük. Ez egy kicsit bonyolult, és ha cpanelben van, akkor lehetőséget biztosítanak arra, hogy ezt egyszerűen elvégezhesse egy kattintás engedélyezési opcióval.
Minta bejegyzésalapértelmezett._domainkey 14400 IN TXT "v = DKIM1; k = rsa;
p = MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAmDb9e2q41oLc0ZDtSNo2Ik4khVMUMkv98N1Y0
FehUCcFUIUIUIUIUIuiuicfhdyeytrytrryuytytfyfyfytrytrytrtyrytrytrytrytrytdyBQ3XatuaEj
qGR0zfaY6RSU ++ gqGF8ZRpjJd + O3AcqRZT4ZT8d7Uhye6Ctgcv3kQEd5I2dTSpodIzWey8reysHJMdCvulRJYdP "
UWj5PrHfkwY7ec0ZNggTOpmlByXIPRx0Q / oBS9TLlAs785XJMNWjubyyjC6V5JUQ + tRyhwa28TWM / l6 / EIcYNBZE
fWx8oHQsBFLT0dNsRhq9ExX0UDMmbddD0zWoKtx + Wb7ItG0HPPVqne8jWkeXQIDAQAB \;
10. DMARC rekord
A DMARC rekord csak akkor működik, ha vannak megfelelő SPF és SKIM rekordok. Ez a levelezési hitelesítési folyamat házirendje, és az, hogy a fogadó szervernek miként kell kezelnie a levelet, ha ez sérti az irányelvet. Amikor egy bejövő levél érkezik a távoli kiszolgálóra, lekérdezi a DMARC rekordját, és győződjön meg róla, hogy lekérdezi az alábbi kérdéseket
> Megfelelő-e a bejövő levelek DKIM aláírása ?
> Az üzenet egy engedélyezett ip / szerver hosztnévről származik-e, amelyet az SPF rekord említ.
> A bejövő e-mailek fejléce rendelkezik-e az RFC 5322 szerinti megfelelő beállítással.
Minta bejegyzés
_dmarc.tartomány.com. TXT-ben "v = DMARC1 \; p = nincs \; rua = mailto: [email protected] \;ruf = mailto: [e-mail védett] \; pct = 100 "
_dmarc.tartomány.com: Aldomain, amely a DMARC Alone hitelesítéséhez van beállítva.
v = DMARC1: A Dmarc verzió használatban van.
p = nincs: megemlíti a politika preferált kezelését
rua =mailto: [e-mail védett] : Összevont jelentéseket küldünk erre
ruf =mailto: [e-mail védett] : A Foreincsic jelentéseket erre az e-mail fiókra kell elküldeni
pct = 100: ez a százalékos azon e-mailek száma, amelyeknél a tulajdonos szeretné, ha a rekordot ellenőriznék és felhasználnák az irányelvek frissítéséhez
A DMARC / SPF / DKIM szükséges mind a postai szolgáltatások megfelelő hitelesítéséhez
11. PTR (mutató) rekord
A PTR rekordok fordított DNS néven is ismertek az ip számára. A PTR rekordokat általában a Hosting Provider vagy a Server Provider szintjén állítják be. A PTR rekordok segítenek egy ip cím és egy tartomány vagy aldomain (általában egy FQDN teljesen minősített tartománynév) összehangolásában, ami elősegíti a fordított DNS lekérdezések megfelelő működését.
Tehát előfeltételként a fordított DNS beállításához egy IP-hez, most néhány napig a Hosting / Server Providers kéri, hogy először állítson be egy rekordot a tartományra / aldomainre az adott IP-re, és ha ez megtörtént, az Adatközpont beállítja az RDNS-t (Reverse DNS) rekord).
12.CNAME (kanonikus név) rekord
A CNAME rekord segít egy tartományt vagy aldomént egy másik tartományra vagy aldomainre irányítani.
Minta bejegyzés:newdomain.com 14400 CNAME tartományban.com.
mail 14400 IN CNAME mail.tartomány.com.
Az 1. példa az új tartományra mutat.com domainre.com, ahol a második példa a levelek mutatása.newdomain.com levélben.tartomány.com. Ezzel a nyilvántartással, amikor egy kérés érkezik az új domainre.com, talál egy CNAME rekordot a tartományra.com. Ezután új domainkeresést indít.com, és elküldi a kérést a domainnek.com és ugyanez a helyzet a második lemezzel is.
13.SRV (szolgáltatás) nyilvántartás
Az SRV rekord segít abban, hogy rámutassunk egy adott szolgáltatásra, amely az Ön domainjén vagy aldomainjén fut egy céltartományra. Ez segít abban, hogy az egyes szolgáltatások, például a Csevegőszerver vagy az üzenetküldő szolgáltatások forgalmát egy másik szerverre irányítsuk.
Minta bejegyzés:
_sipfederationtls._tcp. 3600 IN SRV 100 1 5061 szippantott.online.lync.com._szolgáltatás._jegyzőkönyv.példa.com 3600 IN SRV 10 0 5060 szolgáltatás.példa.com
_szolgáltatás._proto.név. TTL osztály SRV prioritású súlyport cél.
Szolgáltatás : a szolgáltatások nevét aláhúzással „_” kell kezdeni, majd egy „.”Szolgáltatás lehet bármilyen, például _chat, _xmpp, _sipfederationtls (amelyet a Microsoft Exchange szerverekhez használnak) stb.
Protokoll:A protokoll nevét is aláhúzással kell kezdeni, majd egy „.”Ebben az esetben„ _tcp.”És azt mondja nekünk, hogy egy TCP protokoll van használatban.
Név: A név vagy a domain név az a domain, amely az eredeti forgalmat befogadja a szolgáltatásért.
Kiemelten fontos : Ez a fenti példákban említett első szám (100, illetve 10) segít beállítani a célkiszolgáló prioritását, az Alacsonyabb szám pedig magasabb prioritást jelent. Ez hasonló az MX rekord prioritáshoz, és hasonlóan működik, mivel beállíthatunk egy másik rekordot visszaesésként és egy másik prioritással is.
Súly : Ha hasonló rekordokat hozunk létre ugyanolyan prioritással, akkor a döntő tényező fogja megadni ezt a bizonyos értéket. A súly a fenti példákban 1, illetve 0.
Port: ez azt a TCP vagy UDP portot mutatja, amelyen a szolgáltatás fut.
Cél : ez az a célaldomain vagy -tartomány, ahová ezt a szolgáltatást átirányítják, és érvényes A / AAAA rekorddal kell rendelkeznie ahhoz, hogy a forgalmat oda irányítsák.
14. RP (Felelős személy) nyilvántartás
Erre általában napok óta nincs szükség, mivel van egy e-mail cím a SOA rekordhoz. De ha bármelyik domainnek külön meg kell említenie az alapértelmezett SOA rekord e-mail fiókot, akkor hozzáadhatunk RP rekordot.
15. DNSKEY rekord
A DNS kulcs rekord tartalmaz egy nyilvános kulcsot, amelyet a felbontók használnak a dnssec aláírások ellenőrzésére.
Minta bejegyzés
tartomány.com. 300 IN DNSKEY 257 3 5 Z10wdRIHGJGGIUGIUGKUOIKHpouptYRSyrsYRDfYTpoPOipoEUofZcndFN2aVd ==
Név ttl osztály RRtype flags_filed Protokoll algoritmus public_key
Név: ez általában a domain név vagy a hosztnév
BAN BEN : A rekordosztály képviselete, az alapértelmezett pedig IN (ami azt jelenti, hogy Internet)
Rekord típusa: rekord típusa a rekord típusa, ebben az esetben pedig DNSKEY lesz
Zászlók: A beküldött zászlók vezetékes formátumban vannak, ami 2 bájt hosszú karakter. A lehetséges értékek: 0, 256 és 257. Ha az érték 256, az azt jelenti, hogy az dnskey rekord fizetett ZSK-t (zóna-aláíró kulcs) tart, és ha az értéke 257, akkor ez tartalmazza a KSK-t (kulcs-aláíró kulcselem). Röviden: ez a fielf tartalmaz egy ODD számot, amikor KSK kulcspárral rendelkezik.
Jegyzőkönyv: Ennek értéke mindig 3, a DNSSEC esetében.
Nyilvános kulcs: a nyilvános kulcs a kulcsadat, és ebben az esetben ez a „Z10wdRIHGJGGIUGIUGKUOIKHpouptYRSyrsYRDfYTpoPOipoEUofZcndFN2aVd ==”
Algoritmus: Segít azonosítani a public_keys-eket különböző algoritmusok segítségével, és az alábbiak a leggyakrabban használtak
- 1 = RSA / MD5
- 2 = Diffie-Hellman (ezt a BIND nem támogatja)
- 3 = DSA
- 4 = Fenntartva
- 5 = RSA / SHA1
- 6 = DSA / SHA1 / NSEC3
- 7 = RSA / SHA1 / NSEC3
- 8 = RSA / SHA-256
- 10 = RSA / SHA-512
Következtetés
Remélem, ez valóban segít valamennyien megérteni a DNS-t, és biztosítja, hogy a tárhely beállítása megfelelő legyen.