Vodič za sistemske administratore

5. DNS i e-pošta

Tada Alice osjeti kako joj se oči zatvaraju.
Pospano je promrmljala: - Jedu li mačke mušice? Jedu li mačke mušice? Ponekad je uspevala: - Jedu li mušice mačke?
Alis nije znala odgovor ni na prvo ni na drugo pitanje, pa joj nije bilo važno na koji način ih je postavila.

Vjerovatno ste već bili napadnuti pospanošću uzrokovanom prethodnim dugačkim poglavljem. Srećom, ovo poglavlje se fokusira na temu za koju će vjerovatno biti zainteresovani administratori sistema i pošte: interakcija između DNS-a i e-pošte. Čak i ako vas ova tema ne zanima, trebat će vam mnogo manje vremena za diskusiju nego u prethodnom poglavlju.

Jedna od prednosti DNS-a u odnosu na host tabele je poboljšana podrška za rutiranje pošte. U danima kada je samo datoteka HOSTS.TXT (i njen nasljednik /etc/hosts) bila dostupna pošiljaocima pošte, oni su najbolji slucaj mogao pokušati dostaviti poštu na IP adresu hosta. U slučaju neuspjeha, preostalo je samo nastaviti povremene pokušaje da se pismo pošalje ili vrati pošiljaocu.

DNS pruža načine za specificiranje standby čvorova za prijenos mail poruke. Ovaj mehanizam omogućava jednom čvoru da obavlja dužnosti drugih čvorova koji se odnose na isporuku pošte. Ovo vam, na primjer, omogućava da dodijelite obradu pošte za čvorove koji su stanice bez diska serveru koji ih opslužuje.

Za razliku od host tabela, DNS dozvoljava proizvoljna imena u adresama e-pošte. Moguće je – što većina organizacija na Internetu radi – koristiti Ime domena glavna zona direktnog mapiranja u e-mail adresi.

Također možete dodati imena domena u prilagođenu zonu koja će se koristiti samo u adresama e-pošte i nije povezana ni sa jednim specifičnim mrežnim domaćinima. Takođe, jedna logička adresa e-pošte može predstavljati više servera pošte. Nasuprot tome, kada se koriste tablice hosta, samo imena hosta su se mogla koristiti u poštanskim adresama, i to je to.

općenito, navedene mogućnosti daju administratorima mnogo više slobode u konfigurisanju usmjeravanja e-pošte preko mreža.

MX zapisi

DNS koristi jednu vrstu RR zapisa za implementaciju naprednog rutiranja e-pošte: MX zapis. U početku su funkcije MX zapisa bile podijeljene između dva zapisa: MD zapisa (odredište pošte) i MF zapisa (prosljeđivač pošte). MD zapis je sadržavao konačnu adresu na koju bi trebala biti dostavljena pošta naslovljena na određeni domen; MF zapis sadržavao je informacije o hostu koji bi proslijedio poštu do konačnog odredišta ako to odredište ne bi moglo primiti poštu normalnom rutom.

Rano iskustvo sa DNS-om na ARPAnetu pokazalo je da razdvajanje ovih funkcija nije baš efikasno u praksi. Programu za e-poštu bio je potreban i MD i MF zapis za svako ime domene da bi odlučio gdje će poslati poštu - jedan od njih ne bi bio dovoljan. Eksplicitno traženje informacija bilo koje vrste (bilo da se radi o MD ili MF) dovelo je do keširanja samo zapisa ovog tipa od strane DNS servera. Dakle, pošiljaoci pošte ili su morali napraviti dva upita (po jedan za svaki tip zapisa) ili jednostavno odbaciti keširane rezultate. Kao rezultat toga, troškovi usmjeravanja pošte bili su znatno veći od troškova ostalih usluga, što se na kraju smatralo neprihvatljivim.

Da bi se riješio problem, ove vrste zapisa su objedinjene u jedan tip - MX. Programi za poštu počeli su da se zadovoljavaju skupom MX zapisa za određeno ime domene kako bi doneli odluku o tome kako da rutiraju mail poruke. Upotreba keširanih MX zapisa postala je potpuno legalna, pod uslovom da se poštuju TTL vrijednosti.

MX zapisi definišu razmjenjivač pošte za ime domene, odnosno host koji će obraditi ili proslijediti mail poruke namijenjene primaocu u navedenom domenu (na primjer, kroz zaštitni zid). Obrada pošte se odnosi ili na isporuku e-mail poruka do konačnog odredišta ili na njihov prijenos kroz gateway do drugog transporta pošte, kao što je X.400. Relej znači prijenos pošte na krajnju domenu ili drugi prijenos pošte koji se nalazi "bliže" konačnom odredištu u smislu udaljenosti STMP (Simple Mail). Transfer Protocol, Internet Mail Delivery Protocol). Ponekad, tokom prosljeđivanja, e-mail poruke se stavljaju u red za prijenos pošte na neko vrijeme.

