ქვედომენები სერვერებისთვის: სახელი თითო სერვერსა და აპზე

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

203.0.113.10:25571-ის დარიგება მუშაობს იმ წუთამდე, სანამ ის არ შეიცვლება. მერე ის ორმოც Discord pin-ში, სამ server-list ჩანაწერში, ვიკის გვერდზე, რომლის რედაქტირებაც აღარავის შეუძლია, და ყოველი შენი მოთამაშის კუნთოვან მეხსიერებაში ცხოვრობს. play.example.com-ის დარიგება კი ნიშნავს, რომ ცვლილება ფორმაში ერთი ხაზია. ქვემოთ აღწერილი ტექნიკა ერთ სახელზე ცოტათი შორსაც მიდის: სახელების ორი ფენა, რომ სერვისის გადატანა და მანქანის გადატანა ორი სხვადასხვა ერთხაზიანი რედაქტირება იყოს.

რა არის სინამდვილეში ქვედომენი#

დომენური სახელი არის წერტილებით გამოყოფილი label-ების სია, რომელიც მარჯვნიდან მარცხნივ იკითხება. com არის ზონა, example.com არის მასში არსებული სახელი, რომელიც რეგისტრატორმა შენ დაგიდელეგირა, და play.example.com არის სახელი იმ ზონაში, რომელსაც ახლა აკონტროლებ. მისი შექმნა არც ყიდვაა და არც რეგისტრაცია. ეს ჩანაწერია შენს ზონის ფაილში და ყველა DNS პროვაიდერი ამისთვის ფორმას გაძლევს.

წესები, რომლებიც ცოდნად ღირს, მოკლეა:

• თითოეული label მაქსიმუმ 63 სიმბოლოა, მთელი სახელი მაქსიმუმ 253. არცერთს არასოდეს მიაღწევ.
• label-ები შეიძლება შეიცავდეს ასოებს, ციფრებს და დეფისებს, მაგრამ არა დეფისით დაწყებას ან დასრულებას.
• სახელები რეგისტრის მიმართ არ არის მგრძნობიარე. Play.Example.com და play.example.com ერთი და იგივე სახელია.
• ქვედა ტირეები hostname-ში დაუშვებელია, მაგრამ განზრახ გამოიყენება service ჩანაწერებში, როგორიცაა _minecraft._tcp.play.example.com. სწორედ ამიტომ გამოიყურება უცნაურად: ისინი hostname-ები არ არის.
• სიღრმე უფასოა. eu.play.example.com არც უფრო ძვირია და არც უფრო ნელი, ვიდრე play.example.com.

ერთი განსხვავება, რომელზეც ადამიანები ებმებიან, არის ჩანაწერის დამატებასა და ზონის დელეგირებას შორის. თუ play-სთვის A ჩანაწერს დაამატებ, მასზე შენი DNS პროვაიდერი პასუხობს. თუ play-სთვის NS ჩანაწერებს დაამატებ, play.example.com-ის მთელი შიგთავსი და ყველაფერი მის ქვემოთ სხვისი nameserver-ებისთვის გადაგიცია და ამ სახელებზე შენი საკუთარი ჩანაწერები აღარ გამოიყენება. დელეგირება არის სახელების ქვეხის სხვა გუნდისთვის ან სხვა პროვაიდერისთვის გადასაცემად. სერვერის სახელის უკან დასადგმელად შენ ჩანაწერი გჭირდება. Nameserver-ები თუ DNS ჩანაწერები ამ განსხვავების უფრო გრძელ ვერსიას შეიცავს და ღირს მისი წაკითხვა, სანამ დომენს პროვაიდერებს შორის გადაიტან.

სახელების სქემა, რომელიც სამ სერვერს უძლებს#

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

გამოიყენე ორი ფენა. მანქანის სახელები ინახავს მისამართებს, სერვისის სახელები მანქანის სახელებზე მიუთითებს.

; layer 1 - one name per machine, the only place an address appearsde01        300  IN  A      203.0.113.10de02        300  IN  A      203.0.113.11; layer 2 - one name per service, pointing at a machineplay        300  IN  CNAME  de01.example.com.creative    300  IN  CNAME  de01.example.com.api         300  IN  CNAME  de02.example.com.

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

თავად სახელებზე ათი წამით დაფიქრება ღირს, რადგან მოთამაშეები მათ აკრეფენ და ხმამაღლა ამბობენ:

