Nameserver-ები და DNS ჩანაწერები: ვინ რას აკონტროლებს

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

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

სამი საქმე და ვინ აკეთებს ხოლმე თითოეულს#

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

როგორ პოულობს ძებნა შენს სერვერს#

როცა ვიზიტორის resolver-ს არაფერი აქვს ქეშში, ის ზემოდან ეშვება ქვემოთ.

1. ის ეკითხება root სერვერს, სად პასუხობენ .com-ზე. Root პასუხობს .com-ის nameserver-ების მისამართებით. ეს ნაწილი დღეობით ქეშირდება.
2. ის ეკითხება `.com` registry სერვერს example.com-ის შესახებ. Registry შენს ვებსაიტს არ იცნობს - მან მხოლოდ დელეგაცია იცის, ანუ NS ჩანაწერების სია, რომელიც შენმა რეგისტრატორმა იქ ჩაწერა. ის პასუხობს referral-ით: "ჰკითხე ns1.dnsprovider.net-ს".
3. ის ეკითხება შენს nameserver-ებს ჩანაწერს, რომელიც მას რეალურად სჭირდებოდა, და იღებს პასუხს მიმაგრებული TTL-ით.
4. ის უკავშირდება მისამართს ამ პასუხში.

მე-2 ნაბიჯიდან ორი რამ გამომდინარეობს, და ღირს მათი დამახსოვრება.

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

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

იმის შეცვლა, სად ცხოვრობს ვებსაიტი#

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

1. დღით ან ორით ადრე შეამცირე იმ ჩანაწერების TTL, რომლებსაც შეცვლი - example.com და www - იმისგან, რაც არის, 300-მდე.
2. მოიყვანე ახალი სერვერი სრულად სამუშაო მდგომარეობაში, რომ საიტს თავის მისამართზე ემსახურებოდეს, სანამ რაიმე DNS მას მიუთითებს.
3. გამოსცადე ის რეალური hostname-ით DNS-ის შეცვლის გარეშე. ან დაამატე ხაზი შენს hosts ფაილში, ან ერთი request-ისთვის აიძულე resolution:

$ curl -I --resolve example.com:443:203.0.113.10 https://example.com/$ curl -I --resolve www.example.com:443:203.0.113.10 https://www.example.com/

1. შეცვალე A ჩანაწერი (და AAAA, თუ გაქვს) ახალ მისამართზე. ყველა სხვა ჩანაწერი ხელუხლებლად დატოვე - განსაკუთრებით MX და ფოსტის ნებისმიერი TXT ჩანაწერი, რადგან მათი შეხება ის გზაა, რომლითაც საიტის მიგრაცია ელფოსტას თან წაიღებს.
2. უყურე ორივე სერვერის access ლოგებს. ტრაფიკი ძველიდან ძველი TTL-ის ხანგრძლივობაზე იცლება.
3. ძველი სერვერი ჩართული დატოვე სულ მცირე ერთი დღით. ზოგი resolver TTL-ებს უგულებელყოფს და ზოგ მომხმარებელს ბრაუზერი კვირაა ღია აქვს.
4. დასრულების შემდეგ TTL ისევ გონივრულ მნიშვნელობამდე ასწიე.

RE:NODE-ზე ეს ახალი მისამართი არის ის, რომელიც app და web გეგმების proxy სლოტშია ნაჩვენები. მიუთითე A ჩანაწერი მასზე და სერტიფიკატი გაიცემა და ავტომატურად განახლდება 21-დღიან ფანჯარაში. ჩვენ დომენებს არ ვარეგისტრირებთ და DNS ზონებს არ ვჰოსტავთ, ამიტომ აქ ზონის რედაქტორი არ არის - ჩანაწერს ქმნი იმ პროვაიდერთან, რომელზეც შენი nameserver-ები მიუთითებს, ჩვენ კი მხოლოდ მისამართს გაძლევთ, რომელზეც უნდა მიუთითოს. დომენის მიმართვა შენს სერვერზე დანარჩენ ინსტრუქციას შეიცავს, ხოლო www თუ apex დომენი და გადამისამართებები განმარტავს, რატომ სჭირდება ორივე სახელს ჩანაწერი და არა ერთს.

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

იმის შეცვლა, ვისთანაა ზონა#

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

1. გამოიტანე მიმდინარე ზონა. უმეტესი პროვაიდერი გთავაზობს ზონის ფაილის ექსპორტს; თუ არა, ხელით ჩამოწერე ყველა ჩანაწერი, MX-ის, ყველა TXT-ის (SPF, DKIM selector-ები, DMARC, დომენის დადასტურებები) და ყველა ქვედომენის ჩათვლით. დადასტურების TXT ჩანაწერები, რომლებიც არავის ახსოვს, რომ დაამატა, ჩვეულებრივი მსხვერპლია.
2. სრულად ხელახლა შექმენი ზონა ახალ პროვაიდერთან. ჯერ ნუ გადართავ.
3. პირდაპირ ჰკითხე ახალ nameserver-ებს და შეადარე პასუხები ძველებს, ჩანაწერ-ჩანაწერ:

$ dig @ns1.newprovider.net example.com A +short$ dig @ns1.newprovider.net example.com MX +short$ dig @ns1.newprovider.net _dmarc.example.com TXT +short

1. შეამოწმე DNSSEC. თუ დომენი ხელმოწერილია, registry-ში არის DS ჩანაწერი შენი მიმდინარე პროვაიდერის გასაღებით. Nameserver-ების გადატანა მისი დამუშავების გარეშე ვალიდაციის resolver-ებს გატეხილ ჯაჭვს აძლევს და ისინი SERVFAIL-ს აბრუნებენ - ეს არ არის "ნელი გავრცელება", ეს არის შენი დომენის მიუწვდომლობა ინტერნეტის დიდი ნაწილისთვის. ან მოხსენი DS ჩანაწერი რეგისტრატორთან და დაელოდე მის TTL-ს გადართვამდე, ან გააკეთე სათანადო multi-signer rollover, თუ ორივე პროვაიდერი მხარს უჭერს.
2. შეცვალე nameserver-ები რეგისტრატორთან. ეს ერთადერთი ნაბიჯია, რომელიც იქ ხდება.
3. დატოვე ძველი ზონა ადგილზე, უცვლელი, სულ მცირე ერთი კვირით. Resolver-ები, რომლებმაც ძველი დელეგაცია დაიმახსოვრეს, ძველ nameserver-ებს ეკითხებიან, და სანამ ისინი სწორად პასუხობენ, არავინ არაფერს ამჩნევს.

ფანჯარა, სადაც ორივე nameserver-ების ნაკრები თამაშშია, ზუსტად იმიტომაა, რომ მე-2 ნაბიჯს მნიშვნელობა აქვს: თუ ორივე ერთნაირად პასუხობს, გადართვა უხილავია. თუ განსხვავდებიან, ზოგი ვიზიტორი ერთ პასუხს იღებს, ზოგი მეორეს, ისეთი კანონზომიერებით, რომლის დებაგიც არ შეიძლება.

იმის შეცვლა, ვისგან ქირაობ სახელს#

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

ნაბიჯები ყველა რეგისტრატორთან იგივეა .com-ის, .net-ისა და .org-ისთვის:

1. გახსენი დომენი - registry სტატუსი clientTransferProhibited უნდა მოიხსნას.
2. დარწმუნდი, რომ registrant-ის ელფოსტა, რომელიც ფაილზეა, ისეთია, რომელსაც კითხულობ, რადგან დადასტურება იქ მიდის.
3. აიღე ავტორიზაციის კოდი, რომელსაც ზოგჯერ EPP კოდს ან auth კოდს ეძახიან.
4. დაიწყე გადატანა ახალ რეგისტრატორთან და გადაიხადე. უმეტესი ზოგადი დომენისთვის გადატანა რეგისტრაციას ერთ წელს ამატებს.
5. დაადასტურე. თუ არავინ არაფერს დააჭერს, დასრულებას ხუთ დღემდე შეიძლება დასჭირდეს, რადგან დამკარგავ რეგისტრატორს იმდენი დრო აქვს მოსაქმედებლად.

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

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

დელეგაციის საკუთარი თვალით წაკითხვა#

ყველაფერს გარედან ხედავ, რაც ნიშნავს, რომ არასოდეს მოგიწევს გამოცნობა, ვისი პანელი გახსნა.

# What the registry says: the authoritative nameservers$ dig NS example.com +short# What the zone itself says, asked of one of those nameservers$ dig @ns1.dnsprovider.net NS example.com +short# The whole walk, root to answer$ dig +trace example.com# Serial numbers from each nameserver, to see if they agree$ dig @ns1.dnsprovider.net SOA example.com +short$ dig @ns2.dnsprovider.net SOA example.com +short

Windows-ზე, სადაც dig დაყენებული არ არის, PowerShell იგივე საქმეს აკეთებს:

Resolve-DnsName example.com -Type NS -Server 8.8.8.8Resolve-DnsName www.example.com -Type A -Server 1.1.1.1

whois example.com აჩვენებს რეგისტრატორის სახელსა და nameserver-ებს, როგორც registry-შია ჩაწერილი, რაც საბოლოო პასუხია კითხვაზე "სად შევცვალო ეს". თუ whois და dig NS განსხვავდებიან, ცვლილება შუა გზაზეა და ქეშს უყურებ.

SOA serial-ის შედარება ამათგან ყველაზე ნაკლებად გამოყენებულია. ზონის ყოველი nameserver ერთსა და იმავე serial-ს უნდა აცხადებდეს. ორი სხვადასხვა serial ნიშნავს, რომ ერთ-ერთს შენი ბოლო ცვლილება არ აუღია, და თუ ჩანაწერს დებაგავ, რომელიც "ზოგჯერ მუშაობს", ეს არის მიზეზი.

Vanity nameserver-ები და glue ჩანაწერები#