Da bi se spriječile petlje usmjeravanja pošte, MX zapisi sadrže, pored imena domene releja pošte, sekundarni parametar: vrijednost preferencije. Prioritet je 16-bitni pozitivan cijeli broj (može biti od 0 do 65535) koji specificira prioritet za prijenos pošte. Recimo da je ovaj MX zapis:

peets.mpk.ca.us. IN MX 10 relay.hp.com.

identifikuje relay.hp.com kao relej pošte za peets.mpk.ca.us sa prioritetom 10.

Prilikom odabira prioriteta releja pošte za konkretnu adresu odrediti kojim redoslijedom će ih koristiti pošiljatelj pošte. Sama vrijednost nije posebno bitna, važan je njen odnos prema prioritetima definiranim za druge mail releje: da li je veća ili manja od drugih vrijednosti? U nedostatku drugih unosa, slijedeći unosi

plange.puntacana.dr. IN MX 1 listo.puntacana.dr.
plange.puntacana.dr. IN MX 2 hep.puntacana.dr.

apsolutno su ekvivalentni:

plange.puntacana.dr. IN MX 50 listo.puntacana.dr.
plange.puntacana.dr. IN MX 100 hep.puntacana.dr.

Pošiljači treba da pokušaju da isporuče poštu relejima pošte, počevši od onih sa najnižim vrednostima prioriteta. Možda ne izgleda baš prirodno da najpoželjniji relej ima najniži prioritet. Ali pošto je prioritet nepotpisana vrijednost, to omogućava da se "najboljem" releju pošte dodijeli prioritet 0.

Ako se pošta ne može isporučiti preko najpoželjnijih releja pošte, pošiljalac pošte treba da pokuša da isporuči preko manje preferiranih (većeg prioriteta) releja, birajući ih po rastućem prioritetu. Ukratko govoreći, programi za e-poštu treba ispitati više preferiranih releja prije manje preferiranih. Prioriteti mogu biti isti za dva ili više releja, omogućavajući pošiljaocima pošte da sami izaberu željene releje. Međutim, pošiljatelj pošte mora ispitati sve releje pošte sa određenim prioritetom prije nego što pređe na sljedeću višu vrijednost.

Tako, na primjer, MX zapisi za oreilly.com mogu izgledati ovako:

oreilly.com. U MX 0 ora.oreilly.com.
oreilly.com. U MX 10 ruby.oreilly.com.
oreilly.com. U MX 10 opal.oreilly.com.

Ovi MX zapisi upućuju pošiljaoce pošte da pokušaju isporučiti poštu na oreilly.com slanjem:

1. ora.oreilly.com.
2. Zatim jedan sa ruby.oreilly.com ili opal.oreilly.com.
3. Preostali relej sa prioritetom 10 (onaj koji nije korišten u koraku 2).

Naravno, kada se pošta isporuči jednom od releja pošte oreilly.com, proces glasanja se zaustavlja. Nakon uspješne dostave pošte preko ora.oreilly.com, nema smisla slati je preko ruby.oreilly. com ili opal.oreilly.com.

Imajte na umu da oreilly.com nije domaćin; ovo je naziv domene O'Reilly-jeve primarne zone direktnog prikaza O'Reilly koristi ovo ime domene kao odredište za poštu za sve koji rade za njega. Mnogo je lakše zapamtiti jedan e-mail, oreilly.com, nego zapamtiti koji je sajt - ruby.oreilly.com ili amber.oreilly.com - zapravo kreirao nalog e-pošte za svakog pojedinačnog zaposlenog.

Naravno, takav sistem zahtijeva da administrator mailer-a na ora.oreilly.com održava pseudonim za sve naloge e-pošte zaposlenih u O "Reillyju, prosljeđujući njihovu poštu na mašine sa kojih će zaposleni čitati ovu poštu, ili kreirati server koji omogućava korisnicima da daljinski čitaju vašu poštu putem POP ili IMAP protokola.

Šta se događa ako za odredište ne postoji MX zapis, ali postoji barem jedan A zapis? Zar pošiljalac pošte jednostavno ne isporučuje poštu na odredište? Naravno, više kasnije verzije sendmail programi se mogu kompajlirati sa ovim algoritmom. Međutim, većina dobavljača gradi sendmail sa opuštenijim algoritmom: ako nema MX zapisa, ali postoji barem jedan A zapis, pokušat će se isporučiti pošta na navedenu adresu. Verzija 8 sendmail programa napravljenog iz kutije pokušava da isporuči poštu navedene adrese u nedostatku MX zapisa. Provjerite dokumentaciju priloženu uz vaš sistem ako trebate znati da li se šalje mail server poruke na navedene adrese ako postoji samo jedan adresni zapis.

