როგორ მუშაობს დომენები და DNS: გზამკვლევი არადეველოპერებისთვის
დომენი არის სახელი, რომელსაც ადამიანები კრეფენ შენს საიტთან მისასვლელად, მაგალითად example.com, და DNS (Domain Name System) არის ინტერნეტის დირექტორია, რომელიც ამ სახელს გადათარგმნის იმაში, სადაც შენი საიტი სინამდვილეში ცხოვრობს. დომენს რეგისტრატორისგან ქირაობ, შემდეგ უმატებ DNS ჩანაწერებს, რომლებიც ამბობენ „ვებსაიტი იქ არის“ და „ელფოსტა აქეთ მოდის“. მორგებული დომენის აპთან დაკავშირება ძირითადად იმაში მდგომარეობს, რომ სწორ ჩანაწერს სწორ ადგილას დაამატო და ელოდო, სანამ ის ამოქმედდება.
რატომ არის მნიშვნელოვანი, როცა AI-ით აშენებ
AI აპის კონსტრუქტორს შეუძლია აპის დაწერა და ჰოსტინგი, მაგრამ შენი დომენი აპის გარეთ ცხოვრობს — ხშირად სხვა კომპანიასთან, კონტროლის პანელში, სადაც უცნობი ჩანაწერის ტიპებია. სწორედ აქ ჩერდება ბევრი გაშვება: აპი მზად არის, მაგრამ დომენი შეცდომას აჩვენებს, ან DNS-ის შეცვლის შემდეგ ელფოსტა უცნაურად წყვეტს მუშაობას.
მცირე გაგება დიდ დახმარებას გაწევს. გაიგებ, რომელ ჩანაწერს ითხოვს შენი ჰოსტი, რატომ არ მუშაობს ის ჯერ, და როგორ აიცილო ის, რაც უკვე შენს დომენზე მუშაობს (მაგალითად, ელფოსტა).
ყოველდღიური ანალოგია
წარმოიდგინე შენი ტელეფონის კონტაქტების სია.
შენი მეგობრის ნომერს არ იმახსოვრებ; შეეხები მის სახელს და ტელეფონი ნომერს პოულობს. DNS იგივეს აკეთებს ინტერნეტისთვის: კრეფ example.com-ს და DNS პოულობს იმ სერვერის ნომერს (IP მისამართს), რომელთანაც უნდა დაუკავშირდე.
- დომენი არის კონტაქტის სახელი.
- რეგისტრატორი არის კომპანია, რომელიც ოფიციალურად ჩაწერს, რომ სახელი შენია.
- DNS ჩანაწერები არის დეტალები, რომლებიც სახელის ქვეშ ინახება: ტელეფონის ნომერი, ელფოსტის მისამართი, სახლის მისამართი.
- Nameserver-ები არის, რომელი კონტაქტების წიგნი არის ოფიციალური ამ სახელისთვის.
- ქეშირება არის შენი ტელეფონის მიერ ნომრის გარკვეული ხნით დამახსოვრება. თუ მეგობარმა ნომერი შეიცვალა, ზოგი ტელეფონი ძველ ნომერს დარეკავს, სანამ შენახული ასლი არ განახლდება — ეს არის DNS-ის „გავრცელება“.
დომენის სახელის ნაწილები
ავიღოთ app.example.com:
| ნაწილი | სახელი | შენიშვნები |
|---|---|---|
.com | მაღალი დონის დომენი (TLD) | რეესტრი მართავს. სხვები: .org, .io, .ai, ქვეყნის კოდები, როგორიცაა .uk |
example | მეორე დონის დომენი | ის ნაწილი, რომელსაც არეგისტრირებ |
example.com | ძირითადი ანუ „apex“ დომენი | რაც შენია |
app | ქვედომენი | DNS-ში თავისუფლად ქმნი — www, app, shop |
დომენს სრულად არ ყიდულობ; არეგისტრირებ გარკვეული პერიოდით (ჩვეულებრივ ერთი წელი ან მეტი) და ახლდები. თუ ვადა გაუვა, სხვამ შეიძლება დაარეგისტრიროს.
როგორ მუშაობს DNS-ის მოძიება
როცა ვინმე კრეფს app.example.com-ს:
- ბრაუზერი DNS რეზოლვერს ეკითხება მისამართზე — ჩვეულებრივ მის ინტერნეტ-პროვაიდერს ან საჯარო სერვისს.
- თუ რეზოლვერს აქვს ახალი ქეშირებული პასუხი, მაშინვე პასუხობს.
- თუ არა, იერარქიით ადის: root სერვერები მიუთითებენ
.comსერვერებზე, ისინი კი შენი დომენის nameserver-ებზე. - შენი nameserver-ები აბრუნებენ ჩანაწერს, რომელიც დააყენე, მაგალითად CNAME შენს ჰოსტზე ან A ჩანაწერს IP მისამართით.
- რეზოლვერი პასუხს ინახავს ჩანაწერის TTL-ის (time to live) ვადით და ბრაუზერს გადასცემს, რომელიც სერვერს უკავშირდება.
ეს ყველაფერი ჩვეულებრივ მილიწამებში ხდება.
DNS ჩანაწერების ტიპები, რომლებსაც რეალურად გამოიყენებ
| ჩანაწერი | რას აკეთებს | მაგალითი |
|---|---|---|
| A | სახელს IPv4 მისამართზე მიუთითებს | example.com → 203.0.113.10 |
| AAAA | სახელს IPv6 მისამართზე მიუთითებს | example.com → 2001:db8::10 |
| CNAME | სახელს სხვა ჰოსტის სახელის ალიასად ხდის | app.example.com → myapp.host.com |
| MX | ამბობს, რომელი სერვერები იღებენ ელფოსტას დომენისთვის, პრიორიტეტის ნომრით | example.com → 10 mail.provider.com |
| TXT | ტექსტს ინახავს, გამოიყენება დადასტურებისა და ელფოსტის უსაფრთხოებისთვის | v=spf1 include:_spf.provider.com ~all |
| NS | ჩამოთვლის დომენის ავტორიტეტულ nameserver-ებს | ns1.dnsprovider.com |
| CAA | ზღუდავს, რომელმა სერტიფიკატის ორგანიზაციებმა შეიძლება გასცენ HTTPS სერტიფიკატები | 0 issue "letsencrypt.org" |
მცირე წესები, რომლებიც ღირს ცოდნა:
- CNAME ერთ სახელზე სხვა ჩანაწერებთან ერთად არ შეიძლება. ამიტომ სტანდარტული CNAME ვერ დაედება ძირითად დომენს, რომელსაც ყოველთვის აქვს NS და სხვა ჩანაწერები. ბევრ DNS პროვაიდერს აქვს გვერდის ავლის ფუნქციები, რომლებსაც ALIAS, ANAME ან CNAME flattening ჰქვია.
- TXT ჩანაწერები ბევრ ელფოსტის სამუშაოს ასრულებს. SPF განსაზღვრავს, ვინ შეიძლება გააგზავნოს ფოსტა შენი დომენიდან; DKIM აქვეყნებს გასაღებს ხელმოწერების შესამოწმებლად; DMARC ეუბნება მიმღებებს, რა ქნან იმ ფოსტას, რომელიც ამ შემოწმებებს ვერ გადის.
- MX-ის დაბალი ნომერი მაღალ პრიორიტეტს ნიშნავს. ფოსტა ჯერ ყველაზე დაბალს ცდის.
გავრცელება და TTL
„გავრცელება“ ისე ჟღერს, თითქოს ცვლილებები ნელა ვრცელდება ინტერნეტში. სინამდვილეში ხდება ქეშირება: რეზოლვერები პასუხის ასლს თავიანთი TTL-ით ინახავენ და მხოლოდ მაშინ ეკითხებიან ხელახლა, როცა ის იწურება. ასე რომ:
- ახალი ჩანაწერი, რომელსაც მანამდე არავინ ეძებდა, ხშირად წუთებში მუშაობს.
- არსებული ჩანაწერის შეცვლა სჭირდება მის ძველ TTL-მდე, რომ ყველგან გამოჩნდეს.
- nameserver-ების შეცვლას შეიძლება დასჭირდეს დღე-ორი, რადგან ეს ჩანაწერები TLD დონეზე უფრო ხანგრძლივად ინახება.
კარგი ხრიკი: დაგეგმილ ცვლილებამდე შეამცირე ჩანაწერის TTL (ვთქვათ, რამდენიმე წუთამდე), დაელოდე ძველი TTL-ის გასვლას და შემდეგ შეცვალე.
სამუშაო მაგალითი: სარეზერვო აპის დაკავშირება შენს დომენთან
შენ გაქვს დომენი yoursalon.com. შენი ამჟამინდელი ვებსაიტი და Google Workspace-ის ელფოსტა უკვე მას იყენებს. აშენე სარეზერვო აპი და გინდა, რომ იყოს book.yoursalon.com-ზე.
- იპოვე, სად იმართება შენი DNS. შეიძლება იყოს შენი რეგისტრატორი ან ცალკე DNS პროვაიდერი. შენი NS ჩანაწერები გეტყვის.
- დაამატე CNAME ქვედომენისთვის
book, რომელიც მიუთითებს იმ მისამართზე, რომელსაც შენი აპის ჰოსტი მოგცემს. - დაამატე TXT ჩანაწერი, თუ ჰოსტი მოითხოვს საკუთრების დასადასტურებლად.
- MX და ელფოსტის TXT ჩანაწერებს ნუ შეეხები. ელფოსტა იმუშავებს, რადგან მათ არ შეცვლი.
- დაადასტურე შენს ჰოსტში, როცა DNS განახლდება. ჰოსტი შემდეგ გასცემს HTTPS სერტიფიკატს
book.yoursalon.com-ისთვის. - ტესტირება ტელეფონით მობილური ინტერნეტით, რადგან ის სხვა რეზოლვერს და ქეშს იყენებს, ვიდრე შენი სახლის Wi-Fi.
თუ აპი ძირითად yoursalon.com-ზე გინდოდა, დაგჭირდებოდა A ჩანაწერები ან შენი DNS პროვაიდერის ALIAS/flattening ფუნქცია — და ამით შენს ამჟამინდელ ვებსაიტს იქ ჩაანაცვლებდი. მეტი ნაბიჯებისთვის იხილე როგორ დავაკავშიროთ მორგებული დომენი.
ხშირი შეცდომები და მცდარი წარმოდგენები
- „დომენი და ჰოსტინგი ერთი და იგივეა.“ დომენი არის სახელი; ჰოსტინგი არის ადგილი, სადაც აპი მუშაობს. DNS აკავშირებს მათ.
- A ჩანაწერის გამოყენება, როცა ჰოსტმა CNAME ითხოვა (ან პირიქით). მიჰყევი ჰოსტის ინსტრუქციას ზუსტად.
- წერილები მიზნის სახელში. ერთი არასწორი სიმბოლო CNAME-ის მიზანში და დადასტურება ვერ მოხდება.
- nameserver-ების შეცვლა ჩანაწერების გადაუტანლად. DNS-ის ახალ პროვაიდერზე გადატანა MX და TXT ჩანაწერების თავიდან შექმნის გარეშე ელფოსტის გატეხვის კლასიკური გზაა.
- პროქსირება, როცა არ უნდა. ზოგი DNS პროვაიდერი, მაგალითად Cloudflare, ტრაფიკს პროქსირებს. ზოგ ჰოსტს სჭირდება, რომ ჩანაწერი იყოს „მხოლოდ DNS“, რომ მან სერტიფიკატი გასცეს.
- „უცნობი“ TXT ჩანაწერების წაშლა. ისინი ხშირად დადასტურების ან ელფოსტის უსაფრთხოების ჩანაწერებია, რომლებზეც რაღაც დგას.
- დომენის ვადის გასვლის დაშვება. ჩართე ავტომატური განახლება და შეინახე მიმდინარე გადახდის ბარათი.
რა სთხოვო შენს AI კონსტრუქტორს
DNS შენს კოდს გარეთ ცხოვრობს, ამიტომ ეს უფრო იმაზეა, რაზეც უნდა ჰკითხო:
- „რა ზუსტი DNS ჩანაწერია საჭირო app.mydomain.com-ისთვის — ტიპი, სახელი და მნიშვნელობა?“
- „ეს ცვლილება ჩემს ელფოსტაზე იმოქმედებს?“
- „დომენი შეცდომას აჩვენებს ჩანაწერის დამატების შემდეგ. რა შევამოწმო?“
- „დაამატე სწორი canonical URL და გადამისამართებები, რომ www და non-www ორივე არ აჩვენებდეს საიტს.“
- „მოაწყე ელფოსტის გაგზავნა ჩემი დომენიდან — რომელი SPF, DKIM და DMARC ჩანაწერები დამჭირდება?“ იხილე როგორ გავაგზავნოთ ელფოსტა შენი აპიდან.
მორგებული დომენები Mythex-ზე
ყველა გამოქვეყნებულ Mythex აპს აქვს yourname.mythex.app მისამართი. Pro-ზე შეგიძლია საკუთარი დომენი გამოიყენო: იყიდე Mythex-ის შიგნით (რეგისტრაცია ცალკე ირიცხება, და ნაყიდი დომენების DNS შენთვის იმართება), ან დააკავშირე უკვე შენს მიერ ფლობილი დომენი, დაამატე CNAME ქვედომენიდან, მაგალითად app.example.com, შენი აპის yourname.mythex.app მისამართზე, შემდეგ დააჭირე Verify-ს. HTTPS ავტომატურად გაიცემა. თუ შენი DNS Cloudflare-ზეა, ეს ჩანაწერი დააყენე „DNS only“-ზე. რეკომენდებულია ქვედომენები; ძირითადი დომენები დამოკიდებულია შენი DNS პროვაიდერის ALIAS ან flattening მხარდაჭერაზე. მორგებული დომენის დოკუმენტაცია ყოველ ნაბიჯს აღწერს, ხოლო ფასები გიჩვენებს, რა შედის Pro-ში.
კითხვები
რა არის DNS მარტივად რომ ვთქვათ?
DNS (Domain Name System) ინტერნეტის დირექტორიაა. ის გადათარგმნის ადამიანებისთვის დასამახსოვრებელ სახელს, მაგალითად example.com-ს, კომპიუტერებისთვის საჭირო მონაცემებად — ჩვეულებრივ IP მისამართად — რომ ბრაუზერმა სწორი სერვერი იპოვოს.
რა განსხვავებაა A ჩანაწერსა და CNAME-ს შორის?
A ჩანაწერი სახელს პირდაპირ IPv4 მისამართზე მიუთითებს. CNAME სახელს სხვა ჰოსტის სახელზე მიუთითებს, და მოძიება იქიდან გრძელდება. CNAME მოსახერხებელია, როცა შენი ჰოსტის IP მისამართები შეიძლება შეიცვალოს, მაგრამ სტანდარტული CNAME ძირითად დომენზე თვითონ არ შეიძლება.
რამდენ ხანს გრძელდება DNS-ის გავრცელება?
ხშირად წუთები, ზოგჯერ საათები. ცვლილებები ჩნდება, როცა ძველი ჩანაწერის ქეშირებული ასლები იწურება, რაც დამოკიდებულია ჩანაწერის TTL-ზე. nameserver-ების შეცვლას შეიძლება დასჭირდეს დღე-ორი, რადგან ეს ჩანაწერები უფრო ხანგრძლივად ინახება ქეშში.
DNS-ის შეცვლა ჩემს ვებსაიტს ელფოსტას გატეხავს?
მხოლოდ თუ შეცვლი ან წაშლი იმ ჩანაწერებს, რომლებზეც ელფოსტა დგას — MX ჩანაწერებსა და TXT ჩანაწერებს, როგორიცაა SPF, DKIM და DMARC. www-ის ან app-ის CNAME-ის დამატება ელფოსტას არ ეხება. დომენის გადატანა ახალ nameserver-ებზე შეიძლება ელფოსტას გატეხავდეს, თუ ჯერ ეს ჩანაწერები არ გადაიტანე.
რატომ გამოვიყენოთ www ან app ძირითადი დომენის ნაცვლად?
ქვედომენი, მაგალითად www.example.com ან app.example.com, შეიძლება იყოს CNAME, რასაც ბევრი ჰოსტინგ-პლატფორმა სთხოვს. ძირითად დომენს (example.com) სტანდარტული CNAME არ შეიძლება ჰქონდეს, ამიტომ მას სჭირდება A ჩანაწერები ან პროვაიდერის სპეციფიკური ფუნქცია — ALIAS, ANAME ან CNAME-flattening.