DNS ჩანაწერები ახსნილი: A, CNAME, SRV, TXT, MX და TTL

DNS არის საძიებო ცხრილი, რომლის წინაც ქეში დგას, და თითქმის ყველაფერი, რაც მასში დამაბნეველია, სწორედ ქეშია. თავად ჩანაწერები მარტივია, სულ დაახლოებით ექვსია ისეთი, რომელსაც ოდესმე შექმნი, და წესები, რომლებზეც ხალხი ებმევა, ერთ ხელზე ითვლება: CNAME apex-ზე ვერ იცხოვრებს, MX ჩანაწერს მისამართის ტარება არ შეუძლია, დღეს დაყენებული TTL მხოლოდ ძველის ამოწურვის შემდეგ ამოქმედდება, ხოლო "გავრცელება" არ არის პროცესი, რომელიც შენს ცვლილებას ემართება - ეს სხვისი ქეშებია, რომლებიც თავისი ტემპით ძველდება.

ეს პოსტი აღწერს, რას აკეთებს თითოეული ჩანაწერი, ზუსტად რა ფორმა აქვს მას, როგორ პოულობს მას resolver და რომელი ბრძანებები გეუბნება სიმართლეს მაშინ, როცა ვებ ინტერფეისი წერს, რომ ჩანაწერი შენახულია, და არაფერი მუშაობს.

როგორ მუშაობს ძებნა სინამდვილეში#

როცა რამეს play.example.com-ის მისამართი სჭირდება, ჩვეულებრივ ოთხი სხვადასხვა მანქანაა ჩართული, და იმის ცოდნა, რომელს აქვს შენი პასუხი, დიაგნოზის უმეტესი ნაწილია.

stub resolver შენს ოპერაციულ სისტემაში ნამდვილ სამუშაოს არ ასრულებს. ის ეკითხება იმ resolver-ს, რომელიც მას მიუთითეს, ჩვეულებრივ DHCP-ით, და პასუხს ხანმოკლედ ქეშირებს. ბრაუზერები ამის თავზე საკუთარ ქეშსაც ინახავენ, სწორედ ამიტომ შეუძლია გვერდს ძველ მისამართზე გადაწყვეტა გააგრძელოს მას შემდეგაც, რაც ყველაფერი დანარჩენი გაასუფთავე.

Recursive resolver - შენი პროვაიდერის, ან საჯარო, მაგალითად 1.1.1.1 ან 8.8.8.8 - ნამდვილ დევნას სწორედ ის ეწევა. თუ პასუხი მას უკვე აქვს TTL-ის ფარგლებში, ის მას აბრუნებს და სხვა არაფერი ხდება; ძებნების აბსოლუტურ უმრავლესობაში ასეა, და ამიტომაც გეჩვენება, რომ შენი ცვლილება უგულებელყოფილია.

Root და TLD სერვერები პასუხების ნაცვლად დელეგაციებს ინახავენ. Root-მა იცის, რომელი სერვერები უშვებს .com-ს; .com-ის სერვერებმა იციან, რომელი nameserver-ებია ავტორიტეტული example.com-ისთვის. არცერთს play-ის შესახებ არასოდეს გაუგია.

ავტორიტეტული nameserver-ები შენს ზონას ინახავენ: იმ ნამდვილ ჩანაწერებს, რომლებიც აკრიფე. რასაც ისინი ამბობენ, სიმართლეა. ყველაფერი მათ ზემოთ ასლია, რომელსაც ვარგისიანობის ვადა აწერია.

ორი შედეგი, რომელიც ღირს დაიმახსოვრო. ცვლილება, რომელსაც შეიტან, ავტორიტეტულ სერვერებზე მაშინვე ცოცხალია - არც რიგია და არც დარიგების ეტაპი. და resolver, რომელსაც ქეშირებული პასუხი აქვს, TTL-ის ამოწურვამდე ხელახლა არ იკითხავს, რაც არ უნდა მართალი იყო.

ჩანაწერების ტიპები და რისთვის არის თითოეული#