Uprkos činjenici da skoro svi pošiljaoci pošte isporučuju poruke na odgovarajuće adrese čak i ako je prisutan samo zapis adrese, ima smisla kreirati najmanje jedan MX zapis za svako važeće odredište. Kada je u pitanju isporuka e-mail poruka, većina pošiljalaca pošte, uključujući sendmail, prvo provjerava MX zapise za navedena odredišta. Ako ih nema, DNS server - obično jedan od autoritativnih - mora i dalje odgovoriti na ovaj zahtjev, nakon čega sendmail nastavlja tražiti A zapise. Potrebno je Dodatno vrijeme, usporava isporuku e-mail poruka i dodatno opterećuje autoritativne DNS servere u vašoj zoni. Ako umjesto toga jednostavno dodate MX zapis za svako odredište, navodeći ime domene koje se mapira na istu adresu kao što je vraćeno pretraživanjem zapisa adrese, pošiljaocu pošte ostaje samo jedan upit za slanje, nakon čega lokalni DNS server pošiljatelja kešira da MX - Snimi za kasniju upotrebu.

Konačno, imajte na umu da ne možete koristiti IP adresu umjesto imena domene da navedete relej e-pošte (u polju zapisa nakon prioriteta). Neki programi za e-poštu su dovoljno liberalni da prihvate IP adresu, ali to nije slučaj sa svim programima, tako da ćete doživjeti nepredvidive probleme s poštom.

Mislim da će mnogi biti zainteresirani da konačno saznaju kako mail funkcionira. U nekoliko članaka pokušat ću što je više moguće običan jezik opisati sva glavna pitanja vezana za rad e-pošte općenito i željene postavke- posebno.

Radi jednostavnosti i smanjenja broja slova, razmotrit ćemo najjednostavniju (i najčešću) situaciju:

1 naziv domene (example.com).
1 mail domena(*@example.com).
1 server pošte (mail.example.com).
1 IP adresa (127.127.127.127).

Što se tiče pošte, zanimaju nas četiri vrste zapisa u DNS-u.

Drugi je opcioni, bez njega će pošta biti poslata na A zapis. U principu, možete i bez ostalog, ali šanse da će vaše pismo biti odbijeno kao neželjena pošta značajno se povećavaju - isti mail.ru odbija gotovo svu poštu čije IP adrese nemaju PTR, ili se PTR odnosi na dial-up provajdere. I to je tačno.

A-rekord

A (Adresa) - zapis koji ukazuje na IP adresu imena domene koja nam je potrebna. Za ispravan rad mail zahteva A-rekord servera pošte (mail.example.com). Pogledajte, u našem slučaju to će biti ovako:

mail IN A 127.127.127.127

gdje:
mail - domena.
IN A - vrsta zapisa.
127.127.127.127 - IP našeg mail servera.

MX zapisi.

MX ( Razmjena pošte) je primarni DNS zapis za e-poštu. Određuje koji serveri rukuju poštom za našu domenu.

Imamo jedan mail domen - @example.com. A jedan mail server je mail.example.com. Shodno tome, unos će izgledati ovako:

example.com. U MX 10 mail.example.com

gdje:
example.com je domena za koju se obrađuje pošta.
IN MX - tip zapisa.
10 - prioritet pisanja (Više detalja - ispod).
mail.example.com - A-ime mail servera.

MX zapis mora tačno ukazivati ​​na A zapis servera pošte. Stavljanje MX kao pokazivača na IP ili CNAME nije ispravno.

Prioritet MX zapisa je potreban kada postoji više od jednog servera pošte za istu domenu (na primjer, Google mail ima ih šest). Označava koji server se kontaktira prvi, drugi i tako dalje (ako je prvi (drugi, deseti) server nedostupan ili preopterećen, ili ne može prihvatiti pismo iz drugih razloga). Logika je jednostavna - prioritet je onaj čiji je broj manji. Redoslijed brojeva nije ograničen, najmanje 10-20-30, najmanje 1000-2000-3000.

Ako domena nema nijedan MX zapis, ili ako nijedan od MX servera nije dostupan, server pošiljaoca će pokušati da isporuči poštu na IP naveden u A-zapisu domene. Ovo se zove A-isporuka, ali u principu nije košer i ne koriste ga mnogi serveri - morate navesti MX, čak i ako postoji samo jedan.

PTR zapis.

PTR (PoinTeR) - tzv. pisati natrag". Omogućava obrnuto rješavanje IP adrese na FQDN host.