დაარქვი სახელი სერვისს და არა პროგრამას. play გადარჩება იმ დღეს, როცა Paper-იდან რაღაც სხვაზე გადახვალ; paper.example.com - ვერა. აარიდე თავი ვერსიის ნომრებს და new--ს, რადგან new-play.example.com ორი წლის შემდეგაც ისევ ასე იწოდება. შეინარჩუნე მოკლე და ხმამაღლა თქმისას ცალსახა: ადამიანები მას ერთმანეთს voice chat-ში წაუკითხავენ და mc ყოველთვის სჯობს minecraft-survival-01-ს.

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

ჩანაწერის შექმნა შენს DNS პროვაიდერთან#

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

1. დაადასტურე, რომელი პროვაიდერია ავტორიტეტული. dig +short NS example.com გეტყვის და ეს ერთადერთი პასუხია, რომელსაც მნიშვნელობა აქვს. ჩანაწერების რედაქტირება პანელში, რომელიც ავტორიტეტული არ არის, შუადღის დასაკარგად პოპულარული გზაა.
2. აირჩიე ჩანაწერის ტიპი. A IPv4 მისამართისთვის, AAAA IPv6-ისთვის, CNAME სხვა სახელისთვის. არასოდეს A და CNAME ერთად ერთ სახელზე.
3. შეავსე სახელის ველი იმ ფორმით, რასაც ეს ფორმა ელის. აქ ხდება შეცდომა.
4. დააყენე TTL. 300 მუშაობისას, 3600 როცა ყველაფერი დასტაბილურდება.
5. შეინახე, შემდეგ თავად მოიძიე, სანამ ვინმეს ეტყვი, რომ არსებობს.

ველში სახელის სამი ფორმა გვხვდება. ზოგი ფორმა მხოლოდ label-ს ითხოვს (play), ზოგი სრულ სახელს (play.example.com), რამდენიმე კი ორივეს იღებს. გაარკვიე, რომელი გაქვს, უკვე შექმნილ ჩანაწერზე დახედვით: თუ არსებული www ჩანაწერი host სვეტში www-ს აჩვენებს, ფორმა ფარდობითია და აკრიფე play. თუ www.example.com-ს აჩვენებს, აკრიფე მთლიანად. სრული სახელის ფარდობით ფორმაში აკრეფა გამოიმუშავებს play.example.com.example.com-ს, რაც სრულიად ვალიდური ჩანაწერია სახელისთვის, რომელსაც არავინ მოიძიებს, და არსად არცერთი შეცდომა არ გეტყვის. @ ან ცარიელი ველი შიშველ დომენს ნიშნავს.

რას ვერ ატარებს ქვედომენი#

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

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

ის არ ატარებს პროტოკოლს და გზას. DNS-მა არ იცის, რა არის HTTPS. old.example.com-ის გადამისამართება https://example.com/new-ზე ვებ სერვერის საქმეა და არა ჩანაწერის - იხილე www თუ apex დომენი და გადამისამართებები.

`CNAME` სხვასთან ერთად ერთ სახელზე ვერ დგას. ეს თავდაპირველ სპეციფიკაციაშია და პროვაიდერები მას არათანაბრად აღასრულებენ. თუ play.example.com არის CNAME, მას ერთდროულად დომენის დასადასტურებელი TXT ჩანაწერიც ვერ ექნება და მისი დამატება ან უარყოფილი იქნება, ან ჩუმად დააზიანებს CNAME-ს. ეს ასევე მიზეზია, რის გამოც CNAME apex-ზე უკანონოა: apex-ს უკვე აქვს NS და SOA ჩანაწერები. პროვაიდერები, რომლებიც თითქოს ამის უფლებას იძლევიან, აკეთებენ ALIAS-ს, ANAME-ს ან CNAME flattening-ს, რაც მათ მხარეს გენერირებული სინთეზური A ჩანაწერია. ეს კარგია და ის CNAME არ არის.

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

Wildcard-ები და როდის ავიცილოთ ისინი#

*.example.com პასუხობს დომენის ქვემოთ ნებისმიერ სახელზე, რომელსაც საკუთარი, უფრო კონკრეტული ჩანაწერი არ აქვს. ის ნამდვილად სასარგებლოა multi-tenant აპისთვის, სადაც ყოველ კლიენტს customer.example.com ეძლევა, და ცუდი იდეაა რამდენიმე სერვერისთვის.

*           300  IN  A      203.0.113.20play        300  IN  CNAME  de01.example.com.

აქ anything.example.com ხვდება 203.0.113.20-ზე, play.example.com კვლავ de01-ზე მიდის, რადგან კონკრეტული ჩანაწერი ყოველთვის იგებს, ხოლო example.com თავად საერთოდ არ ემთხვევა - wildcard apex-ზე არასოდეს პასუხობს.

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