A და AAAA არის ის, რასაც ყველაზე ხშირად შექმნი. ისინი სახელს მისამართზე ასახავს, და ერთ სახელს თითოეულის რამდენიმე ცალი შეიძლება ჰქონდეს - კლიენტი ერთს ირჩევს, ჩვეულებრივ პირველს, რომელსაც მიაწოდებენ, თანმიმდევრობა კი ბრუნავს. ეს დატვირთვის განაწილების ყველაზე უხეში ფორმაა და მას ჯანმრთელობის შემოწმება საერთოდ არ აქვს: თუ ერთ-ერთი მისამართი გათიშულია, შენი ვიზიტორების ნაწილი შეცდომას მიიღებს.

CNAME ამბობს: „ეს სახელი სინამდვილეში ის სახელია“. resolver, რომელიც მას იპოვის, ძებნას სამიზნეზე თავიდან იწყებს. ის გამოსადეგია www-ის შენს apex-ზე მისათითებლად, ან ქვედომენის პროვაიდერის hostname-ზე, რომ მათ მისამართი ქვემოდან შეცვალონ შენთვის შეტყობინების გარეშე. მისი წესები შემდეგი თავის თემაა, რადგან ისინი ყველა დანარჩენზე მეტ პრობლემას ქმნიან.

MX hostname-ზე მიუთითებს პრიორიტეტის ნომრით, სადაც ყველაზე დაბალი სასურველია. ორი წესი, ორივე მუდმივად ირღვევა: სამიზნე უნდა იყოს hostname და არასოდეს IP მისამართი, და ამ hostname-ს უნდა ჰქონდეს A ან AAAA ჩანაწერი და თვითონ არ უნდა იყოს CNAME. MX ასევე ის ჩანაწერია, რომელსაც შენს გეიმ სერვერთან არასოდეს აქვს კავშირი. ფოსტა ცალკე სერვისია ცალკე მანქანაზე, ხოლო RE:NODE ელფოსტას საერთოდ არ უმასპინძლებს - თუ ის გჭირდება, ეს სხვა პროვაიდერია და მისი ჩანაწერები დანარჩენების გვერდით ცხოვრობს. SPF, DKIM და DMARC ახსნილი აღწერს იმ TXT ჩანაწერებს, რომლებიც წყვეტს, დაიჯერებენ თუ არა შენს ფოსტას.

TXT თვითნებური ტექსტია, სწორედ ამიტომ დაუგროვდა ამდენი საქმე. დომენის მფლობელობის დადასტურება Google-ისთვის, Microsoft-ისთვის და ათეულობით სხვისთვის; SPF როგორც სტრიქონი, რომელიც v=spf1-ით იწყება; DKIM-ის საჯარო გასაღებები სელექტორის ქვეშ მისამართზე selector._domainkey.example.com; DMARC-ის პოლიტიკა მისამართზე _dmarc.example.com. ერთ სახელზე მხოლოდ ერთი SPF სტრიქონი შეიძლება არსებობდეს - ორი მათგანი კონფიგურაციის შეცდომაა, რომელიც ფოსტის ავთენტიფიკაციას ჩუმად ამარცხებს იმის ნაცვლად, რომ სადმე ხილული შეცდომა გამოიტანოს.

SRV ერთ ჩანაწერში აერთიანებს სერვისს, პროტოკოლს, ჰოსტს, პორტს, პრიორიტეტსა და წონას, და სწორედ ასე მალავს Minecraft-ის მისამართი არასტანდარტულ პორტს. სახელს ფიქსირებული ფორმა აქვს წინმდგომი ქვედა ტირეებით, _minecraft._tcp.play, ხოლო სამიზნე უნდა იყოს hostname საკუთარი A ჩანაწერით. SRV ჩანაწერები Minecraft-ისთვის თითოეულ ველს შლის და აჩვენებს იმ dig ბრძანებებს, რომლებიც ამტკიცებს, რომ ის მუშაობს.