Naš obrnuti IP će izgledati ovako: 127.127.127.127.in-addr.arpa. IN ovaj primjer teško je vidjeti, ali adresa je invertirana u obrnutoj zoni. One. IP 192.168.0.1 će izgledati kao 1.0.168.192.in-addr.arpa.

Za ispravno prepoznavanje hosta, zapis IP adrese sa koje se šalje mora odgovarati imenu hosta servera e-pošte poslanog na HELO\EHLO.

PTR zapis u našem slučaju, odnosno:

127.127.127.127.in-addr.arpa IN PTR mail.example.com.

Vlasnik bloka IP adresa može registrovati ovaj unos (Pročitajte moj članak o distribuciji adresnog prostora). Ako niste jedan od njih i primili ste adrese od provajdera, kontaktirajte svog provajdera ili data centar da postavi rekord.

TXT zapis i SPF.

TXT (TeXT) - unos teksta DNS. Nas to zanima samo zato što može (i u savremeni svet- mora) sadržavati SPF.

SPF (Sender Policy Framework) - zapis koji vam omogućava da navedete koji serveri imaju pravo da šalju poštu u ime vašeg domena (predstavljajući se kao vaš server ili sa povratnom adresom u vašem domenu).

Ako ovaj unos ne postoji, a neko pokuša poslati email (obično neželjenu poštu) sa povratnom adresom na vašoj domeni, većina servera će ga odbiti. Ili ne, i dobićete veliki problemi sa vlastitim data centrom ili provajderom i reputacijom spamera 🙂

SPF zapis izgleda ovako:

v=spf1 ip4:1.1.1.1 +a +mx -sve (primjer).

v=spf1 - verzija protokola.
(+\-)a - dozvola ili zabrana slanja pošte sa IP adrese koja odgovara A-zapisu domene.
(+\-)mx - dozvoljava ili zabranjuje slanje pošte sa IP adrese koja odgovara MX-zapisu domene.
ip4:ip- eksplicitna indikacija IP sa kojeg možete primati poštu u ime domene.
(~\-all) - odbiti ili prihvatiti poštu sa IP adresa koje nisu navedene i nisu eksplicitno specificirane.

U našem slučaju, TXT SPF zapis će izgledati ovako:

example.com. U TXT-u "v=spf1 +mx +a -sve"

Dakle, dozvolili smo primanje pošte u ime domena sa IP adresama koje odgovaraju A ili MX zapisima i zabranili primanje sa drugih adresa - niko ne može da pošalje neželjenu poštu pretvarajući se da smo mi ili da obmane naše korisnike slanjem phishing linka u njihovo ime. podrška.

Za ispravan rad mail servera, važno je imati pravilno konfiguriranu DNS zonu. Već smo se dotakli nekih aspekata vezanih za DNS sistem, danas ćemo se detaljnije zadržati na ovom pitanju. DNS postavka zone se odnosi na pripremne operacije prije postavljanja mail servera i od toga direktno zavisi zdravlje e-mail sistema.

Pogrešne postavke može uzrokovati da se pošta ne može isporučiti na vaš server pošte ili da serveri primaoca odbiju vašu poštu. Zaista, ako zapisi vaše zone ne sadrže informacije o serveru pošte, gdje treba slati poštu? U dedino selo? Možete, naravno, zatražiti od svog provajdera da konfiguriše DNS zonu, ali je bolje da to učinite sami.

Šta nam treba? Namenska IP adresa (recimo 11.22.33.44) koju morate dobiti od svog ISP-a. Ime domene (na primjer.com), može se registrovati kod bilo kog registratora ili njihovog partnera. Prilikom registracije kod partnera provjerite da li on omogućava pristup upravljanju DNS zonom, inače ćete morati potrošiti dodatno vrijeme, živce i novac na prijenos domene na registratora.

Ako već imate domenu i, najvjerovatnije, na njoj radi stranica, provjerite da li je to moguće DNS upravljanje zone sa panela hosting provajdera, u suprotnom je bolje prenijeti domen na registratora, za to kontaktirajte podršku provajdera.

Dakle, imamo domen. Koje zapise sadrži njena DNS zona? Prvo, to je SOA zapis - opis zone. Nećemo detaljno analizirati sve unose, ovo je izvan okvira našeg članka, ali jeste opšta ideja o njima je neophodno. Također bi trebala postojati dva NS zapisa koji upućuju na servere imena ( DNS serveri) serviranje dati domen, to će biti serveri registratora ili hosting provajdera.