თუ საკუთარი დომენის სახელის მქონე nameserver-ებს უშვებ - ns1.example.com, რომელიც example.com-ს ემსახურება - არსებობს bootstrap პრობლემა. ns1.example.com-ის საპოვნელად resolver-მა example.com-ის nameserver-ებს უნდა ჰკითხოს, რაც ზუსტად ის არის, რასაც ეძებდა. პასუხი არის glue ჩანაწერი: nameserver-ის A ჩანაწერი, რომელიც registry-ში ინახება დელეგაციის გვერდით, რომ referral მისამართს თან ატარებდეს.

Glue რეგისტრატორთან იქმნება, ჩვეულებრივ სათაურის ქვეშ, როგორიცაა "register a nameserver" ან "host records", და ის შენს ზონაში მყოფი A ჩანაწერისგან ცალკეა. ორივე უნდა არსებობდეს და ორივე უნდა ემთხვეოდეს. თუ vanity nameserver-ის მისამართს შეცვლი და მხოლოდ ზონას განაახლებ, glue resolver-ებს ძველ მანქანაზე აგზავნის და იღებ პერიოდულ ჩავარდნებს, რომლებიც შენთვის პირადად სწორდება, რადგან შენს resolver-ს შემთხვევით ზონის საკუთარი პასუხი აქვს ქეშში.

თუ კონკრეტული მიზეზი არ გაქვს - ჰოსტინგის ბრენდი ან პოლიტიკა იმის შესახებ, რომელი სახელები ჩანს whois-ში - vanity nameserver-ები დამატებითი ჩავარდნის რეჟიმის ღირსი არ არის. გამოიყენე შენი DNS პროვაიდერის სახელები.

სად უშლის ხელს ეს#

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

Lame დელეგაცია. NS ჩანაწერები მიუთითებს nameserver-ზე, რომელიც ზონას არ ემსახურება - ჩვეულებრივ პროვაიდერის ნარჩენი, რომლისთვისაც გადახდა შეწყვიტე. Resolver-ები მას ცდილობენ, იღებენ REFUSED-ს და სხვებზე გადადიან, ამიტომ საიტი მუშაობს, მაგრამ ყოველი lookup უფრო ნელია და ზოგი resolver საერთოდ თმობს. წაშალე nameserver-ები, რომლებსაც აღარ იყენებ.

ფოსტა დაიკარგა ვებსაიტის გადატანისას. MX ჩანაწერი და SPF TXT ჩანაწერი არასწორად შეიქმნა, ან საერთოდ არ შექმნილა, როცა ზონა ახალ პროვაიდერთან თავიდან აშენდა. ფოსტის ჩავარდნები შენს მხარეს ჩუმია - გამგზავნები bounce-ს იღებენ, შენ - არაფერს. ზონის ნებისმიერი გადატანის შემდეგ მაშინვე შეამოწმე MX და ყველა mail TXT ჩანაწერი; SPF, DKIM და DMARC ახსნილი ჩამოთვლის, რომლებს უნდა დაეძებო.

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

TTL, რომელიც არასოდეს დაწეულა. ჩანაწერი 24-საათიანი TTL-ით, რომელიც 09:00-ზე შეიცვალა, მომდევნო დღის 08:00-ზეც ძველ პასუხს ემსახურება ყველას, ვინც ამასობაში იკითხა. სხვისი resolver-ების გასუფთავება არ შეიძლება. დაგეგმე ეს ან წინასწარ დაწიე.

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

FAQ#

მჭირდება nameserver-ების შეცვლა ჩემი ვებსაიტის გადასატანად?

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

შეიძლება ჩემი რეგისტრატორი და DNS პროვაიდერი სხვადასხვა კომპანია იყოს?

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

რამდენ ხანს გრძელდება nameserver-ის ცვლილება?

.com-სა და უმეტეს gTLD-ზე 48 საათამდე, რადგან ეს არის TTL დელეგაციაზე, რომელსაც registry გასცემს. პრაქტიკაში ხშირად გაცილებით სწრაფია, მაგრამ ვერ შეამცირებ და ძველი ზონა არ უნდა წაშალო, სანამ სრული ფანჯარა არ გავა.

რატომ მუშაობს ჩემი DNS ცვლილება ჩემთან და არა ყველასთან?

იმიტომ, რომ შენმა resolver-მა ახალი პასუხი აიღო, მათი კი ჯერ ძველი TTL-ის შიგნითაა. გამოცადე dig @8.8.8.8-ით და dig @1.1.1.1-ით შენი resolver-ის გარდა, და შეადარე SOA serial-ი შენს nameserver-ებზე, ხომ არ დარჩა ერთ-ერთი უბრალოდ განუახლებელი.

რა ემართება ჩემს ელფოსტას, თუ ვებ ჰოსტს შევცვლი?

არაფერი, სანამ მხოლოდ ვებსაიტის A ჩანაწერს ცვლი. MX ჩანაწერები და mail TXT ჩანაწერები იმავე ზონის ცალკე ჩანაწერებია, და ფოსტა იმ მისამართზე მიეწოდება, რასაც MX ამბობს. პრობლემა მხოლოდ მაშინ ჩნდება, როცა ზონა ნულიდან აიგება ახალ DNS პროვაიდერთან და ეს ჩანაწერები დავიწყებულია.

აძლევს RE:NODE nameserver-ებს ან არეგისტრირებს დომენებს?

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