CAA ის ჩანაწერია, რომელსაც ხალხი შემთხვევით ხვდება. ის ჩამოთვლის, რომელ სერტიფიცირების ორგანოებს შეუძლიათ შენი დომენისთვის გაცემა, და თუ გაქვს CAA ჩანაწერები, რომლებშიც შენი ჰოსტინგის ორგანო არ არის, სერტიფიკატის გაცემა ჩავარდება შეცდომით, რომელიც CAA-ს სადღაც მესამე აბზაცში ახსენებს. უმეტეს დომენს CAA ჩანაწერები არ აქვს, რაც ნიშნავს, რომ გაცემა ნებისმიერ ორგანოს შეუძლია, რაც ნაგულისხმევია და ნორმალურია.

CNAME და რატომ ვერ ცხოვრობს ის apex-ზე#

წესი უფრო ძველია, ვიდრე ინტერნეტის ის ნაწილი, რომელზეც ხალხი მას იყენებს: სახელს, რომელსაც CNAME აქვს, სხვა ჩანაწერი არ შეიძლება ჰქონდეს. არც MX, არც TXT, არც NS ჩანაწერი. CNAME მთელი პასუხია და resolver მას უნდა გაჰყვეს და არა სხვა რამე ეძებოს.

შენი apex - example.com ქვედომენის გარეშე - ვალდებულია ჰქონდეს SOA ჩანაწერი და NS ჩანაწერები, რადგან სწორედ ეს აქცევს მას ზონად. ამიტომ მას CNAME ვერასოდეს ექნება. ამას DNS-ის ყველა პროვაიდერი ამოწმებს, შეცდომის ტექსტი კი ჩვეულებრივ უსარგებლოა.

შემოვლითი გზები იმ თანმიმდევრობით, რომლითაც უნდა სცადო:

1. გამოიყენე A ჩანაწერი apex-ზე და მიუთითე მისამართზე. მარტივია, სწორია და ნიშნავს, რომ მისამართის შეცვლისას მისი რედაქტირება მოგიწევს.
2. გამოიყენე შენი პროვაიდერის ALIAS, ANAME ან CNAME flattening. ეს ნამდვილი ჩანაწერების ტიპები არ არის. პროვაიდერი სამიზნეს შენთვის წყვეტს და შედეგს A ჩანაწერად გასცემს, ფონურად კი განაახლებს. Cloudflare მას flattening-ს უწოდებს და apex-ზე მდგარ CNAME-ს ავტომატურად ამუშავებს; Route 53 მას alias ჩანაწერს ეძახის; სხვები ANAME-ს. ის კარგად მუშაობს და მხოლოდ იმ პროვაიდერთან მუშაობს, რომელიც მას ახორციელებს, ამიტომ გადასვლას ვერ გადაიტანს.
3. საერთოდ არ გამოიყენო apex. დააყენე სერვისი www-ზე ან ქვედომენზე და apex იქითკენ გადაამისამართე HTTP გადამისამართებით იმ რამისგან, რომელსაც apex-ზე პასუხის გაცემა შეუძლია. www თუ apex დომენი და გადამისამართებები აღწერს, რომელი აირჩიო კანონიკურ ჰოსტად და რატომ აქვს ამას ვებსაიტისთვის იმაზე მეტი მნიშვნელობა, ვიდრე ჩანს.

მეორე წესი, რომელიც იმავე შეზღუდვიდან გამომდინარეობს: CNAME ვერ დადგება იმავე სახელის TXT ჩანაწერის გვერდით. თუ სერვისი გთხოვს, დაამატო დამადასტურებელი TXT www-ზე და www უკვე CNAME-ია, ერთ-ერთმა უნდა გადაინაცვლოს.

TTL, ქეშირება და გავრცელების მითი#

TTL არის წამების რაოდენობა, რომელიც ყოველ ჩანაწერს აწერია. ის resolver-ს ეუბნება, რამდენ ხანს შეუძლია პასუხის შენახვა ხელახლა კითხვამდე. მთელი მექანიზმი ესაა.

ხაფანგი ისაა, რომ TTL-ის შემცირება ძველი TTL-ის ამოწურვამდე არ მოქმედებს. თუ შენი ჩანაწერი 86400-ზე იდგა და მას მიგრაციამდე ერთი საათით ადრე 300-მდე ჩამოწევ, იმ resolver-ებს, რომლებსაც პასუხი უკვე აქვთ, ის მთელი დღის დანარჩენი ნაწილი შეუნარჩუნდებათ. დაწიე TTL სულ მცირე ერთი ძველი TTL-ის პერიოდით ადრე, ვიდრე ის დაგჭირდება, რაც ჩვეულებრივ წინა დღეს ნიშნავს.