Prvi unos koji treba da dodate biće A unos ili unos imena. Trebalo bi da upućuje na IP adresu vašeg servera ako odlučite da sami uslužite sve zahtjeve na domenu ili na IP adresu hosting provajdera ako odlučite da hostirate svoju web lokaciju. Kada se hostuje sajt, domen se obično delegira na njegove DNS servere (registruju se odgovarajući NS zapisi) i A zapis će se automatski napraviti kada se domen parkira.

Ova opcija je najčešća, ali ako je potrebno, uvijek možete sami kreirati A zapis. Ovaj unos ima oblik

example.com. U A 22.11.33.44

U našem primjeru, 22.11.33.44 je adresa našeg hosting provajdera, gdje se nalazi stranica. Obratite pažnju na tačku na kraju imena, to znači da je ime apsolutno, ako nema tačke, naziv se smatra relativnim i dodaje mu se ime domena iz SOA-e. Unos možete provjeriti komandom nslookup.

Da bi mail server radio, potrebno je da kreirate MX zapis, koji treba da ukazuje na naš mail server. Kreirajmo unos za ovo:

example.com. U MX 10 mail.example.com.

Možete i samo napisati:

example.com. U MX 10 mail

Ovom nazivu (bez tačke na kraju) example.com će se automatski dodati. Broj 10 određuje prioritet servera, što je niži, to je veći prioritet. Inače, DNS zona možda već sadrži MX zapis u obliku:

example.com. U MX 0 example.com.

Obično ovaj unos automatski kreira hosting provajder prilikom hostovanja stranice, mora se ukloniti.

Sada kreirajmo A zapis za mail.example.com

Mail.example.com. U A 11.22.33.44

Sada će sva pošta za domen example.com biti usmjerena na mail host sa adresom 11.22.33.44, tj. vaš mail server, dok će stranica example.com nastaviti sa radom na serveru provajdera 33.11.44.
Može se postaviti pitanje zašto ne možete odmah navesti IP adresu mail servera u MX zapisu? U principu, moguće je, neki to rade, ali nije u skladu sa DNS specifikacijama.

Također možete napraviti pseudonime za mail server kao što je pop.example.ru I smtp.example.ru. Zašto je to potrebno? Ovo će omogućiti klijentu da ne ovisi o karakteristikama vaše infrastrukture nakon postavljanja postavki. Recimo da je vaša kompanija porasla i dodijelila poseban mail server za opsluživanje vanjskih klijenata. mail1, sve što treba da uradite je da promenite dva DNS zapisa, klijenti neće primetiti da rade sa novim serverom. Za kreiranje alijasa koriste se zapisi tipa CNAME:

Pop IN CNAME mail.example.com.
smtp U CNAME mail.example.com.

U ovom trenutku, podešavanje naprijed DNS zone može se smatrati završenim, ostaje najzanimljivije - reverzna zona. Reverznom zonom upravlja provajder koji vam je izdao IP adresu i ne možete sami upravljati njom (osim ako niste vlasnik bloka IP adresa). Ali morate dodati barem jedan zapis u obrnutu zonu. Kao što smo pisali u prošlom članku, mnogi mail serveri provjeravaju PTR zapise (reverse zone records) za server koji šalje, i ako ih nema ili se ne podudaraju sa domenom pošiljaoca, takvo pismo će biti odbijeno. Zato zamolite svog provajdera da za vas doda ovakav unos:

44.33.22.11.in-addr.arpa. IN PTR mail.example.com.

Malo čudno izgleda, zar ne? Hajde da detaljnije analiziramo strukturu PTR zapisa. Za inverzna transformacija imena koriste posebnu domenu vrhunski nivo in-addr.arpa. Ovo se radi kako bi se koristili isti programski mehanizmi za naprijed i nazad razlučivanje imena. Činjenica je da se mnemonička imena pišu s lijeva na desno, a IP adrese s desna na lijevo. Dakle, mail.example.com. znači da je pošta domaćina u primjeru domene, koja je u domeni najvišeg nivoa com., 11.22.33.44 znači da je host 44 na podmreži 33, koja je dio podmreže 22, u vlasništvu mreže 11. Da bi se održao jedinstveni poredak, PTR zapisi sadrže IP adresu "pozadi naprijed" dopunjenu domenom najvišeg nivoa in-addr.arpa.

Takođe možete provjeriti MX i PTR zapise pomoću naredbe nslookup koristeći dodatni parametar -type=MX ili -type=PTR

I naravno, ne zaboravite da bilo kakve promjene u DNS zone ne nastaju odmah, već u roku od nekoliko sati ili čak dana, neophodnih za širenje promjena u svijetu DNS sistem. To znači da uprkos činjenici da će vaš mail server početi raditi 2 sata nakon unošenja izmjena, vaš partner vam možda neće slati poštu duže vrijeme.