Wildcard ასევე ცვლის სერტიფიკატების მუშაობას. *.example.com-ის სერტიფიკატი მხოლოდ იმის შემდეგ გაიცემა, რაც DNS-01 challenge-ით ზონაზე კონტროლს დაამტკიცებ, რაც ნიშნავს DNS პროვაიდერის API ტოკენს, რომელიც სერვერზე დგას. სახელზე გაცემული სერტიფიკატები გაცილებით მარტივ HTTP-01 challenge-ს იყენებს. HTTPS და Let's Encrypt ახსნილი ორივე ვალიდაციის მეთოდს ფარავს.

TTL და მიგრაციის რუტინა, რომელიც მოსაწყენია#

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

არსებობს მეორე ქეში, რომელიც ადამიანებს აწუხებს. როცა სახელი არ არსებობს, უარყოფითი პასუხიც ქეშირდება და მისი ხანგრძლივობა ზონის SOA minimum ველიდან მოდის და არა რომელიმე ჩანაწერიდან. შეამოწმე play.example.com მის შექმნამდე და შენმა resolver-მა შეიძლება ერთი საათის განმავლობაში იმის თქმა გააგრძელოს, რომ ის არ არსებობს, მაშინ როცა ჩანაწერი დგას და სხვებისთვის უნაკლოდ მუშაობს. ნუ შეამოწმებ სახელს, რომელიც ჯერ არ შეგიქმნია.

სერვერის გადატანის რუტინა განზრახ მოსაწყენია:

1. ერთი დღით ადრე, დაწიე TTL სერვისის სახელზე და მის სამიზნეზე 300-მდე.
2. მთლიანად დაელოდე ძველის ამოწურვას, რომ მსოფლიოში ყოველმა ქეშმა მოკლე აიღოს.
3. გადაიტანე სერვისი. შეცვალე ერთი ჩანაწერი, რომელიც მას უთითებს.
4. ძველი სერვერი რამდენიმე საათი ჩართული და ხელმისაწვდომი დატოვე. უკვე მიმდინარე სესიები არაფერს ხელახლა არ წყვეტს და მოძველებული ქეშები მაინც იქ მოვა.
5. თვალი ადევნე ძველი სერვერის კავშირების ჟურნალს. როცა ჩუმდება, გადატანა დასრულებულია.
6. TTL უკან დააყენე 3600-ზე.

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

შემოწმება, სანამ დაარიგებ#

არასოდეს გამოაქვეყნო მისამართი, რომელიც თავად არ გისინჯავს შენი ქსელის გარედან.

$ dig +short CNAME play.example.comde01.example.com.$ dig +short A play.example.com @1.1.1.1203.0.113.10$ dig +short A de01.example.com @8.8.8.8203.0.113.10

resolver-ის პირდაპირ დასახელება მნიშვნელოვანი ნაწილია. 1.1.1.1-ის ან 8.8.8.8-ის კითხვა შენი როუტერისა და პროვაიდერის ქეშირებულს გვერდს უვლის, რითაც არჩევ „ჯერ არ არის გამოქვეყნებული“ „ჯერ არ არის გავრცელებულისგან“. თუ ყველა ქეშის სურათიდან ამოღება გინდა, dig +trace play.example.com root სერვერებიდან ჩამოდის და გიჩვენებს, რას ამბობენ თავად ავტორიტეტული nameserver-ები.

Windows-ზე, სადაც dig დაყენებული არ არის:

nslookup -type=A play.example.com 1.1.1.1

შემდეგ დაამტკიცე, რომ მეორე ბოლოში ვინმე ნამდვილად უსმენს, რადგან სწორი ჩანაწერი დახურულ პორტზე კლიენტის მხრიდან გატეხილი ჩანაწერისგან არ განირჩევა:

$ nc -vz play.example.com 25571Connection to play.example.com 25571 port [tcp/*] succeeded!

PowerShell-ს იმავე საქმისთვის აქვს Test-NetConnection play.example.com -Port 25571. UDP თამაშისთვის შესამოწმებელი ექვივალენტური handshake არ არსებობს, ამიტომ რეალური შემოწმება თავად თამაშის კლიენტია - გეიმ სერვერის პორტები ახსნილი განმარტავს, რატომ შეიძლება UDP სერვისი მუშაობდეს და მაინც მიუწვდომელი იყოს.

ქვედომენები, სერტიფიკატები და proxy სლოტი#

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

RE:NODE-ზე app და web გეგმები reverse-proxy სლოტს შეიცავს. შენი სახელისთვის A ჩანაწერს ამატებ პანელში ნაჩვენებ მისამართზე და სერტიფიკატი ავტომატურად გაიცემა და განახლდება ვადის ამოწურვამდე 21-დღიან ფანჯარაში. რადგან proxy ამყარებს კავშირს შენს აპლიკაციასთან, შენი კოდი proxy-ს კლიენტად ხედავს და ნამდვილი ვიზიტორის მისამართი X-Forwarded-For header-ში მოდის - წაიკითხე ეს header, თუ ლოგავ, rate limit-ს აწესებ ან გეოლოკაციას განსაზღვრავ, თორემ ყველა ვიზიტორი ერთი და იმავე ადამიანს დაემსგავსება. რას აკეთებს reverse proxy მოთხოვნას თანმიმდევრობით გადის, ხოლო დომენის მიმართვა შენს სერვერზე ნაბიჯ-ნაბიჯ ვერსიაა, იმის ჩათვლით, თუ რატომ ვერ გაიცემა ხოლმე სერტიფიკატი.

თითოეულ სახელს საკუთარი ჩანაწერი და საკუთარი სერტიფიკატი სჭირდება, ამიტომ api.example.com და app.example.com ყველაფრის ორი ცალია. ეს ფუნქციაა: ორივე დამოუკიდებლად შეიძლება გადავიდეს, რაც იყო ამ მთელი სავარჯიშოს აზრი.

თამაშის გეგმებს proxy სლოტი არ აქვს და ეს სწორი დიზაინია - HTTP proxy-ს UDP თამაშის ნაკადთან გონივრული არაფერი აქვს გასაკეთებელი. შენი ქვედომენი სერვერის მისამართს პირდაპირ მიუთითებს, პორტი რჩება იმაში, რასაც მოთამაშეები აკრეფენ, ან SRV ჩანაწერში, და პანელი ორივე მნიშვნელობას სერვერის საკუთარ გვერდზე აჩვენებს.

სად იკბინება ქვედომენები#

არცერთი ეს თეორიული არ არის. ყველა ჩვეულებრივია.

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

Proxy-ით გატარებული ჩანაწერი თამაშის ტრაფიკის წინ. Cloudflare-ის ნარინჯისფერი ღრუბელი HTTP-სა და HTTPS-ს proxy-ს უკეთებს. თამაშის პროტოკოლი არცერთია, ამიტომ proxy-თ გატარებული ჩანაწერი მოთამაშეებს აძლევს მისამართს, რომელიც თამაშის კავშირს არასოდეს მიიღებს. ჩანაწერი, რომელსაც თამაშის კლიენტი წყვეტს, უნდა იყოს DNS-only, ანუ ნაცრისფერი ღრუბელი. Cloudflare ვებსაიტებისთვის და გეიმ სერვერებისთვის არის სრული სია იმისა, რასაც ნარინჯისფერი ღრუბელი გაატარებს და რასაც - არა.

საჯარო DNS როგორც შენი ქონების რუკა. db.example.com, staging.example.com და grafana.example.com ყველა საჯაროდ ჩამოთვლადია, ხოლო certificate transparency ჟურნალები აქვეყნებს ყველა სახელს, რომლისთვისაც ოდესმე მოითხოვე სერტიფიკატი. ამაში არაფერია სასიკვდილო, მაგრამ ეს ნიშნავს, რომ სახელი მინიშნებაა, ხოლო რეალური კონტროლი სერვისის წინ მდგარი firewall-ია. თუ მანქანის გარედან ვინმე მონაცემთა ბაზას არ უკავშირდება, მას არც საჯარო ჩანაწერი უნდა ჰქონდეს და არც ღია პორტი - firewall წესები, რომლებსაც ნამდვილად აქვს მნიშვნელობა ფარავს, რომელი პორტები ეკუთვნის ღიას.

ფოსტა. MX ჩანაწერები apex-ზე ცხოვრობს და ქვედომენებს არ გადაეცემა. ფოსტა you@play.example.com-ზე განსხვავებული კონფიგურაციაა you@example.com-ზე ფოსტისგან და არცერთი მათგანი არაფერია, რასაც გეიმ ჰოსტი გაძლევს. ჩვენ ფოსტას არ ვუმასპინძლებთ, ამიტომ ფოსტის ჩანაწერები ყოველთვის იმასთან რჩება, ვინც ამას აკეთებს.

FAQ#

ქვედომენები რამე ღირს?

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

რამდენი ქვედომენი შემიძლია მქონდეს?

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

თამაშის სერვერის სახელი A ჩანაწერი უნდა იყოს თუ CNAME?

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

შეიძლება ქვედომენი პორტს შეიცავდეს, რომ მოთამაშეებს არ მოუწიოთ მისი აკრეფა?

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

რამდენი ხნის შემდეგ იმუშავებს ახალი ქვედომენი?

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