არსებობს მეორე ქეში, რომლის შესახებაც უმეტესობას არასოდეს გაუგია. როცა resolver ითხოვს სახელს, რომელიც არ არსებობს, ის ამ „არ არსებობს“ პასუხსაც ქეშირებს, იმ ხანგრძლივობით, რომელიც ზონის SOA ჩანაწერიდან მოდის და არა შენ მიერ შექმნილი ჩანაწერიდან. სწორედ ამიტომ შეუძლია ახლახან შექმნილ სახელს NXDOMAIN-ის დაბრუნება რამდენიმე წუთის განმავლობაში მას შემდეგაც, რაც ყველაფერი სწორია - შენ ის შექმნამდე შეამოწმე და ახლა საკუთარ უარყოფით ქეშს იღებ.

„გავრცელება“ ამ ყველაფრისთვის არასწორი სიტყვაა და ის ნამდვილ ზიანს აყენებს, რადგან მიანიშნებს პროცესზე, რომელსაც პროგრესის ზოლი აქვს. არაფერი ვრცელდება. შენი ავტორიტეტული სერვერები სწორია იმ წამიდანვე, როცა შეინახავ, ხოლო მსოფლიოში ყოველი შემორჩენილი ძველი პასუხი სადღაც არსებული ქეშია, რომელიც საკუთარ ტაიმერს ითვლის. პრაქტიკული განსხვავება: პროვაიდერთან ლოდინი არაფერია საჭირო, და სხვისი resolver-ის დაჩქარებას ვერაფრით შეძლებ.

რეგისტრატორი, nameserver-ები და DNS ჰოსტინგი სამი როლია#

დაბნეულობის დიდი ნაწილი სამი ცალკეული საქმიდან მოდის, რომელსაც ხშირად ერთი და იგივე კომპანია ასრულებს.

• რეგისტრატორი ის არის, ვისგანაც დომენს ყიდულობ და ვისთანაც რეგისტრაცია ინახება. მისი ერთადერთი კავშირი DNS-თან არის იმის შენახვა, რომელი nameserver-ებია ავტორიტეტული.
• DNS ჰოსტინგი ამ nameserver-ებს უშვებს და შენს ჩანაწერებს ინახავს. სწორედ აქ ქმნი A ჩანაწერს. ის ხშირად რეგისტრატორიცაა, თუმცა ეს აუცილებელი არ არის.
• ვებ ან გეიმ ჰოსტინგი უშვებს იმ სერვერს, რომელზეც ჩანაწერები მიუთითებს. ეს ჩვეულებრივ სხვა კომპანიაა და მას ჩვეულებრივ DNS-ის ინტერფეისი საერთოდ არ აქვს.

RE:NODE ამ სამიდან მესამეა და მხოლოდ მესამე. პანელში არც ზონის რედაქტორია, არც დომენის რეგისტრაცია და არც ელფოსტის ჰოსტინგი - ჩანაწერებს ქმნი იქ, ვინც შენს DNS-ს უშვებს, და მიუთითებ იმ მისამართზე, რომელიც სერვერის გვერდზეა ნაჩვენები. nameserver-ები თუ DNS ჩანაწერები აღწერს, როგორ გადაიტანო სამიდან ერთი დანარჩენი ორის შეშფოთების გარეშე, რასაც ხალხი დაახლოებით ერთხელ ყოველ დომენზე არასწორად აკეთებს.

nameserver-ების შეცვლა ჩანაწერის შეცვლისგან განსხვავებული ოპერაციაა და უფრო ნელიც. დელეგაცია TLD-ზე ცხოვრობს და ხშირად დღეებში გაზომილი TTL აქვს. გადართვამდე და არა მის შემდეგ გადაიტანე ყველა არსებული ჩანაწერი ახალ პროვაიდერთან, რომ resolver-ებმა, რომლებიც ერთ ან მეორე nameserver-ებთან მივლენ, გადაფარვის პერიოდში ერთნაირი პასუხები მიიღონ.