Ako trebate upravljati DNS zapisima domene i ne pružate takvu mogućnost, možete koristiti servere imena trećih strana, na primjer, besplatnu uslugu Yandex DNS hostinga koja dolazi uz Yandex Mail za domenu. Ovaj članak će pokriti:

Prvo morate registrirati račun na Yandexu. Ako već imate nalog, idite na sljedeći odjeljak"Povezivanje domene na Yandex".

Nakon što popunite sva potrebna polja i potvrdite broj telefona unosom verifikacionog SMS koda, preporučujemo da odete na detalje račun klikom na njeno ime sa desne strane gornji ugao, i odabirom odjeljka "Pasoš" naznačite lične podatke: posebno, sigurnosno pitanje i odgovor na to. Ove informacijeće pojednostaviti vraćanje pristupa računu ako se izgubi lozinka ili prijava.

Nakon toga možete započeti povezivanje domene.

Nakon što se prijavite na svoj račun, morat ćete povezati svoju domenu. To se može učiniti na linku: https://pdd.yandex.ru/domains_add/

Na "Mail for Domain" možete otići i na ovaj način: na nalogu u redu sa dostupne usluge kliknite na "više", u padajućem izborniku odaberite "Sve usluge".

Zatim odaberite "Mail for Domain".

Unesite naziv domene i kliknite na Poveži domenu. Nakon toga, automatski ćete biti preusmjereni na stranicu za potvrdu vlasništva nad domenom.

Delegiranje domena na Yandex

Delegiranje domena na Yandex podrazumijeva slanje domena na odgovarajuće javne servere imena i stjecanje mogućnosti upravljanja DNS zapisima u funkcionalnosti ovog servisa. Ako je domena delegirana u roku od 24 sata nakon povezivanja, a veza nije prethodno uspostavljena na drugom Yandex nalogu, domena će biti uspješno delegirana nakon ažuriranja DNS zapisa (može proći do 72 sata od trenutka kada je ime serveri se mijenjaju na ploči registratora). U suprotnom, morat ćete potvrditi vlasništvo nad domenom.

Da delegirate domenu Yandexu, navedite servere imena dns1.yandex.net i dns2.yandex.net u panelu registrator domena. Ako u funkcionalnosti registratora domena postoje polja za određivanje IP adresa servera imena, ona se ne moraju popunjavati.

Nakon ažuriranja DNS zapisa, status domene će se promijeniti u "Domena je povezana i delegirana na Yandex":

Provjera vlasništva nad domenom

Da biste potvrdili vlasništvo nad domenom, postoje 3 alternativna metoda ispod:

Metoda broj 1 - učitavanje datoteke

Ako već imate hostiranu stranicu, morat ćete učitati html datoteku u njen korijenski direktorij s imenom i sadržajem navedenim na stranici Moji domeni.

Metoda broj 2 - postavljanje CNAME-a

Za navedeni poddomen, postavite CNAME zapis za mail.yandex.ru (sa tačkom na kraju). Za ovo morate imati pristup za uređivanje. DNS zapisi kod registratora imena domena ili hosting provajdera.

Ako imate aktivnu uslugu kod nas virtuelni hosting, možete specificirati CNAME zapis u hostingu cPanel paneli u odjeljku "Domeni" - "Jednostavan uređivač DNS zone" ili "Napredni uređivač DNS zona".

Ako ste kupili VPS sa stranice, tada možete uređivati ​​DNS zapise na SolusVM panelu prema našem vodiču.

Dodani CNAME zapis će izgledati ovako:

Metoda broj 3 - promjena e-pošte

Navedite e-mail sa stranice "Moji domeni" kao kontakt poštanska adresa registrant domena. To se obično može učiniti u funkcionalnosti registratora imena domena. Nakon što se potvrdi vlasništvo nad domenom, možete promijeniti e-mail natrag na originalni.

Nakon dovršetka koraka prema odabranoj metodi verifikacije, kliknite na "Provjeri vlasništvo nad domenom". Imajte na umu da proces ažuriranja DNS zapisa traje neko vrijeme i da se domen možda neće odmah verificirati. U ovom slučaju, Yandex će također vršiti automatske provjere u redovnim intervalima. Nakon što se potvrdi vlasništvo nad domenom, status njegovog domena na stranici "Moji domeni" će se promijeniti u "Čeka se instalacija MX zapisa" ako domen još nije usmjeren na javne servere Yandexa. U ovom slučaju, pogledajte odjeljak „Delegiranje domene“ u trenutnom vodiču kako biste delegirali domenu Yandexu.

Ako je domena već bila usmjerena na Yandex servere imena, nakon ažuriranja DNS zapisa, status domene će se promijeniti u "Domen je povezan i delegiran na Yandex".

Upravljanje DNS hostingom iz Yandexa

Nakon delegiranja domene na stranici "Moji domeni", u njenim detaljima će se pojaviti sljedeća funkcionalnost (označena na snimku ekrana):

Da biste upravljali DNS zapisima, potrebno je da odete u DNS Editor.

Pošto je domen već delegiran Yandexu, DNS zapisi potrebni da Yandex.Mail i Jabber rade na vašoj domeni će se automatski dodati. Možete prenijeti DNS zapise sa prethodnih servera imena na Yandex servere imena. Da biste to učinili, kliknite na "Transfer NS-records", provjerite njihovu ispravnost i kliknite na "Transfer".

Po potrebi dodajte unose koji nedostaju. Ako dodajete unos za glavni domen, ostavite znak "@" u polju "Host". Ako se unos dodaje za poddomenu, navedite dio naziva poddomena bez glavnog naziva domene. Odaberite tip DNS zapisa, unesite vrijednost i kliknite na Dodaj DNS zapis. Na primjer, za poddomenu my.domain.com, A-zapis bi izgledao ovako:

Za ispravan rad stranice potrebni su sljedeći DNS zapisi:

Domaćin	Tip	Rekordna vrijednost
@	A	XXX.XXX.XXX.XXX
*	A	XXX.XXX.XXX.XXX

Umjesto XXX.XXX.XXX.XXX, navedite IP adresu hostinga sa kojeg treba otvoriti stranicu.

Primjer DNS zapisa za domen je prikazan u nastavku:

Tražite gdje? Nudimo odlično. Ako želite ili virtuelni hosting, onda možete naručiti ne samo, već i dobiti sertifikat na poklon za virtuelni hosting na S4 tarifi i za xVPS40 VDS plan.

4. februara 2016. u 16:05

Najosnovnija potreba: kako smo implementirali DNS hosting u Mail.Ru for Business

• Blog grupe Mail.ru

Prošle godine smo lansirali besplatni DNS hosting na Mail.Ru for Business, a nedavno je izašao iz beta testiranja. Danas želim da vam kažem kako smo to uradili, šta tehnička rješenja bili prihvaćeni, i malo o tome kako smo se plasirali cijeloj publici.

Pažljivo slušamo želje naših korisnika i vodimo evidenciju o svim željama. Na ovoj listi, DNS hosting je konstantno držao prvu liniju. Kao rezultat toga, riješili smo dva problema: implementirali smo dodatna usluga, koji su tražili mnogi, i dodao još jedan način za provjeru domene za nove korisnike. Osim toga, nakon prelaska na naš DNS hosting, automatski se dodaju svi DNS zapisi potrebni za rad pošte.

Odabir DNS servera

Prilikom odabira DNS servera fokusirali smo se na brzinu, potrošene resurse i jednostavnost korištenja. Zaista sam želio da on može raditi sa bazom podataka iz kutije. Razmotreni su BIND, NSD i PowerDNS.

BIND je najviše popularan server, Ima dobra dokumentacija, i, vjerovatno, na njemu možete pronaći odgovor na bilo koje pitanje. Međutim, on ne zna kako raditi sa bazom podataka izvan kutije. Postoji, naravno, DLZ zakrpa, ali Posljednje ažuriranje datira iz 2013. godine. Nije drugačije Visoke performanse.

NSD je neprikosnoveni lider po brzini i utrošenim resursima, ali ne može raditi ni sa čim osim sa fajlovima. U praksi, to znači da morate napisati skriptu koja periodično dobija sve zapise iz baze podataka, upisuje ih u fajl i ponovo učitava NSD.

PowerDNS ima dobre performanse, umjereno koristi resurse servera. Ima mnogo korisnih i ne tako izvornih zakrpa. Mogućnost rada sa PostgreSQL iz kutije.

Na kraju, kada birate između visokih performansi NSD-a i dobrih performansi i jednostavnosti korištenja, PowerDNS je pobijedio nad PowerDNS-om.

Rad sa PowerDNS-om je zadovoljstvo: vi unosite promjene u bazu podataka, a on ih sam preuzima. Osim toga, pošto se svi podaci preuzimaju iz baze podataka, ne morate konfigurirati master-slave na PowerDNS strani, ali možete prebaciti njihovu replikaciju u bazu podataka.

Istorija imena

Za potvrdu domene izdajemo dva NS zapisa - na primjer, moscow.ens.mail.ru i spb.ens.mail.ru. Odakle su gradovi? Da bismo ovo objasnili, prvo moramo govoriti o problemu koji smo pokušavali riješiti.