ჩანაწერები გეიმ სერვერისთვის და ვებსაიტისთვის#

გეიმ სერვერისთვის მთელი საქმე ჩვეულებრივ ორი ჩანაწერია ან ერთი.

node       300  IN  A     203.0.113.10play       300  IN  CNAME node.example.com._minecraft._tcp.play  300  IN  SRV  0 5 25571 node.example.com.

A ჩანაწერი მისამართს ინახავს. CNAME მას უფრო მოსახერხებელ სახელს აძლევს, ისე, რომ სერვერის გადატანა ერთ ადგილას ერთი რედაქტირება იყოს. SRV ჩანაწერი, მხოლოდ Java Minecraft-ისთვის, მოთამაშეებს პორტის გამოტოვების საშუალებას აძლევს. სხვა არაფერია ჩართული: არც MX, არც TXT და არც proxy. თუ შენი DNS პროვაიდერი HTTP proxy-ს გთავაზობს - Cloudflare-ის ნარინჯისფერი ღრუბელი ყველას შეხვედრია - ის უნდა იყოს გამორთული ყველა იმ ჩანაწერზე, რომელსაც თამაშის კლიენტი გამოიყენებს, რადგან ის მხოლოდ HTTP-სა და HTTPS-ს ატარებს და სხვა არაფერს. Cloudflare ვებსაიტებისთვის და გეიმ სერვერებისთვის ზუსტად აღწერს, სად გადის ეს ზღვარი.

ვებსაიტისთვის ფორმა ასეთია:

@     3600  IN  A     203.0.113.20www   3600  IN  CNAME example.com.@     3600  IN  TXT   "v=spf1 -all"@     3600  IN  CAA   0 issue "letsencrypt.org"

@ apex-ს ნიშნავს. -all SPF ჩანაწერი იმ დომენზე, რომელიც ფოსტას არ აგზავნის, პატარა სიკეთეა ყველასთვის, რადგან ის მიმღებ სერვერებს ეუბნება, რომ შენგან გამოგზავნილად წარმოჩენილი არაფერია ნამდვილი. CAA ჩანაწერი არჩევითია და მისი დამატება მხოლოდ მაშინ ღირს, თუ იცი, რომელი ორგანო გასცემს შენს სერტიფიკატებს.

თანმიმდევრობას მნიშვნელობა აქვს, როცა საქმეში სერტიფიკატია ჩართული. ჩანაწერი სერვერზე უნდა გადაწყდეს მანამ, სანამ გაცემას სცდი, რადგან შემოწმება იმით მუშაობს, რომ ორგანო თავად უკავშირდება ამ სახელს. შენი დომენი და მისი სერტიფიკატი აღწერს თანმიმდევრობას, ხოლო დომენის მიბმა გეიმ სერვერზე იმავეს აკეთებს თამაშის შემთხვევისთვის. თუ რამდენიმე სერვერს ელოდები, თითოეულს თავიდანვე საკუთარი სახელი მიეცი - ქვედომენები სერვერებისთვის ხსნის, რატომ არის ეს უფრო ადვილი, ვიდრე მისი მოგვიანებით მისადაგება.

ჩანაწერის შემოწმება dig-ითა და nslookup-ით#

არასოდეს ენდო პროვაიდერის ჩანაწერების სიას, როგორც მტკიცებულებას იმისა, რომ ჩანაწერი გამოქვეყნებულია. ჰკითხე resolver-ს.

# მოკლე პასუხი შენი ნაგულისხმევი resolver-იდან$ dig +short A play.example.com203.0.113.10# ჰკითხე კონკრეტულ საჯარო resolver-ს, პროვაიდერის ქეშის გვერდის ავლით$ dig @1.1.1.1 +short A play.example.com# ჰკითხე პირდაპირ ავტორიტეტულ სერვერებს, ყველა ქეშის გამოკლებით$ dig +trace play.example.com$ dig NS example.com +short# სხვა ტიპები$ dig +short MX example.com$ dig +short TXT _dmarc.example.com$ dig +short SRV _minecraft._tcp.play.example.com# TTL ისეთი, როგორიც ახლა არის, ქეშში უკუთვლისას$ dig A play.example.com | grep -A1 'ANSWER SECTION'