Pokušali smo da registraciju na Mail.Ru for Business učinimo jednostavnom i praktičnom. Sada radi na sljedeći način. Pretpostavimo da posjedujete bestcompanyever.ru domenu i želite se registrirati. Vi dodate bestcompanyever.ru domenu na našu stranicu, mi vam dajemo nekoliko domena za NS zapise. Nakon što ih registrujete, moći ćete da upravljate poštom i DNS zapisima.

Međutim, moguće je da će dvije osobe pokušati registrirati bestcompanyever.ru u isto vrijeme. Za takve slučajeve potreban je algoritam koji će vam omogućiti da identifikujete pravog vlasnika domene i date mu prava da upravlja poštom i DNS serverom za ovu domenu.

Najjednostavnije rješenje je izdati imena u standardni format: dns1.mail.ru, dns2.mail.ru, itd., i koristiti jedinstvenu kombinaciju zapisa za identifikaciju. Recimo da se od prvog korisnika koji je dodao bestcompanyever.ru traži da registruje dns7.mail.ru i dns23.mail.ru, a od drugog - dns3.mail.ru i dns84.mail.ru. Zatim proveravamo koji par NS zapisa je registrovan za domen i na osnovu toga utvrđujemo ko je pravi vlasnik. Čini se da je to odličan sistem - ali postoji nijansa. Često korisnici, nakon što su primili, na primjer, dns3 i dns84 kao svoje zapise, propisuju sve ostale u ovom rasponu: dns3, dns4, dns5, dns6, itd. Ovo ne daje nikakve bonuse: jedino što korisnik dobija kao rezultat takvih radnji je greška tokom verifikacije domena. Da bismo izbjegli takve situacije, izdajemo imena gdje redoslijed nije očigledan. Da bismo to učinili, koristili smo nazive gradova. Sada imamo dvije liste od 50 gradova.

Svako ko se registruje na Mail.Ru for Business dobija po jedan unos sa svake liste. Ovo daje 2500 jedinstvenih kombinacija, što osigurava da je vlasnik domene jedinstveno identifikovan, čak i ako više ljudi pokuša da registruje istu domenu.

Nakon što je registracija završena, imena servera se gube tehnički značaj. Bez obzira sa koje adrese dolazi zahtjev, uvijek ćemo dati traženu evidenciju.

Poprsje

Teoretski, napadač bi mogao početi da registruje isti domen ispod 2500 naloga i dobije sve moguće varijacije parova NS imena. Kada bi pravi vlasnik domene došao i započeo proceduru registracije, dobio bi nekoliko onih koje je napadač već zauzeo. I onda nakon što ih dodaju kod matičara i automatska provera aktivirali bismo domenu registrovanu na napadača.

Naravno, ovaj scenario je složen, skup i generalno nema toliko domena za koje bi vrijedilo toliko trpjeti. Ovaj problem smo riješili na sljedeći način: dodali smo ograničenje na broj nepotvrđenih domena sa istim imenom, a za svaki domen je garantirano generisan jedinstveni par.

Koristeći ovu priliku, želim da vas podsjetim da Mail.Ru Group ima program za pretragu ranjivosti. Ako vi, radoznali čitalac, pronađete greške u DNS hostingu (kao i na biz.mail.ru općenito), možete zaraditi dodatnu karmu i novac podnošenjem prijave.

Sistem karakteristika

Sve nove funkcionalnosti su omogućene korisnicima kroz sistem funkcija. Ovo vam omogućava da fleksibilno uvedete funkcije odabirom korisnika koji će im dati pristup. Na ovaj način možemo testirati nove funkcije u proizvodnji bez da ih pokažemo svima. Ako je potrebno, možete omogućiti funkcije za određene korisnike, domene ili određeni postotak publike.

U slučaju DNS hostinga, imali smo spisak korisnika koji su zaista, zaista želeli da ga isprobaju. Oni su bili uključeni u grupu zatvorenog beta testiranja. Ovaj korak nam je omogućio da identifikujemo greške povezane sa rijetkim slučajevima, kao i da popravimo nekoliko problema u upotrebljivosti sučelja.

Na kraju zatvorenog beta testiranja, počeli smo da otvaramo pristup hostingu svim korisnicima: prvo 10%, zatim 50%, a nedelju dana kasnije - svim našim korisnicima.

Umjesto zaključka

Stvorili smo brz i pouzdan DNS hosting i nećemo stati na tome. Planiramo da pokrenemo DNSSEC u bliskoj budućnosti. Nastavljamo da poboljšavamo naš hosting i volimo biti kritikovani. Zato molim sve koji su ga već koristili da u komentarima kažu šta želite poboljšati ili dodati na hosting.

A ako niste imali vremena isprobati našu uslugu - ostavite komentare. Prvih 100 habrauzera će dobiti promo kod za registraciju besplatna domena u .ru zoni sa povezanim servisom pošte i DNS-om.