Windows-ზე, სადაც dig არ არის, იმავე საქმეს აკეთებს nslookup -type=MX example.com 1.1.1.1, და ბოლოში resolver-ის დასახელება მნიშვნელოვანი ნაწილია. 1.1.1.1-ის პირდაპირ კითხვა გეუბნება, რას ხედავს უცხო ადამიანი; შენი ნაგულისხმევის კითხვა გეუბნება, რა დაიმახსოვრა შენმა როუტერმა.

სრული dig პასუხის სტატუსის ხაზის წაკითხვა ბევრი გამოცნობისგან გიხსნის:

• NOERROR ცარიელი პასუხით ნიშნავს, რომ სახელი არსებობს, მაგრამ ამ ტიპის ჩანაწერი არ აქვს. შექმენი A ჩანაწერი და AAAA იკითხე, ან SRV მოითხოვე სახელზე, რომელსაც მხოლოდ A აქვს.
• NXDOMAIN ნიშნავს, რომ სახელი არ არსებობს. შეცდომა აკრეფაში, ან ზონა ორჯერ მიეწერა, ან უარყოფითი ქეშის ფანჯარაში ხარ.
• SERVFAIL ჩვეულებრივ ნიშნავს გატეხილ ან მიუწვდომელ nameserver-ს, ან DNSSEC-ის შემოწმების წარუმატებლობას. ის თითქმის არასოდეს ნიშნავს, რომ ჩანაწერი არასწორია.
• REFUSED ნიშნავს, რომ სერვერი, რომელსაც ჰკითხე, ავტორიტეტული არ არის და შენთვის რეკურსიას არ გააკეთებს.

საკუთარი ქეშების გასასუფთავებლად, როცა სუფთა ტესტი გჭირდება: ipconfig /flushdns Windows-ზე, sudo dscacheutil -flushcache და შემდეგ sudo killall -HUP mDNSResponder macOS-ზე, და resolvectl flush-caches systemd-ის Linux-ზე. Chrome საკუთარს chrome://net-internals/#dns-ზე ინახავს, სწორედ ამიტომ შეიძლება ბრაუზერი ცდებოდეს მაშინ, როცა ყველაფერი დანარჩენი უკვე სწორია.

რატომ არ ამოქმედდა შენი ცვლილება#

დაახლოებით იმ თანმიმდევრობით, თუ რამდენად ხშირად არის თითოეული პასუხი:

1. რაღაც ისევ ძველ ჩანაწერს იჭერს. შენი resolver, შენი როუტერი, შენი ოპერაციული სისტემა ან შენი ბრაუზერი, იმდენ ხანს, რამდენსაც წინა TTL აძლევდა უფლებას. შეამოწმე 1.1.1.1-თან, რომ სიმართლე ნახო.
2. სახელი ორჯერ მიეწერა. ვებ ინტერფეისების უმეტესობა ფარდობით სახელს იღებს, ამიტომ ჰოსტის ველში play.example.com-ის აკრეფა ქმნის ჩანაწერს play.example.com.example.com-ისთვის. შეხედე არსებულ ჩანაწერს, რომ დაინახო, რომელ კონვენციას იყენებს ფორმა. ეს ჩანაწერების სიაში უხილავია, თუ ყურადღებით არ წაიკითხე.
3. ზონა იმ პროვაიდერთან შეასწორე, რომელიც ავტორიტეტული არ არის. რეგისტრატორთან მითითებული nameserver-ები სხვაგან მიუთითებს, ხშირად იმ ჰოსტინგზე, რომელიც თვეების წინ დატოვე. dig NS example.com ამას ერთ ხაზში არკვევს.
4. უარყოფით ქეშში ხარ. შექმნამდე შეამოწმე, NXDOMAIN მიიღე, და resolver-ს უფლება აქვს, ეს SOA-ს მინიმუმის განმავლობაში ახსოვდეს.
5. ჩანაწერი სწორია და სერვისი გათიშულია. DNS, რომელიც დახურულ პორტზე მიუთითებს, ზუსტად ისე გამოიყურება, როგორც არამომუშავე DNS. პორტი ცალკე შეამოწმე - გეიმ სერვერის პორტები აღწერს, როგორ გააკეთო ეს გარედან.
6. გზაზე proxy დგას. proxy-ს უკან მყოფი ჩანაწერი proxy-ის მისამართს გასცემს და არა შენი სერვერისას, რაც HTTP-სთვის სწორია და ყველაფერი დანარჩენისთვის სასიკვდილო.

რუტინა, რომელიც დაგეგმილ ცვლილებაზე ამ ყველაფერს გვერდს უვლის, მოსაწყენია და მუშაობს: დაწიე TTL ერთი დღით ადრე, დაელოდე ძველის ამოწურვას, შეიტანე ცვლილება, შეამოწმე dig-ით საჯარო resolver-თან და დატოვე ძველი დანიშნულება რამდენიმე საათით ჩართული. სერვერის გადატანა მოთამაშეების დაკარგვის გარეშე შეიცავს დანარჩენს.

FAQ#

რამდენი დრო სჭირდება DNS-ის ცვლილების ამოქმედებას?

შენს პროვაიდერთან - მყისიერად. ყველასთვის, ვინც ეს სახელი უკვე მოიძია - ძველი TTL-ის ხანგრძლივობამდე. სრულიად ახალი სახელი, რომელიც არსად არის ქეშირებული, ჩვეულებრივ წამებში მუშაობს, სწორედ ამიტომ ჩანაწერის შექმნა უფრო სწრაფი გეჩვენება, ვიდრე მისი შეცვლა.

რატომ არ შემიძლია CNAME-ის დაყენება ჩემს root დომენზე?

იმიტომ, რომ სახელს, რომელსაც CNAME აქვს, სხვა ჩანაწერები არ შეიძლება ჰქონდეს, ხოლო ზონის ძირს SOA და NS ჩანაწერები უნდა ჰქონდეს. ამის ნაცვლად გამოიყენე A ჩანაწერი, ან შენი პროვაიდერის ALIAS, ANAME თუ CNAME flattening, თუ მას ასეთი აქვს.

რა განსხვავებაა nameserver-სა და DNS ჩანაწერს შორის?

nameserver-ები ის მანქანებია, რომლებიც შენი დომენის შესახებ კითხვებს პასუხობს და რეგისტრატორთან ყენდება. ჩანაწერები ის პასუხებია, რომლებსაც ისინი გასცემენ და იქმნება იქ, ვინც ამ nameserver-ებს უშვებს. nameserver-ების შეცვლა მთელ ზონას გადააქვს; ჩანაწერის შეცვლა ერთ პასუხს ასწორებს.

მჭირდება MX ჩანაწერი ჩემი გეიმ სერვერისთვის?

არა. MX ჩანაწერები ფოსტისთვისაა და სხვა არაფრისთვის, ხოლო ფოსტა არასოდეს უნდა მიიმართოს გეიმ სერვერზე. თუ გაქვს MX ჩანაწერები, რომლებიც ფოსტის პროვაიდერზე მიუთითებს, ხელი არ ახლო, სანამ სერვერის A ჩანაწერს ცვლი.

რომელი TTL გამოვიყენო?

3600 წამი ჩვეულებრივი მუშაობისთვის, ჩამოწეული 300-მდე დაგეგმილ ცვლილებამდე ერთი დღით ადრე და შემდეგ უკან დაბრუნებული. 60 გამოიყენე მხოლოდ დინამიკური DNS-ისთვის, სადაც მისამართი მართლა იცვლება გაფრთხილების გარეშე.

როგორ შევამოწმო ჩანაწერი ქეშის ლოდინის გარეშე?

ჰკითხე საჯარო resolver-ს სახელით: dig @1.1.1.1 +short A example.com, ან პირდაპირ ავტორიტეტულ სერვერებთან წადი dig +trace-ით. ორივე გვერდს უვლის ყველაფერს, რაც შენს ქსელს დაამახსოვრდა.